Dark_Arc

joined 2 years ago
MODERATOR OF
[–] Dark_Arc@social.packetloss.gg 3 points 1 month ago (2 children)

That's interesting; I find the git CLI pretty intuitive especially for basic use cases most people would need, but I've also used git for 15 years now.

[–] Dark_Arc@social.packetloss.gg 17 points 1 month ago (4 children)

git is genuinely one of the best tools ever created. It is an extremely simple idea with crazy effectiveness and a reasonable UX that is a bit off putting at first but makes a lot of sense later on.

That said, I'd genuinely be curious what you think jj has improved upon git.

I hate that rentable but not self-hostable gaming servers have become a thing.

I'm skeptical that enough games run on arm to make that work.

[–] Dark_Arc@social.packetloss.gg 4 points 1 month ago* (last edited 1 month ago)

"Unused road" is ridiculous except in extremes. Unless people merge well over a mile back, 1 lane of traffic will make no difference. The only way "unused road" matters is for the people that haven't entered the traffic jam yet who are getting off before they reach it.

Very few people (from what I've seen) merge more than 30 car lengths out. 30 cars is not going to make a difference.

What does make a difference is the fact that we can't do a merge at speed because some people want to "zipper late." It's the zipper behavior that matters, the "at the very end" part never should've been added to that recommendation.

Looking at an actual research paper about this, the zipper merge demonstrated is not at the last possible point. A merge point forms ahead of that point and that's what should be used. The pictures from their study show the zipper occurring over a wide area with many of the zipped cars driving in the middle.

https://rosap.ntl.bts.gov/view/dot/35694

I don't know how studies like this have become the recommendations we have. They seem to me to miss critical bits.

Edit: based on my quick read, it's worth noting the study finds only minimal support for the zipper merge and only in contexts not involving trucks largely based on visual analysis from their video feed as the quantitative data was not statistically significant. We need better transparency on recommendations like this frankly and the research supporting them. We should be able to have an honest debate on the merits of the papers.

[–] Dark_Arc@social.packetloss.gg 7 points 1 month ago (1 children)

I really like the idea of peertube, but until it finds a way to pay creators I'm not sure it will ever be able to replace YouTube.

YouTube is as good as it is because people get paid.

The old school YouTubers just did it for fun, but YouTube was a lot different back then ... and as much as I hate how aggressively Google is monetizing YouTube these days, it's honestly a lot higher quality than it was years ago.

[–] Dark_Arc@social.packetloss.gg 2 points 1 month ago* (last edited 1 month ago) (1 children)

The problem with zipper merges as this person describes them is a zipper merge is SUPPOSED TO get traffic back up to speed. However, when your take on the zipper merge is "up there where the wreck is at the last possible spot I can merge" there's no time for a human to safely merge at speed. So everything has to continue at a crawl.

So the people jumping out of their lane and "zipper merging" at the last second instead of 50 feet out or so end up making things worse for everyone.

The zipper does not and should not be at the point of the physical problem on the road. Just like you should not just drive to the end of the on ramp and at the last possible second merge into the lane on your left without paying attention.

[–] Dark_Arc@social.packetloss.gg 4 points 1 month ago (2 children)

I really can't more strongly disagree with this take.

Zipper merging is to interleave two lanes of traffic when there's one lane of traffic available ahead.

It DOES NOT matter if it's done with 3 feet to merge or 300 feet to merge. There's no efficiency gain.

What does matter is some assholes trying to merge at speed at the last possible second.

The zipper point should not be the point where there's NO ROOM to merge SAFELY without EVERYONE going 3 miles per hour.

The handful of times I've seen a zipper merge actually start to work, someone rushes down to the end of the line where the problem is, nearly causes a second accident trying to get over, and then everything starts moving at a crawl again.

You don't need to zipper merge at the "physical barrier" causing the zipper merge to be necessary.

[–] Dark_Arc@social.packetloss.gg 5 points 1 month ago (1 children)

Why would a car alarm be a problem...?

Every place I've ever been, they take the keys and drive it into the garage to do any work they're doing.

Car alarm should only be relevant if the mechanic locks the car, no?

[–] Dark_Arc@social.packetloss.gg 4 points 1 month ago* (last edited 1 month ago)

I think it's fine to have an opinion, just qualify it with "I've not been in that situation before, but ... I think bla ... because bla."

It's just about being honest.

[–] Dark_Arc@social.packetloss.gg 5 points 1 month ago (1 children)

I had a friend who's latest and greatest dating advice was to go back and hangout at the college I graduated from (at the time already) several years ago.

I thought it was an incredibly disingenuous and creepy suggestion.

Him and his partner were like "it's totally fine..."

Not a single female friend disagreed with me that, that would be very creepy and I absolutely should not do that.

He got mad that I would never listen to his (terrible) dating advice.

I'm surprised wheat buns aren't more popular. If they're good, they add their own charming character to a burger

 

I thought this was a nice summary. I haven't been on in a while so I haven't seen the changes first hand. How are folks liking them?

 

Hi all,

I'm visiting a relative that has a Google WiFi system with multiple access points. There's an access point literally right next to me that I can see in the KDE BSSID list with 100% connection strength.

For some reason, it's instead picking a BSSID with only 60% strength. Does anyone have any thoughts on why it's choosing this access point instead of one of the others? Is this something the Google WiFi controls/suggests to the laptop, is something bugged, or is there a good reason Linux might be choosing this particular access point?

EDIT: It turns out the access point placement was actually just really bad, and the access point in question was not even making it to the rest of the LAN... The speed difference between my phone and laptop seems to be just that, something to do with a difference between the framework and the Pixel's wireless cards (or drivers). Even with everything corrected, the Pixel is significantly out performing the framework.

 

(A catch up post ... the bot was broken by my instance upgrading to Lemmy 1.19, fixed now!)

 

(A catch up post ... the bot was broken by my instance upgrading to Lemmy 1.19, fixed now!)

 

(A catch up post ... the bot was broken by my instance upgrading to Lemmy 1.19, fixed now!)

 

(A catch up post ... the bot was broken by my instance upgrading to Lemmy 1.19, fixed now!)

view more: ‹ prev next ›