"systemd is a microkernel" - https://x.com/mycoliza/status/1765058565956587757

It seems like the biggest reason is "KDE and GNOME need systemd, so we need systemd".

In other words, systemd is winning because systemd is winning. Not because it's better.

Exactly, this is straight up pressure from GNOME to get systemd everywhere.

considering gnome runs on freebsd, that's just not true. The only work those folks had to put in was implementing one interface for what logind provides

Is gnome feature complete on freebsd? The article mentions gnome clocks wants to use timer units in the future, and gnome-session logs to journald.

As far as i know it is. As far as what's in the future no idea. I'm only speaking of the present.

Not really, it's garbage to the point that it only runs the X11 session, mutter can't even be compiled with Wayland support because it then tries to include some Linux-only header.

Eh, I'd say it's more likely pressure from RedHat. They benefit hugely from a complex ecosystem that creates demand for their consulting business.

  What fancy new features will we get with systemd?

    Granular privilege controls
    Powerful service dependency and security analysis features
    Tight cgroups integration both static and dynamic
    Socket activation (so you can print from your phone without having CUPS running all the time!)
    Built in boot-time analysis

also

  What's wrong with the polyfills?

...

  corecollector (systemd-coredumpd) 1: Not needed to run KDE and GNOME, but a very useful tool that many developers expect to be able to use to easily retrieve coredumps and associated metadata, without first figuring out how to configure them properly. It is great that there is a polyfill for it, but it is unmaintained since 2020. Plasma Mobile developer Devin wrote: "When debugging crashes, it’s incredibly useful to be able to view coredumps and attach a debugger after the fact with coredumpctl, this can help us obtain backtraces that would otherwise be hard to replicate again with a debugger attached. We can also then enable DrKonqi’s coredumpd integration, which can allow users to get notifications about process crashes and see them from a GUI. DrKonqi also has optional integration with our Sentry instance, which we can enable on developer installs to automatically send crashes to a web dashboard for us."

  - Granular privilege controls
  - Tight cgroups integration both static and dynamic

highlighting these in particular because of notable regressions in the systemd 254 -> 255 release. i think there's the perception that "systemd features are so easy to use" so therefore "systemd must be equally easy to maintain". it's not.

my advice to pmOS maintainers is to experience at least one systemd upgrade cycle before committing to it in any meaningful sense. that said, if the project has the bandwidth to maintain all of these different service managers/init systems, then yeah absolutely go for it.

Same as ten years ago.

nice! Two systemd features that would (IMHO) be especially useful in cell phones are:

- socket activation (as post says, "print from your phone without having CUPS running all the time")

- extra security. Many daemons drop privileges, but how many of them also isolate filesystem and install seccomp filters? With systemd, it could be "every one"

>socket activation

Is there a page that lists all of systemd's features?

what about tmpfiles? systemd-tmpfiles?

Most non-systemd-init distros use systemd-tmpfiles.

It’s one thing to launch a daemon with restricted privileges, but they often need to do privileged things at startup and then drop privileges them on their own. How would systemd help with that??

A lot of times you cat offload stuff to systemd. For example, a server might need privileged operations to open low port and set up logging. But with systemd, you use socket activation, so low port is opened for you, and logging is centralized, you just write to stdout. If this is not enough, you can have "ExecStartPre" command in unconfined mode. Great if you need to fix up permissions for example.

And if that does not work either, you can do privilege dropping twice. For example, systemd isolates filesystem, sets capabilities and NoNewPrivileges bit, but still runs daemon with root access. Daemon does whatever init it needs to do, and then drop the remaining privileges.

Does socket activation also stop the service after a while? In my experience dbus autostart services are always a huge mess, making it unpredictable what will be running after a while of using the computer, and they never stop themselves either.

I generally prefer either stopping/starting a service on demand or just keeping it always on, to ensure predictability and prevent buildup of never-stopped services.

When you set Accept=yes (new process per connection), then service naturally stops once connection closes. But that approach has relatively high per-connection overhead, so it cannot be used in a lot of cases. Still pretty useful for stuff like x11vnc.

For Accept=no, there is no auto-stop. I think it's because once service is activated, systemd no longer has reliable information about socket and thus cannot tell if the service is idle or not.

But what socket/dbus activation does is it enables services to exit on idle. And some services actually do it - systemd-timedated being one example. Any time I enter "timedatectl" I see it start and then exit.

would love to see tighter collaboration between pmOS and sxmo maintainers on this one. sxmo is sort of a pmOS-exclusive right now because it does all its own service management. seems like a great opportunity while pmOS is rethinking its service management to do it in a way that helps sxmo be more multi-distro capable.

Hm... time to move to bare Alpine for my Pinebook Pro.

I do not really need Gnome nor KDE.

Did you read the post?

It's an option now. If you don't want it, don't install it.

> I do not really need Gnome nor KDE.

Then it's unlikely that this change will impact you. You probably already need to build your own image, just build without systemd.

Oh hell yeah! The cell phone server idea just became a lot more viable for this Sysadmin.

Just now? pmOS was probably the last popular mobile distro that didn't default to systemd yet.

It's also the only one that worked on first try on my OnePlus 6.

(For a certain value of "worked")

I don't think most other ones are viable outside of a Pinephone.

My OnePlus 6 running Kupfer (Arch Linux ARM) [0] and my Shift6mq running Mobian [1] (Debian blend) in dual boot from microSDXC card [2] would like to have a word. Droidian (Halium-based Debian) also supports the enchilada.[3]

And then, there's also NixOS mobile [4]. They all have had systemd before this.

[0] https://kupfer.gitlab.io/, setting up kupferbootstrap can be hard though, especially if you don't have docker set up on that system already.

[1] https://wiki.debian.org/InstallingDebianOn/OnePlus/OnePlus6 To be frank though, I failed at installing Mobian on sdm845 hardware earlier myself, too.

[2] https://wiki.debian.org/InstallingDebianOn/SHIFT/SHIFT6mq#In...

[3] https://devices.droidian.org/#/devices/enchilada

[4] https://mobile.nixos.org/devices/oneplus-enchilada.html

Mobile NixOS is mostly dead. Last successful hydra build for op6 was in January 2023.

Bluetooth refused to turn on in mobian, I'm not sure why.

Resistance is futile, you will be assimilated...

> Is Alpine cool with this?

> We have shared this blog post with the Alpine devs before this publication, and we hope that they understand our reasoning.

So then they weren't cool with it, huh?

Seems like kinda a weird Q&A question regardless, who cares if Alpline is cool with it or not? It doesn't actually matter?

I think it's quite important to have a good relation with upstream developers. You don't want to get into the situation that Manjaro got in with Arch Linux.

Arch largely hated the idea of Manjaro and their users from day one, as it 'goes against the spirit of Arch', whatever that means.

That the team was(still is?, not sure) rather incompetent didn't help things for sure, but certainly didn't cause the rift.

> Arch largely hated the idea of Manjaro and their users from day one, as it 'goes against the spirit of Arch', whatever that means.

Because it puts more work onto the maintainers of Arch having to deal with the issues by a distro that people claim is "basically Arch".

I'm actually really excited about this. With all the things on a phone that are constantly switching on and off, connecting and reconnecting and disconnecting and moving, etc. etc. Systemd's dependency management, etc. seems like a no-brainer. Sorry to the Systemd haters, I do get it, I don't like how programs are baking in Systemd dependency either, but to me, it's a big step in the right direction for modern computing init systems.

> With all the things on a phone that are constantly switching on and off, connecting and reconnecting and disconnecting and moving, etc. etc

Could I trouble you for an example? The only regular connection changes I can see are networking changes that are managed at a different layer, or things that are user-level applications.

Sure. Networking is the obvious one, then comes similar stuff like Bluetooth, then you've got stuff like peripherals; headphones, hardware keyboards, and to a lesser extent stuff like USB storage. You have state changes like charging and not charging. To a lesser extent stuff like switching SIMs or removing SD cards. More broadly, i.e., stuff that isn't networking or peripherals, you have stuff like the screen being on or not, wheyher the screen is locked or not, whether the phone has been unlocked since a restart (and therefore the filesystem still partially encrypted), you have power saving modes, dynamic brightness changes.

While a lot of these also apply to more traditional computing, I'd say on a phone that many of them are more prone to changing rapidly, part of a more integrated device (for instance, turning off your phone screen is usually a very different kind of action that merely turning off your monitor), and generally effect the function of the device to a greater extent. Would you agree?

It doesn’t actually answer the libc question.

> Our current understanding having spoken to systemd developers is that we should be able to find a path that brings us much closer to upstream, if not entirely.

What’s the path here? Running glibc on Alpine?

Either that or something else, like Mobian, with apk I guess.

"Our current understanding having spoken to systemd developers is that we should be able to find a path that brings us much closer to upstream, if not entirely."

Adapt or don't offer GNOME/KDE (get fscked), classic Red Hat!

Dupe: https://news.ycombinator.com/item?id=39624181 (0 comments)