How KDE Plasma 5 Optionally Uses systemd

[anda_skoa]

I really wish the KDE team would stop wasting their time with MacOS and Windows, just concentrate solely on Linux and BSD.

Nobody is working on Plasma 5 for either OS X or Windows.
They can hardly stop doing something that they are not doing at all, let alone stop wasting time on something they don't even spend time on.

Cheers,
_

[Awesomeness]

I really wish the KDE team would stop wasting their time with MacOS and Windows, just concentrate solely on Linux and BSD.

If they did that, Intel would have never sponsored development of Calligra Gemini to showcase convertible notebooks running Windows 8.
Calligra's music note feature was contributed by someone who uses it under OSX (wich, unlike legacy MacOS, is a BSD).

[Awesomeness]

Nobody is working on Plasma 5 for either OS X or Windows.

The Plasma (4) framework was ported to OSX and Windows because an Amarok panel uses it. As a byproduct Plasma Desktop also compiled, although it's not really usable as alternative Windows shell because of things like Plasma's systray not displaying Windows systray icons, the K menu not showing entries from Windows' Start menu, and so on.

[anda_skoa]

The Plasma (4) framework was ported to OSX and Windows because an Amarok panel uses it.

Sure, but this article is about Plasma 5, the shell. Nobody is actively working on this for either OSX or Windows as far as I know.

I was just pointing out the misconception that time would be spent on developing shell replacements for proprietary systems.

Cheers,
_

[erendorn]

As a programmer, this looks like a classic mix up of "is-a" and "has-a", i.e. inheritance vs. aggregation.

systemd has an Init system.

Cheers,
_

Oh, one cannot really blame the mix up, because:
systemd, as in the systemd project, has an init system. Which, absolutely not confusingly, is called... systemd.
systemd, as in the systemd daemon, is an init system. It is part of a project named systemd.

[anda_skoa]

Oh, one cannot really blame the mix up, because:
systemd, as in the systemd project, has an init system. Which, absolutely not confusingly, is called... systemd.
systemd, as in the systemd daemon, is an init system. It is part of a project named systemd.

Right, easy to get confused.
Even in the second case one would have to say that it can be an init system.

All of its user application facing features are provided by the daemon wether it is the init or not.

Which is why it is IMHO quite important to get the distinction right, otherwise we'll continue to see misinformed claims like "GNOME depends on a specific init" as seen during the Debian discussions.

Cheers,
_

[Delgarde]

Hmm, that quote was not much about logind, but more about services.

Same story, though. Logind is just one of the services provided by the systemd package, along with the ones for hostname and date/time, etc. So if BSD can't use the systemd versions, it'll have to provide compatible equivalents instead.

[Delgarde]

The problem have historically been, that the *BSD's don't pull their share when it comes to DE development. On top of that they have been dragging their feet to implement the necessary infrastructure like KMS, even though their OS benefits from it.

Or to put it more generously, they *can't* pull their share. Linux is just so much bigger in terms of developer numbers, especially in areas that matter for desktop use. And that means that change is driven by Linux developers - people building things like KMS and systemd, and people using those things when developing Gnome and KDE.

The BSDs are kind of stuck - they don't have the developer numbers to keep up with what upstream desktop projects are doing on Linux, and if they can't keep up, they lose influence in that area... too small and too backward for upstream to really care too much about them.

[rdnetto]

Are you sure about that?
Which kernel functionatily is needed for that which is restricted to PID 1?

Cheers,
_

IIRC, systemd-init has an explicit check that it's running as PID 1. However, I believe it's more of a strong recommendation (to avoid leaking processes outside the control of the cgroup manager) than a hard dependency.

As a programmer, this looks like a classic mix up of "is-a" and "has-a", i.e. inheritance vs. aggregation.

systemd has an Init system.

I think this is a really important aspect of the discussion that most people miss. It certainly doesn't help that the systemd project refers to their init system as just systemd instead of something else, like initd or systemd-init...

[anda_skoa]

IIRC, systemd-init has an explicit check that it's running as PID 1.

That makes sense, it is the systemd project's init component.

I am mostly referring to the fact that, at least on my system, the output of systemd --help list this

--system Run a system instance, even if PID != 1

So systemd itself seems to be capable of running as PID != 1, which for mean means that if anyone claims that some systemd feature needs PID 1, it is the kernel actually requiring that.

The comment I was replying to had claimed that systemd needed to be PID 1 in order to provide the functionality needed by logind.
Based on my information that seems incorrect, but I wanted to give the other poster a chance to provide information about which kernel function needed by logind is only made available to PID 1.

I think this is a really important aspect of the discussion that most people miss. It certainly doesn't help that the systemd project refers to their init system as just systemd instead of something else, like initd or systemd-init...

Indeed!
Really frustrating because a lot of people seem to be up in arms about an alledged init dependency when in fact there is none.

Cheers,
_