For many systems out there, /bin and /lib are no longer a thing. Instead, they are just a link to /usr/bin and /usr/lib. And for some systems even /sbin has been merged with /bin (in turn linked to /usr/bin).

Not just Linux… 99% of the time you see something weird in the computing world, the reason is going to be “because history.”

The C developers are the ones with the ageist mindset.

The Rust developers certainly are not the ones raising the point “C has always worked, so why should we use another language?” which ignores the objective advantages of Rust and is solely leaning on C being the older language.

They very rarely have memory and threading issues

It’s always the “rarely” that gets you. A program that doesn’t crash is awesome, a program that crashes consistently is easy to debug (and most likely would be caught during development anyway), but a program that crashes only once a week? Wooo boy.

People vastly underestimate the value Rust brings by ensuring the same class of bugs will never happen.

It really depends.

If I know I will never open the file in the terminal or batch process it in someways, I will name it using Common Case: “Cool Filename.odt”.

Anything besides that, snake case. Preferably prefixed with current date: “20240901_cool_filename”

People back then just grossly underestimated how big computing was going to be.

The human brain is not built to predict exponential growths!

I don’t think the battery argument is convincing enough to me unfortunately, since it’s more likely that the recent increase in battery capacity is due to battery chemistry improvements rather than increased physical size.

I mean, I have two similar sized phones from different eras. One had 3000mAh, another had 5000mAh. They both include a headphone jack.

I am trying to. My current phone has a headphone jack. But I fear that the possibility of getting a high-end phone with a headphone jack is diminishing.

I don’t see how the jack can make a phone less appealing? 99% of the time you’ll be looking at the screen, you’re not going to see the headphone jack.

Though, perhaps it’s because of lifestyle differences between countries (I am not American), I simply cannot imagine not using the 3.5mm jack ever. I am still using AUX on my car radio.

I am not so sure about the waterproofability of headphone jacks, but does it benefit to make phones even “thinner and lighter”?

I still don’t quite get why some people are defending manufacturers which remove the headphone jack on their phones…

3.5mm jacks don’t cost much materially. Removing it doesn’t bring any benefit at all, and you are forced to buy a bluetooth headphone or a Type-C-to-3.5mm dongle on top of that.

This also explains why VPN is a possible workaround to this issue.

Your VPN will encapsulate any packets that your phone will send out inside a new packet (its contents encrypted), and this new packet is the one actually being sent out to the internet. What TTL does this new packet have? You guessed it, 64. From the ISP’s perspective, this packet is no different than any other packets sent directly from your phone.

BUT, not all phones will pass tethered packets to the VPN client – they directly send those out to the internet. Mine does this! In this case, TTL-based tracking will still work. And some phones seem to have other methods to inform the ISP that the data is tethered, in which case the VPN workaround may possibly fail.

Not sure if it’s still the case today, but back then cellular ISPs could tell you are tethering by looking at the TTL (time to live) value of your packets.

Basically, a packet starts with a TTL of 64 usually. After each hop (e.g. from your phone to the ISP’s devices) the TTL is decremented, becoming 63, then 62, and so on. The main purpose of TTL is to prevent packets from lingering in the network forever, by dropping the packet if its TTL reaches zero. Most packets reach their destinations within 20 hops anyway, so a TTL of 64 is plenty enough.

Back to the topic. What happens when the ISP receives a packet with a TTL value less than expected, like 61 instead of 62? It realizes that your packet must have gone through an additional hop, for example when it hopped from your laptop onto your phone, hence the data must be tethered.

If I remember right, the syncing issue was particularly egregious when you run windowed X11 programs on Wayland. So it could be that you got lucky.

It’s the explicit sync protocol.

The TL;DR is basically: everyone else has supported implicit sync for ages, but Nvidia doesn’t. So now everyone is designing an explicit sync Wayland protocol to accommodate for this issue.

You need to enable DRM KMS on Nvidia.

Mine is simply default KDE. The only visible thing I’ve changed is the wallpaper – changes to my desktop mostly concentrate on the “invisible” ones like shortcut keys or setting changes or scripting.

Desktop? I settled on Arch and Fedora.

Server? Debian. Although technically I never distrohopped on servers, been using Debian since the beginning of time.

Ackshually you still can blame Windows for not supporting live updates.

There are times when the original standard has zero forwards compatibility in it, such that any improvement made to it necessarily creates a new standard.

And then there’s also times when old greybeards simply disregard the improved standard because they are too used to the classic way.