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.
If I'm working for someone else (company or otherwise), I'll write comments and docs in whatever language I can speak that they want me to (which pretty much means I write comments in English, because I rarely work for Hungarian companies nowadays, and even the ones I did work for preferred English, and these are the only two human languages I can write :().
When working on my own projects, it is always English, because Hungarian doesn't have good translations for many of the technical terms, so half my comments would be English borrowed words anyway. Might aswell write the rest in English too. Also makes it easier for others to chime in, because there are a whole lot more people speaking English than Hungarian.
It was harder in the beginning, when my command of the English language was far worse, but even then, half-Hungarian/Half-English comments just looked weird, and more jarring than full English, even if that English was kinda bad.
A free account is an easy way to test out the platform, give it a test ride, see if it works for you. If it does, you can pay for a Pro (or Team) subscription, and you get to use your own domain, and keep all the posts you already made on the free account, with all their comments and replies and whatnots.
Or, if it works out, and you want to self host, you can do that, too!
The difference between write.as and medium and other enshittified things, though, is that write.as is not VC funded, and Matt has no interest in making an "exit". Even if there are things I disagree on with him (eg, CLAs), I trust Matt to not enshittify write.as anytime soon. He's been running things for almost a decade now, remarkably well.
It is pretty darn trivial to turn those env vars into a config.ini. But if you don't want to, my writefreely-docker has you covered. It has been used in production for a couple of hundred writefreely blogs over the past few years.
( ͜ₒ ㅅ ͜ ₒ)ლ(´ڡ`ლ)
I think that comes pretty close. Seeing as LLMs seem to avoid the topic of sex and female presenting nipples, I doubt they'd be able to recognise this picture, and thus, it might be a decent way to poison their training set. Sex talk and cursing should also drive a scraper away quickly, but... horny emoji art? That might just get through and poison the training set.
At least if I understood the question correctly, and the goal is to scew with an ML trying to scrape and learn.
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)
That would result in those fediverse servers theoretically requesting 333333 * 114MB = ~38Gigabyte/s.
On the other hand, if the site linked would not serve garbage, and would fit like 1Mb like a normal site, then this would be only ~325mb/s, and while that's still high, it's not the end of the world. If it's a site that actually puts effort into being optimized, and a request fits in ~300kb (still a lot, in my book, for what is essentially a preview, with only tiny parts of the actual content loaded), then we're looking at 95mb/s.
If said site puts effort into making their previews reasonable, and serve ~30kb, then that's 9mb/s. It's 3190 in the Year of Our Lady Discord. A potato can serve that.
...and here I am, running a blog that if it gets 15k hits a second, it won't even bat an eye, and I could run it on a potato. Probably because I don't serve hundreds of megabytes of garbage to visitors. (The preview image is also controllable iirc, so just, like, set it to something reasonably sized.)
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.
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.
Better NixOS integration, less resources used, similar levels of containment. The containers I planned to use don't provide any additional safety than the system services. In many cases, I could harden the system services more. Like, if a container has a /bin/bash in it, it's hard to remove that, while I can pretty easily prevent my systemd service from accessing it.
Like, systemd.services.<name>.confinement is pretty darn strong. If enabled, NixOS will set up a tmpfs-based chroot with just the required runtime store paths for the service. Good luck doing something similar in a container!
I was in similar shoes (my server is running Debian, as it has been for the past two decades), and am going to rebuild it on something else. I chose NixOS, which I recently switched to on my desktop, because it lets me configure the entire system declaratively, even the containers. The major advantage of a declarative configuration is that it will never be out of date.
My main reason for switching is that I've been running the server for a good few years, initially maintained via ansible, but that quickly turned into a hellish bash-in-yaml soup that never quite worked right. So I just made changes directly. And then I forgot why I made a change, or had the same thing copy & pasted all over the place. Today, it's a colossal mess. With NixOS, I can't make such a mess, because the entire system is declared in one single place, my configuration.
Like you, I also planned to use containers for most everything, but... I eventually decided not to. There's basically two things that I will run in a container: Wallabag (because it's not so well integrated into NixOS at the moment), and my Mastodon instance (which runs glitch-soc, which is considerably easier to deploy via the official containers). The rest will run natively. I'll be hardening them via systemd's built-in stuff, which will give me comparable isolation without the overhead of containers. Running things natively helps a lot with declarative configuration too, a nice bonus.
For reference, you can find my (work in progress) server configuration here. It might feel a bit overwhelming at first, because it's written in a literate programming style using org mode & org roam. I found this structure to work great for me, because my configuration is thoroughly documented, both the whys and hows and whats.