In what ways do you feel Rust is too clunky and how do you think it could be improved? Not looking to argue or even disagree necessarily; I’m just curious where that perspective comes from.

I’m not familiar with the specific install/upgrade process on Gentoo so maybe I’m missing something, but what’s wrong with forcing new installations to use time64 and then forcing existing installs to do some kind of offline migration from a live disk a decade or so down the line? I feel like it’s probably somewhat uncommon for an installation of any distro to be used continuously for that amount of time (at least in a desktop context), and if anyone could be expected to be able to handle a manual intervention like this, it’s long-time Gentoo users.

The bonus of this would be that it wouldn’t be necessary to introduce a new lib* folder - the entire system either uses time64 or it doesn’t. Maybe this still wouldn’t be possible though depending on how source packages are distributed; like I said I dont really know Gentoo.

The fact remains that Arch generally requires more work to maintain an installation than a typical point-release distro. I’m speaking from experience - I had two systems running Arch for over 2 years. I switched away when each system separately had a pacman update somehow get interrupted resulting in a borked install. I was using Mint before and Fedora now, and both are a lot more hands-off at the cost of some flexibility.

Also, just to be clear, I’m not trying to disparage Arch at all. I think it’s a really cool distro that’s perfect for a certain type of user; I just don’t think it’s great to lead people to believe it’s more reliable than it is in the way that I’ve been seeing online for a while now.

I hate when people insist that Arch isn’t easier to break. There was an incident a couple of years ago where a Grub update was rolled out that required that grub-mkconfig be re-run manually, and if you failed to do this the system would brick and you’d need to fix it in a recovery environment. This happened to my laptop while I was on vacation, and while I had luckily had the foresight to bring a flash drive full of ISOs, it was a real pain to fix.

Yes, Arch offers a lot more stability than people give it credit for, but it’s still less reliable than the popular point-release distros like Fedora or Ubuntu, and there’s not really any way around that with a rolling-release model. As someone who is at a point in life where I don’t always have the time nor energy to deal with random breakage (however infrequently), having the extra peace of mind is nice.

I mean, technically there’s nothing preventing that, but in practice it’s a fairly uncommon mistake to make and it’s immediately obvious that there’s an issue the first time that path is taken. If something like that makes it to production, it clearly points to an issue with test coverage rather than code paradigm.

Heartbleed was the result of an accidental buffer overread bug, not a backdoor.

Fair warning, you do lose access to some offline AI features like improved voice dictation and song recognition as well as Google Pay. I’m okay with the tradeoff personally but it is still a downside.

SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0 my brother.

continue is useful as a loop analog to early return in a function context, which helps keep indentation/nested conditionals under control and in turn improves code readability.

To Valve’s credit, since that post they did implement base station power management and some DEs now implement Wayland’s DRM leasing protocol, and there’s a somewhat buggy async reproduction implementation in place (although it’s broken in SteamVR 2.0 onwards).

The parent comment is not correct. The Index paired with SteamVR on Linux has a plethora of issues and sometimes doesn’t work at all. It’s usually possible to get it working through some combination of switching SteamVR versions and rebooting, but it’s never a guarantee and usually takes a good chunk of time to get sorted when it’s being temperamental.

It most certainly is not. Besides the missing features mentioned by the other commenter, SteamVR 2.1 literally shipped last week with a bug that caused it to completely stop functioning on Linux. I think the hotfix version still isn’t in the release channel. There’s another bug still present in 2.1.7 that prevents VR games from starting. SteamVR Home doesn’t work at all anymore.

2.0 had an issue where vrdashboard was using the wrong pixel format which caused the red and blue channels to be swapped (pretty sure that made it into the release channel), and there was a regression introduced in the last year (and is still yet to be fixed) that causes vrdashboard to be rendered to the controller instead of the battery indicator. Granted, these are more minor issues, but it shows the level of QA that goes into the Linux version (next to none).

I’m approaching the point where I’m seriously considering buying a spare drive for a Windows install exclusively for VR. I’m currently dealing with 3 separate serious issues with SteamVR on Linux, one of which I sometimes can’t even work around depending on how it’s feeling that day. Not to mention, every new release lately seems to introduce a new problem.

I haven’t had a Windows install on my system since my previous SSD died 2 or 3 years ago, but it’s getting to the point where it’s more trouble than it’s worth.

Just as a note, I believe you still need to tick the “Enable Steam Play for all titles” in Steam settings to allow it to be used with non-verified games.

I don’t think I’ve ever felt the urge to apply an alignment chart to monospace fonts of all things, but Xenon and Radon are basically lawful and chaotic evil respectively.

Nope, different product with almost the exact same name lol.

As another user mentioned, package managers are specific to distributions rather than DEs. The main difference between them is that they’re developed by the respective distribution teams, but there are some practical differences too. For example, apt supports versioned dependencies while pacman doesn’t because of the different distribution models between Debian and Arch (monolithic vs. rolling release). This affects their dependency resolution strategy with each being better suited for it’s respective distribution.

To address your point about package managers being the main difference between distros, this isn’t quite true. As mentioned, different distros have different distribution models, priorities, and overall biases/opinions that affect the user experience in a variety of ways and make them better suited to different use cases. I would never dream of putting Arch on one of my servers in the same way that you’d probably never catch me installing Debian on my gaming machine.

Nah, I did this once and didn’t notice until the call was placed because I was a little tipsy and engaged in conversation. IIRC it didn’t make any noise since my phone is always on vibrate, it just buzzed a bit and by the time I processed what was happening it was too late and I had to explain to the dispatcher that no, I was just fidgeting with my phone.

This article seems to be outdated as both apps are now visible in the Play Store and I had no problems downloading and running them. A comment suggests that it may be due to the previous minimum SDK target for the apps being too low. I’d be willing to chalk this up to being more innocuous than active malice on Google’s part.