Hacker News Reader

Comment by zie | Hacker News Reader

So a server that's dedicated to well-supported(by nixos) services running NixOS is awesome. it's easy to upgrade every 6 months and generally very painless. Everything else is a PITA though. Of course if you use an LTS like Debian Stable or Ubuntu, you only have to upgrade every 5-ish years, so unless you always need the latest and greatest release of something, it maybe isn't worth the hassle.

Trying to hack on other people's junk with NixOS is just asking for pain. Just use Ubuntu LTS like everyone else. That's generally easy and painless.

View on HN

"Trying to hack on other people's junk with NixOS is just asking for pain."

To me that's a large part of the very definition of a useful general purpose OS is that it's flexible and enables you to do whatever you need to do today, without the developers having previously somehow planned and provided for exactly that thing.

It's like the systemd argument all over. The exact thing systemd aims to prevent is the exact thing that made the original unix so powerful and useful that 40 years after architecting it, it still worked because they didn't try to think of every possibility, they gave you a toolbox that let you do whatever you might need to do. Where systemd sees a shell script as "unmanaged chaos" I see "unconstrained utiliy", a useful toolbox including a saw that doesn't have it's own opinions about me what boards I can cut.

If "Trying to hack on other people's junk with NixOS is just asking for pain." that is basically the definition of "this is not a useful operating system that empowers me to get things done". It's useful maybe as a crafted firmware for a static device.

(Not saying that nixos inflexibility is driven by the same paternal "we'll give you the whitelist of actions Poettering thinks are valid" attitude as systemd. In nixos it's merely a natural consequence of indirection and layering. They aren't trying to remove any agency from the user/admin, it's just the simple indirection itself that makes pre-planned and standardized things easier at the expense of anything direct and unplanned becoming harder.

Like instead of having an OS that may or may not be driven by ansible, let's replace the OS with just ansible, and now there is no way to do anything any other way except by figuring out how to write a playbook to do it.)

> To me that's a large part of the very definition of a useful general purpose OS is that it's flexible and enables you to do whatever you need to do today,

NixOS gains most of its power from restrictions. These restrictions enable awesome things like starting a shell with all dependencies in seconds versus minutes using alternative technologies (used by great effect by replit). Nix works surprisingly well for most software, but anything with a ton of dynamic dependencies is going to cause issues. Even knowing what the dependencies might be statically can be hard. Sure, providing an OS with no restrictions and complete flexibility is an option, but then you'll just end up no better off.

Whatever the future of operating systems will be, it certainly will involve more restrictions and less flexibility.

Not to be too presumptuous, but you sound like someone would might like Gentoo. It still works without systemd, though it does install sys-apps/systemd-utils (mostly for the /dev FS stuff). I'd say the focus of Gentoo is on "managing choice", and it is true that some choices can make your system(s) diverge from the most frequent instances floating around (but those tend to be systemd-based these days). It's still pretty decent, though. I've been incrementally upgrading the same basic install since Jan, 2007. Of course, you may already know all about it and have other opinions.

Safe presumtion. I never used it for real but for instance I like freebsd and the ports system, prefer macports to brew etc.

> Trying to hack on other people's junk with NixOS is just asking for pain.

Yeah, but being that Nix is essentially a giant wrapper for the system, that kind of goes without saying. The other side of the coin is that, using other people's Nix junk is extremely easy. Far easier than what any other distro could hope to achieve.

My favorite example is simple-nixos-mailserver. Try passing someone a dovecot, postfix, and openssh configurations/instructions in any other distro and see how long it takes before they mess up, or more likely, give up.

Whereas with simple-nixos-mailserver, you're guaranteed to get something to work, essentially right out of the box.

agreed. Like I said, if what you want to do is within NixOS's well supported wheelhouse, it's great to have a fully declarative OS, that includes application configuration.

LTS is harming the industry and holding everything back! IMO it is the wrong direction.

Why do you think that? That seems like a pretty extreme viewpoint to me.

Stability is a great thing for busy professionals that want stuff to just work.

How many apps have you upgraded that have crashed and burned from the update? Me, a lot. both commercial and OSS. With OSS at least you get all the pieces so you can figure out how to put it back together again. With Commercial, you rollback, file a bug report and hope someone somewhere in the company will be incentivized enough to fix it for you.

To mitigate breakages we should be aiming for better test coverage, at various build levels: class, package, program, system.

Our industry's story for system-level testing, for Linux distributions, is poor. NixOS tests are decent, but need more coverage, and something similar needs to be available to upstream so issues are caught during development.

Meanwhile, LTS releases have downsides:

* Alienating you from upstream: why contribute upstream if you'll only benefit from them in 2 years.

* Having to support stable versions makes refactoring harder. Developers don't want stable to be too different, lest backporting becomes too tricky.

* Maintenance costs is sunk, compared to if we can make rolling release reliable (see above re tests, and easy rollbacks).

https://abseil.io/about/philosophy#we-recommend-that-you-cho... is the same idea but from Google C++ team.

If your software is in such heavy development that you need changes all the time, it should never be in a stable distro to begin with, it's not stable code.

Overall(last I checked), the testing is roughly equal between the stable distro's(Debian/Ubuntu/etc) and NixOS. The difference is stable distro's back-port bug-fixes. NixOS rarely does, since their release cycle is only 6 months long.

> * Alienating you from upstream: why contribute upstream if you'll only benefit from them in 2 years.

I contribute upstream, regardless of if I'm running NixOS, Debian Stable or Windows. It makes no difference to me which OS I'm running when a bug shows up. If I find a bug in X package, I go fix X package. Sure I also fix it locally in my running instance(s), but that's my problem, regardless of which OS I'm running.

> To mitigate breakages we should be aiming for better test coverage, at various build levels: class, package, program, system.

Yes, yes we should. Most software has a terrible testing story. There are very few pieces of software with robust testing. SQLite is one such. One could probably name a handful of others, but after that the list gets really hard to add to.

> If your software is in such heavy development that you need changes all the time, it should never be in a stable distro to begin with, it's not stable code.

Stable code by this definition experiences some stagnation. But the cost of stagnation is worth it for the stability. That's LTS.

Slowly, we'll build enough checks that we can achieve frequent change and still be stable. This is partially here, and "unevenly distributed".

> Overall(last I checked), the testing is roughly equal between the stable distro's(Debian/Ubuntu/etc) and NixOS. The difference is stable distro's back-port bug-fixes. NixOS rarely does, since their release cycle is only 6 months long.

NixOS has system-wide tests that run on PRs, and go green if they pass. E.g. upgrade OpenSSH will trigger a suite of VMs to start, each running OpenSSH in different configurations, and checking they work as expected. These run automatically, are visible to contributors/reviewers, and take O(minutes) to complete. They run on automated backport PRs too.

> contribute upstream, regardless of if I'm running NixOS, Debian Stable or Windows. It makes no difference to me which OS I'm running when a bug shows up. If I find a bug in X package, I go fix X package. Sure I also fix it locally in my running instance(s), but that's my problem, regardless of which OS I'm running.

Bravo. But I don't think it's controversial to suggest that, on average, the closer a person is to upstream version, the more likely they will be to have the motivation and success in making a contribution that meets theirs and and upstream's needs.

> NixOS has system-wide tests that run on PRs, and go green if they pass. E.g. upgrade OpenSSH will trigger a suite of VMs to start, each running OpenSSH in different configurations, and checking they work as expected. These run automatically, are visible to contributors/reviewers, and take O(minutes) to complete. They run on automated backport PRs too.

That concept is not new to stable distro's either. Though the OpenSSH package doesn't do that level of testing in Debian, their tests are here: https://salsa.debian.org/ssh-team/openssh/-/tree/master/debi...

> Bravo. But I don't think it's controversial to suggest that, on average, the closer a person is to upstream version, the more likely they will be to have the motivation and success in making a contribution that works you and upstream.

This mindset makes no sense to me. A bug is a bug is a bug.

Those Debian tests are great. Good coverage, run on PRs. A little obtuse in parts, but still great.

agreed.

Reply on news.ycombinator.com