8 ms·

InitWare, a portable systemd fork running on BSDs and Linux

167 points by sunshine-o 2y ago

oguz-ismail 2y ago
[flagged]
- blankx32 2y ago
  Came to ask this too
- rurban 2y ago
  Because systemd is actually good and useful. Better than init.d scripts, the windows sh*t and the macOS launchctl
  - jeroenhd 2y ago
    For all of Windows' shortcomings, I think their service manager is quite good for something built two or three decades ago. They fell behind since, but it took a while for init.d to disappear in Linux and some distros still use it. I even think Microsoft had the right idea not to use 1970's main() and signalling code as service control, using dedicated callback APIs instead. Together with Windows' Task Scheduler and PowerShell, you can configure Windows daemons quite well. They're limited by problems like "services can't take command line arguments", though, which is unfortunate.
- AHTERIX5000 2y ago
  systemd is good. Also enjoyed SMF with Solaris. Maybe the best way to manage operating system services might be something else than bunch of scripts envisioned in the 70s.
travisgriggs 2y ago
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.
- ape4 2y ago
  Yeah, I thought systemd relied very heavily on Linux-native things like cgroups.
  - zokier 2y ago
    They implemented their own cgroups-like thing with fuse https://github.com/InitWare/CGrpFS https://github.com/InitWare/CGrpFS
  - netbsdusers 2y ago
    Systemd uses groups for two things: for tracking processes other than direct children of the service manager, and for imposing resource limitations. Both can be done with other mechanisms, like kqueue's EVFILT_PROC and login classes respectively. But my experience in any case was that hacking up systemd to build and run under BSD it didn't need cgroups at all for basic running. Supervision of `Type=simple` and `oneshot` services worked fine. It wasn't particularly surprising to see this as cgroups really aren't ideal as a tracking mechanism - under cgroups v1, you only had a "cgroup empty" notification available as far as tracking the lifetime of processes within a cgroup, and even that was unreliable and could be left undelivered! So systemd used them to augment a more traditional process supervisor. That's why Pottering insisted on having it be PID 1, and got subreapers added to Linux for the per user systemd instances so that they could get the more traditional SIGCHLD based notification of process exits.
    - o11c 2y ago
      Okay, but ... if you only get something that seems to work, but isn't actually reliable, what's the point? You seem to be wrong about cgroup v1; freezing works and is sufficient to reliably kill all children. Half-killed services was one of those really annoying problems back in the dark ages of sysvinit (not the most common problem, but perhaps the hardest to detect or deal with when it did come up).
      - netbsdusers 2y ago
        I'm saying that it did work perfectly fine and reliably for the common case of types oneshot and simple services. To expect it to work for type Forking services would be absurd since no mechanism would exist to even try to keep track of them. It's just a point to illustrate that systemd is not as intimately and irretrievably integrated with Linux features as some imagine. Freezers were never used by systemd as part of its process tracking mechanism. And cgroup emptiness notification was unreliable under cgroups v1. So that's not wrong. It used some horrible mechanism where a binary is launched (!) when the cgroup becomes empty. And that can fail to happen under situations of low memory availability. Related read is Jonathan de Boyne Pollard on cgroups:https://jdebp.uk/FGA/linux-control-groups-are-not-jobs.html https://jdebp.uk/FGA/linux-control-groups-are-not-jobs.html
egberts1 2y ago
Shoot. Almost there, at least for us cybersecurity-minded folks. A need for a default-deny-all and then select what a process needs is the better security granularity. This default-ALLOW-all is too problematic for today's (and future) security needs. Cuts down on the compliance paperworks too.
- westurner 2y ago
  DAC: Discretionary Access Control: https://en.wikipedia.org/wiki/Discretionary_access_control https://en.wikipedia.org/wiki/Discretionary_access_control : > The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control). Which permissions and authorizations can be delegated? DAC is the out of the box SELinux configuration for most Linux distros; some processes are confined, but if the process executable does not have the necessary extended filesystem attribute labels the process runs unconfined; default allow all. You can see which processes are confined with SELinux contexts with `ps -Z`. MAC is default deny all; MAC: Mandatory Access Control: https://en.wikipedia.org/wiki/Mandatory_access_control https://en.wikipedia.org/wiki/Mandatory_access_control
  - egberts1 2y ago
    Biggest problem is the use of a SELinux compiler into components understood only by SELinux engine. Does not help when the SELinux source text file is not buildable by function/procedure axiom: it is at its grittiest granularity, which ironically is the best kind of security, but only if composed by the most savviest SELinux system admins. Often requires full knowledge of any static/dynamic libraries and any additional dynamic libraries it calls and its resource usages. Additional frontend UI will be required to proactively determine suitability with those dynamic libraries before any ease of SELinux deployment. For now, it is a trial and error in part on those intermediate system admins or younger.
    - westurner 2y ago
      From https://news.ycombinator.com/item?id=30025477 https://news.ycombinator.com/item?id=30025477 : > [ audit2allow, https://stopdisablingselinux.com/ https://stopdisablingselinux.com/ ] Applications don't need to be compiled with selinux libraries unless they want to bypass CLI tools like chcon and restorecon (which set extended filesystem attributes according to the system policy; typically at package install time if the package provenance is sufficient) by linking with libselinux.
throw0101c 2y ago
Perhaps worth noting some differences: * https://github.com/InitWare/InitWare/wiki/Dropped-components https://github.com/InitWare/InitWare/wiki/Dropped-components
- LinuxBender 2y ago
  This is a very reasonable list especially resolved. To their point DNS is handled very well by Unbound.
dontlaugh 2y ago
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.
- freedomben 2y ago
  Yeah, I remember that being discussed pretty heavily in the early days of systemd (especially the socket activation model & parallelization) but (IIRC) there were some concerns about how it would integrate with the rest of the linux world which did things a lot differently than Mac OS, especially in the server space where Linux has to be near-universal with nearly any conceivable application running on top of it. That definitely smells to me like a subjective determination and there were people at the time who disagreed with that analysis, so I'm not presenting it as fact, just my recollection of the winning argument(s) at the time. Edit: Yes, I looked at the original "Rethinking PID 1" post and that seems to be the case[1] [1]: https://0pointer.de/blog/projects/systemd.html https://0pointer.de/blog/projects/systemd.html
- egorfine 2y ago
  I am managing a fleet of server-side macs for rendering purposes and launchd is one of the major PITA. It's horrible. A single output saying "I/O error" for any error, including typos in plist files adds to the pain.
  - wpm 2y ago
    Don't worry, there's `launchctl error` where you can get oh goddamn it it just prints the same useless fucking error
- amarshall 2y ago
  launchd’s ergonomics as a user are quite terrible, though. `start`? No…`kickstart`? No…`enable`? No…`load`? No…`bootstrap`? Maybe. I honestly don’t know. But either way, now is it the file path, the service name, or the fully-qualified name I need…?
  - 2y ago
Ericson2314 2y ago
https://github.com/nixos-bsd/nixbsd https://github.com/nixos-bsd/nixbsd This is a very cool project that I hope will get upstreamed into NixOS proper, eventually. I always thought InitWare would be good for that. See https://github.com/NixOS/nixpkgs/issues/26850 https://github.com/NixOS/nixpkgs/issues/26850 --- we've been discussing this before NixBSD existed, even!
actionfromafar 2y ago
This is great!
LinuxBender 2y ago
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 "The Suite may run either as an init system or as an auxiliary service management system under another init system." 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 option in Alpine, perhaps by setting a variable much like other installation options. There are also some interesting notes in Myths and Truths [1] I hope they are still actively developing this. last 5 commit dates which appear low for an alpha. Maybe we need to contribute to this or raise funding. 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 [1] - https://github.com/InitWare/InitWare/wiki/Myths-and-Truths https://github.com/InitWare/InitWare/wiki/Myths-and-Truths
- classichasclass 2y ago
  The part I'm particularly impressed with is what they determined was better to leave out ( https://github.com/InitWare/InitWare/wiki/Dropped-components https://github.com/InitWare/InitWare/wiki/Dropped-components ), especially the crypto and DNS portions which they quite reasonably determined they were insufficiently skilled to maintain (and modules that could be catastrophically damaging if you got them wrong). That's simply ample prudence and speaks well of the project.
  - cf100clunk 2y ago
    I too appreciated that they readily stepped back from reinventing a bunch of wheels. Doing it with humility adds a bit of polish to their project.
donnachangstein 2y ago
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? That said, this sounds like what systemd should have been: 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. But one of those already exists, it's called launchd, as long as you don't mind XML vs Windows INI syntax.
- evanphx 2y ago
  Agree and so I went looking and here is the reason: https://github.com/InitWare/InitWare/commit/3ee721035525dbb1dbdc1eb29d6b3d6663e0bc1a https://github.com/InitWare/InitWare/commit/3ee721035525dbb1.... They started with a specific version of systemd and have been mutating it since then, so the whole this is "tainted" with LGPL now.
- WD-42 2y ago
  Because it’s a fork of systemd which is GPL. So, working as intended. Sorry Apple, you’ll have to keep using your own init system.
  - larusso 2y ago
    What is a fork of systemd? launchd? My understanding was that systemd was inspired by launchd.
    - flkenosad 2y ago
      It probably was. But InitWave is a fork of systemd which means they have no choice but to use a copyleft license.
      - larusso 2y ago
        Ahhhh now the comment meaning clicked for me. I totally misunderstood it.
    - 2y ago
exceptione 2y ago
The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together. 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. The integration of all this stuff is now actively under test and maintenance with systemd. 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. I personally have had no need for systemd-resolved, but I think for *desktop* the list of droppable components is not large. So maybe we should first have a conversation about the *desktop* vs *container-os* purpose?
- udev4096 2y ago
  systemd has definitely made huge improvements to boot security which not a lot of "systemd haters" see. this is a great post from lennart: https://0pointer.de/blog/brave-new-trusted-boot-world.html https://0pointer.de/blog/brave-new-trusted-boot-world.html
  - donnachangstein 2y ago
    Most 'systemd haters' see boot security as unnecessary, or a toy no one would use, and that UEFI secure boot is a conspiracy orchestrated by Microsoft. It fits the personality profile of not wanting to learn new things. After all, we didn't need it in 2002, so why do we need it now? There is no fixing these people, so it doesn't make sense expending energy convincing them.
    - M95D 2y ago
      That's almost entirely correct, with one exception: > It fits the personality profile of not wanting to learn new things. 'systemd haters' learn a lot. They learn how to write manual boot scripts, set up mdev instead of udev, compile their own kernel, install their own u-boot or coreboot, strip binary blobs, etc. etc. They know MORE than the average systemd guy. They just don't want to learn systemd. Isn't the whole purpose of systemd to ease and automate administration and configuration, so the user need not care? Doesn't that imply that systemd admins/users know LESS? ---- Now let me make my own characterization of 'systemd enthusiasts'. These people are overworked sysadmins that hate manual configuration. They want it easy, everything automated, they want to not care about it, they want the distro to auto-do everything and not even ask, they want less admin work. Systemd does all these things for them and they are in heaven. They're so enthusiastic that they feel we should all be one big happy family under the systemd umbrella. But they fail too see that no company or manager will tolerate people that are _not_ overworked. When something becomes automated, people previously doing the manual job are fired. A 10 people non-systemd team that works day-and-night to set manually up boot, mounts, network, services, cron, backups, logs, etc., as soon as systemd automates the work, will be cut down to just one guy (or less) and he will still work day-and-night, same as before, doing the work of the entire team. And he won't be able to take break because there's nobody left to replace him. They also fail to see that resilience comes from diversity. Uniformity, systems where software is identical, updates are identical, configuration is identical, permissions are identical, etc., will also fail identically and probably at the same time, and will be hacked identically and at the same time (by automated bots/tools).
udev4096 2y ago
I have been using supervisord (https://github.com/Supervisor/supervisor https://github.com/Supervisor/supervisor) on alpine and it works great for running different daemon processes. It's lightweight and hasn't ever crashed, highly recommended!
ConanRus 2y ago
yeah all we need is another systemd
imglorp 2y ago
[dead]
Vilian 2y ago
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
matu3ba 2y ago
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 https://github.com/davmac314/dinit https://github.com/davmac314/dinit.
WD-42 2y ago
This project has barely seen a commit in the last 4 years.
betimsl 2y ago
Uhoh! -- The virus just spread a litl more!
foresto 2y ago
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. (I won't spend my time detailing all my reasons for disliking systemd, but I have previously shared a small taste of them...) https://news.ycombinator.com/item?id=40217144 https://news.ycombinator.com/item?id=40217144
ajross 2y ago
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. Pick the parts you want in your BSD and clone it. Don't port.
- wkat4242 2y ago
  Trust me we in BSD don't want it anyway. If we wanted Linuxisms we would have used... Linux. It's not just systemd that is a linuxism, but it relies heavily on other linuxisms like dbus. Which does work on BSD, sure. But it shouldn't be part of the core system which an init daemon obviously is.
johnea 2y ago
[flagged]
pkkm 2y ago
Could someone who's more familiar with this project explain the advantages? To me, the main advantages of systemd are 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. 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. 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. 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? [1] https://www.freedesktop.org/software/systemd/man/latest/daemon.html#SysV%20Daemons https://www.freedesktop.org/software/systemd/man/latest/daem...
wkat4242 2y ago
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) What I like about FreeBSD is the rc.local idea which is a bit like Nix.
vermaden 2y ago
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. In other words - to make it simple - get the fuck out of my lawn with that shit.

167 points by sunshine-o 2y ago

oguz-ismail 2y ago

[flagged]

blankx32 2y ago
Came to ask this too
rurban 2y ago
Because systemd is actually good and useful. Better than init.d scripts, the windows sh*t and the macOS launchctl
- jeroenhd 2y ago
  For all of Windows' shortcomings, I think their service manager is quite good for something built two or three decades ago. They fell behind since, but it took a while for init.d to disappear in Linux and some distros still use it. I even think Microsoft had the right idea not to use 1970's main() and signalling code as service control, using dedicated callback APIs instead. Together with Windows' Task Scheduler and PowerShell, you can configure Windows daemons quite well. They're limited by problems like "services can't take command line arguments", though, which is unfortunate.
AHTERIX5000 2y ago
systemd is good. Also enjoyed SMF with Solaris. Maybe the best way to manage operating system services might be something else than bunch of scripts envisioned in the 70s.

travisgriggs 2y ago

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.

ape4 2y ago
Yeah, I thought systemd relied very heavily on Linux-native things like cgroups.
- zokier 2y ago
  They implemented their own cgroups-like thing with fuse https://github.com/InitWare/CGrpFS https://github.com/InitWare/CGrpFS
- netbsdusers 2y ago
  Systemd uses groups for two things: for tracking processes other than direct children of the service manager, and for imposing resource limitations. Both can be done with other mechanisms, like kqueue's EVFILT_PROC and login classes respectively. But my experience in any case was that hacking up systemd to build and run under BSD it didn't need cgroups at all for basic running. Supervision of `Type=simple` and `oneshot` services worked fine. It wasn't particularly surprising to see this as cgroups really aren't ideal as a tracking mechanism - under cgroups v1, you only had a "cgroup empty" notification available as far as tracking the lifetime of processes within a cgroup, and even that was unreliable and could be left undelivered! So systemd used them to augment a more traditional process supervisor. That's why Pottering insisted on having it be PID 1, and got subreapers added to Linux for the per user systemd instances so that they could get the more traditional SIGCHLD based notification of process exits.
  - o11c 2y ago
    Okay, but ... if you only get something that seems to work, but isn't actually reliable, what's the point? You seem to be wrong about cgroup v1; freezing works and is sufficient to reliably kill all children. Half-killed services was one of those really annoying problems back in the dark ages of sysvinit (not the most common problem, but perhaps the hardest to detect or deal with when it did come up).
    - netbsdusers 2y ago
      I'm saying that it did work perfectly fine and reliably for the common case of types oneshot and simple services. To expect it to work for type Forking services would be absurd since no mechanism would exist to even try to keep track of them. It's just a point to illustrate that systemd is not as intimately and irretrievably integrated with Linux features as some imagine. Freezers were never used by systemd as part of its process tracking mechanism. And cgroup emptiness notification was unreliable under cgroups v1. So that's not wrong. It used some horrible mechanism where a binary is launched (!) when the cgroup becomes empty. And that can fail to happen under situations of low memory availability. Related read is Jonathan de Boyne Pollard on cgroups:https://jdebp.uk/FGA/linux-control-groups-are-not-jobs.html https://jdebp.uk/FGA/linux-control-groups-are-not-jobs.html

egberts1 2y ago

Shoot. Almost there, at least for us cybersecurity-minded folks. A need for a default-deny-all and then select what a process needs is the better security granularity. This default-ALLOW-all is too problematic for today's (and future) security needs. Cuts down on the compliance paperworks too.

westurner 2y ago
DAC: Discretionary Access Control: https://en.wikipedia.org/wiki/Discretionary_access_control https://en.wikipedia.org/wiki/Discretionary_access_control : > The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control). Which permissions and authorizations can be delegated? DAC is the out of the box SELinux configuration for most Linux distros; some processes are confined, but if the process executable does not have the necessary extended filesystem attribute labels the process runs unconfined; default allow all. You can see which processes are confined with SELinux contexts with `ps -Z`. MAC is default deny all; MAC: Mandatory Access Control: https://en.wikipedia.org/wiki/Mandatory_access_control https://en.wikipedia.org/wiki/Mandatory_access_control
- egberts1 2y ago
  Biggest problem is the use of a SELinux compiler into components understood only by SELinux engine. Does not help when the SELinux source text file is not buildable by function/procedure axiom: it is at its grittiest granularity, which ironically is the best kind of security, but only if composed by the most savviest SELinux system admins. Often requires full knowledge of any static/dynamic libraries and any additional dynamic libraries it calls and its resource usages. Additional frontend UI will be required to proactively determine suitability with those dynamic libraries before any ease of SELinux deployment. For now, it is a trial and error in part on those intermediate system admins or younger.
  - westurner 2y ago
    From https://news.ycombinator.com/item?id=30025477 https://news.ycombinator.com/item?id=30025477 : > [ audit2allow, https://stopdisablingselinux.com/ https://stopdisablingselinux.com/ ] Applications don't need to be compiled with selinux libraries unless they want to bypass CLI tools like chcon and restorecon (which set extended filesystem attributes according to the system policy; typically at package install time if the package provenance is sufficient) by linking with libselinux.

throw0101c 2y ago

Perhaps worth noting some differences: * https://github.com/InitWare/InitWare/wiki/Dropped-components https://github.com/InitWare/InitWare/wiki/Dropped-components

LinuxBender 2y ago
This is a very reasonable list especially resolved. To their point DNS is handled very well by Unbound.

dontlaugh 2y ago

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.

freedomben 2y ago
Yeah, I remember that being discussed pretty heavily in the early days of systemd (especially the socket activation model & parallelization) but (IIRC) there were some concerns about how it would integrate with the rest of the linux world which did things a lot differently than Mac OS, especially in the server space where Linux has to be near-universal with nearly any conceivable application running on top of it. That definitely smells to me like a subjective determination and there were people at the time who disagreed with that analysis, so I'm not presenting it as fact, just my recollection of the winning argument(s) at the time. Edit: Yes, I looked at the original "Rethinking PID 1" post and that seems to be the case[1] [1]: https://0pointer.de/blog/projects/systemd.html https://0pointer.de/blog/projects/systemd.html
egorfine 2y ago
I am managing a fleet of server-side macs for rendering purposes and launchd is one of the major PITA. It's horrible. A single output saying "I/O error" for any error, including typos in plist files adds to the pain.
- wpm 2y ago
  Don't worry, there's `launchctl error` where you can get oh goddamn it it just prints the same useless fucking error
amarshall 2y ago
launchd’s ergonomics as a user are quite terrible, though. `start`? No…`kickstart`? No…`enable`? No…`load`? No…`bootstrap`? Maybe. I honestly don’t know. But either way, now is it the file path, the service name, or the fully-qualified name I need…?
- 2y ago

Ericson2314 2y ago

https://github.com/nixos-bsd/nixbsd https://github.com/nixos-bsd/nixbsd This is a very cool project that I hope will get upstreamed into NixOS proper, eventually. I always thought InitWare would be good for that. See https://github.com/NixOS/nixpkgs/issues/26850 https://github.com/NixOS/nixpkgs/issues/26850 --- we've been discussing this before NixBSD existed, even!

actionfromafar 2y ago

This is great!

LinuxBender 2y ago

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 "The Suite may run either as an init system or as an auxiliary service management system under another init system." 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 option in Alpine, perhaps by setting a variable much like other installation options. There are also some interesting notes in Myths and Truths [1] I hope they are still actively developing this. last 5 commit dates which appear low for an alpha. Maybe we need to contribute to this or raise funding. 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 [1] - https://github.com/InitWare/InitWare/wiki/Myths-and-Truths https://github.com/InitWare/InitWare/wiki/Myths-and-Truths

classichasclass 2y ago
The part I'm particularly impressed with is what they determined was better to leave out ( https://github.com/InitWare/InitWare/wiki/Dropped-components https://github.com/InitWare/InitWare/wiki/Dropped-components ), especially the crypto and DNS portions which they quite reasonably determined they were insufficiently skilled to maintain (and modules that could be catastrophically damaging if you got them wrong). That's simply ample prudence and speaks well of the project.
- cf100clunk 2y ago
  I too appreciated that they readily stepped back from reinventing a bunch of wheels. Doing it with humility adds a bit of polish to their project.

donnachangstein 2y ago

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? That said, this sounds like what systemd should have been: 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. But one of those already exists, it's called launchd, as long as you don't mind XML vs Windows INI syntax.

evanphx 2y ago
Agree and so I went looking and here is the reason: https://github.com/InitWare/InitWare/commit/3ee721035525dbb1dbdc1eb29d6b3d6663e0bc1a https://github.com/InitWare/InitWare/commit/3ee721035525dbb1.... They started with a specific version of systemd and have been mutating it since then, so the whole this is "tainted" with LGPL now.
WD-42 2y ago
Because it’s a fork of systemd which is GPL. So, working as intended. Sorry Apple, you’ll have to keep using your own init system.
- larusso 2y ago
  What is a fork of systemd? launchd? My understanding was that systemd was inspired by launchd.
  - flkenosad 2y ago
    It probably was. But InitWave is a fork of systemd which means they have no choice but to use a copyleft license.
    - larusso 2y ago
      Ahhhh now the comment meaning clicked for me. I totally misunderstood it.
  - 2y ago

exceptione 2y ago

The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together. 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. The integration of all this stuff is now actively under test and maintenance with systemd. 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. I personally have had no need for systemd-resolved, but I think for *desktop* the list of droppable components is not large. So maybe we should first have a conversation about the *desktop* vs *container-os* purpose?

udev4096 2y ago
systemd has definitely made huge improvements to boot security which not a lot of "systemd haters" see. this is a great post from lennart: https://0pointer.de/blog/brave-new-trusted-boot-world.html https://0pointer.de/blog/brave-new-trusted-boot-world.html
- donnachangstein 2y ago
  Most 'systemd haters' see boot security as unnecessary, or a toy no one would use, and that UEFI secure boot is a conspiracy orchestrated by Microsoft. It fits the personality profile of not wanting to learn new things. After all, we didn't need it in 2002, so why do we need it now? There is no fixing these people, so it doesn't make sense expending energy convincing them.
  - M95D 2y ago
    That's almost entirely correct, with one exception: > It fits the personality profile of not wanting to learn new things. 'systemd haters' learn a lot. They learn how to write manual boot scripts, set up mdev instead of udev, compile their own kernel, install their own u-boot or coreboot, strip binary blobs, etc. etc. They know MORE than the average systemd guy. They just don't want to learn systemd. Isn't the whole purpose of systemd to ease and automate administration and configuration, so the user need not care? Doesn't that imply that systemd admins/users know LESS? ---- Now let me make my own characterization of 'systemd enthusiasts'. These people are overworked sysadmins that hate manual configuration. They want it easy, everything automated, they want to not care about it, they want the distro to auto-do everything and not even ask, they want less admin work. Systemd does all these things for them and they are in heaven. They're so enthusiastic that they feel we should all be one big happy family under the systemd umbrella. But they fail too see that no company or manager will tolerate people that are _not_ overworked. When something becomes automated, people previously doing the manual job are fired. A 10 people non-systemd team that works day-and-night to set manually up boot, mounts, network, services, cron, backups, logs, etc., as soon as systemd automates the work, will be cut down to just one guy (or less) and he will still work day-and-night, same as before, doing the work of the entire team. And he won't be able to take break because there's nobody left to replace him. They also fail to see that resilience comes from diversity. Uniformity, systems where software is identical, updates are identical, configuration is identical, permissions are identical, etc., will also fail identically and probably at the same time, and will be hacked identically and at the same time (by automated bots/tools).

udev4096 2y ago

I have been using supervisord (https://github.com/Supervisor/supervisor https://github.com/Supervisor/supervisor) on alpine and it works great for running different daemon processes. It's lightweight and hasn't ever crashed, highly recommended!

ConanRus 2y ago

yeah all we need is another systemd

imglorp 2y ago

[dead]

Vilian 2y ago

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

matu3ba 2y ago

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 https://github.com/davmac314/dinit https://github.com/davmac314/dinit.

WD-42 2y ago

This project has barely seen a commit in the last 4 years.

betimsl 2y ago

Uhoh! -- The virus just spread a litl more!

foresto 2y ago

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. (I won't spend my time detailing all my reasons for disliking systemd, but I have previously shared a small taste of them...) https://news.ycombinator.com/item?id=40217144 https://news.ycombinator.com/item?id=40217144

ajross 2y ago

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. Pick the parts you want in your BSD and clone it. Don't port.

wkat4242 2y ago
Trust me we in BSD don't want it anyway. If we wanted Linuxisms we would have used... Linux. It's not just systemd that is a linuxism, but it relies heavily on other linuxisms like dbus. Which does work on BSD, sure. But it shouldn't be part of the core system which an init daemon obviously is.

johnea 2y ago

[flagged]

pkkm 2y ago

Could someone who's more familiar with this project explain the advantages? To me, the main advantages of systemd are 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. 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. 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. 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? [1] https://www.freedesktop.org/software/systemd/man/latest/daemon.html#SysV%20Daemons https://www.freedesktop.org/software/systemd/man/latest/daem...

wkat4242 2y ago

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) What I like about FreeBSD is the rc.local idea which is a bit like Nix.

vermaden 2y ago

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. In other words - to make it simple - get the fuck out of my lawn with that shit.