That’s funny. As I’ve been paying more and more attention to kernel development this year, I’ve found this to be disappointingly untrue. Kernel testing is actually in a pretty poor state right now IMO.
As if the same isn’t true for systemd release candidates? It is.
It’s not that long.
bcachefs has been merged. It’s been in mainline since 6.7. And yes, it has led to a tremendous amount of internal drama in the kernel mailing lists because they don’t actually manage this stuff that well. Testing has been among the biggest drama-causers with bcachefs.
I don’t understand how you can make this point, refute it in your last sentence, and then ignore yourself by just saying “it’s still a crazy number of lines”. The kernel is also a crazy number of lines, and yet you don’t seem to have an issue in that case.
This has been covered in this thread a dozen times already, but I’ll reiterate. systemd is a collection of tools. It is not one thing doing too many things. It is a lot of things in the same monorepo. Each of those things generally does its one job pretty well, and relatively independently from each other. Your udev bug isn’t really a good example of your point, because it wouldn’t have been any different if udev weren’t in the systemd monorepo. There was a bug in udev, which is a component that is rightly depended on by many others because of how low level it is. It’d be like saying that a bug in glibc affecting other programs indicates glibc violates the unix philosophy, which obviously doesn’t make sense.
I don’t know if the Linux kernel project is such a paragon of good test (or even general development) practice. It’s largely done manually, and quite prone to mistakes. The CI projects around it - which have only really existed since 2014 - do not cover the incredibly large set of modules, and even then hardware testing is notoriously difficult, especially for all those architectures.
I’d wager systemd’s testing is more rigorous simply because of project age and size, more recent and smaller projects tend to have a better baseline in terms of development practice - as much as the kernel punches above its weight.
I think I agree with @ElvishJerricco that the kernel is helped far more by its modularity, allowing for a happy core embraced by a large corona where nobody really looks too closely at the bugs.
The more often this stuff comes up the more I honestly question the place of “Unix Philosophy”. Unix is half a century ago. Do we really need to hamstring our architectures by stubbornly adhering to a narrow interpretation of something thought up by people working at the cradle of software engineering, and completely ignore how much has changed since then?
And that’s ignoring that, yeah, systemd really does not go against this philosophy very much by any reasonable interpretation…
There is lots of reasonable criticism of any software project (nix/os is hardly good “Unix Philosophy” either), but I don’t think vague allusions to project architecture from people clearly not involved in the relvant upstream explains every bug or misfeature.
For what it’s worth, @ma27, our generic “boot the kernel” tests didn’t catch the 6.12.2 regression either, though @spiage found it nigh-immediately.
$ git checkout 867db1d91e417f9a95f0d8af779dbb576f498d0f
$ nix-build -A nixosTests.kernel-generic.linux_6_12
/nix/store/f5n9l79jj3r3ig5zwrxl6kjs13prdvpl-vm-test-run-kernel-6.12.2
The fact this doesn’t happen on every single kernel release, given the number of ways of configuring the kernel, the architectures it runs on, and so forth, makes me believe that testing’s happening.
Now, did I run those test before merging? No, I ran on my machine, which also didn’t boot loop.
I understand I may have made some errors in my statements. I should have lead by saying I don’t know much about systemd development. Personally, I have distanced myself from systemd as much as possible, so I understand your frustration.
My main point was this: “Linux is meant to be customizable, not inherintly easy. I’m okay with putting up with broken packages if it means I get to choose my way as opposed to someone else’s decision.” I use openrc as my daily driver, so I know the struggle of having to put up with a systemd-reliant unix world. However, as shown by this thread, there are people genuinely interested in other init systems on NixOS maintream, and packages like sys-apps/systemd-utils on gentoo has been proven to work. You don’t need to give up everything from systemd, but I would rather have something a little more minimal running on PID1. I’m not calling for the NixOS developers to work on it for us, I’m asking them to make room for us to work alongside them.
It’s sad for me to see the Linux kernel swaying away from harsh guidelines just to bend to developers that don’t want to listen to them. I think Linus (not criticizing him in any way, he’s a great guy) should put harsher rules on contributions. If Linux is to survive the test of time, they need to follow the one thing proprietary companies do very well: strict guidelines.
Do we really need to hamstring our architectures by stubbornly adhering to a narrow interpretation of something thought up by people working at the cradle of software engineering, and completely ignore how much has changed since then?
I’m not calling for everyone to completely throw away anything not in line with the Unix philosophy, I’m just asking that we make the option available for people who would rather adhere to it. I personally like the Unix philosophy, but people who don’t care and would rather have a more supported, stable system should have an option for their use case too.
I mean, it’s not all black & white.
So me questioning whether the kernel’s testing is in an exemplary state or not doesn’t make we question whether they test their stuff at all.
But it has some irony that it’s claimed that systemd’s testing is bad and use the kernel as their perfect counter-example exactly on the day it happened.
That being said, @ElvishJerricco has summarized my impression pretty well:
That’s funny. As I’ve been paying more and more attention to kernel development this year, I’ve found this to be disappointingly untrue. Kernel testing is actually in a pretty poor state right now IMO.
But again, this doesn’t mean that no testing at all is happening.
I don’t see anyone stopping you from contributing to any existing projects, or making your own? But NixOS uses systemd and it doesn’t make sense to write code that NixOS won’t use.
Maintaining the existing distro is already effortful and time-consuming, I don’t see why that job needs to be made harder to suit the whims of like, 5 people.
And to be clear, further up in the thread you can see that there clearly is interest in making space for use cases NixOS currently does not cover, in particular making NixOS a viable platform for embedded devices. There just isn’t enough actual manpower around to make it happen.
Also, importantly, that discussion is not “let’s remove systemd because some people think it’s bad and we don’t like Poettering” but “let’s do stuff to provide features for embedded devices, this could mean adding an option to disable systemd if we want to target super tiny devices, pending on solving lower-hanging fruit first”.
If you have a clear value proposition for a change you’re interested in, and have the manpower to push the distro in that direction, just do it - this is open source, you can always make stuff do what you want, if enough other people want it too you might even be able to maintain it.
Void Linux which is built on runit, has a Nix package in its repo, although I’m really not sure how effectively it integrates into the system. I tried using it to install something and it threw a bunch of errors so I moved on.
Runit is a quite simple init system. it should be trivial to swap out runit and replace it with systemd, but not the opposite.
I work with embedded Linux devices, the OS is built with Yocto and is around 10 MB compressed despite having a very capable toolset. And still a lot of could be removed to go down in size if necessary. If we could use Nix as an OS build tool and achieve similar sizes while having Nix ergonomics that would be a really nice upgrade.
If NixNG, finix and whoever else wants a minimal runtime closure agrees on a common set of overrides and that gets put in a repository, yes, yes it would. It wouldnt be cheap, though we dont have to build all of nixpkgs. Doubt anyone needs a minimal chromium
i think the cost can be alleviated by sticking to one release channel (maybe small stable) because updates from hydra aren’t so large and so frequent, and as @MagicRB said about limiting scope
i could be incorrect but i believe @NotAShelf also had interest in such a thing, maybe even so far as planning to create such a thing…?
FWIW, we kind of already do this, in a manner of speaking. The initrd is a functional NixOS-based OS in the 10-20MB range. I’ve often wondered about retooling the initrd to just function as the OS rather than mounting and switching to a root FS. With systemd initrd, you’d be surprised how pleasant the initrd environment can be.
±1 from me, you dont need systemd. You need a somewhat competent service manager. dinit for example is imo better than finit for this. finit relies on runlevels, dinit, like systemd, is completely free-form.
There could also be a situation where there is a non-nix generated boot with some initrd for potential recovery needs and nix would be used only for the root file system image generation, but still it would have to be around or below 10 MB packed with the usual tools to be competitive with Yocto. I don’t know how small can we go with systemd, it might not be the main issue and I guess in that case it should be a different discussion. Anyway it would be cool if Nix could compete with Yocto.