While I am not a fan of Nix the language, it is no more insane than ansible or kubernetes yaml soups.

As for packages… nixpkgs is by far the largest repo of packaged software. There are very few things I haven’t found there - and they are usually not in any other distro either.

I switched to NixOS because I wanted a declarative system that isnt’t yaml soup bolted onto a genetic distro.

By 2022, my desktop system was an unmanagable mess. It was a direct descendant of the Debian I installed in 1997. Migrated piece by piece, even switched architectures (multiple times! I386->ppc-i386->amd64), but its roots remained firmly in 1997. It was an unsalvagable mess.

My server, although much younger, also showed signs of accumulating junk, even though it was ansible-managed.

I tried documenting my systems, but it was a pain to maintain. With NixOS, due to it being declarative, I was able to write my configuration in a literate programming style. That helps immensely in keeping my system sane. It also makes debugging easy.

On top of that, with stuff like Impermanence, my backups are super simple: btrfs snapshot of /persist, exclude a few things, ship it to backup. Done. And my systems always have a freshly installed feel! Because they are! Every boot, they’re pretty much rebuilt from the booted config + persisted data.

In short, declarative NixOS + literate style config gave me superpowers.

Oh, and nixos’s packaging story is much more convenient than Debian’s (and I say that as an ex-DD, who used to be intimately familiar with debian packaging).

SuSE in 1996. Then Debian between mid-1997 and late 2023, NixOS since.

I’m not a big distrohopper…

I do, yes. I’d love to use it, because I like Scheme a whole lot more than Nix (I hate Nix, the language), but Guix suffers from a few shortcomings that make it unsuitable for my needs:

• There’s no systemd. This is a deal breaker, because I built plenty of stuff on top of systemd, and have no desire to switch to anything else, unless it supports all the things I use systemd for (Shepherd does not).
• There’s a lot less packages, and what they have, are usually more out of date than on nixpkgs.
• Being a GNU project, using non-free software is a tad awkward (I can live with this, there isn’t much non-free software I use, and the few I do, I can take care of myself).
• Last time I checked, they used an e-mail based patch workflow, and that’s not something I’m willing to deal with. Not a big deal, because I don’t need to be able to contribute - but it would be nice if I could, if I wanted to. (I don’t contribute to nixpkgs either, but due to political reasons, not technical ones - Guix would be the opposite). If they move to Codeberg, or their own forge, this will be a solved issue, though.

Before I switched from Debian to NixOS, I experimented with Guix for a good few months, and ultimately decided to go with NixOS instead, despite not liking Nix. Guix’s shortcomings were just too severe for my use cases.

NixOS, because:

• I can have my entire system be declaratively configured, and not as a yaml soup bolted onto a random distro.
• I can trivially separate the OS, and the data (thanks, impermanence)
• it has a buttload of packages and integration modules
• it is mostly reproducible

All of these combined means my backups are simple (just snapshot /persist, with a few dirs excluded, and restic them to N places) and reliable. The systems all have that newly installed feel, because there is zero cruft accumulating.

And with the declarative config being tangled out from a literate Org Roam garden, I have tremendous, and up to date documentation too. Declarative config + literate programmung work really well together, amg give me immense power.

NixOS.

It is good for everything, if you invest a little time^[1] into it.

If any repository that you use, or are interested in, is hosted on a commercial, for-profit service (even if it has a free tier), back it up. It will, eventually, disappear.

Considering the amount of CVEs the kernel puts out, I’d argue there’s plenty there that’s broken, and could be fixed by implementing them in a language less broken than C.

TLDR: Is it normal to distro hop after being using a distro perfectly for so long?

I have used the same distribution (Debian) for over 20 years when I decided to change distributions and switch to NixOS. Debian was - and still is - a very fine distribution. I just needed something radically different.

So, to answer your question: yes, it is perfectly normal. Two years isn’t even long.

If they have no desire to maintain/sysadmin their own linux systems, then the best distro to recommend is whatever you can help them with, and possibly even maintain for them.

Case in point, my Wife is a very happy NixOS user, despite knowing absolutely nothing about Linux. Yet, she’s on a distribution that’s as far from being newbie friendly as a distro can possibly be. She’s still happy with it, because I set it up for her, and I maintain it for her, she never has to install, upgrade or configure anything, ever.

I’d say “under no circumstances”. When building for production, you want to build on a stable foundation. LFS isn’t that, it’s an educational tool. It does not result in a maintainable, robust system. It requires tremendous amounts of work to keep it secure and updated: there’s no package manager, no repository you can pull from, no nothing. You have to build an entire distribution on your own. Outside of educational purposes, I’m having trouble to imagine any situation where that might be a good idea.

No, not even embedded. There were always distros targetting embedded systems, LFS was never a good choice there either. It was much more straightforward to strip down - say - Debian for a limited device, than to build something from scratch for it. (I spent a few years building and operating embedded Linux systems at the early 2000s, we built it on a stripped down Debian.)

Does the target layer (the number layer) have to be a layer number greater than the starting layer? Number layer is layer 4, and QWERTY is 9 - do I need to move 4 to 10? Is there some other, common, issue I’m encountering?

Yes, you’ll need to move the number layer, to have a higher index than the QWERTY layer. In QMK, layers are index-ordered (see the docs here), no matter the order you activate them. If you activate layer 9 (qwerty) and layer 4 (numpad), then even if you activated layer 4 later, it will still be below layer 9. So any key that is not transparent on 9, will be looked up from 9. Only transparent keys will be looked up from layers below.

My Emacs needed a bootloader.

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

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.

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.