Of course there's many more Linux servers out there than there are programmers, but the OS the programmer uses to develop on is just as important as the OS they deploy to.
Nowdays Linux is very stable, you can have things that don't work properly but you won't need a full re-install.
Every time I’ve tried to run a standard Linux distro like Ubuntu for more than a couple of years I inevitably end up breaking something in a way that I can’t recover.
Are you taking snapshots to roll back to?
If you install the newest versions of whatever from random repos or compile stuff yourself you are very likely to mess things up. But nowadays there is very little reason to do that. And you can pick a distro that releases at a pace you are comfortable with, so you have choices.
Usually broken distro upgrades I see are because people run "curl randomdomain.ck/totallysafescript.sh | sudo bash -" to install things or use custom repos.
That `totallysafescript.sh` could at least be inside of the package manager scope. Most of the times someone already did it, and published it to AUR.
IMO the reason why there are so many people running random scripts in Ubuntu/Debian is due to how more difficult/inconvenient it is to get a dpkg .deb when compared to a PKGBUILD file. Same for MacOS, in which you have to either rely on Homebrew wizardry or just running the script
The AUR is still not as good as proper package management and shouldn't be considered a stable or reliable method of software distribution at scale.
I've been running rolling release distros for a decade and never had any problems - you have to follow some software migrations when needed, but I managed to migrate to systemd on Arch without an issue while any dist upgrade on ubuntu was wrecking my system.
It's not a good distro. I don't know why people insist on using it. Notice that the GP said Debian instead. (Probably Stable, because testing and unstable will break within 10 years.)
My gut is that if I was to try and get my 3 monitor setup such that the seams are all pixel aligned, I would be in for a world of pain. I imagine that would be the same for other OSes, as well?
I liken Nix to source control in the time of CVS. We need two more implementation iterations before its going to be useful to the general public.
Such an exaggregation. Many thousands of people use it by choice, despite all alternatives. Hardly a disaster, by any definition.
But among those who do, there are plenty of people who have learned Nix well enough it's no longer a weird arcane thingy that spews out incomprehensible errors for them. Although, I guess, among those no one will deny Nix can be better (but there are no multi-billion-dollar corporations spending tons of their resources on it).
It's like vim. First time you run it you probably can't even exit it - so, of course you think it's a disaster ;)
Is that an aggregation of exaggerations? :p
Actually, that portmanteau kinda-works in this context.
When it works, it’s great. I like that I can install (and uninstall) much of the software I use declaratively, so I always have a “clean” base system that doesn’t accumulate numerous little packages at strange versions over time in the way that most workstations where software is installed more manually tend to do.
This is a trade-off, though. Much is made of the size of the NixOS package repository compared to other distros, but anecdotally I have run into more problems getting a recent version of a popular package installed on my NixOS workstation than I had in probably a decade of running Debian/Ubuntu flavoured distros.
If the version of the package you want isn’t available in the NixOS repo, it can be onerous to install it, because by its nature NixOS doesn’t follow some popular Linux conventions like FHS. Typically, you write and maintain your own Nix package, which often ends up similar to fetching a known version of a package from a trusted source and then following the low-level build-from-source process, but all wrapped up in Nix incantations that may or may not be very well documented, and sometimes with a fair bit of detective work to figure out all the versions and hashes of not just the package you want but also all its dependencies, which may in turn need packaging similarly themselves if you’re unlucky.
It’s also possible to run into this when you’re not installing whole software applications, including those that are available from the NixOS package repository, but rather things like plug-ins for an application or libraries for a programming language. You might end up needing a custom package for the main application so that its plug-in architecture or build system can find the required dependencies in the expected places when you try to install the extra things. Again, this is all complexity and hassle that just doesn’t happen on mainstream Linux distros. If I install Python and then `pip install somepackage` then 99.9% of the time that just works everywhere else but frequently it won’t work out of the box on NixOS.
It’s one of those things that is actually perfectly reasonable given the trade-offs that are explicitly being made, yet still makes NixOS time-consuming and frustrating in a way that other systems simply aren’t when you do run into the limitations.
This comment is already way too long, so I’ll just mention as a footnote that NixOS also tries to reconcile two worlds, and not all Linux software is particularly nicely arranged to be managed declaratively. So in practice, you still end up with some things being done more traditionally/imperatively anyway, and then you have a hybrid system that compromises some of the main benefits of the declarative/immutable pattern. There are tools like Flakes and Home Manager that help to overcome some of this as well, and as others have said, they are promising steps in good directions, but we’re not yet realising the full potential of this declarative style and it’s hard to see how we get from here to there quickly.
I think this is my favourite comment about Nix ever. I'm not going to stop using Nix until a genuinely better alternative arrives, but that day can't come soon enough
Fixing the issue ends up being rather difficult though
A custom GPT have been surprisingly helpful after feeding it manuals for nix, nixpkgs and NixOS and other Linux books.
I can make a nix-shell for each project but then every nix upgrade was forcing me to go through a lengthy reinstall + wrecking compatibility sometimes.
Not to mention the amount of derivations I had to write myself just to use latest packages.
Using things like virtualenv instead of nix-shell can fix the general instability, but packaging is too big of a problem.
I went back to Arch.
Containers, and snapshots+clones are your friend. For a while I was doing ZFS snapshots and clones of Gentoo userlands.
However, if you knew how bad things really are with glibc and how not-well designed Linux is to resist badly behaving software, and how easily some big players can inject badly behaving software into the channels you are fetching from, you would probably seriously consider Qubes.
illumos is a kernel you can rely on to run somewhat arbitrary software.