I’ve been daily driving NixOS for about a year now, switched from over two decades of running Debian. I’ll try to answer your questions from my perspective:

How much can I grok in a week?

If you have some experience with functional programming or declarative configs (think Ansible), then it’s a lot easier. You can definitely learn enough in a week to get started. One year in, my Nix knowledge is very light still, and I get by fine. On the other hand, there’s a lot of Nix I simply don’t use. I don’t write reusable Nix modules, and my NixOS configuration isn’t split into small, well manageable files. It’s a single 3k lines long, 130k sized flake.nix. Mind you, it’s not complete chaos: it is generated from an Org Roam document (literate programming style; my Org Roam files are 1.2mb in size, clocking in at a bit below 10k lines).

With that said, it took me about a month of playing and experimenting with NixOS in a VM casually, a couple of hours a week, to get comfortable and commit to switching. It’s a lot easier once you switched, though.

How quick is it to make a derivation?

For most things, a couple of minutes tops. I found it easier to create derivations than creating Debian packages, and I was a Debian Developer for two decades, had a lot more and lot deeper understanding of Debian packaging practices. It’s not trivial, but it’s also not hard. The first derivation is maybe a bit intimidating, but the 10th is just routine.

Regarding make install & co, you can continue doing that. I use project-specific custom flakes and direnv to easily set up a development environment. That makes development very easy. For installing stuff… I’d still recommend derivations. A simple ./configure && make && make install is usually very easy to write a derivation for. And nixpkgs is huge, chances are, someone already wrote one.

How quick is it to install something new and random?

With a bit of self control and liberal use of direnv & flakes, near instant.

How long do you research a new package for?

https://search.nixos.org/packages, you can search for a package, and you can explore its derivation. The same page also provides search for NixOS options, so you can explore available NixOS modules to help you configure a package.

Can you set up dev environments quickly or do you need to write a ton of configs?

Very easy, with a tiny amount of practice. Liberal use of flakes & direnv, and you’re good to go. I can’t comment much on Python, because I don’t do much Python nowadays, but JavaScript, Go, Rust, C, C++ have been very easy to build dev environments for.

What maintenance ouchies do you run into? How long to rectify?

None so far. If it builds, it usually works. I do need to read release notes for packages I upgrades, but that’s also reasonably easy, because I can simply “diff” the package version between my running system, and the configuration I just built: I can see which packages were upgraded, and can look up their release notes if need be. In short, about the same effort as upgrading Debian was (where I also rarely ran into upgrade/maintenance gotchas).

Do I need to finagle on my own to have /boot encrypted?

If you use the NixOS installer, then yeah, you do have to fiddle with that a bit more than one would like. If you install via other means (eg, build your own flake and use something like nixos-anywhere to install it), then it’s pretty easy and well supported and documented.

Feel free to ask further question, I’m happy to elaborate on my experience so far.

Meson and CMake are the two major players I’ve seen along autotools. Are they better? In some respects, yes (especially Meson, imo), in others… not really. For a pet project that only targets two platforms, I’d just stick to handwritten worst-practices Makefile. You will likely have less trouble with that than any of the others, simply because you know it already.

I think the first thing to figure out would be why udev is getting shut down. Perhaps you could extract its logs? journalctl -b -u systemd-udevd.service should do the trick. This gets you the logs of the current boot’s udevd service.

Once you know why it is shutting down, it will be time to figure out how to stop it from shutting down. That should, hopefully, fix the problem you’re having.

Yeah. But I’m also using a keyboard layout where frequently used keys aren’t on my pinky, and a keyboard where modifiers are on my thumb cluster, rather than on my pinky.

My parents moved to Linux on their own accord: Dad just wanted something that stays the same, and doesn’t try to exploit him, so he’s been a happy Debian & XFCE user for about a decade now; Mom never used Windows, so she’s happy with Debian & GNOME I was a Debian user (and developer) back when they switched to Linux, and Debian is where they stayed. Dad’s in IT, so he can manage both systems fine, most of the time. I need to unfuck it from time to time, when Dad decides it is a good idea to try and install the latest LibreOffice Ubuntu arm64 .deb package on his x86_64 Debian oldstable, throwing whatever --force flags at dpkg he can find, but other than that, they have everything they need, are happy with their choices, and need very little support from me.

In my own household, Linux is the only system to begin with (apart from a handful of Android phones we all hate, and an XBox, which is slowly getting replaced by a Linux mini PC). I’ve been a Linux user since late 1996, and I purposefully only bought hardware that works decently with Linux, so setting up scanners, printers and the like are a breeze.

Wife saw my setup, how I operate it mostly with the keyboard (she hates the mouse more than I do!), wanted the same, so I built her something similar (NixOS + Wayland + niri + firefox + geary). She never had her own computer before, but did use Windows at work from time to time. She didn’t want to use it on her laptop, though. She wanted something tailor built for her, for her very reluctant computer-usage. So Linux it is! She doesn’t hate it, which is the best I can accomplish with anything computer-related when it comes to her. I’m maintaining her laptop, but that too, requires little work. I just update it from time to time. She’s loving that she can send a print job from her laptop, from the living room, to the printer in my work room.

Kids played with both the xbox, and the gaming mini pc I built, and much prefer the latter, because it is easier to navigate, it is faster (using cheaper hardware), it is more stable, so when they’re old enough to get their own computers, they want Linux too, and I shall abide. Luckily, while schools around here are rather windows-oriented, they have to accommodate Linux users too, so the kids will be more than fine with their Linux computers, even for school tasks. Whether they’ll end up maintaining their computers or not remains to be seen. If they want to, I’ll teach them how to.

IT years are similar to dog years, an IT year is multiple normal human years, so 14 IT years is certainly IT decades.

algernon nods sagely

Sadly, that’s not code Linus wrote. Nor one he merged. (It’s from git, copied from rsync, committed by Junio)

There’s plenty, but I do not wish to hijack this thread, so… have a look at the Forgejo 7.0 release notes, the PRs it links to along notable features (and a boatload of bugfixes, many of which aren’t in Gitea). Then compare when (and if) similar features or fixes were implemented in Gitea.

The major difference (apart from governance, and on a technical level) between Gitea and Forgejo is that Forgejo cherry picks from Gitea weekly (being a hard fork doesn’t mean all ties are severed, it means that development happens independently). Gitea does not cherry pick from Forgejo. They could, the license permits it, and it even permits sublicensing, so it’s not an obstacle for Gitea Cloud or Gitea EE, either. They just don’t.

There are no bugs. Just happy little accidental features.

It’s about 5 times longer than previous releases were maintained for, and is an experiment. If there’s a need for a longer term support branch, there will be one. It’s pointless to start maintaining an 5+ year branch with 0 users and a handful of volunteers, none of whom are paid for doing the maintenance.

So yes, in that context, 15 months is long.

A lot of people do. Especially on GitHub, where you can just browse a random repository, find a file you want to change, hit the edit button, and edit it right there in the browser (it does the forking for you behind the scenes). For people unfamiliar with git, that’s huge.

It’s also a great boon when you don’t want to clone the repo locally! For example, when I’m on a slow, metered connection, I have no desire to spend 10+ minutes (and half of my data cap) for a repo to clone, just so I can fix a typo. With the web editor, I can accomplish the same thing with very little network traffic, in about 1 minute.

While normally I prefer the comfort of my Emacs, there are situations where a workflow that happens entirely in the browser is simply more practical.

Yes.

Forgejo has no official Windows builds, and since it is not tested on windows at all, it’s not guaranteed to work.

Fair bias notice: I am a Forgejo contributor.

I switched from Gitea to Forgejo when Forgejo was announced, and it was as simple as changing the binary/docker image. It remains that simple today, and will remain that simple for the foreseeable future, because Forgejo cherry picks most of the changes in Gitea on a weekly basis. Until the codebases diverge, that will remain the case, and Forgejo will remain a drop-in replacement until such time comes that we decide not to pick a feature or change. If you’re not reliant on said feature, it’s still a drop-in replacement. (So far, we have a few things that are implemented differently in Forgejo, but still in a compatible way).

Let me offer a few reasons to switch:

• Forgejo - as of today, and for the foreseeable future - includes everything in Gitea, but with more tests, and more features on top. A few features Forgejo has that Gitea does not:
  • Forgejo makes it possible to have any signed in user edit Wikis (like GitHub), Gitea restricts it to collaborators only. (Forgejo defaults to that too, but the default can be changed). Mind you, this is not in a Forgejo release yet, it will be coming in the next release probably in April.
  • Gitea has support for showing an Action status badge. Forgejo has badges for action statuses, stars, forks, issues, pull requests.
  • …there are numerous other features being developed for Forgejo that will not make it into Gitea unless they cherry pick it (they don’t do that), or reimplement it (wasting a lot of time, and potentially introducing bugs).
• Forgejo puts a lot of effort into testing. Every feature developed for Forgejo needs to have a reasonable amount of tests. Most of the things we cherry pick for Gitea, we write tests for if they don’t have any (we write plenty of tests for stuff originating from Gitea).
• Forgejo is developed in the open, using free tools: we use Forgejo to host the code, issues and releases, Forgejo Actions for CI, and Weblate for translations. Gitea uses GitHub to host the code, issues and releases, uses GitHub CI, and CrowdIn for translations (all of them proprietary platforms).
• Forgejo accepts contributions without requiring copyright assignment, Gitea does not.
• Forgejo routinely cherry picks from Gitea, Gitea does not cherry pick from Forgejo (they do tend to reimplement things we’ve done, though, a huge waste of time if you ask me).
• Forgejo isn’t going anywhere anytime soon, see the sustainability repo. There are people committed to working on it, there are people paid to work on it, and there’s a fairly healthy community around it already.

There’s a very important difference between what you can do with a thing, and what the thing was intended for, and what it is best at doing.

So then a Game Boy is a PC, and so is the SNES, and the SEGA Genesis. Cool, cool, makes perfect sense.

Myself, I think the wikipedia definition is far better than yours.

Yes, it can run all that. You may have to jump through a few hoops (just like in the case of the Steam Deck, just different hoops), but it can run all that.

I’ll also turn your question back to you: how many people use the Steam Deck for productivity, rather than for gaming, which is its intended purpose? And does it matter?

Like it or not, the steam deck is a gaming console, even if you can run non-game stuff on it too. Heck, even stuff like the Game Boy had (official!) accessories like the Game Boy Camera and Game Boy Printer, which were both useful outside of gaming. Does that stop the Game Boy from being a (retro) gaming console? There’s an ongoing project to provide productivity apps for the Game Boy (though, arguably, it did not ship yet, but you can extend the game boy with a cartridge in whatever way you can imagine).

Or, you can use your SNES as a MIDI Synthesizer (https://www.supermidipak.com/)! No modding or anything necessary, it’s just a regular cartridge. Can it be used for fun? Yes. Is it a game? No. You can do a lot of stuff with an SNES cartridge that has nothing to do with gaming. There was even a cartridge that let you play online games on the SNES (https://en.wikipedia.org/wiki/XBAND) - but not only games, it also let you read and write messages to other people. You didn’t need to go into “desktop mode”, nor install a browser, nor do anything special. You plugged in the cartridge, and it worked. It was far less locked down than the XBox or even the Steam Deck! Does that disqualify the SNES (or the game boy) from being a gaming console?

I disagree. It’s a gaming console. It is marketed as such. It’s primary purpose is to run games. By the way, you can browse on the Xbox. And because it has a full-blown browser, you can even use Office365 if you attach a keyboard and a mouse. So lets disqualify that too? :)

Aren’t all consoles like that, though? They all run mainstream operating systems, and are basically locked down PCs in a fancy box. If anything, the Steam Deck is further from a PC than an XBox/PS, due to being handheld, with an embedded screen and controller, while XBox and its friends require a display and an external controller (like a PC).

Steam Deck, because it is handheld, and can run a lot of my Steam games. I can also dock it to a big screen and attach a controller.