Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

[calc]

Ubuntu only provides long-term support for packages in its quite limited "main" repository, not in "universe". And the default install includes many packages from "universe"! So Ubuntu in my opinion only pretends to provide long term support for their distribution.

Clearly you are speaking from ignorance as Ubuntu does NOT include ANY packages from universe in the default install, as it doesn't even have universe enabled in the default install.

Other flavors do enable universe and support their own packages for some amount of time, usually 3 years, you can see how long by looking at the package metadata, eg.

Supported: 3y

[Guest]

Uh, playing audio streams concurrently is something that worked pretty much forever (that is, '96 on Windows 95, and '03 with alsa dmix).

I was actually referring to the ability to move individual audio streams between different devices. AFAIK that was only introduced in Windows 10 in 2018. (But I've been able to do it in KDE since 2010).

[oiaohm]

Actual desktop applications. And I believe that saying that you can set it up to do something doesn't solve anything. If the developer can't count on a feature being present, available and working 100% of the time for 100% of the users with zero additional user interaction required, then that feature simply doesn't exist.

The reality is the Linux desktop is not a Windows desktop. It a secure company workstation desktop style. So no feature working 100% of the time for 100% of the users is the reality because many controls are in the administrators hands with the Linux desktop. Basically this is the nature of the beast.

You do realise that we are now talking about 100s of lines of very error-prone and nontrivial code to accomplish a basic function that all modern and sensible OSes let you do with no more than, say, five?

This is 100s of lines of code that could be a helper program for cron/timers. With a helper program number of lines of code massively reduce. Problem I was getting at is with current state of play with session management implementing this helper is up hill battle.

Define of modern and sensible have different meaning depending on who you are talking to.

cgroups are an essential component of the puzzle to make it work but they aren't the solution by themselves.

I see the problem. We have the problem here of attempt to build a house from the roof before putting in the foundations.

It's a very low level mechanism that doesn't manage application lifecycle, it doesn't make sure that time is accounted for during periods where your laptop is put to sleep, it doesn't give you the API to handle such essential but mundane functionalities using 1-liners. They are to this particular problem what the kernel's syscall interface at the assembly level is to the development of web applications. It's absolutely required, but you wouldn't want to target it directly.

You cannot have a API or application helpers giving you nice 1-liners if the low level functionality is not implemented then you need the level above that implemented then you can get to API or application helpers. Having cgroups setup to track applications by service management/session management is one step above low level. Of course you miss that Windows and OS X easy to use timers are accessing the setup session information.

Linux has a lot problems at the low level ruining stuff at the upper level due to the parts that came across from Unix world that don't in fact match how Linux unix like in fact behaves.

Result is you need to start at the foundations and work your way up and locate what is missing. What has been missing as the next required step is good dependable service and session management systemd does provide a plan to address this. Of course others could decide to develop a plan to address this as well.

This is why I get really annoyed with anti-systemd people saying lets go back to sysvinit what is basically return to completely busted foundation and will result in long time of no possible progress.

Timers API could be provided by gnome/qt if the foundation of session management and service management was complete and functional.

[audir8]

I think this is more or less the crux of the matter and what the systemd flamewars are really about. Many people argue that "you can set it up to do X", "It could do X if...", "You could just implement X" etc. But I look at it from the point of developing desktop applications: not cloud or server which I'm not really interested in, not system administration, not web apps running on electron etc... Actual desktop applications. And I believe that saying that you can set it up to do something doesn't solve anything. If the developer can't count on a feature being present, available and working 100% of the time for 100% of the users with zero additional user interaction required, then that feature simply doesn't exist.

You do realise that we are now talking about 100s of lines of very error-prone and nontrivial code to accomplish a basic function that all modern and sensible OSes let you do with no more than, say, five?
...

This is looking for a problem where none exists. Applications do manage to add cron entries just fine whether it's system wide or user specific. Applications also use udev, sockets, network, logging and other resources (dkms, dbus) just fine with minimal work without systemd. If a library isn't available by default, it's a dependency, and gluing things together hasn't been any particularly harder on Linux than anywhere else. Does systemd change how I might want to make a KDE or gnome app? Only the tinniest bit. A desktop app developer needs little more than a line or two in normal cron, a way to launch a daemon using start-stop-daemon and stable UI/library APIs. If you're an app developer, certainly use cgroups directly if you need to manage processes, any language has decent cgroup apis now.

Things like systemd-nspawn are a nice to have, as are systemd-cron, networkd, cgls/top, slices, and journald. These are all cloud and server features, period. All together, they're a sysadmins dream come true. The complexity and management of distributed apps makes these features mandatory. For how bad slack and chrome might be at memory usage, it's ok if I just restart them once in a while. Things like setting a nice priority or creating a namespace using unshare or starting apps using virtualbox/virt-manager/docker/flatpack etc.. have massively simpler interfaces for doing exactly what cgroups does. Average users and app developers actually do use these simpler features all the time.

The fact is without something like the Android security model on Linux DEs, cgroups and namespaces won't be used widely by app developers. Systemd-* is not for the current average user or app developer, it's for the cloud or server developer. Systemd service unit files vs OpenRC init scripts and conf scripts is a toss up, if I only want to do one thing and not deal with anything else, guess what my choice is going to be.

Edit: the distro maintainer is closest to the server developer. Offcourse system-level things are going to be better handled by something like systemd-*. The average user or app developer doesn't care, and to the extent they do, they want everything to work the same and probably loathe overly complex things.

[oiaohm]

Systemd-* is not for the current average user or app developer, it's for the cloud or server developer.

This statement of yours is wrong. You have not typed systemctl --user recently.
https://wiki.gnome.org/Initiatives/SystemdUser would be a good read.
https://guadec.ubicast.tv/videos/man...systemd_85843/ this is a good watch on the topic from GUADEC 2019.

Same is happening with KDE. Session manager of kde and gnome is going away replaced by systemd --user in a lot of cases. A number of applications running for user accounts are already using systemctl --user.

Systemd-* stuff is for your cloud or server or desktop environment developer. I would agree with not for your average app developer.

The fact is without something like the Android security model on Linux DEs, cgroups and namespaces won't be used widely by app developers.

Foundation work for having Android security model is fixed up the DE session manager. No point applying android security model if the services started by the session manager are not secured.

Yes it will not be the job of app developers in most cases to use cgroups/namespaces directly. Even for DE developers cgroups/namespace management is most be in what ever the session manager is.

If you're an app developer, certainly use cgroups directly if you need to manage processes, any language has decent cgroup apis now.

Or maybe you do what gnome and kde are doing use systemd --user to do the cgroups stuff for your.

Openrc has not done any work to make it suitable for session management.

First time systemd --user was tried as session manager 16.04 ubuntu. So systemd being part of desktop has been around for a while.

Of course after session management is solved then comes lets run applications in cgroups/namespaces.

[audir8]

This statement of yours is wrong. You have not typed systemctl --user recently.
https://wiki.gnome.org/Initiatives/SystemdUser would be a good read.
https://guadec.ubicast.tv/videos/man...systemd_85843/ this is a good watch on the topic from GUADEC 2019.

Same is happening with KDE. Session manager of kde and gnome is going away replaced by systemd --user in a lot of cases. A number of applications running for user accounts are already using systemctl --user.

Systemd-* stuff is for your cloud or server or desktop environment developer. I would agree with not for your average app developer.

...

elogind does what systemctl --user does. loginctl doesn't show me anything currently, so I don't think plasma uses it on Gentoo, but it could. https://github.com/elogind/elogind

If you count everything not in elogind and only boot time *.service unit files, it's all for cloud and servers. DEs and distros can use this stuff, but there are perfectly sane simpler alternatives which work fine for developers and users.

[Paul Frederick]

The answer to all this Debian init system conflict has been in plain sight for quite awhile: Devuan! https://devuan.org
If Debian without systemd is desired, use the equivalent Devuan version and be glad you did. Simple.

When I looked into using Devuan it was running a version behind Debian so the packages in it were too old to support software I wanted to compile to run. I would have been glad if I could but the incompatibility made that choice a non-starter for me. The project seems to have too few resources to be viable.

[oiaohm]

elogind does what systemctl --user does. loginctl doesn't show me anything currently, so I don't think plasma uses it on Gentoo, but it could. https://github.com/elogind/elogind

You really should have watched the video. Because elogind does not do what systemctl --user shows. Plasma and Gnome currently fall back and run using the system prior to systemd if "systemd --user" is missing or not usable at this stage.

https://github.com/KDE/plasma-systemd-integration

The kde work moving in the direction of systemd --user is here. Plasma can uses systemd --user but will run without it at this stage using the older system so not gaining you the advantages of cgroups and other security things around the different parts of the desktop environment.

systemd --user/systemctl --user is something different to systemd-logind/loginctl.

Basically you have not been on a systemd using distribution. Interesting enough replacing gnome-session with the same system used for the system wide service management running in usermode was not first done with systemd but first done with upstart.

I will give you it simple to miss. There are two things that can be called session manager.

1) login manager and login session this is logind and consolekit stuff.
2) Desktop environment session manager. Gnome version is Gnome-session then you have ksmserver under kde as the older versions. This is what systemd --user is working on being used to replace.

I really don't know why we have had to have a unique desktop environment session manager per major DE one thing systemd --user does possible promise is ending new windows managers creating their own unique DE session manager. Of course I would prefer a platform neutral solution over systemd --user for this that does support cgroups on LInux.

Basically you have had your head dangerously in the sand about what is going on. Systemd based distributions have systemd piece by piece replacing the desktop environment session management with systemd --user.

Openrc has focused on the service management getting that right. elogind is the login manager. DE session management is something where there is no fully functional competition on Linux to what systemd --user does.

Yes a lot of the old DE session mangers work okish on freebsd due to being coded around BSD style logic of processes but they are not in fact working fine on Linux systems for the same process leak problems.

Why okish is that is possible for gnome-session and ksmserver or some other DE session manager to both load on a user at the same time and decide to lock down the same device. Yes pulseaudio fixed sound server hell where two different DE sound server tried to get the audio device but other items remain where this disaster can still happen.

Basically DE session management has been broken for over 3 decades now. Yes longer than Linux has existed and it really about time it gets fixed.

[Drizzt321]

Okay, but just understand: https://www.youtube.com/watch?v=o_AIw9bGogo

In the middle of watching this, this is fantastic.

[Alliancemd]

I wait for the day when Linux software stops resisting change and integrate better with systemd.
It brings So Many features that Linux needs, especially when it comes to security...