<- Back
Comments (85)
- exceptioneThe 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?
- LinuxBenderThis 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
- donnachangsteinWriting 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.
- travisgriggsThis 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.
- Ericson2314https://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 --- we've been discussing this before NixBSD existed, even!
- throw0101cPerhaps worth noting some differences:* https://github.com/InitWare/InitWare/wiki/Dropped-components
- WD-42This project has barely seen a commit in the last 4 years.
- dontlaughIt’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.
- udev4096I have been using supervisord (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!
- forestoI 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
- egberts1Shoot. 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.
- Vilianthe 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
- matu3baHow 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.
- betimslUhoh! -- The virus just spread a litl more!
- johneaYack! It's metastasized!!!
- ajrossYeah... 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.
- actionfromafarThis is great!
- ConanRusyeah all we need is another systemd
- imglorp[dead]
- oguz-ismail[flagged]