Systemd Introduces "Portable Services" Functionality, Similar To Containers

[rtfazeberdee]

By 2014 any system using updated system parts did not need a bi-pass library. Issue is the failure to update the non systemd solutions consolekit to consolekit2. Of course is not the issue the anti-systemd crowd wants to hear.

I think i might have got that a bit wrong. i finally found the interview where LP discussed what he did

"www.linuxvoice.com LENNART POETTERING INTERVIEW V " archive.org/stream/LinuxVoice/Linux-Voice-Issue-012_djvu.txt

LinixVoice: Some people see it as a requirement for Gnome...

LP: But it's not actually a requirement. Some people don't realise that when Gnome started making use of Logind, I actually wrote the patch for that. I ported GDM onto Logind. But when it did that, I was very careful to make sure it would still run on ConsoleKit. I didn't want to have those fights - if people want to continue running ConsoleKit, they can. Those patches made it in, but some people saw that Gnome now works with Logind, hence it must not work with ConsoleKit any more!

But that's actually not true. And to my knowledge the code is still in there - the compatibility for ConsoleKit. The Gnome team has the general problem though, that nobody's willing to maintain it. People who want to stick to the old stuff, they actually need to do some work on it. If they don't, then it will bit-rot and go away.

So anyway, we tried to do these things in the nicest possible way, but of course people generally don't acknowledge it! "

[oiaohm]

I think i might have got that a bit wrong. i finally found the interview where LP discussed what he did

"www.linuxvoice.com LENNART POETTERING INTERVIEW V " archive.org/stream/LinuxVoice/Linux-Voice-Issue-012_djvu.txt

LinixVoice: Some people see it as a requirement for Gnome...

LP: But it's not actually a requirement. Some people don't realise that when Gnome started making use of Logind, I actually wrote the patch for that. I ported GDM onto Logind. But when it did that, I was very careful to make sure it would still run on ConsoleKit. I didn't want to have those fights - if people want to continue running ConsoleKit, they can. Those patches made it in, but some people saw that Gnome now works with Logind, hence it must not work with ConsoleKit any more!

But that's actually not true. And to my knowledge the code is still in there - the compatibility for ConsoleKit. The Gnome team has the general problem though, that nobody's willing to maintain it. People who want to stick to the old stuff, they actually need to do some work on it. If they don't, then it will bit-rot and go away.

So anyway, we tried to do these things in the nicest possible way, but of course people generally don't acknowledge it! "

I did not have it wrong. Lennart Poettering fix would have allowed GDM to work with on original consolekit no requirement to move to consolekit2 but this is not really the right thing. Please note past Sep 2013 original Consolekit is not getting any updates including security updates. Thinking this GDM an item that should have feature selected considering security Gnome developers decide to cease support for original consolekit as to be secure upgrading to Consolekit2 should have been done.

Basically what you missed is consolekit original itself is bit rotting at high speed once it end Sep 2013. Is it right to maintain compatibility with something that is known security flawed.

I really do believe the GDM developers made the right choice supporting logind and not bothering about consolekit. Yet people have attempted to push that logind was systemd only to attempt to get them to maintain dead consolekit instead of moving to consolekit2 as they should have.

[pal666]

So instead of refuting any of them , or all

your idiocy was refuted many times, you are just repeating same bullshit again. why waste time on explaining to idiots?

[pal666]

I don't see the point of these "Portable Services", could someone explain?

it's a service which can be shipped as tarball or iso file.
1) make one service and ship it for any distro
2) more secure than standard service because it can't see root filesystem

[pcxmac]

systemd is a french word -

System D (in French, Système D) is a shorthand term that refers to a manner of responding to challenges that requires one to have the ability to think fast, to adapt, and to improvise when getting a job done. The letter D refers back to either of the French nouns "débrouille", débrouillardise or démerde (French slang).



but really, its Red Hat's way to consume user space and control the linux eco system. Thankfully there are distros like Gentoo which offer great software customization and choice when it comes to "init" systems. I don't mind waiting a few more seconds during boot and shutdown in order to evade 'cancerous' projects with no clear scope or demarcation.

[oiaohm]

systemd is a french word -

System D (in French, Système D) is a shorthand term that refers to a manner of responding to challenges that requires one to have the ability to think fast, to adapt, and to improvise when getting a job done. The letter D refers back to either of the French nouns "débrouille", débrouillardise or démerde (French slang).

but really, its Red Hat's way to consume user space and control the linux eco system. Thankfully there are distros like Gentoo which offer great software customization and choice when it comes to "init" systems. I don't mind waiting a few more seconds during boot and shutdown in order to evade 'cancerous' projects with no clear scope or demarcation.

Reality is even gentoo openrc has expanded scope.

Too tight of scope can cause trouble.

https://wiki.gentoo.org/wiki/Comparison_of_init_systems

Most people when they say sysvinit think shell script. Reality is none of the scripts that make up sysvinit system are part of sysvinit. So sysvinit had too tight of scope and that made big bad problems. Systemd in some ways has gone the other way. No clear scope is better than too tight of scope leading to stacks and stacks of different distributions doing their own uniquely broken implementations.

I will give you that balance. Openrc is the only one working on supporting BSD and Linux kernels properly. Most people missed that the BSD init is maintained and cared for BSD only. Runit and Epoch are also Linux only.

Now if you look at the gentoo runit page read down. https://wiki.gentoo.org/wiki/Runit#O...ration_feature

So OpenRC support sysvinit and BSD style configuration with work to support runit. In time possible Epoch.

So OpenRC kind of has feature creep as well being support all the common init systems that are not systemd so allowing them to be moved to cgroup using and reduce the number of unique per init system configuration files that have to be maintained.

Even gentoo cannot justify having as many init options as they currently do. Gentoo in time most likely will come down to 2. Fairly rigid systemd and more flexible OpenRC .

With what OpenRC is doing is really massive init system choice required or is it just wasting resources that should be put into OpenRC to complete it.

Reality is neither OpenRC or Systemd have a solid defined scope or demarcation.

Most init systems developed for Linux have gone in all kinds of strange directions most running into major trouble due to too tight of scope like only use POSIX functions this has resulted in them long term end up in the failed pile.