Adding systemd to postmarketOS
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.
Posted Mar 6, 2024 20:16 UTC (Wed)
by zdzichu (guest, #17118)
[Link] (1 responses)
Posted Apr 29, 2024 2:15 UTC (Mon)
by linuxEnjoyer (subscriber, #170639)
[Link]
Posted Mar 6, 2024 21:21 UTC (Wed)
by parametricpoly (subscriber, #143903)
[Link] (13 responses)
Posted Mar 6, 2024 21:40 UTC (Wed)
by atnot (subscriber, #124910)
[Link] (2 responses)
> i think @alpinelinux should join pmOS in getting off openrc, the project is basically on life support anyway
Further elaborated in:
Posted Mar 9, 2024 6:23 UTC (Sat)
by Heretic_Blacksheep (guest, #169992)
[Link] (1 responses)
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.
Posted Mar 9, 2024 11:26 UTC (Sat)
by khim (subscriber, #9252)
[Link]
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. 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.
Posted Mar 7, 2024 11:14 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (7 responses)
This has happened in python a few times, so they officially discourage people from using anything else than glibc.
Posted Mar 7, 2024 12:28 UTC (Thu)
by bluca (subscriber, #118303)
[Link]
Posted Mar 8, 2024 11:26 UTC (Fri)
by parametricpoly (subscriber, #143903)
[Link] (5 responses)
Posted Mar 8, 2024 13:28 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (3 responses)
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.
Posted Mar 8, 2024 13:53 UTC (Fri)
by parametricpoly (subscriber, #143903)
[Link] (2 responses)
Posted Mar 8, 2024 14:38 UTC (Fri)
by calebccff (subscriber, #165861)
[Link] (1 responses)
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.
Posted Mar 8, 2024 20:23 UTC (Fri)
by parametricpoly (subscriber, #143903)
[Link]
Posted Mar 13, 2024 15:38 UTC (Wed)
by zoobab (guest, #9945)
[Link]
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.
Posted Mar 8, 2024 12:17 UTC (Fri)
by alonz (subscriber, #815)
[Link] (1 responses)
Posted Mar 8, 2024 12:33 UTC (Fri)
by bluca (subscriber, #118303)
[Link]
Posted Mar 6, 2024 21:22 UTC (Wed)
by Shiba (guest, #151620)
[Link] (7 responses)
Posted Mar 6, 2024 23:58 UTC (Wed)
by gioele (subscriber, #61675)
[Link]
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.
Posted Mar 9, 2024 8:18 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (3 responses)
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,
Posted Mar 9, 2024 18:05 UTC (Sat)
by zdzichu (guest, #17118)
[Link]
Posted Mar 9, 2024 19:01 UTC (Sat)
by parametricpoly (subscriber, #143903)
[Link] (1 responses)
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.
Posted Mar 9, 2024 19:51 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Cheers,
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?
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.
Posted Mar 6, 2024 22:14 UTC (Wed)
by bluca (subscriber, #118303)
[Link] (1 responses)
Posted Mar 6, 2024 22:58 UTC (Wed)
by tamiko (subscriber, #115350)
[Link]
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?
Posted Mar 6, 2024 23:30 UTC (Wed)
by flussence (guest, #85566)
[Link]
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.
Posted Mar 7, 2024 5:05 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
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.
Posted Mar 7, 2024 9:21 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (3 responses)
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.
Posted Mar 7, 2024 20:12 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Mar 7, 2024 23:58 UTC (Thu)
by Conan_Kudo (subscriber, #103240)
[Link] (1 responses)
Posted Mar 9, 2024 14:28 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
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,
Posted Mar 9, 2024 17:52 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (2 responses)
Choosing a text editor is generally a _personal_ decision, rarely ever affecting anyone else.
Posted Apr 29, 2024 5:45 UTC (Mon)
by amacater (subscriber, #790)
[Link] (1 responses)
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 ...
Posted Apr 29, 2024 19:56 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link]
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.
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
https://social.treehouse.systems/@ariadne/112044941290779320
> 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
> I'd argue that 60% coverage is always "good enough" if that 60% covers the necessities and aspirational features you're interested in.
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
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
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Wol
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Wol
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
Adding systemd to postmarketOS
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
Adding systemd to postmarketOS
Wol
Adding systemd to postmarketOS
Adding systemd to postmarketOS
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].
Adding systemd to postmarketOS