Invent a time machine. Go back in time. Study.

Failing that, learn from your mistakes, and next time… well… study.

Is it by a for-profit company, in year 3190 of our lady Discord?

Then nope, it is not.*

(* some exceptions may apply, not in this case though)

My Emacs needed a bootloader.

I have Emacs, and I have my NixOS configuration. That’s all the GUI system configuration I need.

Lie to myself, and chug another cup of coffee.

In our kids’ elementary school, the rule at the start of year was that kids tell the teacher they have to go, then they simply go. Notifying the teacher is mandatory, 'cos they are responsible for the kids, they need to know where they are.

This was slightly changed since, because of bullies. While the vast majority of kids can go to the bathroom whenever they want, bullies don’t: they can only go alone, or supervised. So if there’s anyone else out, from any class, they have to wait. If it is urgent, a teacher or another adult will go with them, and stand by the door, close enough to intervene if need be.

Both KDE and GNOME are good DEs (and there are many other great ones, and you don’t even need to use a DE; a mismash of applications with your compositor of choice works just aswell - but I digress), you can’t really go wrong with either.

For someone new to Linux, I would likely recommend GNOME, because it is more opinionated. While KDE is a lot more configurable, that also has a huge downside: configuration fatigue. GNOME is more restrictive, yes, but that has the advantage of not overwhelming you right out of the box.

If you like and wish to tinker, though, go with KDE. If you want to gently ease into Linux, go with GNOME first, and once you’re comfortable, you can still experiment with KDE. You can install both, and switch between them simply by logging out of one and into the other.

To add some nuance to the rest of the comments posted here: GPL’d code can be made proprietary, if the copyright holders all agree. For example, given a project that requires copyright assignment, if the project owner decides to take it proprietary, they can do that, because they’re the copyright owner. GPL alone is not enough to keep a codebase FLOSS. Luckily, both the kernel and git have hundreds of copyright owners (and does not require copyright assignment), so legally changing the license of either of them is practically impossible. So, really, Linus wouldn’t be able to take anything, code wise. He could take his future work, yeah, but he hasn’t been doing much development for the past decade.

Otherwise… He let go of git pretty early on, and it’s been maintained by Junio ever since. So nothing would happen there whatsoever, Linus’ retirement (friendly or otherwise) would be inconsequential for git.

The kernel has capable maintainers who have been maintaining stable trees for a long while now (often with companies backing them), and people who have been maintaining large subtrees. There’s a considerable overlap there, too. In short, there are a fair number of people who could fill in for Linus in a pinch. There’d be a small hiccup, and that’s about it. His skills and experience would be missed, but it wouldn’t cause any lasting harm.

My bank app does not function under Graphene, because my bank is doing anything in its power to force using a stock Android. I have friends, who use the same bank, and while the bank app works under Graphene from time to time, it is broken often enough to render it unusable.

But it doesn’t matter, because Graphene does not support my phone anyway. As I wrote: most alternative operating systems for phones support only a very limited set of phones. Mine’s not one of them.

I did that, it did not make my phone experience any better.

On desktop: Linux since late 1996. It is the only operating system that I can perfectly tune to adhere to my - often weird - ideas, and can run all the software I need. I’m a developer, mostly working on free and open source software, so Linux is right there to assist me with that. When I play games, I play them through Wine/Proton, have been since I started gaming on Linux some two decades ago. If a game does not work under Wine/Proton, that’s simply not a game I will be playing.

For portable gaming, I have a Steam Deck. Surprisingly, that also runs Linux.

My phone is running stock Android, and I hate it, because the way I function, and how Android imagines I would are not compatible, and the system does not let me bend it to my will, there isn’t enough flexibility built in. Like… I can’t uninstall a bunch of applications I’m never going to use, because my phone came preinstalled with it, and they’re not removable, unless I jailbreak it. Unfortunately, I can’t jailbreak it, because then my bank’s application would stop working. Which would be fine, since I don’t do banking on the phone. Except the application is required for mandatory 2FA. FML.

Thankfully, I can go days without touching my phone, so I can live with it being a piece of crap.

(The rest of my family is also on Linux: both parents, wife, and eventually the kids too.)

What is stopping someone; say the FSF or some other group championing libre software from coming up with their own web engine completely different from the incumbent engines?

Building a browser engine is hard, especially when the target is moving at a rapid pace, and that target is controlled by Google. Like it or not, the web as it is today, is pretty much driven by Google (and to a lesser extent by Apple and Microsoft) these days. They can throw infinite resources into developing the browser engine and the browser itself. The closest competitor we have today is likely Servo, and they scrape by on pennies.

Developing something from scratch, with even less funding and expertise than Servo is a non-starter. It’s not going to happen. Sure, sure, there’s LadyBird and some other independent efforts, but I very highly doubt they’ll ever catch up to the three major engines.

To develop and maintain a browser, you need people, and they need to be paid. Paying open source developers is… quite a big problem in and of itself, even for things considerably easier and smaller in scale than a web browser.

surely if Web Devs tell them to go pound sand, or intentionally break the site when using Google Chrome, and put a message saying, “Go to Firefox / Safari for a better experience”, that will make Google backtrack.

They would not, because for every developer who would do this, there’s 100 who would not, because their livelihood depends on people with Google browsers being able to use their stuff. Google is in a position of power here: they are the #1 search engine, they are the #1 browser, they’re pretty well positioned on the mobile phone market too. The vast majority of businesses (companies or individuals, doesn’t matter) simply can’t afford to go against Google.

If the vast majority would, then yeah, Google would backtrack. But that would require a coordinated effort, from the vast majority of the internet. Likely multiple months of protest. That’s not going to happen, people can’t afford it.

Again, you’re misunderstanding the problem. Keeping applications up to date is not a problem. Keeping things working the way my family got used to is an entirely different matter, and it’s actually worse on Android & iOS (thus, most phones and tablets).

The main reason the family even has desktop PCs is because we couldn’t make tablets work for them. Something as simple as reading email was a problem, because the various email apps (gmail, k9, etc) changed their UIs, confusing the heck out of my parents. It would’ve been possible to improve that situation, but the tooling to remotely manage an android phone are far more limited than on a bog standard Linux desktop.

A lot of people do use phones tablets as their main computer, yes. Ask them how happy they are about it, how much trouble updates and random UI changes cause. Just because they “can live with it” does not mean they enjoy the experience, or want to live with it. Chances are, they don’t have other options. My family does. I think more people should have those options available to them.

(Also, the blog post is about desktop, specifically, and is a critique of distros trying to aim at non-enthusiasts. When it comes to mobile, those efforts are even more futile, because those specialised distros will have absolutely no chance of working on anything but a very tiny subset of mobile devices.)

I don’t like it. I don’t hate it, but I don’t like it. It’s not flexible enough for what I - and my family - needs from an operating system.

That does not address the problem at all, though. That solves the upgrade and maintenance problem, but does nothing for users who just want things to work as they always did. It does not address change.

By maintaining a system for my family, I can address that: either by undoing things, working them around, or preparing them in advance. No amount of automation will solve that. It’s not a technical problem.

Sadly, no. That doesn’t account for software changing, which is the #1 reason my family hates upgrades, and which is why I manage their systems, so I can either undo a change they don’t want, work it around, or prepare them in advance. No amount of A/B updates and automation helps with this.

I use Rust mostly because I am comfortable working with it. It hits a sweet spot of often letting me write in a functional style, at often zero or very low cost. It has a lot of high quality libraries, for almost any purpose. And the language itself comes with great things too. Traits, Option, and Result are all things I miss when working in other languages like Go.

It’s also a memory safe language that is also fast, approachable, and has a ton of good documentation. What’s not to like?

Anything and everything, really.

I wrote an idle inhibitor in Rust, a GUI WiFi connection manager for my wife, an API client for WriteFreely, I contributed to a Wayland compositor (niri), wrote a library & CLI tools to talk to Kaleidoscope-powered keyboards. I wrote the frontend of my personal search engine in Rust too.

But I also built a Tauri application where the backend and the frontend were written in Rust too. No HTML or JavaScript in sight, not in the sources at least.

Professionally, the answer’s the same: if I am allowed to write it in Rust, I will write it in Rust, whether it is a low-level library that talks with hardware, a GUI application, or some web related thingy, or anything inbetween.

It’s not even the upgrades. Automatic, unattended upgrades have been a thing for a long while, and in general, they work remarkably well. At least in the sense that nothing “breaks”: programs will still work, and start up, and all that.

But automatic upgrades can change things. Change an icon, move things around, change behaviour, introduce new features, new bugs, and so on. That is the hard part of maintenance, not the technical “go from version A.B to A.C”.

Most immutable distros I’ve seen aim at improving the A.B->A.C upgrade scenario. They do very little, if anything at all, to keep the system familiar. Because they can’t, unless they control the entire stack. And even if they do, like in the case of the proposed GNOME OS, the UI still changes - often considerably - between major versions. If I maintain a system for others, I can prepare them in advance. If they do it themselves, they do not have that luxury, they’re not going to follow the development of the software they use, and I wouldn’t expect them to do so either. I can do it, and I am doing it, because I’d be doing it anyway for myself.

I’m supporting three people, only one of them lives with me. My parents live in a different city, pretty far away (far enough that just randomly visiting them for in-person troubleshooting is not an option). I maintain three separate computers for them. It doesn’t take much effort nowadays, because I used a system I am familiar with, a general purpose distribution, and set it up so that I can manage it remotely.

I wouldn’t be able to maintain a more limited system for them, because it would lack the tools I need for remote maintenance. Hence my assertion that distributions focused entirely on non-enthusiasts are a futile attempt.