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?
> The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.
These are also all components which would be extremely difficult to make portable - they require tight integration with the kernel and its boot process. I can't imagine how you'd implement them in a portable fashion, short of either making changes to the kernel on one or both operating systems, or implementing a complex set of shims to make them present similar interfaces. Either one of those options would be a sizable project on its own - I can't fault the developer from shying away.
As someone who uses systemd, "boot security" is pointless. If someone has enough access to your hardware to try booting a different kernel, they have time to load a signed shim that passes secure boot and launches unsigned code.
The only boot security real users need is disk encryption.
"on a system not configured for boot security, you get no boot security" is indeed correct. If you care about boot security, your local platform doesn't give you the chance to boot custom kernels and not passing secure boot doesn't give you decryption keys.
The problem with boot security is that the computer has no way to know its owner from someone who isn't its owner. All it can go on is who was there first. Which, you guessed it, was Lenovo.
I have no problem with secure boot as a concept but I don't know how to implement it so it can't be used to lock you out of your own computer. And an implementation which allows that is worse than no implementation.
The owner is whoever controls the installed keys. I think the issue is one of misuse rather than implementation.
The firmware refusing to let you change the keys is the root of the problem but it's also useful as an anti theft measure when it's not being abused by OEMs. Boot security doesn't depend on that though.
In addition to the above, as an alternative implementation I believe measured boot and a sealed secret is also sufficient to implement boot security without the need for the firmware to manage user provided keys at all.
If the manufacturer wanted to conduct a supply chain attack on you, they wouldn't need secure boot to do it. They could just design an implant of their own using proprietary technology.
So why does the presence of secure boot as a user-controlled feature affect that risk calculation?
Because manufacturers aren't trying to add surreptitious implants. They're trying to prevent you installing operating systems other than the one they get a bulk discount if they force you to have.
Whatever the intent, the point stands: why would they need secure boot to do that? They could just do it with proprietary controls. So how does the existence of secure boot as a user-controlled feature affect that risk?
I think that is a uselessly reductive interpretation of what secure boot is because you could apply the same logic to any security technology. Why should we allow login passwords or user permissions or disk encryption, since those could be used as lock-out technologies by manufacturers, if they just ship them with defaults you can't control?
Manufacturers don't need any user-facing standardized controls to implement lockouts. So the possibility of a feature being used as a lockout shouldn't be a justification for taking away the option of having a user-controlled security feature. Taking it away from users isn't going to stop manufacturers from doing it anyway with proprietary technologies instead.
sbctl [0] makes secure boot a lot easier. you just enable setup mode from BIOS and it will take care of enrolling and managing the keys. Are you immibis from libera.chat by any chance?
There was this SixOS presentation[0] 2 months ago of a single man's own distro, among a lot of things he claims that he's created the most secure boot process ever
> 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.
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.
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).
An enjoyable perspective on how workload can affect techno-tribalism. Like many who have worked in, or run, mixed shops over the years, I've lamented the interpersonal friction that can happen amongst camps. It can be corrosive, almost to the point of destruction, at which point I've had to fire people for using terms like ''hater'' or worse. Good riddance, because we had work to do.
That's because Debian 'stable' has a half-assed implementation of systemd, frozen in time on some ancient version. So you are stuck waiting years between upgrades. Bookworm finally supports the crypto functions.
Arch OTOH was where these functions first worked out of the box.
It stops being a feature and becomes a bug bordering on retardation when they purposefully ship broken software.
First example coming to mind, TLS is broken in the version of OpenSMTPD that ships with Debian Stable.
Yes you read that correctly.
The version of OpenSMTPD in Debian Stable does not have functioning TLS. It's also not well documented why this is, things just don't work and you are forced to discover why.
It has to do with a broken dependency on their ancient version of OpenSSL. They refuse to patch it because muh stability - it requires a version jump. So you are forced to jump through hoops and install a newer version from backports if you expect TLS to work on your SMTP server.
Arch user here. These things work much nicer than any of the previous alternatives. Sure, kernel signing is a bit of a mess, but that's more of a product of how key-signing at a low-level works than anything. Cryptsetup, cryptenroll, unified kernel images, and systemd-boot worked for me out of box.
They very much did not for me. I beat things into shape with sbctl but it was very much an uphill battle.
idk why Arch seems allergic to packaging shim-signed (it's an AUR, why would I trust such a key component to essentialy a stranger?), but here we are I guess.
you can inspect the PKGBUILD file very easily. it's same as alpine's abuild and various other build file formats from distros. don't just blindly build it
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
The part I'm particularly impressed with is what they determined was better to leave out ( 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.
> 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.
This well-trending HN story is a great boost, I'm sure. There is clearly an interest.
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.
> Always felt like Debian was stuck between “all in” or “go without”
Debian can be configured at installation to go ''all in'' with systemd or ''go without'' if you prefer. The latter option pretty well mooted the purpose of the Devuan spinoff. In the Bullseye version it is possible to change a running system from using systemd to sysvinit or OpenRC.
I agree about seeing how Debian reacts to how InitWare develops from alpha.
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.
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).
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.
My point is that a lot of apparently "simple" services do in fact call fork internally. Just a few things I've seen:
* fork to periodically make a snapshot of server state, to avoid slowing down the main server
* spawn an external gzip to compress a log file
* spawn a handler for some file format
* spawn a daemon to actually handle some resource, which might be used by other processes too (this really should be a separate managed service, but in the anti-systemd world this is often not the case)
If everything is working fine, you'll only waste a bit of server RAM for a few seconds if you fail to kill the children alongside the parent. But the circumstances in which you want to restart the service are often not "everything is working fine".
The idea of using a third party init system has always been quite alien to BSDs, the sames goes for almost all other Unix-like systems, which are almost all developed with a greater deal of integration within the core system. Linux is exceptional in this respect, that it has ever had a diversity of init systems.
This war of words between the BSD community and systemd, as far as I've been able to tell, dates back to when Poettering went to the GNOME mailing list to propose making GNOME depend on systemd. He made this request with the proviso that it shouldn't necessarily be a hard dependency, so that needn't have been a problem in itself, but then he made a remark in an interview with linuxfr.org:
> I don't think BSD is really too relevant anymore, and I think that this implied requirement for compatibility with those systems when somebody hacks software for the free desktop or ecosystem is a burden, and holds us back for little benefit.
and as you can imagine this was ill-received by the BSD community.
Could systemd, or at least a useful subset of it, have been made cross-platform from the get-go? It would've taken more work. I don't think the amount of work necessary would have been particularly onerous, which I hope InitWare shows. It would have required making certain compromises like systemd being happy optionally running as an auxiliary service manager rather than as the init system.
In the end, though, Poettering has his preference to target GNU/Linux only, and he is entitled to that.
Yes, I much prefer this more nuanced take of "here's some things I like about systemd and here's some things I don't" then the blanket "everything about systemd sucks" feedback.
I wish this project well. I hope it improves compatibility with BSDs for more projects.
"everything about systemd sucks" people generally don't understand the problems that systemd is attempting to remediate, in my experience. Just repeating dogma that they heard someone they consider cool say.
Or perhaps, we don't have the problems that systemd is trying to solve. Or systemd creates new problems that we didn't need or want. Kind of like pulseaudio.
Yeah pulseaudio was like "you need this so you can have two apps playing music at the same time" entirely ignoring the existence of sound cards with mixers or the alsa soft mixer. Similarly, systemd was hyped at the time for, among others, allowing parallel service start entirely ignoring the several init systems that were already managing parallel start quite happily.
This turned out to be entirely the right approach, though, and it was probably pretty obvious even at the time. Sound Cards with built in mixers have all but died out. Everything they did has been eaten by software,
Even at the time, few games used an API where they managed multiple channels directly; Software mixing was commonplace from the 90s. Any game that wanted to play battle sounds was not relying on the mere 6-8 channels that cards from that time could handle.
Our modern Pipewire based workflow is remarkably simple and remarkably effective, and it's significantly an evolution of PA.
No, I hate PA cause it didn't work properly to the end. (Pipewire was better day 1 than PA ever was.) I just think that "you absolutely need PA to have multiple apps playing sound" was always nonsense, and the same sort of nonsense that was used to push systemd.
Yeah, that was total nonsense. Good cards existed. And if you didn't have a good card, alsa had a soft mixer. FreeBSD added a softmixer to OSS, too, so you didn't even need alsa. Worst case, you could run the Enlightenment sound daemon without Enlightenment and it was compact and just worked (as long as you had a simple sound setup)
I'm always happy to discuss sound cards with mixers, though! As a supporter of the Bloop Museum[1], I think that the "What might have been" if we had dedicated hardware for playing dozens or hundreds of sound files at a time is an interesting question. There's a lot of experimentation in the audio space that has kind of died out, because audio is so cheap - While over in in graphics, we're still seeing interesting advancements and dead ends.
I do. systemd solves a lot of my problems, actually. Of course all of systemd could be cobbled together by combining a dozen or so independent projects, but that mess is exactly why normal people (even normal computer people) shy away from Linux.
And I don't recall a lot of software working well when Pulse isn't available, so I don't know why people still bring it up. Perhaps it's because I wasn't there at the time, but I've only seen ALSA as "that audio system you use when you have nothing else available". I still need the PulseAudio-wrapper for Pipewire to be useful for my systems, so clearly the Linux world has moved to Pulse-first.
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.
I'll take the well documented (man launchd.plist) XML property list (well, XML rendered, they're usually in binary) any day over some flat unstructured nonsense. I loathe INI syntax.
In case someone gets the misapprehension that there is a contrast between systemd and launchd in terms of the "well documented" attribution, systemd configuration is also well documented e.g. man systemd.timer etc. I didn't know if launchd has an equivalent of timers, but it does and I've just read `man launchd.plist` "StartCalendarInterval" and compared it with `man systemd.timer` "OnCalendar". I would have said they're about equal. Launchd is more concise, but systemd talks a lot about the interactions with other settings and edge cases.
As for ini vs xml, I've generally found xml is a crueller syntax for humans than ini. At the time I started using systemd, it was a bit funny - the last time I'd been editing ini files was on Windows 3.11. But I think ini and toml are now once again reasonably common so I forgot about how out of place it felt at the time.
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...)
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?
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.
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]
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.
Kind of the main issue doing that is that Apple developed launchd behind closed doors, releasing periodically to open source. That kind of environment doesn't exactly inspire confidence that launchd on Linux could remain in sync with the main branch for very long nor that Apple will play nice with FOSS devs.
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…?
Launchd 2.0 changed the syntax for the launchctl commands (and made it closed source as it now heavily relies on XPC.Framework). The man page for launchctl lays it all out. Load and unload became "bootstrap" and "bootout". Start became kickstart. As far as I can remember enable/disable are still the verbs, though in order to see the status of jobs' "enablement" you have to use the poorly named "print-disabled". Though the latter only matters for jobs that can actually be disabled, ie, any that have the "Disabled" key set to true in their plist file. By default, jobs in the various LaunchAgents or LaunchDaemons directories are always enabled and always loaded at login or boot respectively.
I literally teach people how to use launchctl every other week. I've found it's unituitive for learners because init systems tend to be unintuitive because there is a lot of hidden action and state going on. It wasn't until I started using it on my own I could develop some instinct for it. Personally, I don't find launchd anything but more ergonomic than systemd. A few man pages and some experimentation and you're at least crawling.
Not to say it couldn't be improved; I'd love to know why a failed bootstrap can't call plutil to at least lint the goddamn plist to notify of basic formatting issues instead of printing the same useless error for everything under the sun. "Error 5: Input/Output error" might as well just be an exit status of 5 for all the help it gives me.
I 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!
> 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`.
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.
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
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.
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.
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?
> The list of dropped components is quite large. The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.
These are also all components which would be extremely difficult to make portable - they require tight integration with the kernel and its boot process. I can't imagine how you'd implement them in a portable fashion, short of either making changes to the kernel on one or both operating systems, or implementing a complex set of shims to make them present similar interfaces. Either one of those options would be a sizable project on its own - I can't fault the developer from shying away.
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
As someone who uses systemd, "boot security" is pointless. If someone has enough access to your hardware to try booting a different kernel, they have time to load a signed shim that passes secure boot and launches unsigned code.
The only boot security real users need is disk encryption.
"on a system not configured for boot security, you get no boot security" is indeed correct. If you care about boot security, your local platform doesn't give you the chance to boot custom kernels and not passing secure boot doesn't give you decryption keys.
There are multiple possible configurations. Only the most basic will permit an arbitrary payload as you describe.
I've never been entirely clear about the security model when the signed shim is permitted. I assume I'm missing some nuance.
Disk encryption alone won't protect you from either persistent malware (remote) or evil maids (local).
> The only boot security real users need is disk encryption.
Which becomes easy to bypass without boot security. If an adversary can modify code that executes in the boot process, they can steal your keys.
> signed shim
How would they sign such a shim without my keys? I don't leave Microsoft keys enrolled on my laptop.
You don't but 99.99% of people do :) Especially because most Linux distros use a key signed by Microsoft by default.
The “people” don’t really matter.
Anyone who needs a secure boot environment is having their own MOK and probably a private CA.
The problem with boot security is that the computer has no way to know its owner from someone who isn't its owner. All it can go on is who was there first. Which, you guessed it, was Lenovo.
I have no problem with secure boot as a concept but I don't know how to implement it so it can't be used to lock you out of your own computer. And an implementation which allows that is worse than no implementation.
The owner is whoever controls the installed keys. I think the issue is one of misuse rather than implementation.
The firmware refusing to let you change the keys is the root of the problem but it's also useful as an anti theft measure when it's not being abused by OEMs. Boot security doesn't depend on that though.
In addition to the above, as an alternative implementation I believe measured boot and a sealed secret is also sufficient to implement boot security without the need for the firmware to manage user provided keys at all.
If the manufacturer wanted to conduct a supply chain attack on you, they wouldn't need secure boot to do it. They could just design an implant of their own using proprietary technology.
So why does the presence of secure boot as a user-controlled feature affect that risk calculation?
Because manufacturers aren't trying to add surreptitious implants. They're trying to prevent you installing operating systems other than the one they get a bulk discount if they force you to have.
Whatever the intent, the point stands: why would they need secure boot to do that? They could just do it with proprietary controls. So how does the existence of secure boot as a user-controlled feature affect that risk?
The specific proprietary controls you're referring to are called "secure boot".
I think that is a uselessly reductive interpretation of what secure boot is because you could apply the same logic to any security technology. Why should we allow login passwords or user permissions or disk encryption, since those could be used as lock-out technologies by manufacturers, if they just ship them with defaults you can't control?
Manufacturers don't need any user-facing standardized controls to implement lockouts. So the possibility of a feature being used as a lockout shouldn't be a justification for taking away the option of having a user-controlled security feature. Taking it away from users isn't going to stop manufacturers from doing it anyway with proprietary technologies instead.
sbctl [0] makes secure boot a lot easier. you just enable setup mode from BIOS and it will take care of enrolling and managing the keys. Are you immibis from libera.chat by any chance?
[0] - https://github.com/Foxboron/sbctl
There was this SixOS presentation[0] 2 months ago of a single man's own distro, among a lot of things he claims that he's created the most secure boot process ever
> 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.
[0] : https://news.ycombinator.com/item?id=42884727
> but I don't know how to implement it so it can't be used to lock you out of your own computer.
You probably need Heads with Librem Key, like Purism offers for their laptops.
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.
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).
An enjoyable perspective on how workload can affect techno-tribalism. Like many who have worked in, or run, mixed shops over the years, I've lamented the interpersonal friction that can happen amongst camps. It can be corrosive, almost to the point of destruction, at which point I've had to fire people for using terms like ''hater'' or worse. Good riddance, because we had work to do.
> The cryptsetup, cryptenroll, unified kernel images, kernel signing and systemd-boot work nicely together.
This has not been my experience across Debian and Arch
That's because Debian 'stable' has a half-assed implementation of systemd, frozen in time on some ancient version. So you are stuck waiting years between upgrades. Bookworm finally supports the crypto functions.
Arch OTOH was where these functions first worked out of the box.
> frozen in time on some ancient version.
Yeah that's a feature of Debian stable
A broken implementation?
It stops being a feature and becomes a bug bordering on retardation when they purposefully ship broken software.
First example coming to mind, TLS is broken in the version of OpenSMTPD that ships with Debian Stable.
Yes you read that correctly.
The version of OpenSMTPD in Debian Stable does not have functioning TLS. It's also not well documented why this is, things just don't work and you are forced to discover why.
It has to do with a broken dependency on their ancient version of OpenSSL. They refuse to patch it because muh stability - it requires a version jump. So you are forced to jump through hoops and install a newer version from backports if you expect TLS to work on your SMTP server.
Arch user here. These things work much nicer than any of the previous alternatives. Sure, kernel signing is a bit of a mess, but that's more of a product of how key-signing at a low-level works than anything. Cryptsetup, cryptenroll, unified kernel images, and systemd-boot worked for me out of box.
They very much did not for me. I beat things into shape with sbctl but it was very much an uphill battle.
idk why Arch seems allergic to packaging shim-signed (it's an AUR, why would I trust such a key component to essentialy a stranger?), but here we are I guess.
you can inspect the PKGBUILD file very easily. it's same as alpine's abuild and various other build file formats from distros. don't just blindly build it
The AUR is just a repository of PKGBUILDs. You don't need to trust a stranger to use PKGBUILD.
Am on Arch and I use them with unattended boot(TPM) and they work flawlessly.
My cryptenroll is currently broken by the latest system update (I think it was a bios update). It’s better, but I’m not sure it’s good.
somehow they missed journal though...
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.
[1] - https://github.com/InitWare/InitWare/wiki/Myths-and-TruthsThe part I'm particularly impressed with is what they determined was better to leave out ( 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.
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.
> 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.
This well-trending HN story is a great boost, I'm sure. There is clearly an interest.
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.
> Always felt like Debian was stuck between “all in” or “go without”
Debian can be configured at installation to go ''all in'' with systemd or ''go without'' if you prefer. The latter option pretty well mooted the purpose of the Devuan spinoff. In the Bullseye version it is possible to change a running system from using systemd to sysvinit or OpenRC.
I agree about seeing how Debian reacts to how InitWare develops from alpha.
Interesting... here's a good writeup on one way to do it: https://lecorbeausvault.wordpress.com/2022/02/07/debian-swit...
And info direct from Debian here:
https://wiki.debian.org/Init
The repo has had 3 commits in the last 4 years or so. I don't think it's going to get developed from alpha unless something suddenly changes.
A well-trending publicization via HN is a good help.
Yeah, I thought systemd relied very heavily on Linux-native things like cgroups.
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.
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).
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
My point is that a lot of apparently "simple" services do in fact call fork internally. Just a few things I've seen:
* fork to periodically make a snapshot of server state, to avoid slowing down the main server
* spawn an external gzip to compress a log file
* spawn a handler for some file format
* spawn a daemon to actually handle some resource, which might be used by other processes too (this really should be a separate managed service, but in the anti-systemd world this is often not the case)
If everything is working fine, you'll only waste a bit of server RAM for a few seconds if you fail to kill the children alongside the parent. But the circumstances in which you want to restart the service are often not "everything is working fine".
This is what I was wondering when I searched and found this project: was systemd designed in a way it would inevitably leave behind the BSDs?
Because we always assume the BSDs rejected systemd but it might just be that they were put in a situation where they had no choice.
The idea of using a third party init system has always been quite alien to BSDs, the sames goes for almost all other Unix-like systems, which are almost all developed with a greater deal of integration within the core system. Linux is exceptional in this respect, that it has ever had a diversity of init systems.
This war of words between the BSD community and systemd, as far as I've been able to tell, dates back to when Poettering went to the GNOME mailing list to propose making GNOME depend on systemd. He made this request with the proviso that it shouldn't necessarily be a hard dependency, so that needn't have been a problem in itself, but then he made a remark in an interview with linuxfr.org:
> I don't think BSD is really too relevant anymore, and I think that this implied requirement for compatibility with those systems when somebody hacks software for the free desktop or ecosystem is a burden, and holds us back for little benefit.
and as you can imagine this was ill-received by the BSD community.
Could systemd, or at least a useful subset of it, have been made cross-platform from the get-go? It would've taken more work. I don't think the amount of work necessary would have been particularly onerous, which I hope InitWare shows. It would have required making certain compromises like systemd being happy optionally running as an auxiliary service manager rather than as the init system.
In the end, though, Poettering has his preference to target GNU/Linux only, and he is entitled to that.
Very informative, thank you.
The BSDs are not in competition with Linux so there's really no concept of being "left behind"
They implemented their own cgroups-like thing with fuse https://github.com/InitWare/CGrpFS
Yes, I much prefer this more nuanced take of "here's some things I like about systemd and here's some things I don't" then the blanket "everything about systemd sucks" feedback.
I wish this project well. I hope it improves compatibility with BSDs for more projects.
"everything about systemd sucks" people generally don't understand the problems that systemd is attempting to remediate, in my experience. Just repeating dogma that they heard someone they consider cool say.
Or perhaps, we don't have the problems that systemd is trying to solve. Or systemd creates new problems that we didn't need or want. Kind of like pulseaudio.
Yeah pulseaudio was like "you need this so you can have two apps playing music at the same time" entirely ignoring the existence of sound cards with mixers or the alsa soft mixer. Similarly, systemd was hyped at the time for, among others, allowing parallel service start entirely ignoring the several init systems that were already managing parallel start quite happily.
This turned out to be entirely the right approach, though, and it was probably pretty obvious even at the time. Sound Cards with built in mixers have all but died out. Everything they did has been eaten by software,
Even at the time, few games used an API where they managed multiple channels directly; Software mixing was commonplace from the 90s. Any game that wanted to play battle sounds was not relying on the mere 6-8 channels that cards from that time could handle.
Our modern Pipewire based workflow is remarkably simple and remarkably effective, and it's significantly an evolution of PA.
I find it indicative of the quality of these complaints that sound cards with mixers were brought up at all. As if that's a good reason to hate PA.
No, I hate PA cause it didn't work properly to the end. (Pipewire was better day 1 than PA ever was.) I just think that "you absolutely need PA to have multiple apps playing sound" was always nonsense, and the same sort of nonsense that was used to push systemd.
Yeah, that was total nonsense. Good cards existed. And if you didn't have a good card, alsa had a soft mixer. FreeBSD added a softmixer to OSS, too, so you didn't even need alsa. Worst case, you could run the Enlightenment sound daemon without Enlightenment and it was compact and just worked (as long as you had a simple sound setup)
I'm always happy to discuss sound cards with mixers, though! As a supporter of the Bloop Museum[1], I think that the "What might have been" if we had dedicated hardware for playing dozens or hundreds of sound files at a time is an interesting question. There's a lot of experimentation in the audio space that has kind of died out, because audio is so cheap - While over in in graphics, we're still seeing interesting advancements and dead ends.
[1] https://oldbytes.space/@bloopmuseum
I do. systemd solves a lot of my problems, actually. Of course all of systemd could be cobbled together by combining a dozen or so independent projects, but that mess is exactly why normal people (even normal computer people) shy away from Linux.
And I don't recall a lot of software working well when Pulse isn't available, so I don't know why people still bring it up. Perhaps it's because I wasn't there at the time, but I've only seen ALSA as "that audio system you use when you have nothing else available". I still need the PulseAudio-wrapper for Pipewire to be useful for my systems, so clearly the Linux world has moved to Pulse-first.
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.
Agree and so I went looking and here is the reason: 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.
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.
Something tells me Apple is not remotely interested in systemd.
launchd, however works fine.
Launchd was one of the inspirations for systemd anyway
What is a fork of systemd? launchd? My understanding was that systemd was inspired by launchd.
It probably was. But InitWave is a fork of systemd which means they have no choice but to use a copyleft license.
Ahhhh now the comment meaning clicked for me. I totally misunderstood it.
[dead]
I'll take the well documented (man launchd.plist) XML property list (well, XML rendered, they're usually in binary) any day over some flat unstructured nonsense. I loathe INI syntax.
In case someone gets the misapprehension that there is a contrast between systemd and launchd in terms of the "well documented" attribution, systemd configuration is also well documented e.g. man systemd.timer etc. I didn't know if launchd has an equivalent of timers, but it does and I've just read `man launchd.plist` "StartCalendarInterval" and compared it with `man systemd.timer` "OnCalendar". I would have said they're about equal. Launchd is more concise, but systemd talks a lot about the interactions with other settings and edge cases.
As for ini vs xml, I've generally found xml is a crueller syntax for humans than ini. At the time I started using systemd, it was a bit funny - the last time I'd been editing ini files was on Windows 3.11. But I think ini and toml are now once again reasonably common so I forgot about how out of place it felt at the time.
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 --- 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.
(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
Perhaps worth noting some differences:
* https://github.com/InitWare/InitWare/wiki/Dropped-components
This is a very reasonable list especially resolved. To their point DNS is handled very well by Unbound.
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/daem...
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.
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
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.
Don't worry, there's `launchctl error` where you can get oh goddamn it it just prints the same useless fucking error
Kind of the main issue doing that is that Apple developed launchd behind closed doors, releasing periodically to open source. That kind of environment doesn't exactly inspire confidence that launchd on Linux could remain in sync with the main branch for very long nor that Apple will play nice with FOSS devs.
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…?
Launchd 2.0 changed the syntax for the launchctl commands (and made it closed source as it now heavily relies on XPC.Framework). The man page for launchctl lays it all out. Load and unload became "bootstrap" and "bootout". Start became kickstart. As far as I can remember enable/disable are still the verbs, though in order to see the status of jobs' "enablement" you have to use the poorly named "print-disabled". Though the latter only matters for jobs that can actually be disabled, ie, any that have the "Disabled" key set to true in their plist file. By default, jobs in the various LaunchAgents or LaunchDaemons directories are always enabled and always loaded at login or boot respectively.
I literally teach people how to use launchctl every other week. I've found it's unituitive for learners because init systems tend to be unintuitive because there is a lot of hidden action and state going on. It wasn't until I started using it on my own I could develop some instinct for it. Personally, I don't find launchd anything but more ergonomic than systemd. A few man pages and some experimentation and you're at least crawling.
Not to say it couldn't be improved; I'd love to know why a failed bootstrap can't call plutil to at least lint the goddamn plist to notify of basic formatting issues instead of printing the same useless error for everything under the sun. "Error 5: Input/Output error" might as well just be an exit status of 5 for all the help it gives me.
I 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!
This project has barely seen a commit in the last 4 years.
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.
DAC: 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
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.
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
Uhoh! -- The virus just spread a litl more!
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.
This is great!
yeah all we need is another systemd
[dead]
[flagged]
[flagged]
Because systemd is actually good and useful. Better than init.d scripts, the windows sh*t and the macOS launchctl
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.
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.
Came to ask this too