
Portable systemd services - cheiVia0
https://lwn.net/Articles/706025/
======
m3rc
I used to spend time arguing with people on the internet about how systemd was
an actually very useful tool but I never changed any minds and didn't help
myself any. Now I just wait and watch for new helpful things it does to show
up and I live a much happier life.

~~~
badsock
I almost think there should be a divorce. Call it systemdOS and be done with
it. At that point every service it subsumes will be seen as a step closer to
the obvious end-goal rather than a point of contention. And the other OS can
be something like the Gnome2 fork MATE.

It's not a technical thing, it's cultural. The two sides are playing tug-of-
war with the same OS, and systemd's winning, but maybe it would be better to
have a positive culture around the changes they're making instead of always
having people dragging on the rope. Some forks have been good in the past -
EGCS/GCC for example.

~~~
SwellJoe
> Call it systemdOS and be done with it.

Every major Linux distro has chosen systemd as their future. I think that
means whoever wants something different needs to change their name, rather
than every major Linux distro changing theirs. Just as the Gnome 2 fans chose
a new name for their future based on that lineage.

~~~
snaky
> Every major Linux distro has chosen systemd as their future

Gentoo is a major Linux distro too.

~~~
belorn
Correct me if I am wrong here, but I thought Gentoo user had to make active
choices when it came to make, compile and configure an installation, and that
Gentoo as a distribution had a hands-off approach when it came to make
decisions for the user. Is there a "default" init system, where if the user
make no decision they end up with a specific one?

~~~
pdkl95
[https://wiki.gentoo.org/wiki/Comparison_of_init_systems](https://wiki.gentoo.org/wiki/Comparison_of_init_systems)

Gentoo officially uses OpenRC (and eudev), which is what you get if you follow
the installation handbook. However, Gentoo also encourages choice and allows
many options for init, daemon management, etc, which includes systemd. Other
options ( are also available, too, at least unofficially.

> if the user makes no decision

While OpenRC is the official default, the "compile and setup everything
yourself" nature of Gentoo makes this kind of statement somewhat irrelevant.
One of the major reasons to use Gentoo is the ability to pick the components
you want in your OS so it meets your specific needs. So yes, while there is a
default, the concept of having a "default" is less important when you are
installing everything manually.

------
sandGorgon
It's very interesting how the whole article (and Lennart) shies away from even
uttering "package manager" and instead talks about containers.

This is fundamentally an implementation of Lennart's blog post -
[http://0pointer.net/blog/revisiting-how-we-put-together-
linu...](http://0pointer.net/blog/revisiting-how-we-put-together-linux-
systems.html). That article used the words "We want an efficient way that
allows vendors to package their software " ... which was followed by a storm
of angry systemd-is-the-borg-it-needs-to-die tweets and articles.

Even on HN - the response to this article seems fairly muted... although it is
a bigger political issue than even init systems. I wonder what the response
would have been to "systemd introduces new portable packaging format"

~~~
oblio
If no one will say it, I will: it's stupid that we have multiple package
managers and package formats.

There's no fundamental technical reason Linux couldn't have just 1 extensible
package format and 1 extensible package manager. All the reasons for the split
are social ("I like A"), political ("we want to be able to control A") or
historical ("A came first, we built our house on A, we can't abandon A").

~~~
majewsky
The historical argument might be the biggest one, from my own experience with
the steaming pile of shit that is RPM:
[https://blog.bethselamin.de/posts/argh-
pm.html](https://blog.bethselamin.de/posts/argh-pm.html)

~~~
oblio
I actually recently took a much shallower dive through RPM than yours
([http://blog.oblio360.com/2016/08/23/rpm-
install/](http://blog.oblio360.com/2016/08/23/rpm-install/)). I knew that RPM
was not that loved as a format, but what you've described there truly is
"insane" (I know that you used that word many times in the article, but it
fits the situation).

------
dkarapetyan
Isn't ubuntu snap already doing all this? The competing standards I don't
think help in this regard. Now to make a "portable service" I will need to
make sure whatever I do can be used as a snap and a systemd portable service.

Why is it so hard to settle on a standard when it comes to this stuff? The
same confusion exists when it comes to rpm and deb packaging formats. At the
end of the day both do the same thing and yet to deliver software to redhat
and debian systems you have to double your packaging effort.

~~~
derefr
The RPM/Deb split, at this point, isn't so much about packaging formats, as it
is about dependency graphs. Even if the two distro "families" of Redhat and
Debian shared a common packaging format, a package would still have to be
built—or at least specified—twice for them, because each family would still
have its own set of deps that are factored out in incompatible ways to the
deps of the other family. (For example, in Debian land, if your package wants
to declare a dependency on OpenSSL, that might mean a package dependency on
any of 'openssl', 'libssl1.0.0', 'libssl1.0.0-dbg', or 'libssl-dev'. RHEL _et
al_ do not have an isomorphic set of packages that these dependencies could be
mapped to.)

~~~
vbernat
This is already the case for SuSE and Redhat. Package names are different, RPM
macros are different. Doing a package that works for both is gruesome. Also,
at the time of SysV, you had to use two different init scripts.

------
qwertyuiop924
I'm sorry, but I can't keep a straight face hearing the phrase "portable
systemd."

I don't care what init system you run, but if you're writing userland software
(GNOME, for one), than what init system I run is none of your damn business.
For that matter, ideally you'd at least try to support the *BSDs.

As much as Systemd is the borg, I could at least live with that. I cannot live
with the fact that systemd maintainers continue to say that having high-level
userland software link to libsystemd is viable and acceptable. I cannot live
with the fact that systemd continues to violate widely-accepted defaults for
no reason (kill all processes on logout? really?). I cannot live with the fact
that Lennart has widely stated that you should ignore POSIX and that all
systems other than Linux don't matter.

~~~
progman
> high-level userland software link to libsystemd is viable and acceptable

This is a direct violation of the KISS principle which made Unix and Linux so
great. Not only do they want to intertwine user software with system software,
now they even want an additional layer of abstraction on the _system_ level!

I think we need a counter strategy against the aggressive takeover of the
Linux land before it is too late. I have nothing against people who love
systemd. If they want it they should use it. But any Linux user should also
have the option to get rid of systemd _completely_ if it turns out to be a
failure.

Init systems and system services should be as replacable as desktop
environments! Only if systemd is aiming to be "portable" like that than I can
live in peace with it.

~~~
qwertyuiop924
>I think we need a counter strategy

The Gentoo folks, as well as many of us Arch users, are with you. Gentoo in
particular has been aggressively forking and maintaining patch sets for any of
the software that has succumbed to the cancer (the *kits, various desktop
software, DBUS, GNOME, and most notably udev. Although if they weren't needed
for some pieces of software I use, I'd gladly chuck 90% of that stuff). So
yeah, if you want to help, that's where to contribute your effort.

~~~
progman
> So yeah, if you want to help, that's where to contribute your effort.

Gentoo and Arch are good options. However, in the long term classical Linux
will likely only be able to run on retro systems and FREE HARDWARE! If Gentoo
and Arch want to survive they should focus on free hardware pretty soon.

I think so because upcoming mainstream hardware will likely all be based on
UEFI/SB. SB is yet optional but I expect it to be mandatory soon. Only Linux
with certified kernels -- likely systemd Linux -- will be supported on those
systems. I don't like that because I want to be able to install up-to-date
kernels and software at any time without messing around with proprietary
certificates.

The Monster 6502 [1] was an excellent starting point into a world of discrete
SMD cpus. I hope there will also be a 16/32-bit cpu capable to run Linux (or
its successor). At least 68katy [2] is capable.

The most promising project however is RISC-V which will hopefully be available
with non SB-mainboards.

[1] [http://monster6502.com](http://monster6502.com)

[2]
[http://www.bigmessowires.com/category/68katy/](http://www.bigmessowires.com/category/68katy/)

[3] [https://riscv.org](https://riscv.org)

~~~
qwertyuiop924
I'm dubious of that assertion, although it is good to know how the free
hardware projects are going. We may well get a cert for UEFI SB, and if we
don't, then someone will crack it sooner or later.

Honestly, the only thing that keeps me from migrating to the BSDs at this
point is Steam.

~~~
progman
> We may well get a cert for UEFI SB,

As long as the vendors cooperate you will be fine. We will see how it works at
Win 11+.

> and if we don't, then someone will crack it sooner or later.

Other people may be able to live with it but for me this is an unacceptable
option. Either a system fully supports Linux or BSD, or I take another one.

------
AceJohnny2
Tangentially, glad to see Jon finally put up a signup banner for non-
subscribers :)

(see discussion 3 months ago:
[https://news.ycombinator.com/item?id=12224408](https://news.ycombinator.com/item?id=12224408))

------
hardwaresofton
Excited to see where this goes. After some recent issues with running docker
on arch (vague devicemapper issues, inability to stop containers properly),
and my newfound love for systemd using it from day to day on my personal
computer (writing unit files is pretty darn easy), I've actually been
seriously considering going back to writing applications that just get run as
processes, and managed by something other than me.

If my understanding is right, the industry went:

CGI -> processes -> VMs -> containers

I'm thinking of going back to step 2.

------
Karlozkiller
This should surely stop the critics from saying systemd is doing too much and
is bloatful.

No, but seriously I understand the reason why you'd want this, but what stops
systemd from being divided into smaller modules? Like the Linux I'm used to.

~~~
SwellJoe
systemd is modular, and is divided into many components. There are several
dozen binaries in a systemd package. Where do you believe the lines should be
drawn differently?

~~~
mfukar
> There are several dozen binaries in a systemd package.

That's not what modular means. Can you use only parts of systemd if you wanted
to? Can I e.g. use the very useful dependency-based service initialisation but
keeping my log facilities and networking management intact?

~~~
SwellJoe
_" Can you use only parts of systemd if you wanted to?"_

Yes, though most distributions have chosen to use more than just the init
functionality.

 _" Can I e.g. use the very useful dependency-based service initialisation but
keeping my log facilities and networking management intact?"_

No (logs) and yes (networking). Logging from systemd components, as far as I
know, have to go through journald, but journald can send it as plain text to
syslog, if you want it to. So, kinda yes on that one, too.

networkd didn't even exist yet when many people began using systemd for their
init, and it is entirely possible to use other methods of managing your
network services. RHEL still, AFAIK, has a hybrid model that keeps a lot of
the old configuration files even though they have switched to systemd for a
lot of stuff. Maybe it uses networkd on the backend; I haven't needed to find
out, as the config files work the same way they always have.

I think the confusion comes from the fact that very few people _want_ to only
use one component of systemd. Even though you can, there is value in all of
the pieces working well together and providing a consistent interface and API.
Most distros that switch, choose to switch a lot of things over at the same
time, because it's just nicer to do so, not because they had to. And, the
people who hate systemd don't want _any_ of it, so they never learn enough to
know that they probably could get the bits from it they want without being
tied to all of it.

~~~
mfukar
There is value in only some of the pieces working together, too. I'm sure
having all the pieces together makes sense for some setups, but not all.

