upvote
I think the reasonable argument is not old thing is better ( like some people make, but it has its own problems that are usually because of it trying to do everything.

My main issues stem from it's prevalence in server Distro's especially for micro service images.

D-bus is one of the great offenders for me and I don't like having it on even my desktop system but systemd wants it for many things and some things will just break without it. On a small micro service image, it would be nice to be able to strip lots of it down but systemd fights you on this because of the amount of moving parts and interconnected subs-sytems it introduces.

reply
I concur. My main pain point is the size and aggressiveness of the whole "subsystem". I compare it to Sys-V init, because it's the best example I have used until systemd.
reply
I have been finding myself more and more reaching for alpine linux and have liked openrc.

I am a nixos user so have to use systemd on nixos and that makes it very painful, but I can see myself moving away nixos as my host machines os for many reasons but systemd and the painful way nixos uses it is a big one.

reply
I'm using Debian for more than I like to admit, and I'm entwined with the project somewhat, considering what I do as a work, and how much I like Debian as a whole, distro-hopping looks a bit distant, and I'm not very keen on leaving Debian as an ecosystem considering what's possible at the distro level.
reply
Could you elaborate on the reasons for considering moving away from NixOS? :) I like it in principle, but my main issue is that if you filter out the package activity from the repository, the actual core contribution is low. At least in comparison, and if you filter out the ones with a few one off commits, the actual primary contributors are just a handful so to speak. I worry that, since there are so few who truly understands the internals, if something happens to them, things may go more awry than expected ... or something like that. It's been a few years since I last checked the project. There's also that, at the time, pull requests were growing much faster than being closed or merged, not sure if that's still the case? So very curious to hear. :)
reply
> Could you elaborate on the reasons for considering moving away from NixOS?

Sure I also don't want to take away from what nix and even NixOS does do well, it is a great project and has many great ideas.

Also not sure you are aware (I think you probably are but I will state it any way) Nix != NixOS, and to complicate things further Nix it's self has many parts, it's a build system, a language, a package manager, enviornment profile manager (think like what python venv's provide) and kind of what ever you can make it do.

I will say Nix as a tool is a fantastic thing to have around and now with AI the wrangling and learning can become less painful but it does allow you to do a lot of cool things. Building Deterministically Deterministically building environments, integration tests/ setting up environments for such tests, more easily managing multiple possible builds for a project (well easier then wrangling make files or what ever directly and does provide nicer abstractions (not pain free) for building code). If nothing else give nix a try for building your next project and see what you think, very nice for setting up your dev env as well.

Personally I use something called flakes which is a way of managing a project and pinning it's deps. And this is one of the points things will break down and you will understand some of the issues. flakes are supported and used by many but also many reject them and the tooling is just kind of their and breaks some bits of nix. This aspect of different competing community standards is very very common in the nix world and is one of the major pain points.

> I worry that, since there are so few who truly understands the internals.

I have not filter it in that way but, I am not sure the issue lies with the lack of knowledge of the internals but nix seems to complicate things... a lot.

You have the nix daemon and nix store. Until you have good working knowledge of how nix works (not necessarily knowing the code I have only glanced at the internals of daemon and such and the more important aspect is actually the code written in the nix language generally). Don't touch store directly including trying to copy files manually between stores and such the daemon keeps a sql database of the entries and other things about the nix store means you should not directly touch it until you understand this and it's not intuitive or made to be understood easily.

>NixOS? Finally NixOS it's self is great especially at the start and once you get it but the whole idea is declarative configs and well I know have spent lots of time fighting this and while it does have escape hatches they can be obscure and confusing and error prone. An example of this might be something like llama-swap module, you configure your modules in nix and llama-swap will module will configure a systemd unit for you once enable it which sounds great but in truth you probably want to do things outside the config and make ad-hoc changes and you can set it up so all this is possible but you end up finding your self avoiding a lot of the declarative features and having to edit your config then build it and push it every time for things that are small can be very annoying.

The thing is though you can generally just tell it to use a path to your config or give it a config or even not cofigure a systemd unit at all, but many of these things stack up and you find your self fighting it a lot of the time. The default will have things like a firewall unit that pushes some 'useful' firewall rules that block listening and such and works with declarative configs to enable particular ports which is good, but if you don't know that you might spend a bit of time wondering what the hell is going on.

I would say if you still interested look first at nix tooling and nix and if you want to dip into the operating system you will understand a lot more about why things are the way they are and if you are someone who is finding they want to make a lot of quick ad-hoc changes to the system in question nix can get very annoying. The language is not great and difficult to learn, the main issue is that it's not typed and a lot of the features and right way to do things is arcane and occult, AI will help learning all this a lot though and bare in mind it's a lazy functional language.

Alpine for me is looking more attractive to build my host system on and still use nixos for some dev vms and other vms I use and configure Alpine in a well defined way but still lets me quickly hack a bash script into something. Again you can use nix it's self on any distro and even mac and windows (I think).

reply
This is not a good comparison because even Windows 2000's service model is better than SysV.
reply
It doesn't have to replace the cron, resolver, time synchronization, system logs, bootloader, home folder management, all of the disk encryption, TPM, signing, users, and a whole lot to manage services.

I can understand the frustrations with Sys-V init scripts, but on the other hand, I never had a problem with that both as a sysadmin and a distribution developer.

To be honest, loginctl allowed us to pull some hacks, but to be fair, that hacks were to handle bad behavior from a very bad codebase. Any self-respecting development team wouldn't have written anything which needed OS/kernel level reaping to clean from system correctly.

We have been chatting recently, and someone who's more experienced than me said that they have never seen Nixie's cron to die spontaneously in the last 30 years. systemd's timers not only did that, the systemd didn't bother to restart it. Ironic, considering that the biggest feature of systemd is service supervision and unattended recovery.

reply
But isn't that the point of it having many parts? You don't have to use all of them.

I'm not that much of a sysadmin, but as a Linux user and home lab owner, I definitely prefer the integrated systemd solution. At least I can be certain that the interactions between the components are known and tested. If you instead throw together loads of KISS tools in the old UNIX style, all your tools might be individually correct but their interaction is just bad.

reply
The problem is, these parts sometimes are forced upon you, creating rugpulls. You update your system, and tada! something has changed without you even notice, and that might be something you have relied on for a decade or more.

Learning new things is not a problem, but now I have to adapt into that thing and it might not even perform the same, and a fallback might not be possible. Opening a great can of worms you didn't want in the most unpleasant time.

One of the problems with integrated solutions is how much glue code they contain to handle these interactions. KISS tools talk over sockets, via very simple protocols. i.e. they shout each other over mountains using well defined horns and the voices they use are distinct and simple. Less glue code, simpler codebases, more robust tools.

KISS, Everything is a File, Send conservatively but receive generously are three pillars of what makes *NIXen robust systems. If that interconnectedness and meshing of things were robust, we wouldn't have made Windows a laughing stock for its crashes and security problems.

Tell me, how can a WMF or cursor file can infiltrate a whole OS? How can not you print without installing half of the desktop or literally can't have a terminal only Windows Server system? Because everything is connected and they can't be separated anymore.

These "tools thrown together in a bucket in haphazard manner" have kept systems running for literal years between reboots because they talked over these simple sockets. Heck, many good Linux servers die not because of software, but hardware failure.

And I respect Linux because this is still true despite systemd today.

reply
> At least I can be certain that the interactions between the components are known and tested.

Oh good _lord_ you absolutely cannot. It has been my professional experience that Systemd Project is fractally complex, most of that complexity is accidental, and approximately no one on the project is interested in investigating and fixing the intermittent-but-showstopping problems that arise from that accidental fractal complexity. [0]

Poettering and crew really built the project a fantastic escape hatch with their whole "Your usecase is legacy and we're not supporting it." attitude.

[0] The mess of tools in the Systemd Project work fine until they very suddenly do not, and then the best you can do is bodge a workaround because you're very unlikely to ever get a fix for your problem. The folks that staff the project simply don't have the attitude required to work on and maintain a ever-more-sprawling project that aims to be _the_ userspace thing atop which every Linux distribution is built. "That's hard to fix/do. I don't care that you've had a working system for 10+ years, I'm not fixing the thing that's broken for you." is an absolutely unacceptable attitude for folks involved with such a project to have. [1]

[1] If the project was a little take-it-or-leave-it side project, that attitude would be entirely acceptable... encouraged, even! But because of the position in which the project willingly and aggressively put itself into, it's not a little side project.

reply
> It doesn't have to replace the cron, resolver, time synchronization, system logs, bootloader, home folder management, all of the disk encryption, TPM, signing, users, and a whole lot to manage services.

All of those components you mentioned have improved my linux experience on both servers, desktops and mobile clients.

reply
On the other hand, I have seen no improvements and some regressions.

So, experiences differ, apparently.

reply
There is no one thing a modern operating system should be. Requirements differ and for many systems you do in fact not need to cover more than in 1970's Unix.
reply
But what about muh swarms of containers running microservices written with python or JS, using just 350MB per container on my K8S cluster?

Just wanted to take a jab. Feel free to downvote. =]

reply