The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.<p>I think Systemd has a view that those things should reliably work together. I do not fancy a revival of the past where the user has to cobble a mesh of hopefully compatible libraries to achieve the same, taking weeks to study the Arch manual and resolving tons of gotcha's, all to be broken by next week's update.<p>The integration of all this stuff is now actively under test and maintenance with systemd.<p>And yes, the mentioned services also have an impact on the scope of service managing. Because if you have a unit that depends on a disk that needs to be unencrypted, this has to be resolved somehow in the right time.<p>I personally have had no need for systemd-resolved, but I think for *desktop* the list of droppable components is not large.<p>So maybe we should first have a conversation about the *desktop* vs *container-os* purpose?
This is an impressive project especially considering there are only 4 contributors. In my opinion this should have existed prior to systemd as it is more modular and very much optional <i>"The Suite may run either as an init system or as an auxiliary service management system under another init system."</i> This would have been a much better direction to go on Redhat in my opinion. I might still be using CentOS or one of the forks had systemd gone this direction. Just a personal preference of course but this does not feel forced and does not appear to commandeer functionality that should not be in the init process. It's also interesting to see it implemented in Alpine Linux already though I do not see it in the edge repo guess I have to build it. I use Alpine for all my VM and bare metal servers. This may be worth tinkering with. After this is extensively battle hardened I would like to see this as an installation <i>option</i> in Alpine, perhaps by setting a variable much like other installation options. There are also some interesting notes in Myths and Truths [1]<p>I hope they are still actively developing this. <i>last 5 commit dates which appear low for an alpha</i>. Maybe we need to contribute to this or raise funding.<p><pre><code> Date: Fri Aug 16 18:55:06 2024 +0100
Date: Mon Aug 12 22:33:49 2024 +0200
Date: Tue Feb 1 12:31:57 2022 +0000
Date: Tue Feb 1 12:31:42 2022 +0000
Date: Thu Dec 2 18:43:39 2021 +0000
</code></pre>
[1] - <a href="https://github.com/InitWare/InitWare/wiki/Myths-and-Truths" rel="nofollow">https://github.com/InitWare/InitWare/wiki/Myths-and-Truths</a>
This actually is kind of cool imo. There are things I like about systemd, and things I don’t. And this seems to fit much more closely around the things liked. Wish I had the time to play more with it on Linux. Would love to see Debian switch to something like this. Always felt like Debian was stuck between “all in” or “go without”. This would have been a nice middle ground choice to have had back in those days.
Writing software specifically for the BSDs then licensing it LGPL is like trying to sell them chilled, bottled poison from a roadside stand. What were they thinking?<p>That said, this sounds like what systemd <i>should have been</i>: a service control manager and nothing more, before they got a thirst for power and wanted to control any and every thing about the system.<p>But one of those already exists, it's called launchd, as long as you don't mind XML vs Windows INI syntax.
<a href="https://github.com/nixos-bsd/nixbsd" rel="nofollow">https://github.com/nixos-bsd/nixbsd</a> This is a very cool project that I hope will get upstreamed into NixOS proper, eventually.<p>I always thought InitWare would be good for that. See <a href="https://github.com/NixOS/nixpkgs/issues/26850" rel="nofollow">https://github.com/NixOS/nixpkgs/issues/26850</a> --- we've been discussing this before NixBSD existed, even!
I find the Dropped Components section encouraging. It has me imagining this project as a way to supplant systemd on Debian-based systems, for a compatible init system without the endless meddling and overreach that come with Poettering's systemd. That would be lovely.<p>(I won't spend my time detailing all my reasons for disliking systemd, but I have previously shared a small taste of them...)<p><a href="https://news.ycombinator.com/item?id=40217144">https://news.ycombinator.com/item?id=40217144</a>
It’s a pity macOS’s launchd couldn’t be adapted to Linux. It was an inspiration for systemd, so we might have had a single modern init for all common unix machines.
I have been using supervisord (<a href="https://github.com/Supervisor/supervisor" rel="nofollow">https://github.com/Supervisor/supervisor</a>) on alpine and it works great for running different daemon processes. It's lightweight and hasn't ever crashed, highly recommended!
Shoot. Almost there, at least for us cybersecurity-minded folks.<p>A need for a default-deny-all and then select what a process needs is the better security granularity.<p>This default-ALLOW-all is too problematic for today's (and future) security needs.<p>Cuts down on the compliance paperworks too.
Could someone who's more familiar with this project explain the advantages? To me, the main advantages of systemd are<p>1) It enables better separation of concerns, Twelve-Factor App style. For example, user-installed programs no longer need to connect to a logging daemon or execute a complex daemonization dance [1]. They can just run like a normal command-line program and dump logs to stderr.<p>2) It cuts down on integration problems, shell script glue, and the amount of different config syntaxes you have to know. Its architecture is modular with over 100 different binaries, so you can still pick-and-choose components and do privilege separation, but because these components are all coming from the same vendor, you know they're going to work well together.<p>3) It can do certain things far more reliably because it's willing to use Linux-specific APIs. For example, thanks to cgroups v2, it can supervise a process correctly no matter what kind of weird forking strategy the process is using.<p>Since this project is intended to be compatible across Unix-like systems, it won't be able to use Linux-specific APIs, so advantage 3 is gone. It looks like it dropped many components of systemd, so advantage 2 is partially gone too. Is this project just about getting some cross-cutting concerns into the init system and having better scheduling of service startup?<p>[1] <a href="https://www.freedesktop.org/software/systemd/man/latest/daemon.html#SysV%20Daemons" rel="nofollow">https://www.freedesktop.org/software/systemd/man/latest/daem...</a>
How does it compare to dinit, which is usable in Linuxes, BSDs and default used by Chimera Linux? The goals look identical, see
Introduction at <a href="https://github.com/davmac314/dinit">https://github.com/davmac314/dinit</a>.
Yeah... I wouldn't dare touch this. Probably the worst possible thing to happen to systemd would be a fork. It's an extremely complicated suite of software operating at a maximally exposed security context, and it's all but guaranteed that the small cadre of volunteers doing what amounts to a *BSD port aren't going to understand it deeply enough.<p>Pick the parts you want in your BSD and clone it. Don't port.
the advantage of systemd is the company backing, almost noone gonna donate for their init system, or their timezone system, or the network etc.., donating to their desktop enviroment is hard enough, but because all of that is inside systemd, with company backing, it's a good tradeoff, and people can donate directly to all the project instead of only one software
I'm running FreeBSD but I'm not exactly waiting for this to be included there, especially the way it was done on Linux (as the only option without any fallback)<p>What I like about FreeBSD is the rc.local idea which is a bit like Nix.
As FreeBSD UNIX user and sysadmin for about 20 years now - FreeBSD importing some systemd(1) fork is the LAST thing I want to see in the FreeBSD land.<p>In other words - to make it simple - get the fuck out of my lawn with that shit.