Making Use Of Systemd Portable Services

[johanb]

I was a bit sceptical about these "Portable Services" to begin with, but after reading potterings blog post they seem pretty sane.

At least as long as people use this tool for the right task, of course someone is going to package something incredibly stupid into one of these services, just like someone recommended me once to install Minecraft in a damn docker container a few years ago because only a single line was needed to download it and another line to start it.

[jm111]

I think it's time for an anti-trust lawsuit against Red Hat, let's force Red Hat (Microsoft) to remove systemd portable services (Internet Explorer) so that we can actually choose what to use and (Netscape) won't have an unfair competitive disadvantage!

Just wait for the systemd maintainers to start making the life of all other container software maintainers miserable, e.g. by trying to monopolize on the use of relevant kernel resources. They won't stop adding unrelated stuff to systemd until they can ship a distribution solely consisting of one big systemd blob.

Clearly they are offering competing products to already existing, third-party solutions in order to take over some market share and make systemd more indispensible, just like Microsoft was doing back in the day.

There is no difference whatsoever, but now everyone here (or elsewhere) is probably going to whine that it's different because this time it is "open source" even though 1 person really controls all of it.

"Anyone can fork it" sure go ahead be my guest, why would you even want to fork that thing if it's an inferior product to begin with.

I guess you could make a fork "systemd --- the service manager --- AND NOTHING ELSE" but then you'd have to maintain someone else's product ad infinitum and no one is going to install your product anyway because you are not going to make your life work out of this, and so will never be able to support it as the main guy does.

You'd have to have a *real* competing product.

Moreoever everyone should just vow to stay away from attractive "addons" that simply ensure that honest competing products get less traction.

You often cannot choose not to use systemd, but at least invest in docker/lxc/lxd/whatever else and not this crap.

You can only invest your energy and your love once you know; you can only serve one master.


And about the noise everyone was creating here because one person went rabid on Poettering; shame I couldn't read his post, instead of your 2 page long comments about his post.

[jm111]

I think that post could be removed or moved to garbadge message dump just because it's offtopic without caring about any other reasons.

I guessed what the 19 comments before mine mostly were before reading any of them. Now I go and unsubscribe this thread. It's almost impossible to have sensible discussion about systemd here.

It's not the 'troll' that causes this, but the police types, they create a noise storm about someone else's post, and then the original guy is blamed for the police types' noise.

If you stay quiet and ignore him, or at best just message a moderator who will curtail the post to say 25% of its size, you don't get all this noise, just please don't create noise to quell noise, and don't create problems to solve problems.

[Weasel]

Damn, there is still people in 2018 that thinks systemd is a single blob and not a project composed by around 80-ish separate daemons or tools.

Seriously? What's the difference when they are intertwined and dependent on each other?

You think splitting a giant blob into 100 different files is somehow less monolithic?

And yes btw, the Linux kernel is made up of tons of modules, is that not monolithic either? They are all dependent on the exact kernel version, so it is a monolithic kernel, and if you don't believe me for it, look it up on wikipedia or wherever, this is a known fact. In fact it was designed as a monolithic kernel on purpose compared to a micro-kernel (like Windows has).

Obviously since the kernel is good it doesn't mean all monolithic stuff is bad. But systemd is monolithic. At least the kernel doesn't usually (or ever?) start to get non-kernel functionality that doesn't have business being there in the first place.

Can't say the same about systemd's future at this rate.

[starshipeleven]

Seriously? What's the difference when they are intertwined and dependent on each other?

Depends on how this dependency happens.
In the case of systemd daemons, the interfaces are documented and under a "stability promise" https://www.freedesktop.org/wiki/Sof...bilityPromise/

Which is why there are projects that replace this or that component (elogind, eudev) at all. If it was a breakfest like GNOME extensions API, none would even attempt that.

And yes btw, the Linux kernel is made up of tons of modules, is that not monolithic either?

A monolithic kernel is a kernel where all services (file system, VFS, device drivers, etc) as well as core functionality (scheduling, memory allocation, etc.) are a tight knit group sharing the same space. This directly opposes a microkernel.

A microkernel prefers an approach where core functionality is isolated from system services and device drivers (which are basically just system services). For instance, VFS (virtual file system) and block device file systems (i.e. minixfs) are separate processes that run outside of the kernel's space, using IPC to communicate with the kernel, other services and user processes.

In short, if it's a module in Linux, it's a service in a microkernel, indicating an isolated process.

Obviously since the kernel is good it doesn't mean all monolithic stuff is bad. But systemd is monolithic.

No it is not, really this is the nth time people keep repeating the same bs, I have years of canned answers that destroy this statement.

By the very same definitions applied to the kernel, systemd is NOT monolithic as its core functionality (the init) is split from the other services (logging, login management, and so on) and each of these separate daemons is NOT run as PID1, nor as root, nor with access to things that it should not need access to, and all communicate with each other using an IPC.

[rtfazeberdee]

. But systemd is monolithic.

No, its not. redefining the meaning of monolithic to suit your misinterpretation doesn't work.

[jm111]

You think splitting a giant blob into 100 different files is somehow less monolithic?

This was a great read, wasn't it:

Not So Fast, Slick

[jm111]

In the case of systemd daemons, the interfaces are documented and under a "stability promise"

Why would you want to replace a module whose architectural place and position and functioning you do not like, with another module that has to comply with the same API specification, where basically you can only decide its implementation, but not really its functioning?

Conversely, why would you want to write a completely independent API/architecture for a certain functionality, and then "plug it into" systemd according to ITS API that you now have to write a layer for, only to ensure that a certain systemd module is "there" (but now it's yours)?

And, is it possible to not have ANY such systemd module at all, and use your independent design as a replacement, not speaking the systemd API?

Cause if systemd would only define "plugin" interfaces (where you plug into systemd) it would be fine; but as soon as your module also needs to offer pre-defined APIs, all freedom is gone.

So my question to you, starshiptwelve, is: are systemd modules typically also required to offer a predefined API?

[jm111]

Which is why there are projects that replace this or that component (elogind, eudev) at all.

Both elogind and eudevd are systemd modules being extracted, not replaced.

That means they still have to comply with (offer) a certain systemd API, while now being able to run standalone;

this is not an example of module replacement at all, so don't be deceitful.

By the very same definitions applied to the kernel, systemd is NOT monolithic as its core functionality (the init) is split from the other services (logging, login management, and so on) and each of these separate daemons is NOT run as PID1, nor as root, nor with access to things that it should not need access to, and all communicate with each other using an IPC.

The word monolithic in general conveys being made of one whole, big and unchanging.

Google calls it:

"(of an organization or system) large, powerful, indivisible, and slow to change."

Systemd is clearly large and powerful.

And just because you can tear some components out and with a lot of work make them standalone, doesn't mean you have effected the organisation itself.

All of the APIs are determined by systemd; without those components systemd would fail, so they are indivisible as well.

That is to say, all of them are necessary, indispensible, and this might be growing.

The modules you mention have been extracted to offer a certain functionality (e.g. to Gnome).

That's like extracting Internet Explorer and making it work on the Mac.

Doesn't mean Microsoft is not a monolithic entity.

Windows as a host for third party applications is not "monolithic" but as soon as you force all 3rd party applications through an app store, it would become "monolithic".

So basically your "canned responses" abuse a certain specific computer-tech meaning of the word monolithic as it relates to kernels,

in order to "prove" that the more natural, informal usage of the world "monolithic" does not apply.

You fail.

Weasel meant the colloquial term.

[Ericg]

At least as long as people use this tool for the right task, of course someone is going to package something incredibly stupid into one of these services, just like someone recommended me once to install Minecraft in a damn docker container a few years ago because only a single line was needed to download it and another line to start it.

That's really not a terrible idea though... Each minecraft world gets to be self-contained. The logs are self contained, the server data is self-contained. Makes it very easy to swap the various ports that each world is listening on. Easy versioning since the docker images are versioned as part of docker. Sure, its wasteful from a disk space portion, but are we really sweating a gig or two of -disk- space these days? I know I'm not.