[HN Gopher] InitWare, a portable systemd fork running on BSDs an...
___________________________________________________________________
InitWare, a portable systemd fork running on BSDs and Linux
Author : sunshine-o
Score : 129 points
Date : 2025-04-03 12:11 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| travisgriggs wrote:
| 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 wrote:
| Yeah, I thought systemd relied very heavily on Linux-native
| things like cgroups.
| zokier wrote:
| They implemented their own cgroups-like thing with fuse
| https://github.com/InitWare/CGrpFS
| netbsdusers wrote:
| 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 wrote:
| 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 wrote:
| 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
| cf100clunk wrote:
| > 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.
| jefurii wrote:
| Interesting... here's a good writeup on one way to do it:
| https://lecorbeausvault.wordpress.com/2022/02/07/debian-
| swit...
| cf100clunk wrote:
| And info direct from Debian here:
|
| https://wiki.debian.org/Init
| yuriks wrote:
| 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.
| cf100clunk wrote:
| A well-trending publicization via HN is a good help.
| markstos wrote:
| 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.
| skyyler wrote:
| "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.
| toast0 wrote:
| 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.
| FeepingCreature wrote:
| 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.
| GauntletWizard wrote:
| 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.
| skyyler wrote:
| 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.
| throw0101c wrote:
| Perhaps worth noting some differences:
|
| * https://github.com/InitWare/InitWare/wiki/Dropped-components
| LinuxBender wrote:
| This is a very reasonable list especially _resolved_. To their
| point DNS is handled very well by Unbound.
| dontlaugh wrote:
| 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 wrote:
| 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
| egorfine wrote:
| 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 wrote:
| Don't worry, there's `launchctl error` where you can get oh
| goddamn it it just prints the same useless fucking error
| amarshall wrote:
| 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...?
| 6SixTy wrote:
| 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.
| egberts1 wrote:
| 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 wrote:
| 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
| Ericson2314 wrote:
| 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!
| actionfromafar wrote:
| This is great!
| LinuxBender wrote:
| 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
| classichasclass wrote:
| 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.
| cf100clunk wrote:
| 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.
| cf100clunk wrote:
| > 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.
| donnachangstein wrote:
| 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 wrote:
| Agree and so I went looking and here is the reason: https://git
| hub.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 wrote:
| 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 wrote:
| What is a fork of systemd? launchd? My understanding was that
| systemd was inspired by launchd.
| flkenosad wrote:
| It probably was. But InitWave is a fork of systemd which
| means they have no choice but to use a copyleft license.
| renewedrebecca wrote:
| Something tells me Apple is not remotely interested in
| systemd.
|
| launchd, however works fine.
| wpm wrote:
| 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.
| exceptione wrote:
| 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 wrote:
| 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
| donnachangstein wrote:
| 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.
| immibis wrote:
| 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.
| udev4096 wrote:
| 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
| fc417fc802 wrote:
| 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.
| shawnz wrote:
| 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?
| swe02 wrote:
| 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.
| fc417fc802 wrote:
| 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).
| viraptor wrote:
| "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.
| craftkiller wrote:
| > signed shim
|
| How would they sign such a shim without my keys? I don't
| leave Microsoft keys enrolled on my laptop.
| badgersnake wrote:
| 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.
| DrillShopper wrote:
| > The cryptsetup, cryptenroll, unified kernel images, kernel
| signing and systemd-boot work nicely together.
|
| This has not been my experience across Debian and Arch
| mattpallissard wrote:
| 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.
| DrillShopper wrote:
| 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.
| donnachangstein wrote:
| 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.
| bogantech wrote:
| > frozen in time on some ancient version.
|
| Yeah that's a feature of Debian stable
| donnachangstein wrote:
| 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.
| exabrial wrote:
| somehow they missed journal though...
| duskwuff wrote:
| > 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.
| udev4096 wrote:
| 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!
| ConanRus wrote:
| yeah all we need is another systemd
| Vilian wrote:
| 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 wrote:
| 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.
| WD-42 wrote:
| This project has barely seen a commit in the last 4 years.
| betimsl wrote:
| Uhoh! -- The virus just spread a litl more!
| foresto wrote:
| 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
| ajross wrote:
| 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.
| johnea wrote:
| Yack! It's metastasized!!!
___________________________________________________________________
(page generated 2025-04-03 23:00 UTC)