While I do get your sentiment, we currently see in Ukraine what happens if you don’t have a defense industry: You’re reliant on other countries to supply you in case a hostile nation notices that you’re lacking it.

All that follows is my personal opinion, but for ease of writing, I’m gonna present it as facts.

Once you have grasped the advantage that Nix offers, all the fundamentally different solutions just seem s o inferior. When I first tried NixOS on a decommissioned notebook, the concept immediately made sense. Granted, I didn’t understand the language features very well – I mostly used it for static configuration with most stuff just written verbatim in configuration.nix, though I did use flakes very early on because of Lanzaboote. But just the fact that you had a central configuration in a single language that was able to cross-reference itself across different parts of the system absolutely blew me out of the water. I was a very happy and content Arch user, even proficient enough to run my own online repository that built from a clean chroot for AUR packages (if you use Arch with AUR packages on multiple systems, check out the awesome aurutils!), but after seeing the power of NixOS in action, I switched over all my machines as soon as I could - desktop, virtual servers (thanks nixos-anywhere!), main notebook and NAS.

People often praise the BSDs for their integrated approach – NixOS manages to bring that approach to Linux. Apart from GUIX System that I never tried because Secure Boot was a requirement when I last looked at other distributions, none of them have tackled the problem that NixOS solves, and it’s not even certain if they actually understand it. Conceptually, it plays on a whole different level. No more unrecoverable systems, even with broken kernels – just boot the previous configuration. Want to try changes without any commitment? nixos-rebuild test got you. Need an app quick? nix shell nixpkgs#app it is.

Plus the ecosystem is just fantastic. The aforementioned nixos-anywhere really helps with remote provisioning, using disko to declaratively setup filesystems and mounts, you have devenv which is a really good solution for development environments, both regarding reproducibility and features, and many more that I can’t mention here. There is nothing comparable, and the possibilities are unlike in any other ecosystem.

It’s not perfect for sure though, and documentation is sparse. The language concepts which allow one to “unlock” the most powerful features are different from what most people know.

I was lucky enough to have some downtime at work to get into the system a bit deeper (this was still for work though, just not my core skillset) by implementing a “framework” for our needs which forced me to not just copy and paste stuff, though I definitely did get inspired from other solutions, but to actually better understand the module system (I think?), thinking in attribute sets, writing your own actual modules, function library and so on. But in the end, it was definitely worth it, and I’m unaware of any other system that would allow what Nix and NixOS allowed me to build.

NixOS […] some packages are kinda old

Fair

that server will be going back to debian next summer.

I don’t think that will solve the “some packages are kinda old” issue.

I have full IPv6, none of my ports that I haven’t explicitly whitelisted in the firewall can be accessed from the Internet. I can open a host completely, but it’s not default. This is on the most common brand of consumer routers here.

Just because it’s not NATted doesn’t mean there’s no firewall in place.

My router will still block all ports not explicitly allowed for the hosts regardless of protocol, it’s a firewall after all and not just NAT. Just because the host addressable doesn’t mean its ports are reachable.

Testing is actually mandatory, what’s not mandatory though is to do it before deploying.

what’s feurking

An optional step in the développement process

Emacs? When there’s ed? Talk about bloat…

Could be the kernel itself

Wouldn’t make sense to me because the thread says GNU/Linux and others, though this could relate to Android or distros not using any GNU.

gnupg

Usually not exposed to the network though, but it’s generally a mess so wouldn’t be too surprising

Another candidate I have in mind is ntpd, but again that is usually not easily accessible from outside and not used everywhere, as stuff like systemd-timesyncd exists.

Just want to stress that I’m not sure about it being OpenSSH, it was more supposed to be a fun guess than a certain prediction

Since this affects Linux and others, I’m guessing this is about OpenSSH. But I’m not very certain. Just can’t think of another candidate.

But holy sh, if your software has been running on everything for the last 20 years

This doesn’t sound like glibc as someone in the thread guessed.

I, a systems guy, have a better time learning go than nix packages.

Go is a simple and elegant imperative language (that does come with its downsides); Nix the DSL is a functional language which requires a different way of thinking. Systems usually are operated imperatively, so it’s normal that you’d find it easier.

It’s not an easy language at all and one might ask if another one wouldn’t do the job better, which is what Guix System kind of explores, but its (nix) design goals make a lot of sense.

NTSYNC is one example, I don’t know what the current progress is https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/

It was supposed to be in 6.10, I don’t know if that actually happened

deleted by creator

For most network share I use /mnt/$server.

I use /mnt/$proto/$server, though that level of organization was probably overkill. Whatever…

I do /volumX for additional hard drives.

A good first approximation.

So where in this setup would you mount a network share? Or am additional hard drive for storage? The latter is neither removable nor temporary. Also /run is quite more than what this makes it seem (e.g. user mounts can be located there), there is practically only one system path for executables (/usr/bin)…

Not saying that the graphic is inherently wrong or bad, but one shouldn’t think it’s the end all be all.

The title says “bcachefs-tools”, the linked kernel thread that the comment referred to was about the bcachefs kernel part and did not touch the bcachefs userspace tools. Debian says they can’t package with these pinned dependencies and explains why. Kent says relaxing dependencies breaks the programs.

The only hint at the other topic I see is this:

(not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit)

I guess this is about https://www.reddit.com/r/bcachefs/comments/1em2vzf/psa_avoid_debian/, and while I think the title is too broad, the actual message is

If you’re running bcachefs, you’ll want to be on a more modern distro - or building bcachefs-tools yourself.

I don’t consider Kent’s reasoning (also further down the thread) a rant - it might not be the most diplomatic, but he’s not the only one who has problems with Debian’s processes. The xscreensaver developer is another one for similar reasons.

I think, in fairness, bcachefs and Debian currently aren’t a good fit. bcachefs is also in the kernel so users can rest it and report, but it wasn’t meant to be stable; it’s meant to not lose data unrecoverably.

Anyhow, while I think that he’s also not the easiest person on the LKML, I don’t consider him ranting there; and with the author’s and my judgement differing in these points, I’m led to believe that we might also disagree on what qualifies as hostile.

Lastly, while I’m not a big fan of how Rust packaging works, it ensures that the program is built exactly the same on the developer’s and other machines (for users and distributors); it is somewhat ironic to see Debian complain about it, since they do understand the importance of reproducibility.

You must have missed the last half of the post then. Especially the last two paragraphs.

There’s isn’t much more to that issue than that sentence, while all other paragraphs cover the packaging. It’s tangential at best.

The OP is about packaging issues with userspace utilities due to version pinning in Rust. It’s an issue with Rust in general. Kent is not obligated to lock dependencies in any particular fashion. He could loosen the dependencies, but there is no obligation, and Debian has no obligation to package it.

This is different from the thread you linked in which the bcachefs kernel code and the submission process is discussed, and on which there was a thread here as well in the last days. But your criticism, as valid as it is, only applies there, not in a thread about tooling packaging issue.

Which is a completely different issue than what the post is about, hence my question

Submitting something that is generally problematic and yelling about how it will EVENTUALLY be good is a good way to get your shit tossed out.

What are you hinting at regarding this specific news?