Sixos: A nix OS without systemd [video]
media.ccc.de
media.ccc.de
> On NixOS, either the initrd "secrets" or the software that decrypts them is stored unencrypted on writable media. Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground... coreboot [loads] an immutable pre-kexec kernel from write-protected SPI flash... authenticate the user, decrypt writeable storage, kexec into the post-exec kernel... The speaker runs ownerbooted sixos on his workstations, servers, twelve routers, stockpile of disposable laptops, and on his company's 24-server/768-core buildfarm.
Yes, it is maybe monolithic (but so is the Linux kernel). Its philosophy may differ from unix's "get one thing done well" too but integration of various functionalities comes with its benefits.
Some people say it is bloated. The substitutes to systemd are lightweight but less featureful. Maybe some of them will get bloated as they achieve feature parity.
People have a right to build substitutes and replacements -- I believe in the "Let a hundred flowers bloom" philosopy. However I can't understand why systemd is the point of so much disagreement.
Nothing makes my life easier than cleaning out crontabs of things that wake my box in the night and find out that something still gets launched. Oh yes, systemd now has timers no one asked for.
Nothing makes my life easier than disabling a service then masking a service then masking it's sockets, then blanking files then chattr +x those files and end up having broken ubuntu instance because there are so many ways to launch a service it's not even funny at this point.
Nothing makes my life easier than finding out multi gigabytes /var/log/journald folder that has exactly zero reasons to exist because text-based logs are still collected and properly rotated in a place where any sane person would expect them to be.
Shall I continue or do you get the gist? :-)
Nothing wrong with this if a system service is going to be present on 99.999% of installs and frees the developer from having to do work.
e.g. GNOME swapped its service manager for subprocesses (e.g. bluetooth) to systemd user units because it does a far better job.
Is there a sign linux installs will hit this metric in our lifetime? I don't think there's any strong indication of this. There are multiple distros devoted to not moving to systemd.
> GNOME swapped its service manager for subprocesses (e.g. bluetooth) to systemd user units because it does a far better job.
Not on computers without systemd it doesn't! Besides, Gnome still runs just fine on systems with init scripts like *BSDs with no visible loss of quality or stability so this was a purely political choice to spite their own linux user base.
Yes and zero have wide spread adoption outside of specific use cases (e.g. Alpine with containers, Android with its.. slop).
As far as base distros go, only RHEL and Debian have any wide spread impact and both use systemd.
> so this was a purely political choice to spite their own linux user base.
It's possible the old system exists as a fallback, but it wouldn't surprise me if its not guaranteed to stay around. People aren't required to support other peoples choices unless you pay them.
This kind attitude will be the death of Linux. In the form of systemd-os.
> a system service is going to be present on 99.999% of installs
It's not, because a large number of users and system administrators dislike it, and don't use it. And the high number it does have is mostly due to distributions forcing it on you - so that you can only remove it by switching distributions altogether.
I like that, because it's so easy to change into systemDOS. AKA Denial Of Service. :-)
Well yes but actually no.
With every new Ubuntu version I have to carve out new metastasis no one asked for. For example, 24.04 (or maybe even 23.10) changed the way sshd is started up - by systemd listener instead of sshd on its own like it was for decades. This way they saved a few megabytes of RAM (solely on computers that are not exposed to the internet, of course).
While fighting against systemd-as-PID1 is futile for many years, fighting against the spread is definitely worth it.
So, please do continue to criticize, continue to raise awareness. That's useful.
That's the thing, that it is quite difficult to vote with your feet. You can't remove systemd from your distribution in favor of separate independent facilities: The combination of its design, its gradual expansion, and the way some higher-level packages depend on it (especially GNOME) - typically prevent its removal.
So, you would need to switch distributions, which most users are not very inclined to do. And - even then, you look around, and you see that the big basic distros: RedHat/Fedora, Debian (and Ubuntu), Arch - use systemd. So almost all of the distributions based on them are also not an option if you want to avoid systemd.
... and the bottom line is that users will effectively not vote with their feet. And neither will system administrators, or whoever maintains OS images at organizations, because it's difficult for them to tell their superiors they want to switch everyone to, say, Slackware, or Devuan.
But overall, I agree on this point. Having been a Gentoo purist during Uni time, I'm now full on NixOS. NixOS has fully abstracted away any interaction I have with SystemD, so I don't think it's useful to replace it.
> monolithic
> It's philosophy may differ from unix's "get one thing done well"
> it is bloated.
Besides all this, the main issue, for me, is how it managed to spread and ingrain itself into distributions making them dependent on it.
If you want to use an alternative to systemd on those distributions, you are usually on your own, constantly trying to fix it whenever there are breaking changes.
It's good to have options which are simple to replace.
> It is chock full of features and it gets the job done.
So is Windows :)
I don't think the phrasing is correct. Your choice of word (spread/ingrain itself) seems to imply there is malicious intent. Software do not sneak itself into distribution by themselves. It is the other way around. Distribution creators have total freedom on what components/software they find useful to build their distributions on. If a majority of distros decided to use systemd, that mean a majority of people maintaining distributions found the positive outcomes of using systemd were worth dealing with any disadvantage it may had over using another solution.
This is overall fairly weak evidence that users actually find the software to be of quality. Surely there's got to be a stronger signal that this is a positive way forward, like users enthusiastically saying "wow this is an improvement".
I find it hard to imagine objective evidence more robust than the real-world actions of subject matter experts who make real-world decisions. This would have been hotly debated within teams of Linux experts at Debian, Ubuntu, Fedora/RHEL, SuSE, and Arch. These aren't armchair experts who debate on the internet, they're the ones who actually make decisions and, more than most, wear the consequences of those decisions.
Who are the users in this case?
There is. Well, sort of.
For example, we had cron working just fine for decades . We had sshd listen on its port for decades. We had fstab for decades. No one wanted systemd-timesyncd.
In my opinion, all these aux systemd projects came to life purely out of psychological reasons. Can we label them malicious?
Which we somehow did not have for the last few decades. I wonder why.
There was a time, in the 1990s, when UNIX heavily leaned into the idea of multiuser multiprocessing. That philosophy is pretty much dead in a world that prioritizes networked systems, Docker images and idempotent deployment. Most Linux boxen are cattle, not pets.
Speak for yourself. Lots of us spent many man-months over years engineering around crusty 80s abstractions that no longer worked.
No, you're right: It's people that do that. And those definitely can have intent (often benevolent, sometimes malicious, other times just so misguided as to be in-effect-malicious).
So let's go with "the main issue is how some people managed to spread and ingrain it into distributions making them dependent on it."
Does that make it much better?
Also, the core of systemd is not even particularly big. People often mix into completely optional modules that run under the wider systemd project, but that's a false conclusion that "systemd eats the world".
> How it managed to spread
You mean that individual distributions voted/decided separately, multiple times to choose the better tool? Debian has the most democratic voting system and unanimously voted for systemd.
And yeah, if I want to use my own display manager protocol instead of X or Wayland I would also be similarly stranded. Options are good, but standards and compatibility are just as important - a million incompatible options only give rise to chaos.
I am, for example, very happy that Linux applications are finally not as distribution-dependent and there is a good chance to run that .deb file on anything else running systemd without much trouble. I remember the times when it was not so.
They are influenced by other distros decisions. Debian's justification of adopting systemd starts "Systemd is becoming the de facto standard init system for Linux." https://wiki.debian.org/Debate/initsystem/systemd
I do not think this looks like a unanimous vote: https://www.debian.org/vote/2019/vote_002#outcome
> Booting up a system is a complex domain.
systemd goes far beyond this domain.
This is a mystery to me. Given the LP attitude is known to be hostile to people with expertise and given the cancerous nature of systemd projects, I really wonder how did people choose to be treated that way.
Maybe they have voted for systemd-as-PID1, which is incomparably better than sysvinit, but this is the way systemd crowd got its foot in the door and before you know nothing works without systemd metastasis present.
So how "optional" are those modules in practice -- how many systems run just the init core of systemd and not the whole shebang?
> that run under the wider systemd project, but that's a false conclusion that "systemd eats the world".
Isn't the very fact that there is what you call a "wider systemd project" at least a fairly good indication that systemd indeed is attempting to "eat the [Linux] world"?
Because it's better than the alternatives?, don't remember systemd buying distro maintainers lol
>If you want to use an alternative to systemd on those distributions, you are usually on your own, constantly trying to fix it whenever there are breaking changes.
Of course they aren't being paid to support everything under the sun and http://islinuxaboutchoice.com/
>So is Windows :)
Then use it if it's better for you
At least that’s me. I use systemd in most of my installs for reasons similar to yours, but nothing feels more sublime to me than installing a simple init system and a few other daemons for system features I actually use.
Also, feel free to "rob that feeling back" by learning how systemd works
Waste of time. It's easier to get used to a systemd-free distro
Eg. make your system "login interactive" before networking and other unneeded services (database, web server, whatever) are even attempted to be set up/started.
Use just drop-in configuration fragments (*.service.d/override.conf) without making an unmaintainable mess (ie. without making your own copies of whole, OS installed unit files).
That should get you the feel. :) And it's not something crazy, it's just basic re-ordering of dependencies.
Indeed, nothing crazy.
In a friendly system, I'd just edit the getty service config and change After/Before/whatnot and be reasonably confident I didn't break anything. But
1) it's not possible, you can't just override After/Before alone.
2) systemd doesn't make it easy to inspect existing relationships in a simple to understand, localized manner in the first place. So unless you're the one that wrote all units in the system, getting a concept of what you'll possibly break by changing things is almost impossible, without just rebooting and seeing if the system will start up.
You can create a massive SVG of dependencies from systemd-analyze, but that's really not that helpful. It's a picture that has at least 10 meters on one side. :D
Numerous kernel features, reliance generally on it by itself and by third party programs (running ceph w/ openrc is hard bc it assumes systemd is present). I’m buying the full car when I use it, when what I really want is a kit that I can optimize for purpose. Honestly though, this close integration is worth it. My main OS build at the moment is pretty much just systemd and podman on top of linux.
> Also, feel free to "rob that feeling back" by learning how systemd works
I really want to! I just don’t know any good resources that can help get me familiar with all it’s doing for me in the background. All I know about it is what I have gleaned from tutorials, I don’t yet feel I know what’s possible with it yet.
https://michael.stapelberg.ch/posts/2024-01-17-systemd-indef...
Stuff like this is possibly where the complaints from some people begin.
Fortunately, I can find a tracked bug that is active. New updates get pushed, as the honestly phenomenal community of people intended this process to go. But How may years have some of those people been patching bugs like this in systemd on a regular basis? Did that time have to be spent if systemd's architecture was better from the get go?
The Trail of Bugs to get to the point we are at today has truly taken a monumental effort from MANY people. Why wasn't systemd's community doing things well "enough" from the beginning before being folded into so many OSes?
Let's be real. From then till now they have put in hard work, in the face of huge community pushback, because someone had to do it.
Diehards feel it felt "foisted" upon us before it was fully baked, everyone knew sysvinit was way past its prime. Put up or shut up. Plug in a different init for your OS and move on.
But, you know, people like talking and complaining to each other. It's a very important part of solving technical problems!
Also, I would be delighted to see that mythical program that requires no maintenance and just works^TM.
Also, what does it have to do with systemd's architecture?
It sure feels like it because Ubuntu insist on installing this incredible piece of software even on the server installs.
...yes? If dolphin sucked then that's a fault in KDE.
The goal of systemd is of course to be a highly integrated system which solves everything. As can easily be seen how hard it is to run e.g. dbus without systemd.
That was the minor problem. The major meta-problems are that:
1. The baked form itself is broken. It has numerous fundamentally flawed aspects to its design (and to its existence as a project). More baking would not have helped this.
2. It is not intended as an option, nor even just the default option - but to make more and more utilities and libraries for managing various system facilities and services become unusable and incompatible, to be taken over by systemd. It's not like foisting, say, Thunderbird instead of Evolution as the default mail client; if you don't like it, you run the other thing. Or even version X of the kernel instead of version Y of the kernel and so on.
> everyone knew sysvinit was way past its prime
At this point we can say with clarity that systemd has almost nothing to do with the choice of init system. You could replace the init system with any number of things - some already existing 15 years ago, some which could be developed in the mean time. In hindsight, this is an excuse and not a reason.
See the slides of the linked talk, starting at page 7: https://cfp.cccv.de/media/38c3-community-stages/submissions/...
This is a pretty common feeling after writing a couple of nix packages.
It's huge, messy, has a poor bug and security history, obfuscates things that don't need obfuscating, and is just generally IMO not a clean or efficient implementation. It's a very Windows style solution, very different from the lean and minimal stuff I like to run generally.
The advantages it provides are questionable, and are dwarfed by the issues it has had in the past IMO.
OpenRC perfectly meets my needs at present and my system boots incredibly quickly. When s6 is finished that situation will only be improved.
Now I'd be up for a better config format, or perhaps other implementations that use the systemd config format, but I think config is a pretty good idea.
I have no problem with config, but openrc is simple and intuitive enough that no config file is needed.
It's certainly not more complicated than authoring a unit file.
What distro are you running?
PostmarketOS which is based on Alpine switched to systemd, but I've seen nothing indicating Alpine is interested in doing so.
systemd is indeed totally incompatible with musl libc.
It's more that it is incompatible with being small, lean and secure.
lol, no.
> the OpenRC is a good example how miniscule your world is
Weird attempt at an insult, but ok.
I personally think the basic “service manager” functionality works pretty well and I like systemd overall.
However, the same is not true for a bunch of the more peripheral services (e.g. resolved, networkd, timesyncd). What’s particularly annoying is that there exist mature open source projects that can provide better functionality in a lot of cases which could be used, rather than bundling a half-assed attempt with systemd (eg. unbound, chrony).
It also has a good integration with Linux features, like cgroups, allowing easy user-isolation, has user-services that allow proper resource management, and many more.
It works, and it works well. It does what it says on the tin. It brings together multiple disparate functionalities to a level that most end users need, while also having the ability to replace a lot of those functionalities (systemd-resolved, systemd-networkd, systemd-timesyncd as examples) with other services if that's what your deployment needs.
It replaces the old style of services being just a bunch of shell scripts that ran one after another. It provides a consistent interface to configure, start, stop, restart, enable, disable, and monitor those services. It allows dynamism by creating service templates, allowing you to launch six different variants of a service using the same base service configuration.
It also allows you to take advantage of a lot of Linux's security features, by implementing service-level restrictions on filesystems, network access, user IDs, PIDs, and so on. It even provides the ability to listen on a socket and pass connections to a process, meaning you could have a network-listening daemon that doesn't even actually have access to your network.
It provides cgroup integration so that you can limit the resources provided to an individual service so that you can prevent one process from causing issues with the rest of your hardware. It can even point a service at a separate root directory, essentially chrooting a service before it even starts.
It provides tooling so that individual services can interact with one another, and so that user-space tooling (either theirs or a custom d-bus client) can interact with services, and provides functionality for validating whether or not the user has permissions to do so. It also provides functionality to easily override configuration in override files, allowing you to make local changes without changing the files that were distributed, making it easy to debug whether it's your changes or not that are causing an issue, or to test changes without worrying about putting things back.
It eliminates the issues of having multiple different services, often either conflicting or overlapping, to provide the things it provides. Multiple separate configuration files, configuration syntaxes, and so on. It eliminates the need for distros to create config generation tooling to produce the right config files to tie each service together, and then write their own daemons or cronjobs to check each of them for changes.
And all of this functionality is, essentially, optional. I can do a hundred different things with a service file, but I don't have to; I can basically write a service file in ten lines of ini-compatible configuration, using (and being aware of) none of that functionality, and it works fine, or I can write a service file that locks a service into its own network, with no access to the existing filesystem, only the most basic entries in /dev, only the files it needs in /etc, limited by seccomp filters, using systemd's watchdog functionality to restart it if it hangs or gets overloaded, limiting it to specific CPU cores and changing CPU and IO weighting, limiting the number of processes that it can create, and even filtering which system calls it's allowed to use.
In short, it's a system that can be very easy to use and start working with, but provides more functionality and complexity than I think almost anyone realizes. It's the most capable and simplest way of handling system services, and the extra pieces just make it less complex to add functionality like network management, name lookups, boot management, and so on to your system if all you need is the basics.
I personally think that most of the OS decisions done by Microsoft are wrong and should be killed with fire but also I'm far from thinking bad about the people who made these decisions. Perhaps these decisions make sense from their standpoint given the information they had a time.
On the other hand on Linux I'd really wish for a centralized settings repository like Registry. But not from the systemd crowd, of course.
If you want some more structure to it then you'll probably end up with the registry and whatever it is that people hate about it.
IMO it would be enough to put the /etc into git so one can rollback bad changes.
As an aside, the reason I don't like systemd is because it's inferior to its UNIX counterparts -- especially SMF -- for system management.
None of these are mandatory though. It's up to the distros whether to use them. For example at this point resolved is pretty commonly enabled by default, networkd not at all, and timesyncd is perhaps 50-50 with chrony.
The most convincing advocacy I have seen for systemd (by a BSD developer, its fairly well known) is that it provides an extra layer of the OS (on top of the kernel) to standardise things.
Really curious now what it was so.
It's a new (ill specified, non standard) runtime to target. It's like what Win32 is to the raw NTDLL, or the dotnet or Java API. It hides the OS.
systemd (the PID 1), journald and udev are different, though, because they're mandatory; and there's no alternative to logind while technically optional.
I don't see how it defeats the point - it still nice init / services manager, it still provide features say sysvinit couldn't do at all for my _services_ and management/lifecycle of services.
How often I tackle with resolved or networkd or timesyncd - not even sure, may be once a 2-3 months, while systemd-as-service-manager I do almost every day.
Mind providing some example on your setup/cases?
I haven't seen anything worse than those two from systemd crowd.
I started using Linux because I liked stability. Systemd makes a Linux system as dynamic as a Windows one (which is nice) at the price of making it as stable as a Windows one (which is not).
I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster.
Also, bringing INI to Linux is unforgivable.
I can see the case. I use it myself on a laptop. And by "use" I mean that I just gave up looking into Linux desktop networking like a decade ago. It works, fine.
> I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster.
... this is ... incredibly wrong. Hardest disagree on all points here.
For what it's worth, I have never found this to be the case. systemd's functionality has been far more reliable to me than the old methods of using `ifupdown` and dhcpd.
> I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in.
I'd love to know what you've seen from systemd that indicates that this is the case.
> Writing it in Lisp would have been smart.
Hard disagree here. You need a language that more people know if you want contributors, and you need to be able to interact as well with other libraries/languages in ways that are understandable to the typical user. Lisp is, at best, an obscure edge case in the context of mainstream programming, and would severely hamper its adoption as an open-source project.
> Writing it in Go nowadays would probably be okay.
Ehh, I agree with this only because you're so noncommital about it. I agree that it would probably be okay. Rust would be far better, in my opinion, if we're looking for a modern language with far more memory safety guarantees (which IMHO is very important for low-level system services).
> Also, bringing INI to Linux is unforgivable.
I'd love to know what you'd recommend that would meet the criteria that INI provides:
1. Simple to read, simple to write (for users)
2. Simple to parse, simple to generate (for software)
3. Uncomplicated syntax that isn't prone to errors when being written or generated (e.g. wrong indentation in YAML, missing brackets in JSON)
I can't think of any options off the top of my head that don't end up introducing additional complexity with little to no benefit, but I'd be happy to be wrong.
> I believe that part of the problem is that it is written in C,
You know the Linux kernel, and probably most of your userspace, are also written in C? Why do you say systemd is a disaster solely based on its use of the C language but seem to be believe the rest of "Linux" is stable despite also using C?
I mean, there could be some argument here about everything systemd does actually being harder than a kernel's job... but you didn't say that.
I'm on the C-hate bandwagon as much as anyone else, but it doesn't make sense. I have mixed feelings about systemd though.
I’m aware. It would be nice were that not the case. One of my favourite userspace programs uses C, but just to build a Lisp runtime!
> Why do you say systemd is a disaster solely based on its use of the C language
I wrote ‘part of the problem.’ Systemd is a disaster in part due to its use of C. Its bugs are in part because C is not a language which is really suitable for abstraction and reasoning over abstractions.
I do think that what systemd does is more complex than the parts of a kernel which require assembler or C. I wasn’t constructing a full argument, just opining. I think that the sheer weight of C required to do anything complex makes it very difficult to reason about what that code is doing. Languages higher on the abstraction curve make it easier to reason about abstractions. Reasoning about abstractions helps prevent design bugs. And also languages with good abstraction capabilities tend to help avoid implementation bugs.
It's a blessing and a curse. Look at package managers, they more or less all do the same thing, with one primary job of "go download some binary so I can run it", yet there's so many to choose from. Every time you read some Linux guide they have to list 7 different ways of installing the same package. It's stupid, probably even more so for the maintainers of those packages because they have to distribute their package 7 different ways. At least I'm glad systemd has mostly become the standard, so you don't have to also see 7 different ways of creating a service.
And as an end user of multiple distros, I really appreciate it because I also have to make services on occasion and it's nice that there's one way to do it and it's pretty easy to do correctly.
We are overdue to package manager interop and common interfaces.
https://security-tracker.debian.org/tracker/source-package/s...
[0] https://security-tracker.debian.org/tracker/source-package/o...
Systemd has 4 open CvEs in ~1M lines of code.
The linux kernel hash 18 open CvEs in ~30M lines of code.
Let's rephrase the question the other way: is there anyone who thinks that LP's attitude is fine?
You have the people who like GNOME as it is now just as people accept systemd but you might as well be talking to Mac fans - to people who have to learn to like it because they have no choice.
Technically I think launchd might be the inspiration for systemd and for people who like the way the Mac works it's "yay" but it's not necessary.
Anyhow, I like dinit. It's declarative with a simple config language and not a monolith - absolutely perfect.
it isn't, it's great. it is different, though.
and then come in two phenomenon:
1. people resist to change, often out of ignorance.
2. some people tend to look at tradition and consider it just better, without much reason. "unix systems in the 80ies had shell scripts to launch system services, that's what i shall do in the 2020ies".
> Yes, it is maybe monolithic (but so is the Linux kernel).
it really isn't, it's largely a collection of relatively small binaries that do one thing well but they are designed to work with each other. systemd appears to be monolithic from outside, but it really isn't.
> Maybe some of them will get bloated as they achieve feature parity.
they will, most likely. it's easy (as a piece of software) to be lean and clean when you're doing very little (with little error checking and recovery).
> However I can't understand why systemd is the point of so much disagreement.
systemd was essentially pushed down everybody's throat by Red Hat when they realized it was high time to level up the boot process for the whole ecosystem. systemd made a bunch of things not only feasible (concurrency, on-demand service activation, multiple-instances of the same service running, proper log management) but so easy they're trivial.
so 10+ years, it's definitely a net positive.
some people are still complaining but meh, some people will complain anyway, so let them talk, whatever.
> it really isn't, it's largely a collection of relatively small binaries that do one thing well but they are designed to work with each other.
So where are all small the projects trying to replace the small parts of systemd? AFAIK there are no stable or convenient APIs in all those parts, so even though technically systemd consists if many binaries, it is monolithic.
This is exactly what people call "forces distributions to use it", i. e., you must choose all or nothing.
you should go ask that to "small projects" developers, not to systemd developers, i guess
And from that the systemd crowd tend to draw the following conclusion: if something was done a certain way for decades then it is bad and should be replaced.
Systemd is none of those things.
Having said that, I have to additionally admit that init scripts had to go at a certain point. It's hard to imagine a modern scripts-based PID1. Times have changed.
If it looks like a duck, walks like a duck... systemd is modular solely in theory. In practice, I am grateful that I can still remove journald and resolved from current Ubuntu installs and I'm pretty sure that's not going to be possible quite soon.
Systemd itself may be modular, but practically distros are not going to bother.
Why would you even begin to think that openrc would ever want to include a whole virtualization manager. Are you serious?
>but they are designed to work with each other.
And they are not designed to work without one another. See e.g. dbus and how hard it is to get it working on non systemd systems.
Systemd binaries aren't drop in features.
I think the simplest way to describe it is that it's a religious conflict.
A not insignificant segment of people who develop and/or use Linux are fervent followers of POSIX philosophy, the Unix heritage, Free Open Source Software development, and the Anti-Microsoft Church (note: Poettering is a Microsoft employee).
These people have a religious duty to hate systemd, it's essentially heresy. It's not a disagreement based on technical or even practical merits, so the conflict can't be addressed with technical debates and will continue for the foreseeable future.
Don't the holders of that opinion get to call your position equally religious?
"not a disagreement based on technical or even practical merits" indeed, right there in the mirror.
The first few minutes of this video absolutely articulated some perfectly technical and practical merits. So have some comments here on this hn post. I don't see how it's valid to say no one has ever produced any.
The conflict as parent commenter witnesses it continues because that small minority continue to (very loudly) disagree not on the merits. It is their prerogative to disagree if they desire, but their basis is much more about beliefs than superiority.
It's like Polandball memes where UK crazily chants "Britannia rule the waves...!" while US goes off to freedom some oil with its boats.
And that their merits align with the merit of everyone else. /s
Philosophy can't be reasoned based on merits. Of course there are technical merits as to why systemd-as-PID1 was (not today!) an extremely good piece of software compared to sysvinit, there's no question about that. Likewise there are valid technical reasons why systemd-timesyncd should be abolished and never mentioned again.
But how do you decide LP's attitude on merits? How do I argue with Red Hat who shoved systemd down everyone's throat?
So yes, it's a religious question of sorts. The religion that made Unix unix.
I'm not a typical example. My view is inarticulate, subjective and maybe even irrational, but I remember the system I came to love and that was Linux. My overwhelming impression with systemd is that it's not Linux and it should not be referred to as Linux or even in the context thereof. It's not evil or bad or anything but itself, but it's not Linux. In my abstract, medieval view, Linux has a soul, albeit, at times, a tormented one. Systemd exorcises this soul for me.
Now despite me disclaiming the subjectivity and abstraction of these perceptions, I'm pretty certain there will be some hostile replies, possibly with valid points. If you're really trying to understand the creature, I suspect it's very improbable that it will happen here. There are existing strong, well written arguments both for, against, and even neutral. Definitely worth one's time if understanding is the true objective.
For me, it's scratching a chalkboard and smells bad. It frightens me and makes me sad. It's worse than brussel sprouts and freaks me out.
Yes, systemd is an init system/service handler (and a lot of related utilities) running on top of the OS kernel Linux. They are two different things working together to make an usable OS.
But yeah, you cracked a tough one there. Two separate things. Who'd have thunk it!
systemd is very good because it makes many things that the Linux kernel can do very easy. I would like to know how the people who swear against it implement features that I regularly use in systemd like socket/mount/dbus activation, services that dynamically create a user and group on activation and keep their service and temp directories private from other services, syscall filtering, user session services that start when I log into a graphical session (very useful when you have issues with your system tray's config, for example), network mounts that get mounted asynchronously only when you're using them, actual service management and restarting a service when it fails and service dependencies (which some init systems still don't do!), and so on and so forth...
Yes you could do all of these things by composing other programs, but there is lots of value in having them all bundled together and only having to consult one resource for documentation on them, and the fact that these are all designed to work together reduces the friction that you would get by composing other "general-purpose" tools.
On the other hand, systemd is bad because the implementation is messy, when it does fail it tends to do so in odd and obscure ways, it comes bundled with tons of components that most people won't need, and yes the fact that it's essentially the only option you're given and that it's not portable to BSDs is not very nice.
I would encourage people to read dinit's comparison page and Chimera Linux's FAQ section on systemd for good arguments that are not fueled by religious belief as to both why systemd is valuable and in which ways it is bad.
https://github.com/davmac314/dinit/blob/master/doc/COMPARISO...
http://chimera-linux.org/docs/faq#what-is-the-projects-take-...
https://papers.freebsd.org/2018/bsdcan/rice-the_tragedy_of_s...
https://www.youtube.com/watch?v=o_AIw9bGogo
HN discusion: https://news.ycombinator.com/item?id=19207533
LWN comments: https://lwn.net/Articles/777595/
I believe "nuance" is the key word here.
Humans have a natural tendency to change resistance. This tendency tends to be higher in sysadmins who are often deep into autistic spectrum.
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
The article compares the Unix/C philosophy with the Lisp philosophy and concludes that Lisp is "better" (it is The Right Thing), but that Unix/C will probably end up dominating. Obviously, he was right.
The article is pretty famous around the suckless, minimalist, crowd. But I think everyone who reads it takes a slightly wrong lesson from that article. The point isn't that Unix/C won because it was simple. The point is that Unix/C was simple enough to use, simple enough to implement on most available hardware and that it did everything you needed it to do.
The minimalist people have turned software simplicity into the modern version of The Right Thing, and are surprised when they found out that the "worse" (more complex) thing wins. But The Right Thing will never win. The Good Enough always wins.
Is Linux better than *BSD? Well *BSDs are more simple, easier to understand and reason about etc. But, at least OpenBSD, doesn't have mount --bind, so I can't use it. Case closed. And I think that's the case for most people. Linux has thing X which I need so I will use Linux, even if ideologically *BSD is imo better.
Is D-Bus The Right Thing? No; but it is The Good Enough. polkit, selinux, ACLs, and so on.
The most recent example I can think of is Hyprland. It is basically the only viable Wayland window manager (aside from sway). Not because it is the best designed or the simplest, or anything like that. But simply because it is the only one Good Enough to use.
SystemV init was not good enough for complex service management. systemd is. systemd simply does everything you need it to do well enough. So systemd wins. Simple as. It will only be replaced when it is no longer Good Enough.
Something like Wine, where in the analogy systemd is the Microsoft Win32 API and we want to be able to run systemd "enabled" software on something else. Or at least re-compile it.
Wine also started with an incredible amount of stubs which did nothing, but that was often enough for many programs to work anyway.
The problem is that if the only complaint with systemd is that it's too complex, any backwards compatible alternative will necessarily be as complex as systemd + the new thing (at least in terms of complexity of interface).
If there are actual technical deficiencies of systemd, then sure, maybe such a backwards compatible alternative might be in order.
Also, everything expands in time. Wine may have started out with many stubs, but now we're at the point of implementing Windows-y APIs in the kernel with the sole goal of improving wine performance (NTSYNC).
As I understand it, that isn't the only, nor even the main, complaint with systemd. On the contrary, the main complaint with systemd is that, like strangler vine (kudzu?), it's spreading everywhere, taking over functions that it originally had nothing to do with, and forcing ever more unrelated things to adapt to systemd -- thereby making them much less portable away from systemd; to something that doesn't use it.
It's like the old debate about "BTW, you should call it GNU/Linux, because..." is sooo yesterday: Nowadays it's systemd/Linux -- and well on its way to becoming systemd-OS, with the kernel a mere afterthought, soon to be if not replaced at least easily replacable. Sure, that may not bother you or most systemd fans, but one can't help wonder: Do you even realise that this is what you're condoning, or even actively advocating? Maybe it would bother you, if you realised it.
(Also, the whole "strangler vine" thing, when deliberately applied, used to have a name: "Embrace, Extend, Extinguish". Now, I can't really swear that it is being deliberately applied here... But do we really dare to blithely assume it's just a coincidence that the creator of systemd so naturally found a home at the company the expression was coined for?)
We've seen the launch of GNU's systemd equivalent, which seems to introduce more complexity to the simplest levels and is more difficult for users to understand and configure. Given that every service file is its own erlang program/DSL/whatever, understanding erlang is critical to being able to write or reason about service files.
In essence, it seems to be trying to re-implement what systemd does, but badly.
Reimplementing systemd's API but using other discrete components would also be a bad idea. The biggest reason systemd took off is that it's all the tools a system needs, built in a way that they work well together and can be interacted with and configured consistently. Providing systemd-compatible replacement shim APIs would mean trying to tie a dozen (or more) discrete OSS projects, each with their own philosophies, developers, licenses, goals, etc. together, generating their config files consistently, and trying to mush all that together in a way that doesn't make things vastly more complex than what systemd already provides.
In short: the reason systemd is successful is that it got rid of a giant mess of unrelated or overlapping services and replaced it with something simple, coherent, and functional, built out of components that you can (in most cases) choose to use or not. Most people who hate systemd seem to hate it for largely ideological reasons ("it's too big!") and are more interested in solving those ideological problems at the expense of practical solutions to real user issues. I've yet to see someone argue against systemd because it's bad for end users; only because they don't like the way that it provides benefits for users.
Shim out enough for it to at least run in some capacity on something which does not have systemd.
Go from there.
The amount of work that a project would require over the long-term would be pretty substantial, so I assume that there are a lot of these things which you would suggest fixing over time to be rid of systemd, but I'm not certain what the end benefit of this work would be. Interested to hear more.
(Now, the importance of portability is a separate question. If you want systemd to "eat the world" it's even a negative value.)
1: https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd
The most prominent dependency on systemd components is Gnome on logind, which already has a shim.
I'd wager the vast majority of (non-embedded / single-purpose) Wayland deployments are gnome and KDE.
Part of the problem with all of them is less the wm and more knowing what parts you need. Not so much bars as portals. I'm vaguely surprised hyprland doesn't have a "good enough" batteries included config and documentation.
You simply install everything from the "Must-Have" page, then go through the other pages and install everything you want and by the end you have a complete and functional desktop. For every component, there is a good description of how to use it in Hyprland.
I simply followed that guide, remapped some shortcuts, copied some guy's waybar config from GitHub, and, well, did little else, and had a perfectly functional Hyprland desktop that I used virtually unchanged for ~six months.
Only recently got into ricing it more, and only to the extent that now all my components (app launcher, notification manager, waybar etc.) use the same color theme.
As for SystemV... as I mentioned in another comment - in hindsight, that was not the issue. There were and are SystemV alternatives [1]. One can even write one that uses D-Bus in an opt-in fashion, to foster other facilities' use of it.
The init system excuse is very much like the stone in the fable of the stone soup: https://en.wikipedia.org/wiki/Stone_Soup - it's what gets the vagabond's foot in the door, and is the first ingredient for the soup. But actually, the stone carried no significance, and the resulting soup is pretty much the same thing as without the stone part.
[1] : ruint, OpenRC, launchd, s6, nosh, finit, procd, upstart etc. See brief description and links at https://alternativeto.net/software/sysvinit/ for example.
and one more thing about that: For PC users and "vanilla" machine setups - sysvinit, weirdly, still works fine. Startup is quick, and developers don't live in pain making it work. Of course it is kind of lame design-wise, but it's not even that we just _had_ to replace it - we've still not reached even that point.
These are software designed by people who have no experience in user-centric design, they design in theory, reasoning in theory, ignoring practice.
Until it doesn't. Fortunately I didn't have to debug it often, but when it was a lot of pain.
I prefer the fs under /tmp to be tmpfs. On the BBB is wasn't. I changed that and on next reboot the system didn't come up again -- no way to log in. Why? And what to do? Turns out I failed to state the fs_freq and fs_passno fields -- those aren't optional, but while the old mount tool tolerated their absence, systemd chose to interpret the fstab strictly, failed to mount that fs, consequently didn't reach the local-fs.target and hence didn't offer any way to log-in. Unlike Raspberry Pis, the BBB doesn't offer the possibility to remove (and mount and debug elsewhere) the boot medium. Fortunately, I found help on-line on how to connect a serial terminal to the BBB and interrupt the boot process, forcing the use of /bin/sh as init process...
Except exactly the opposite is true: it is sysvinit (and derivatives) who had the job done. In a very basic way, slow and perhaps not even compatible with modern requirements and expectations, but the job was done.
Systemd on the other hand does the job it thinks should be done, not you. Your opinion does not matter.
You can spend however much time you want editing /etc/ssh/sshd_config and then restarting sshd and then pulling your hair out on why tf sshd ignores certain options while still definitely parsing sshd_config. Only to later find out that systemd/ubuntu crowd decided to listen on port 22 via systemd, sort of like inetd did back in the days. It's like sshd directly listening on port was not good enough for the last 30 years, definitely had to be changed. Oh yeah, and to make your life miserable, they mask the name of the listening process with "sshd" in it, so you get confused even more.
And people can come up with countless of similar examples.
Incredible attitude and arrogance is what makes people hate systemd.
My view is that there is an attitude/approach spillover from systemd crowd into other teams. Switching port 22 from sshd to systemd was not something that any sane person could come up with. It's a stream of incredibly hostile decisions from systemd upstream that allowed that kind of thinking.
Labelling a technical decision that was made about a system design (that a lot of people agree with) as "not sane" makes you look like a fundamentalist.
* decided to covertly move port 22 from sshd to systemd while actively masking the change so that `ps ax` shows "sshd" in the process title
* decided to not mention this fact in sshd_config while leaving the Port configuration clause in place
Yeah, call me a fundamentalist, I would like to talk to a sane person like that.
Personally I found that to be offering nothing at all & having every maintainer and sysadmin diy their services to be incredibly inefficient & waste a ton of time because every service you looked at was potentially built from a different init skeleton & modified in bespoke unique ways.
Sysvinit offers way way way too little.
sysvinit was bad, no arguing about that, but it was controllable, predictable and comprehensible. While I believe that there was a time when systemd-as-PID1 looked like an excellent solution, I am confident that systemd has none of those qualities.
There's a lot of reasons to be pro systemd, because it does so much cohesively & well.
But if we just look at the task of running jobs, if we ignore all the other excellent management & other things in the systemd monorepo: when it comes to running programs, systemd is millions of miles head and shoulders above everything else. Like, everyone else was throwing shit up in the air, and systemd was launching fucking rockets. Nothing else has had even the faintest dose of taking itself seriously or trying to get good: it's all been sad recreations of 1970/1980's with no acceptance that the scope needed to be bigger, that we should have better more secure ways of running services.
Upstart may have been a semi ok way of wiring some kind of graph of services together, in an event based way. But honestly I prefer systemd's level-based way, rather than evented, because events don't reconcile in stable ways and level-based relationships do, are understandable not just sequences of actions but as relations of systems.
Its daunting as fuck, and I think this is why most haters hate systemd: because they don't want to get better. But a third of what's available in systemd.exec and systemd.service is absolutely crucial brilliant bundled-in ways to make your service more secure, to make it less of a risk. It exposes incredible awesome things the OS could do that most people simply never got good at doing, that the anti-pattern of sysv never could encompass. SysV said it was up to every service to define their own init scripts, and most of these were very very very dumb init scripts, bespoke and unique and brutally dumb mostly, grafting some random shitty bad shell scripting to running something in the background. Systemd exposes a cornocopia of offerings that Linux has to do this, but securely, safely, with isolation, in a standard, clear/concise (not having to delve into bespoke shell scripts) cross-cutting/repeatable way. Whats on tap here is amazing. None of the haters seem to have the faintest most remote appreciation or interest in getting good, in making any of this incredibly good potentiating shit available or on tap, much less in any repeatable consistent clear fashion. I think the haters are playing at such deeply sad forsaken stupid levels, actively fighting the ability to appreciate even remotely the awesome forces they - if they had any idea what was good for them - would be moving towards, be it via systemd or other.
Yes, 1/3rd of this is incredibly niche. 1/3rd is common/good/necessary and somewhat buried amid the rest. 1/3rd of it is just fantastically good security/safety practice that no one did, that no one knew about, that's just on tap, and easy to bring in, that's so accessible, that was so hard & weird & difficult to do before, that's such a colossal improvement in posture:
https://www.freedesktop.org/software/systemd/man/latest/syst... https://www.freedesktop.org/software/systemd/man/latest/syst...
Yah, well, systemd has thrown shit at me. Depending on the Distro, time, maybe hardware/firmware too, while other inits&(service-)supervisors didn't at the time.
> ...and systemd was launching fucking rockets.
Which sometimes go BOOM in spectacular fireworks. It's not exactly that it has reached the state of full reusability like SpaceX intends to ;->
> ...because they don't want to get better.
Maybe some, not me.
See? https://postimg.cc/CZtH4rHp Système D whoohoohoondrrbarr! Arr tyarr tyarr!1!!
I genuinely believe it's the reason Linux has dominated the other operating systems in the server space in the past decade. As someone who manages servers I wouldn't even consider the other options in space right now, and the features systemd provides is a substantial part of that decision.
I don't think that makes sense; Linux was already completely dominant before systemd came along.
I have been trying out atomic Fedora and enjoying it. I like ostree, read only root, podman, building the distro from containers. I think I have had enough of systemd, though, and might move on because of it.
Your first sentence explains, to a great extent, your second. You see, systemd is designed to _prevent_ a hundred flowers from blooming. Unlike most Unix-like system components, the idea is for systemd not be an alternative replacable component, but the whole installation above the kernel. You don't choose things; you get those services and facilities which live within systemd; and those which don't - mostly won't work. That is, unless you tear out everything related to systemd. Which is difficult, since GNOME and some other packages over time have introduced dependencies on systemd, rather than on services or facilities it provides via a common protocol or interface.
This was also how the big Debian debate exploded, causing the fork of Devuan: The "opposition" did not demand "No systemd in Debian!", but rather, that the user would be able to choose not to have systemd at all, if they so please. I am paraphrasing from memory of course, but I believe that was the gist of it.
And the speaker in this video faced this situation.
I am not well-versed in NixOS and certainly not in this new project, but I imagine that if the author could easily just configure NixOS not have systemd, they might not have bothered starting this project and would more likely have published some kind of recipe/how-to page on
I’ve tried a half dozen systemd distros. Each one hit some insane bug at some point that took a day to debug. Every single time, it was some undocumented systemd thing that has no reason for existing.
Anyway, it’s all devuan and openbsd at home these days. I’ve had zero non-hardware related issues in over a year.
Actually, that’s not true. Devuan still defaults to pulseaudio (the moral precursor to systemd), which still doesn’t support locking your audio output port in a way that survives reboot. It also crashes randomly when audio ports come and go. The upside is it randomly requires a reboot or moves audio out to an unconnected jack.
I replaced it with pipewire, bringing the number of Poettering services on my machines to zero. Now things work reasonably.
I find it easier and better on so many levels!
>I find it easier and better on so many levels!
Openrc is by any possible standard easier to use. Among the reasons is that it does not include a way to create virtual machines.
Exactly. So why is it part of your init system? Can you think of a reason why it is not a totally separate project which is totally independent of systemd?
From a surface glance systemd and openrc are almost identical. Both require very little to get something to work. The difference is that systemd does a million things more.
What you probably should know though is that many systemd distros do not have a real fstab, the fstab is just a file which systemd uses to create mount units, which are then used during boot.
Another important piece of knowledge is what a systemd "transaction" is, that is a very unintuitive concept which you absolutely need to know if you are debugging on your init system.
Is it?
Systemd is not an init system. One component of systemd is an init. There are other components.
(People hate systemd? They hate a piece of software? Eesh)
What has to do with it is people being unable to tell you why it contains a virtualization manager. In fact the response "it is not an init system" tells you pretty much everything. It is a terrible piece of software, which has completely lost all focus.
What?
You can use SystemD to have services like a webserver or a python script started after boot. Doing it with systemd is exponentially more easy than with an init script.
How else would you start that if not with systemd (if that's all you have). I'm not sure you really understand what you can do with systemd, or you would not have written the comment you did
The old school init styles, whether BSD or SysV, adhere to that philosophy.
Systemd is a travesty. I think it was about a decade ago that there was a remotely exploitable root equivalent compromise in the system DS built in DNS resolver. And these days includes not just DNS but also privilege escalation and who knows what else
It’s probably fine for most people and most purposes. And by fine, I mean most people can probably use it and never see a live exploited against it.
And if you care about security, you can probably apply enough mitigating controls that it’s not gonna be a disaster for you.
But for me, defense in depth means avoiding systems to begin with and not trying to bandit over the problems with it
How did she do that? Can you dig up the git commit where that happened?
Is this similar to how Jim Zemlin got Rust into Linux?
I only started to hate systemd when I really had to work with it in depth.
It is hard to understand unless why people hate it if you view it from the surface. On a high level there is nothing wrong with it. If you had to write a basic unit file you could easily do so, there are just a few basic concepts and keywords you need to know to get it working. From that perspective systemd is very much like openrc, which works very much in a similar matter.
Systemd is not bad because it is "monolithic" or because it violates some "UNIX principle" or because it is "bloated". Systemd is bad because it is made by people who have no idea what they want to make and who seem obsessed with solving every single problem they can imagine.
Did you know that on Ubuntu your fstab is fake? It is just a file which tells systemd which mount units it should create during boot. (https://manpages.ubuntu.com/manpages/focal/en/man8/systemd-f...)
Did you know that systemd contains an entire virtualization manager? (https://www.man7.org/linux/man-pages/man1/systemd-nspawn.1.h...)
Did you know that you can use systemd to manage network devices? (https://www.man7.org/linux/man-pages/man5/systemd.network.5....)
Why do these things need to be part of my init system? I can not even imagine what the answer could be.
Systemd is an enormous C project, which has innumerable features, many of them used extremely infrequently and which wants to perform very important tasks for your OS. It has lost any focus on being an init systemd.
People hate systemd because it is bad software and it is bad software because it has no idea what it wants to be. The systemd documentation is one of the biggest rabbit holes in computing.
Yes I knew all of these & have used all of these optional components. And they have provided immeasurably better administration than the historical tools that purported to do these jobs before, with far more consistency & clarity about their functioning.
Agreed that there are lots and lots of features. Buts its amazing. Oh you want to make this service secure, with temporary users & limited permissions and limits? Sure of course. Oh you want service restarting? Not perfect I agree but pretty good for me, and avoids some thundering herd problems I've seen other service managers have. There's so many things we could be doing, to make systems better, and a lot of people really are intimidated by & hate the fact that theres a much more competent cohesive system that shows such a lack with the bare bones unchanging unimproving inconsistent low-end insecure dirty past.
Things I do not like:
Configuration splayed out amongst tons of tiny .ini files (this manifests in nixos by a mostly boilerplate ~10 line config burp for every service)
Multiple dependency types including its own enable/disable system including a whole parallel configuration tree of symlinks, as opposed to the simple/standard/traditional approach of configuration being disabled by not existing.
Network interfaces/drives/etc splayed out each into multiple services, some from concrete configuration, some implicit - seemingly to make everything visible to its uniform model.
Complex logical model making it hard to debug it without using bespoke tools to analyze dependency graphs and whatnot.
I'm not sitting around hating on systemd because sysvinit was also totally overwrought and obtuse, and BSD style init scripts weren't really scalable. But I get the hate. And I totally see the room for a drastically simpler init system (especially for NixOS). It's fantastic that someone finally dug in and attempted it.
Mostly I seen misguided criticism from less technical people that don't understand systemd but seem to like the idea of fitting in and have identified that a certain few verbal linux users they consider to be cool hate it with passion.
It's really dumb and boring and they often resort to just make stuff up. This thread has a bunch of such comments.
Systemd solves countless real problems and helped linux grow in many ways.
It not having systemd seems like a bit of a distraction from all of the other stuff that has gone into it.
Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
This is just the same old "systemd sucks, let's rip it out" and then later reinvent everything it provides, because it was needed. Also commonly known as reinventing the wheel, the curse of any IT project.
Continuing with the vehicle metaphors, the wheel has been reinvented many times for different purposes. The wheel on a tractor is different from that of a Formula One car.
It has all of those words next to a bullet point, but the implementation is quite different, and I (like the presenter and probably many many others who are clearly not you) have more confidence in a simple fuse than with systemd[1].
[1]: https://app.opencve.io/cve/?vendor=systemd_project&product=s...
> At that point, any rational person would question the reasons for doing so.
That is excellent advice. The presenter has done something you clearly cannot. You should be rational, follow your own advice, and try to figure out what those reasons are (hint: some of them are actually in the video). That might take a few hours to a few weeks of reading depending on your own experiences, and that's just how life is sometimes.
> Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
When I have a new gadget I want to produce, I'm responsible for all of the code in it, so productivity, reliability, performance, and size are important to me whether I have written the code or I have merely used it in my product. I do not understand the way these things are important to the systemd people (or even if they are important at all), so for me, systemd is off-the-table to begin with.
Or to put it another way: I never needed a car in the first place, because I'm making boats, and I'm not starting with a car just because I like the people who made the engine. Ignoring "solved problems" can just make everything more expensive, and maybe I only know that because I've seen enough people make that mistake, but sometimes this is true.
Keeping an open mind means allowing yourself to be convinced too.
At this point Systemd its unit files are in a really nice place, to the point where Systemd can often guarantee correctness now.
NixOS' module system works, but I don't think there's anybody who thinks it's particularly pretty or generalisable. As soon as you want to run one service twice with slightly varying config you're SOL ...
For some reason I can't directly reply to transpute's comment, but it's relevant to this thread so here goes:
> Ownerbooted sixos closes this loophole without any "trusted computing" voodoo, eliminating all unencrypted storage except for an eeprom whose hardware write-protect pin is connected to ground [...].
Desolder the EEPROM and read the secrets - the loophole is open wide without a TPM/SEP.
The point of TPM is supposed to be that it makes "yoink the laptop" attacks unviable even for state-level actors, while desoldering and reading the flash is trivial for a hobbyist with cheap tools and some patience.
However this is still an enormous step forward. All of the recent attacks on secure boot chains on Windows[1] and Linux[2] are due to usage of partially-unencrypted core system components in a complex boot chain. Sixos takes the correct approach - minimise the attack surface. All it takes is to stop rejecting the "voodoo" and take what the hardware already offers.
On the contrary. TPM _is_ an attack in itself. Its result is that control lies not with you as the user but with whoever provided you with the TPM - relative to all software which uses the TPM. And if you can't avoid that kind of software, then the HW providers and the software providers have conspired against you to control your own hardware.
I am all for an alternative Nix OS trying new approaches though, and sixos seems quite innovative.
Portage is the best package manager out of any distribution.
There are no buts. Gentoo is awesome.
...granted, my potato only has an i7-6700 Skylake with 4 cores+hyperthreads for 8 threads at 3.40GHz, it's not one of those AMD Ryzen things, but still: I'm not running GNU/Linux because I want to buy a new PC every year.
And AIUI that's exactly that the author refers to by "95% is nixpkgs".
The NixOS part (the module system and modules) is in no small part integration between the init-agnostic nixpkgs and the init system (systemd).
That's what enables this project, as well as nix-darwin (integrates with launchd) and NixBSD.
The traditional way (pacman, apk, apt...) is for packages to carry the init files for the service they package.
Antix is essentially Debian for Dummies on crappy hardware running live in RAM, or otherwise unorthodox ways. It may seem ghettoish, but the thing about it is you can mod/remaster it most easily and make it YOURS without much fuss. And because of running from RAM it really flies.
Microkernel multiserver systems could use more exposure.
So in Hacker News fashion: dinit is the one I find easiest so far. It has a declarative syntax but it's not a monolith. For me it solves every thing I didn't like about SystemV and yet it's not embrace, extend, smother.
Void generally plays well with ZFS, including kernel updates, but installing on ZFS root is very much a DIY process.
But NixOS itself does something similar, it has generations and if you change some setting and rebuild your system, the previous' link will be available in the boot menu, so you can easily try out stuff and just revert if it doesn't work - it is file system independent, but it only handles nix-specific stuff.
I just want encryption at rest for when it comes time to dispose of the disk, there's not supposed to be unencrypted sensitive data on it anyway.
But now I'm back on fedora for want of packages and not being on a mainstream distro is all rainbows and unicorns until we hit the corner case or a missing package which is available only as flatpak and won't integrate with the look and feel of the desktop environment.
You'll still be off the beaten path, but you could fix this particular complaint by running Chimera and then putting nix the package manager on top of it
* "Can programming be liberated from the von Neumann style?" https://dl.acm.org/doi/pdf/10.1145/359576.359579
No, that is an urban legend.
> when I have learned Haskell first to understand it's foundations more deeply
Nix is nothing like Haskell.
Also, the functional and lazy nature if Nix is not an ideological decision, it's a necessity when you have a giant monorepo config for 200000 packages. (Without laziness you'd have to wait for an hour just to evaluate the config options.)
But thank you for insights, I have learned Haskell basics and in awe already. Maybe "functional code is going to fix the world" not the full truth when I get more experienced ;-)
If you want to live in the past, go run SunOS. You might need a dusty old tape drive, though.
I’ve laid my actual criticisms bare multiple times on this site.
1) The tight coupling of the userland with systemd means that while systemd replaced a pleathora of inits (not just sysv): the target is now too large to be replaced even if there are better ones. Systemd is the last init linux will have, and increases the barrier to port software to other unix-likes.
2) The non-optional/default features have been buggy and difficult to replace. Journald has no replacement; systemd-networkd is one of the most common causes of failure for my desktop due in part to being flakey when dnssec is not available.
3) The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc.
There are more, but these are my main ones. Throwing away the corpus of admin muscle memory is not an an issue anymore.
To be blunt, I was using Fedora when systemd was coming out, I know how it works intimately because it was constantly broken. Part of what gives me pause is that I know how utterly undebugabble it is when it fails: it just hits those causes less frequently as the world is forced into using it. It becomes battle hardened.
Oh, and the obvious criticism agains the maintainers who have been very unapologetic to bugs and undesired behaviour, in a much worse way than the Apple “you’re holding it wrong”.
Did you ever consider that it’s also free software nerds who are the most likely to hate being told what to do?
Why would you write portable software that has a dependency on an init system?
> systemd-networkd is one of the most common causes of failure for my desktop
What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
It is easier to settle on one method (like literally every other OS) and fix the bugs than continually come up with newer, equally buggy and broken, ways of doing it.
Ask the GNOME project.
> What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
"Linux has 26 different incompatible ways to configure networking. Systemd solves this problem by introducing a 27th way that's buggier than most of the others"???
Because it's not just an init system; it manages to make itself important to a rather lot of the system. A nice page is https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd#Pa...
Dbus itself is another questionable service IMO but it got baked in rather a long time ago and is harder to replace.
False.
One of those 26 incompatible ways works just fine in the situation where systemd is clearly not working.
It is only your opinion that it is better to have "buggy" networking than to have "not buggy" networking that you think is difficult to configure. That is the exact opposite of "objectively."
I never said this.
Fix the bugs. Don't fill the well with yet another equally shite solution.
> I never said this.
I know you didn't say it was your opinion. You said it was objectively worse. You said:
> What is objectively worse than buggy networking in systemd is having 26 different incompatible ways to configure networking in Linux.
and I think it's pretty clear people have experiences where systemd-network malfunctions in places where a rc.local (one of those 26 incompatible ways) works fine.
That is not objectively worse. So it's only your opinion.
> Fix the bugs.
You can fix your own bugs.
> Don't fill the well with yet another equally shite solution.
Do not confuse some fantasy future version of systemd that has had people like me work on it to make it better, despite its many many issues, with the rc.local script that exists today: Only one of these has a chance of existing.
Fascist
This was Fedora 15, in 2011. I would say using this as a baseline qualifies as living in the past?
There's nothing apple-esque about any of this. 'If you're unhappy fork it', is a common adage that is definitely applicable here.
Morally there's no equivalence here.
You cannot fork systemd in practice; it's enormous, and its components are tightly coupled with complex, non-stable interfaces between them. So while you have access to the source code, you do not have the practical ability to exercise the FSF's four freedoms.
GNU/Linux was created as a rewrite of Unix not because Unix was the best operating system around, but because it was a design that could be replaced, changed, and improved piecemeal. GNU were able to write improved open-source versions of the components of a Unix system - such as init - piece by piece, and test them out and use them on existing Unix systems, rather than having to rewrite everything before they could do anything. If those older Unix systems had been designed like Systemd, that would not have been possible, and Linux would never have got off the ground.
GNU is a bunch of utilities no different than various terminal programs. The attempt at the "GNU OS" failed because the Hurd was never really usable.
Pre-systemd you could get Debian with Hurd and it was fine. There was never much reason to use it - hardware support was worse than Linux and there was no real killer feature in practice - but it worked.
No it didn't: GNU / Linux is a huge success.
I think the main reason that there isn't a systemd fork is that it's just not particularly worth it: it works well enough for enough people that no-one is motivated enough to try to improve on it outside what the project is doing anyway. And those that do strongly object to it tend to reject the whole approach and so they start from scratch, and then lack traction because they don't interoperate at all.
It's not modular and when other packages assume it's there it starts to become difficult to remove it. So where's the choice in that? This is just Linux becoming a corporate thing - going in whatever direction the big players want. When money is involved it seems to generate some quite dismissive attitudes.
On the good side, there are non commercial distros already with more than acceptable alternatives and I am using one of them now (with dinit - very nice). I'm not suffering. I have a distro that is far less complicated than Fedora and vastly easier to fit to my needs...and actually faster too. I hope we can avoid Linux becoming Windows or the Mac. Desktop domination is a silly goal - if it happened it would only result in a similarly locked down and unsatisfactory system without choice.
I prefer an introspectable, typed, and efficient communication protocol over streaming text because of the "Unix philosophy" whatever that may be.
Is the philosophy documented somewhere or is it just in our hearts? Because the Systemd Bus interface has great docs right here: https://www.freedesktop.org/software/systemd/man/latest/org....
—Douglas McIlroy
Its difficult to pinpoint a single origin of “everything is a file”, but its referenced in Kernighans memoirs, which is a good read: https://www.cs.princeton.edu/~bwk/memoir.html
Also, not even Linux believed in "everything is a file". Everything is either a file or a stream. The two is not the same.
If you disagree that text streams are a good universal medium then thats totally valid, but then perhaps don’t use a unix-like and go for something like VMS, VAX or Windows.
have you considered the reality that the "unix philosophy" results in incredibly brittle systems? byte streams ("""plain text""") are untyped and prone to mishaps.
SunOS was famous for being incredibly reliable, and its a more pure unix than the current linux environment.
And even if we ignore that, the majority of the web was functioning and functionally reliable atop linux with these text stream systems.
bytestreams are less debuggable, which feels silly to say openly since we are all aware that higher level interpreted languages are easier to write/debug/test and iterate on, but we seem not to be bothered by this not being true for the underlying systems.
Systemd clearly is working though, I’m just levying a criticism of opacity.
Text streams are considered "better", because the standard UNIX userland (unlike e.g. DOS) provided excellent tools for dealing with text streams: grep, sed, awk, find, tr, etc and of course the shell itself.
But once you get your hands on excellent tools (like jq) for dealing with other kinds of data (like JSON), it turns out everything is even more powerful - you can now work with JSON as easily as with text, it just plugs into the existing ecosystem. But even though JSON has a human-readable text representation, it is no longer just text - it is dynamically-structured, but strongly-typed data. A JSON array is a JSON array, you can't just awk it.
There are byte stream formats (e.g. msgpack) that have feature parity with JSON. jq can't accept msgpack-encoded byte streams, but suppose a hypothetical tool, msgpack2json, is widely available - just plug it into jq. You're still working on the same level of abstraction (shell pipes), but easily dealing with complex byte streams.
And of course, what we understand as "text" in the modern era, are UTF8-encoded byte streams. If your "text" kit deals with ASCII rather than Unicode runes, it's that much less powerful, and likely full of painful edge cases that you now have to debug. (Note that UTF is a 1992 thing, it's been invented when UNIX was 20-something yro, and it's been around for 30+ years.)
Debuggability of anything is entirely up to your toolkit, the quality and comprehensiveness of that toolkit is what decides the battle.
The Linux kernel is de facto pretty tightly coupled with GNU stuff, but you don't get irate about that, so why does Systemd deserve your ire?
No it isn't, or Android, Alpine Linux, and Chimera Linux wouldn't work nearly as well as they do.
> you don't get irate about that, so why does Systemd deserve your ire?
And even if it were, systemd has a lot of problems that the classic GNU utils don't. We don't hate systemd just because of the tight coupling.
No it isn't. They go to great lengths to e.g. make sure they can be built with clang and not just gcc. And in the other direction, prior to systemd you could even swap out Linux on Debian for a different kernel.
It's really not; Linux is fine with ex. Alpine or Android userspace, and builds with clang.
> but you don't get irate about that,
Er, I mostly certainly do object strongly to the GNU monoculture too.
I'm fine with that.
> and increases the barrier to port software to other unix-likes.
Don't care about "other Unix-likes", and in fact I wish they didn't exist.
> The non-optional/default features have been buggy and difficult to replace.
Let's not pretend as if the pre-systemd crap wasn't even more buggy.
> The overreliance on dbus turns the “the unix philosophy” ;) away. Text as a universal communication medium, everything is a file, etc.
Dbus is a text-based protocol based on files though. What a silly complaint.
P.S. Dbus sucks, but thankfully it would be pretty easy to replace in systemd if somebody got sick enough of dbus.
As they say: working code or gtfo. Complaining about someone else's software project is so passé. No-one's forcing anyone to use systemd, Linux, or a computer.
What you right here just did, was exactly whining and complaining, except not even about anything that happened to you or that you have to deal with.
* socket activation
* dependency management of startup
* log control
* service supervision.
Except, it did so by interfacing with the operating system in its native language, for example: log files were text.
It is not useful to complain about bash scripts, the original design of init was indeed dated and you’d be hard pressed to find people who don’t think so; so its an invalid point to make in this discussion.
I’m also not saying we should have ported SMF, one complaint I have about it is that it was a product of its time and used XML (much like launchd on macos, which is actually another supervising init btw ;D).
However taking inspiration would have been good, instead of creating software that appears like it belongs on a Windows/DOS based operating system rather than a unix-like.
Why?
I hope you’re not actually responsible for anything.
While I have nothing to say about your general points - I am pretty neutral to systemd, but I really dislike how it makes porting software to BSDs harder - I have one question:
Why are you not using networkmanager on a desktop computer? I have only used networkd on a server where I needed things like MAC matching and device renaming.
Genuinely curious. On my desktop I used a wired connection, so NM is probably overkill, but I like how I can have a tray icon to manage my VPN and wireguard connections.
Even arch has opinions, even if they're much happier to mute them in the name of choice, but it's clear that your life is better if you stick to the happy path.
One of the foundations of Fedora is to be "first" and to integrate big changes like systemd before other distros. Things will break if you do that.
All software fails, which is why it’s important that I can debug/fix it when it fails.
That’s my point, I could fix what came before.
Similarly on Windows, the trouble is never that windows is a new system, it’s that windows by default does not log when issues occur except in special cases, that everything is compiled and inscrutable.
Without pdbs (or equivalent) you literally could not debug issues, which was not the case with comparable inits (SMF) or what came before (bash scripts with various execution styles).
This is not the gotcha you seem to think, and I’m drunk at the moment and typing on a phone- so all I have to say is get over yourself and engage properly with what I’m saying instead of being defensive and flippant.
Because the music was better.
> systemd has enabled so much missing and previously convoluted functionality.
At the cost of much other convolutions and BLOAT.
> If you want to live in the past, go run SunOS. You might need a dusty old tape drive, though.
Not really, there is always http://tribblix.org/ :-) Besides that NetBSD would probably be more fun.
Speaking of which reminds me of https://www.usenix.org/legacy/events/usenix01/freenix01/full...
& https://mewburn.net/luke/talks/auug-2003/
Ever heard of it?
Btw. https://postimg.cc/CZtH4rHp
Nao gätt off mai lawwnh!1!!