Sixos: A nix OS without systemd [video]
362 comments
·January 31, 2025sidkshatriya
Can anybody explain to me again why systemd is so bad ? Genuinely I'm not sure anymore: It is chock full of features and it gets the job done. Since it is used in a lot of big distributions it gets a lot of fixes, updates, testing and feature improvements regularly.
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.
serbuvlad
I think this is as good a time as any to reread "The Rise of Worse is Better".
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.
actionfromafar
Exactly, for some values of "good enough". (Unfortunately IMNSHO) Systemd cannot be toppled by all-out assault. It must be subverted. Looking forward to reimplementations and/or shims which provide the Systemd API but are reimplementations.
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.
danudey
> Looking forward to reimplementations and/or shims which provide the Systemd API but are reimplementations.
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.
serbuvlad
Yeah. Exactly. It's also how Wayland and Pipewire managed to win: by being backwards compatible with X and Pulseaudio, while also overcoming their shortcomings.
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).
throw7
Subversion is key. Remember when "performance" was the key reason for moving to systemd (scripts are sooo slow). To subvert, you need some lever and the chink in the armor to break in.
einpoklum
D-Bus is good enough for all sorts of things. But you absolutely don't need a behemoth like systemd to use D-Bus. A D-Bus communication option can be added to existing programs and utilities, or new ones could be fashioned for which it is a central mode of operation; and still there would have been no an ever-growing pile of centrally-maintained and inter-dependent artifacts.
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.
einpoklum
s/SystemV/sysvinit/
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.
formerly_proven
> 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.
I'd wager the vast majority of (non-embedded / single-purpose) Wayland deployments are gnome and KDE.
t43562
They might be Raspberry Pi which doesn't use gnome or kde! :-)
serbuvlad
Obviously, but I'm talking about bare window managers, not DEs. Alternatives to i3, awesomewm etc. Different niche.
EasyMark
cosmic is going to be a great wayland windows manager.
ratorx
I think a lot of the arguments I’ve seen stem from “Unix philosophy” style arguments. Also, historically the systemd project has been quite hostile to user requests in some cases, which broke existing workflows for people.
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).
bonzini
> resolved, networkd, timesyncd
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.
graemep
Yes, but not using those seems to defeat the point of using systemd.
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.
gritzko
So, systemd is like "doing Linux services the Microsoft way"
teekert
Your remark may suggest that everything MS does is “wrong”. This is of course an extreme overstatement and all of their approaches should be evaluated on their own.
rkeene2
It's more like doing Linux services the UNIX(TM) way since it's more similar to other UNIX service managers like SMF from Solaris or SRC from AIX in the integration -- NT's service manager requires an active event loop which responds to messages.
As an aside, the reason I don't like systemd is because it's inferior to its UNIX counterparts -- especially SMF -- for system management.
danudey
Given that it was based off of the design of OS X's launchd, I think it's probably more accurate to say it's "doing Linux services the Apple way".
egorfine
resolved and timesyncd are intended to be removed by the end user of the operating system. Sort of like a transparent peel is intended to be removed by the buyer of a new shiny device.
I haven't seen anything worse than those two from systemd crowd.
eadmund
Resolved is useful if you frequently change networks (e.g. a laptop), particularly if you’re also using an overlay such as Tailscale. Unfortunately, like anything related to systemd it is flakey and buggy and the solution to most things is to restart it.
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.
EvanAnderson
It's worth pointing out that Lennart Poettering simply rubbed some people the wrong way in his communication, and that ended up reflecting on systemd, irrespective of the software itself. (I am not making a case that this is good or bad, right or wrong. Just pointing it out.)
t43562
It was absolutely the way it was done and the arguments use to shut up the opposition. Then the distros all just adopted it and it was case closed and &*@#$#@ you. This happened with GNOME turning into some attempt at a tablet/phone UI and that upset enough of us to result in Cinnamon and MATE.
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.
datadeft
And there is the track record:
https://security-tracker.debian.org/tracker/source-package/s...
happymellon
That looks not too bad considering what it does and the time range of CVEs
mariusor
Maybe you can do a comparison to another well known open source project and see how well systemd fares: https://security-tracker.debian.org/tracker/source-package/l...
egorfine
some?
Let's rephrase the question the other way: is there anyone who thinks that LP's attitude is fine?
smarkov
> People have a right to build substitutes and replacements -- I believe in the "Let a hundred flowers bloom" philosopy.
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.
f1refly
Usually, it's the distributions problem to package software. You as a software developer publish documentation on how to build your application and then simply wait for other people to do the packaging for you. The creation of services is the same, you can maybe create a recommendation, but the service definition is part of the package file and thus not your problem.
rcxdude
In practice, though, the packagers quite liked systemd, because it a) makes service definition easier than any other system, and b) it significantly increases the likelihood that the developer has already written a suitable service file (and developers will like that that is used, because it reduces the chance that a packager makes a mistake and increases their support burden).
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.
yxhuvud
Usually, this is not good enough. I as a software developer often make use of the package manager built into the language of choice and use that to distribute my software. I also commonly make use of package managers of languages that I don't use to install software.
We are overdue to package manager interop and common interfaces.
McDyver
I think you answered your own question:
> 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 :)
prmoustache
>Besides all this, the main issue, for me, is how it managed to spread and ingrain itself into distributions making them dependent on it.
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.
CRConrad
> Your choice of word (spread/ingrain itself) seems to imply there is malicious intent. Software do not sneak itself into distribution by themselves.
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?
guerrilla
This isn't true. A lot of higher level stuff (e.g. GNOME) assumes systemd.
egorfine
> seems to imply there is malicious intent
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?
taurknaut
> 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".
Hikikomori
How it managed to spread is no surprise. Linux desktop was a complete mess with consolekit and unmaintained stuff. Then they supported cgroups which distros wanted to use and since all the unmaintained stuff didn't there wasn't a lot of options.
gf000
Booting up a system is a complex domain. If you randomly cut a complex domain into pieces, you will have the exact same complexity PLUS a huge amount of additional complexity for all the communication/error handling between the different parts - what other complex domain uses million tiny tools? Does chrome use curl and then pipe it into a html renderer and whatnot? Sure, there are libraries (that's a different architectural layer though with less complexity to break, and functions don't decompose arbitrarily either). The unix's philosophy is more of a sounds good on paper, and there are certain cases where it applies - it's definitely not universal.
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.
graemep
> 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.
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.
egorfine
> You mean that individual distributions voted/decided separately, multiple times to choose the better tool?
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.
CRConrad
> Also, the core of systemd is not even particularly big. People often mix into completely optional modules
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"?
Vilian
>Besides all this, the main issue, for me, is how it managed to spread and ingrain itself into distributions making them dependent on it.
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
kennysoona
> Can anybody explain to me again why systemd is so bad ?
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.
robertlagrant
It would be good to know if it's as ergonomic as systemd. I know it's not perfect, and sometimes the docs are confusing, but it is pretty simple to create a service that starts on boot etc. No scripts required, really.
kennysoona
It's pretty easy, you can add stuff to a 'local' script that runs last, or just create a new service and rc-update add new-service to start it on boot.
Vilian
Half the things you said are straight up lies and the OpenRC is a good example how miniscule your world is
kennysoona
> Half the things you said are straight up lies
lol, no.
> the OpenRC is a good example how miniscule your world is
Weird attempt at an insult, but ok.
egorfine
> OpenRC perfectly meets my needs
What distro are you running?
kennysoona
Alpine. It's wonderful. I've always liked minimal distros, and Alpine actively facilitates that. It doesn't get in the way, has everything needed to run a modern desktop, and the focus on security and musl compatibility are huge pluses.
seemaze
I gave up systemd for openRC on Alpine. Much better suited to my own needs, and uptime is vastly improved.
generalizations
I've noticed the folks who like it tend to want to get other stuff done, don't care about the details, and want things to 'just work'. The ones who don't like it seem to be the folks who do low-level stuff and have to interact with more than it's "happy path" abstractions. i.e. the ones who actually have to care how it was architected.
Vilian
Sysadmins that have to care how the system is running and being organized behind the scenes gonna kill someone before they have to went back to bash script for system management, people who complains about systemd do it because ideological reasons, don't like LP, Unix philosophy or something, etc, or never learned it and want to argue that their mess of bash scripts, that they use solely to boot their system and nothing more, are somewhat more stable or secure
generalizations
From the problems and use case you're describing, that's the first category: sysadmins who just need stuff to work so they can move on.
egorfine
> it gets the job done
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.
lreeves
I'm sure you have other examples (and I'm not really asking for them) but your sshd example would make me dislike the choices Ubuntu made, not systemd. Like I don't blame systemd for snaps being so awful.
egorfine
You are technically right.
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.
jauntywundrkind
Sysvinit left everyone to their own ends to write their own bespoke special ways of configuring & running services. With no security options and no consistency.
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.
egorfine
Let me reiterate: sysvinit had the job done in an extremely inefficient way that it's not really feasible for long ago. Upstart tried to remedy that but failed.
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.
__MatrixMan__
This is pretty cool. I especially like the better encrypted boot support and that it seems to harmonize better with nixpkgs (https://discourse.nixos.org/t/sixos-a-nix-os-without-systemd...). Curious about the infusions bit.
It not having systemd seems like a bit of a distraction from all of the other stuff that has gone into it.
rollcat
> I especially like the better encrypted boot support [...]
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.
einpoklum
> The point of TPM is supposed to be that it makes "yoink the laptop" attacks unviable even for state-level actors
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.
rollcat
I'm specifically referring to TPM and/or SEP as a key escrow. No other commonly available hardware provides equivalent functionality. No point in going off topic on a philosophical/sociopolitical angle.
majoe
You're right. The slides about infusions and the discussion at the end about them were unexpectedly the most interesting part of the talk.
tazjin
amjoseph focused a lot on the s6-init stuff, but I really think that infusions and the way they lead to more composable system configuration is the key thing here.
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 ...
jackwilsdon
https://github.com/NixOS/nixpkgs/pull/372170 is a promising step towards running multiple instances of a service with separate configurations and decoupling from systemd.
likeabatterycar
systemd already has encrypted boot support. I suppose when you rip something out you have to reinvent all its functions. At that point, any rational person would question the reasons for doing so.
Like removing the transmission from a car out of spite then realizing you need a way to switch gears.
tinyrichard
So removing a transmission and installing/testing/improving a new design or way to solve the problem that hasn't been popularized isn't a worthy cause? How do you think we developed the first transmission? Or the various improvements we all take for granted these days? Yes, systemd can do this, but that isn't a reason to imply developing an alternative that can do the same, albeit in a different way, is irrational.
geocar
> systemd already has encrypted boot support.
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.
bythreads
Hear hear!, It's like flogging packages and frameworks at a problem without ever considering if it was easier/more efficient to roll your own.
jorvi
NixOS checks/enforces its own reproducibility via systemd in various ways. It seems unlikely to me that replacing something battle-tested with a bunch of self-rolled brittle scripts will make it more reliable.
jeffrallen
Or ripping the combustion engine out to make a better car with electric and then realizing you ALSO don't need the transmission!
imp0cat
And then later finding out that a transmission in an electric car will help you both with top speed and mileage, so you have to put it back.
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.
__MatrixMan__
See this is how we end up with things like electron.
mongol
The good thing about this that it is a Nix OS without systemd, not NixOS without systemd. systemd is so well integrated in NixOS that any attempt to introduce an abstraction to make it pluggable would come with serious disadvantages.
I am all for an alternative Nix OS trying new approaches though, and sixos seems quite innovative.
kombine
Guix also does not use systemd, but its own service manager Shepherd. Edit: the author of sixos mentions it, boils down to personal preference of not liking Scheme.
ethagnawl
It's a shame there isn't a distribution (at least that I'm aware of) which is dynamic and modular enough to allow choosing your own "process manager" at install or even on boot.
mtlmtlmtlmtl
Artix Linux does this. Arch sans systemd, and you have a choice between openrc, runit, s6, dinit, or even some combination of the 4. Any daemon type package will have a -runit/s6/dinit/openrc variant that includes the relevant scripts/configs.
lloeki
In a sense, nixpkgs is that.
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.
jchw
I believe Gentoo supports multiple init systems, but it's definitely a challenge no matter what.
colechristensen
Gentoo is fun and does indeed give you the choice but…
edoceo
But.... nothing. Gentoo is awesome. I have free KoolAid.
isatty
Compilation is so fast on modern processors that it’s not even much of a hassle.
Portage is the best package manager out of any distribution.
There are no buts. Gentoo is awesome.
LargoLasskhyfv
https://www.antixforum.com/forums/topic/unofficial-antix-23-...
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.
rahen
That's exactly what Devuan does. You pick your init system at install.
ethagnawl
Oh, that's interesting. I was vaguely aware of Devuan but I thought it's distinguishing feature (compared to Debian) was that it used ... _some init system_ that wasn't systemd.
null
poulpy123
As a simple linux user that recently tried nixos to power a very small server, I would say that systemd wasn't part of the issues I encountered at all. It was the confusion tooling, the documentation all over the place, and the lack of ressources on specific topics.
__MatrixMan__
I struggled through that phase and now nixos is pretty comfortable to me. Some of the improvements in sixos are attractive, but I'm afraid to try it because it's going to be the same thing but way worse. There's no sixos community, there's just this video, a forum post or two, and the codeberg repo. That's it.
snvzz
A nix OS w/o Linux would be interesting as well.
Microkernel multiserver systems could use more exposure.
Coolbeanstoo
Guix can run on top of the hurd https://guix.gnu.org/en/blog/2024/hurd-on-thinkpad/
mastertask
Another fork, similar to what happened with other Linux projects regarding systemd. The difference is that in NixOS and now SixOS (SexOS), things are more dramatic, and they love piling up a bunch of complex and unnecessary crap on top of Linux. :D
null
t43562
I have to admit I'm not a big fan of s6 - I found it very hard to understand the scripting language execline.
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.
mtillman
For those looking for a Linux that works like BSD, https://voidlinux.org/.
cbsks
Also see https://www.gentoo.org/
resonious
Or a linux that actually uses the BSD coreutils https://chimera-linux.org/.
gigatexal
Does it make ZFS on root stupid easy and has ZFS boot environments?
kennysoona
Alpine does. Just boot from the extended ISO and modprobe zfs and install zfs tools.
gf000
The normal, systemd NixOS does actually make it "stupid easy". It will fetch the latest kernel that is compatible with ZFS and has single-line config options for auto-snapshots, and the like.
gigatexal
Did not know this. Very cool. Does it also make it easy to replace grub with zfsboot environments?
ssl-3
Nope.
Void generally plays well with ZFS, including kernel updates, but installing on ZFS root is very much a DIY process.
nucleogenesis
Is the XBPS thing kinda like BSD ports?
ssl-3
Not really, no. It's just binary package system, ala apt or apk or whatever.
kennysoona
Better yet just use Alpine IMO.
Slides: https://cfp.cccv.de/media/38c3-community-stages/submissions/...
> 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.
(via https://news.ycombinator.com/item?id=42881772)