Adding systemd to postmarketOS

[Posted March 6, 2024 by jzb]

The postmarketOS project, which produces a Linux distribution for phones and mobile devices, has announced that it is in the early stages of adding systemd to make it easier to support GNOME and KDE.

Users who prefer the OpenRC init system are assured they will still have that option when building their own images "as long as OpenRC is in Alpine Linux (on which postmarketOS is based)":

As with text editors, some people are really passionate about their favorite init systems. When discussing this announcement, please keep a friendly tone. Remember that we all share the love for free and open source software, and that our communities work best if we focus on shared values instead of fighting over what implementations to use.

Proof-of-concept images are available now for a limited set of devices. Users are warned these images are "buggy, unreliable, and NOT suitable for use on a device you rely on". Those interested in helping with testing and development are encouraged to follow along and report bugs on the systemd issue at GitLab.

Adding systemd to postmarketOS

Posted Mar 6, 2024 20:16 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (1 responses)

It is nice development, although let's not forget Jolla shipped systemd on phones a decade ago. (Along with Wayland compositor and btrfs)

Adding systemd to postmarketOS

Posted Apr 29, 2024 2:15 UTC (Mon) by linuxEnjoyer (subscriber, #170639) [Link]

What? That sounds awesome. What were they called? Were they any good?

Adding systemd to postmarketOS

Posted Mar 6, 2024 21:21 UTC (Wed) by parametricpoly (subscriber, #143903) [Link] (13 responses)

This is great. It's a bit annoying that there's so much drama and politics regarding systemd/musl integration. Apparently neither of the projects have any developers that like the other. It's a bit silly that systemd refuses to build with other libc implementations other than glibc. It's also silly that musl refuses to implement APIs that are needed by systemd. Apparently systemd doesn't need any of the braindead glibc features. On top of that Alpine folks seem to hate systemd.

Adding systemd to postmarketOS

Posted Mar 6, 2024 21:40 UTC (Wed) by atnot (subscriber, #124910) [Link] (2 responses)

From what is sounds like, some of them are far more frustrated with openrc and it's ilk than systemd at this point:

> i think @alpinelinux should join pmOS in getting off openrc, the project is basically on life support anyway
https://social.treehouse.systems/@ariadne/112044941290779320

Further elaborated in:
> is the benefit that we can say “we don’t use systemd, we’re proud of that”? and if so, how does that talking point make alpine better? because we don’t use systemd? a silly and circular argument, i think.
> it is like the people who are upset that X is losing maintainer interest while Wayland is gaining maintainer interest. but they aren’t interested in stepping up and doing the work to keep X as a viable alternative.
> the anti-systemd crowd offers the same flavor of argument: here is a bunch of random projects stitched together, and while it works for the proposer, it is more like a 60% solution rather than the 100% solution the proposer sells it as.
https://social.treehouse.systems/@ariadne/112047772821553658
> the moral of the story is that a 60% solution can be good enough *if* it eventually moves toward being a 80-90% solution.
> unfortunately, this is where the polyfills in combination with openrc (or perhaps runit or s6) have fallen short. when API coverage is effectively frozen in 2018 and its 2024 now, the only thing we have gained is a lot of maintenance burden for little reward.
https://social.treehouse.systems/@ariadne/112047732034083106

Adding systemd to postmarketOS

Posted Mar 9, 2024 6:23 UTC (Sat) by Heretic_Blacksheep (guest, #169992) [Link] (1 responses)

I'd argue that 60% coverage is always "good enough" if that 60% covers the necessities and aspirational features you're interested in. The rest is unnecessary fluff with potential downsides to the extra complexity (like using Pandas when all you need is to read an CSV file from Python). There's no need to reach for that extra 20-30% if those extra features aren't useful to the project. The "one size fits all" myth in computer technology needs to die, especially with the problems over complexity is creating with maintenance and security in 2024. It'll only get worse as time moves forward.

Perhaps they're correct that OpenRC isn't a good fit for their OS, but also perhaps, they need to reevaluate what it is they're trying to do and whether or not it aligns with the goals of their parent distribution.

Adding systemd to postmarketOS

Posted Mar 9, 2024 11:26 UTC (Sat) by khim (subscriber, #9252) [Link]

> I'd argue that 60% coverage is always "good enough" if that 60% covers the necessities and aspirational features you're interested in.

Even 20% coverage is perfectly fine if you are doing proper maintainership of the project and project is saying upfront what's in these 80% that are unsupported.

Unfortunately with X or systemd alternatives situation is entirely different: people who refuse to adopt Wayland or systemd are not willing to put their money where their mouth is and refuse to become maintainers.

Instead they demand that someone else should do the work for them.

That's much more significant problem then than the fact that 60% solution is not 80% solution.

> Perhaps they're correct that OpenRC isn't a good fit for their OS, but also perhaps, they need to reevaluate what it is they're trying to do and whether or not it aligns with the goals of their parent distribution.

Defining the goal for your distro is always a good thing, but so very few distros try to do that. Alpine Linux boldly proclaim that it's “small, simple and secure”, but it doesn't say how it achieves that and what are the tradeoffs: what you should expect from it and what you shouldn't expect from. It would be nice to dream that it's “small, simple and secure yet still provides all features to all users”, but that's obvious impossibility… so what's Ok for it not to provide? No one knows.

Adding systemd to postmarketOS

Posted Mar 7, 2024 11:14 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (7 responses)

Usually the issue to impose glibc is that you don't want to deal with weird bug reports that are actually the fault of the libc and not of your own code.

This has happened in python a few times, so they officially discourage people from using anything else than glibc.

Adding systemd to postmarketOS

Posted Mar 7, 2024 12:28 UTC (Thu) by bluca (subscriber, #118303) [Link]

For the systemd case we simply need some APIs, that need to be maintained by the libc providers. We actually don't care that much if that libc is called glibc or flibc or hlibc, we just want these handful of interfaces. And it's not much stuff, it's like 5 or 6 things, but we do _not_ want to reimplement them. The latest one for example is pidfd_spawn, which is like posix_spawn but returns a pidfd and is backed by the clone3 syscall with support for CLONE_INTO_CGROUP. Implementing complex syscall wrappers, with per-architecture magic pixie dust, belongs in the libc layer, and we very much prefer the libc maintainers to be in charge of ensuring it works on all architectures under the sun and whatnot, as they know best how to do that.

Adding systemd to postmarketOS

Posted Mar 8, 2024 11:26 UTC (Fri) by parametricpoly (subscriber, #143903) [Link] (5 responses)

That makes sense in the context of Python, but systemd is the init system, maybe the first package you'd install on a bare bones distro. Some of those distros wish to be light weight for various reasons. Glibc isn't light. Compared to musl, it's a piece of turd. Glibc won't work at all if you want statically linked binaries. Simply requiring glibc at this stage makes the whole init system unusable for many systems. It would really easy to just provide the missing code as some sort of compatibility library or so. Musl & systemd rocks.

Adding systemd to postmarketOS

Posted Mar 8, 2024 13:28 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (3 responses)

If a systemd developer (https://lwn.net/Articles/964676/) said that musl doesn't have API for some syscalls… I think that's a good enough reason.

I presume it just does not compile since the .h file doesn't have the expected definitions…

Perhaps you should consider contributing to musl to implement the missing features.

Adding systemd to postmarketOS

Posted Mar 8, 2024 13:53 UTC (Fri) by parametricpoly (subscriber, #143903) [Link] (2 responses)

I've seen discussions about this both in systemd and musl channels. I also know the musl's author (dalias). He's a great developer but doesn't like systemd at all. The musl channel has been full of people who think even openrc is too "heavy" so they prefer runit and other bsd/plan9 inspired niche init systems nobody uses in practice. I've also built systemd on top of musl with some patches. I don't think the patches were longer than 100 LOC or so. It's just that this was like 10 years ago and nothing has happened. It's becoming evident they don't want it to work.

Adding systemd to postmarketOS

Posted Mar 8, 2024 14:38 UTC (Fri) by calebccff (subscriber, #165861) [Link] (1 responses)

the patches aren't hugely complicated, some OE folks rebase them (see what we're shipping in pmOS here https://gitlab.com/postmarketOS/pmaports/-/tree/systemd/s...)

The impression I've gotten so far is that musl don't want some things (like the printf extensions) for various reasons, POSIX being a motivating factor. Worth noting that systemd isn't explicitly tied to glibc, and for some things like basename() they're unhappy with any existing approach and use their own instead.

We expect that we'll have to carry some stuff in an external library if it's clear that neither project is willing to take it. Lennart has blessed this approach at least (we can have this dependency expressed in systemd). As things go it could certainly be worse, hopefully we can start finding a constructive way forward as frankly this whole situation is just detrimental to the ecosystem as a whole.

Adding systemd to postmarketOS

Posted Mar 8, 2024 20:23 UTC (Fri) by parametricpoly (subscriber, #143903) [Link]

I appreciate your efforts greatly. Thanks!

Adding systemd to postmarketOS

Posted Mar 13, 2024 15:38 UTC (Wed) by zoobab (guest, #9945) [Link]

"Glibc won't work at all if you want statically linked binaries."

Glibc does not document how to make static binaries, and make them difficult to do, because the people behind it don't want static binaries.

The bare minimum would be to write it down in the documentation.

Static linking works like a charm with Musl.

Adding systemd to postmarketOS

Posted Mar 8, 2024 12:17 UTC (Fri) by alonz (subscriber, #815) [Link] (1 responses)

How do the postmarketOS folks build systemd on musl, then? I would expect they have their own patchsets - are they patching musl, systemd, or both?

Adding systemd to postmarketOS

Posted Mar 8, 2024 12:33 UTC (Fri) by bluca (subscriber, #118303) [Link]

Currently they use a set of out-of-tree patches imported from Yocto. As far as I understand, the plan for the future is instead to have out-of-tree patches for Musl or to provide a shim around it to provide the missing APIs.

Adding systemd to postmarketOS

Posted Mar 6, 2024 21:22 UTC (Wed) by Shiba (guest, #151620) [Link] (7 responses)

In a sane ecosystem you wouldn't need to change your init system to get tools.

Adding systemd to postmarketOS

Posted Mar 6, 2024 23:58 UTC (Wed) by gioele (subscriber, #61675) [Link]

> In a sane ecosystem you wouldn't need to change your init system to get tools.

The announcement clearly states that the initial impetus that made them start integrate to systemd is not the init system per se (although that will also be changed), but rather all the independent tools that are part of the systemd project, but not of systemd-pid1.

The non-systemd implementations of these tools (elogind, superd, waked, corecollector, etc) are no longer maintained, so postmarketOS is switching to the systemd-provided versions of them. And while they are at it, they are also moving to systemd-pid1.

Adding systemd to postmarketOS

Posted Mar 9, 2024 8:18 UTC (Sat) by Wol (subscriber, #4433) [Link] (3 responses)

> In a sane ecosystem you wouldn't need to change your init system to get tools.

You forget.

The systemd people are writing an init system for linux. If it doesn't work elsewhere, that's not systemd's problem.

The "anything but systemd" people are writing a generic init system that can be used to boot any OS. If it's not used anywhere but linux, that's not their problem.

I wouldn't call the latter setup a "sane ecosystem".

Cheers,
Wol

Adding systemd to postmarketOS

Posted Mar 9, 2024 18:05 UTC (Sat) by zdzichu (subscriber, #17118) [Link]

Small correction: systemd people are writing suite of low-level services and APIs for Linux. Init is just one of the services.

Adding systemd to postmarketOS

Posted Mar 9, 2024 19:01 UTC (Sat) by parametricpoly (subscriber, #143903) [Link] (1 responses)

> The "anything but systemd" people are writing a generic init system that can be used to boot any OS"

So how do I boot any of Windows 3.1 -- 11 with sysv bash scripts? Does it boot OS/2? DOS? Android? No. If I take the scripts from Debian, it won't even boot Fedora or Gentoo.

Adding systemd to postmarketOS

Posted Mar 9, 2024 19:51 UTC (Sat) by Wol (subscriber, #4433) [Link]

That's why, imho, it's not sane ... :-)

Cheers,
Wol

Adding systemd to postmarketOS

Posted Mar 9, 2024 11:33 UTC (Sat) by khim (subscriber, #9252) [Link]

If that's the definition the all POSIX systems are insane, because certain things can only be done by PID 1 process.

And that's also true for Windows and even MS-DOS or CP/M, thus… do we even have *any* “sane” OSes?

Adding systemd to postmarketOS

Posted Mar 12, 2024 2:18 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

I beg to differ, at least to some degree. I agree that tools shouldn't be made dependent on an init system for trivial reasons, like because the authors just can't be bothered to think about compatibility. But if the tools really need features of the init system to function, it shouldn't be up to those tool writers to make a compatibility layer so their tools work with older init systems. It should be up to the people who want to use the new tools with the old init system to make the two work together.

Nobody should be able to stop others from working on valuable new tools in the name of backward compatibility. That's the route to stagnation.

Adding systemd to postmarketOS

Posted Mar 6, 2024 22:14 UTC (Wed) by bluca (subscriber, #118303) [Link] (1 responses)

Adding systemd to postmarketOS

Posted Mar 6, 2024 22:58 UTC (Wed) by tamiko (subscriber, #115350) [Link]

Yup.

This is likely going to be one of those lwn articles that will hit >50 comments with a lot of people expressing their feelings with respect to init systems, or strong emotions towards developers they never met in person. Of course, all of this will be free of any actual technical discussion.

Honestly, the entertainment value of this is long gone. Like years ago. Which brings me to my response to your comment:

You mean munching very stale popcorn?

Adding systemd to postmarketOS

Posted Mar 6, 2024 23:30 UTC (Wed) by flussence (guest, #85566) [Link]

Objectively good move for a distro without a death wish.

OpenRC (and all init-system packaging in Gentoo besides) has been in a state of bureaucratic decay for a decade now, having all been hoarded by a random corporate contractor about as responsive to the outside universe as OpenOffice (while taking up as much space; they're the entire reason for the farcical metadata/AUTHORS file in the main package repo).

In the past *10* years the only noteworthy changes were to graft on a half-baked imitation of systemd's crash-restarting by frankensteining s6's internal organs inside-out in rcscript wrappers, another NIH pid1 just to avoid the 250kB sysvinit dependency, and being strongarmed into renaming several binaries because _Debian_, which has had zero to do with openrc outside of vestigially packaging it as a bargaining chip in their internal civil wars, was whining about filename conflicts. The punchline is that the crash recovery isn't even used by default!

It is not a healthy project. It was competitive in the 2000s, but only because the alternatives were einit, initng, or banging rocks together with LSB rc scripts and calling it astrophysics.

Adding systemd to postmarketOS

Posted Mar 7, 2024 5:05 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

I've been thinking about the systemd documentation (which is a mess), and one thing that might help going forward that might help everyone is classification of systemd functionality into groups. Something like: core dependency tracking, lifecycle, isolation, scheduling.

Then a project like FreeBSD can specify: "We want an init system that is compatible with systemd for all core dependency and lifecycle directives". This would be a more reasonable way going forward. Individual projects would be able to target that "core dependency+lifecycle" profile and be sure that it works on other systems.

systemd developers might dislike it, though.

Adding systemd to postmarketOS

Posted Mar 7, 2024 9:21 UTC (Thu) by bluca (subscriber, #118303) [Link] (3 responses)

> systemd developers might dislike it, though.

Nah, why would we? Will happily review PRs that add new documentation pages. Someone's got to do the work, though.

Of course it wouldn't mean internal implementation details would be set in stone, as that would be unreasonable, and you wouldn't ask the same to other projects like the kernel.

But what we consider public interfaces are already defined and described as stable in the documentation since time immemorial: https://systemd.io/PORTABILITY_AND_STABILITY/ and that includes "special" units that form transition points during system lifecycle, format of units, and more.

Adding systemd to postmarketOS

Posted Mar 7, 2024 20:12 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

It might result in people asking for stability where it doesn't quite exist right now.

Adding systemd to postmarketOS

Posted Mar 7, 2024 23:58 UTC (Thu) by Conan_Kudo (subscriber, #103240) [Link] (1 responses)

And that's a discussion worth having. As people depend on more of these things, the abstractions we rely on should be more firmly defined so they are well-understood.

Adding systemd to postmarketOS

Posted Mar 9, 2024 14:28 UTC (Sat) by Wol (subscriber, #4433) [Link]

That might also lead to the assumptions behind them being questioned ...

I think a lot of our stuff is built on belief and received wisdom, which may have not been true back then, but is certainly not true now ...

We have too many jobbing tradesmen (don't all professions ...) who know empirically what works, but don't know why. More importantly, they don't understand the fundamentals so they don't understand why things fail. Case in point, a parabolic arch in a bridge is a thing of beauty, but try to copy it without understanding what a parabola is, and your bridge won't last very long - probably falling down the day after you remove the construction supports!

Cheers,
Wol

Adding systemd to postmarketOS

Posted Mar 9, 2024 17:52 UTC (Sat) by marcH (subscriber, #57642) [Link] (2 responses)

> As with text editors, some people are really passionate about their favorite init systems. When discussing this announcement, please keep a friendly tone.

Choosing a text editor is generally a _personal_ decision, rarely ever affecting anyone else.

Adding systemd to postmarketOS

Posted Apr 29, 2024 5:45 UTC (Mon) by amacater (subscriber, #790) [Link] (1 responses)

It depends - when you rock up to a system in a datacentre and all it has is vim and you're a nano guy.
When your co=worker has difficulty sometimes understanding where stuff is / how it works and can only use nano but it isn't installed ... editors are much more than personal when you're trying to work with someone and you never know when knowing bare vi commands will come in handy. [Also: Windows-educated people claiming Windows has everything are _hard_work_ when it comes to them administering a Linux system].

UNIX was only ever intended to be a system for a department's secretary if I have the origin story correct - and the first thing to write was the editor ...

Adding systemd to postmarketOS

Posted Apr 29, 2024 19:56 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

Unix exists because the compute time for Ken Thompson's video game on the GE 635 had a billable value of seventy-five 1969 US dollars per session of play and another team at Bell Labs had a mostly unused PDP-7 sitting around.

The document processing thing was how it secured funding (and, thereby, a PDP-11/45 to port it to) to be more than a lab curiosity.