Just dug this out of the ol' mailbox a while ago from an IT friend of mine back east:

https://lkml.org/lkml/2014/10/7/254

It seems that allegedly the Debian Admins have somehow effectively cancelled development or deployment of systemd-shim in a move to force systemd lock-in upon it's users somehow.

Being that systemd-shim was developed by Canonical I don't see how this would be done by Debian in relation. The launchpad.net website and repository is still intact here: https://launchpad.net/ubuntu/+source/systemd-shim with development last contributed on 9-11-2014 in pre-release status of version 8.1 with other repository developments seemingly on-going.

There also seems to be some accusations of people from Red Hat somehow worming their way into the Debian Committee in a hostile takeover.

I have no way to prove how factual that is, unless someone knows the standing of the Debian committee members in relation to Red Hat, but regardless this is a seriously damning public accusation into the validity of the leadership of Debian and the people in the leadership positions.

The real question now is, will the systemd-shim project be continued on in development status by Canonical, and how will this affect other distributions that may have looked to use the shim in some ways, namely Slackware, if Slackware had been looking to the shim project in future developments, if in fact it is cancelled somehow?

Using a shim has not been discussed, as far as I know.

4 members found this post helpful.

Yeah, I know Slackware still uses scripting for cgroups and ConsoleKit for log in management, but the shim was a promising to say the least. I just wonder now if this will effect anything else?

If you wonder how this will affect "anything else", and since this question bears no relation or relevance to Slackware, perhaps you should ask a moderator to move your topic out of the Slackware forum.

Also, you quote an unfounded accusation. I read the LKML email but there is no source to that accusation in that email either. Considering the weight of this accusation, it would be better to post proof or not quote it altogether.

Eric

4 members found this post helpful.

I agree. The accusations given were heavy but without merit by the author. The lkml has it's share of questionables, but as the topic was directed at Slackware, mentioning what else it could affect was limited strictly to software only by context as things like Xfce, KDE, etc were able to use logind which is part of the shim, not other distributions so moving is not required. I only asked this in the context of if the shim had been considered for usage, but if not, then no harm done, no foul, and no need to play the blame game.

The source - i.e. the person writing that rant - is not reliable and has been making a prize fool of himself on one of the Debian forums lately.

A minimal interface like systemd-shim is going to be very hard to make work as long as the systemd interface is fluid and undocumented. Keeping it updated (importing changes from systemd) would be labor-intensive, and any time it fell out of lock-step it would break.

My speculation is that the systemd-shim developers are backburnering the project until such time that the systemd interface settles down.

It would almost certainly be better to switch to SystemD than to use a "shim", if you're forced to choose one or the other.

precise, and since in future also the virtual terminals will run via systemd
http://cgit.freedesktop.org/systemd/...429ad9bee02bcc
shims will not be good enough

But they don't have to run via Systemd http://linux.slashdot.org/comments.p...3&cid=48093497

3 members found this post helpful.

It's not that simple.

If I were to write a Slackbuild for a project with a dependency on systemd, I could go about it one of two ways: I could patch the package to remove the systemd dependency, or I could add a dependency to a systemd shim (which presupposes that a shim is available).

This is not a hypothetical situation; I have "write Slackbuild for CoreOS's etcd" on my to-do list, and etcd has a slight dependency on systemd.

Removing etcd's systemd dependency would not be difficult. It only depends on systemd for a little configuration information and logging, both easily replaced with conventional UNIX services (a static file for one, syslog for the other).

If it were just a matter of a single project, this would be a no-brainer. Patching is a lot less work than developing and maintaining a shim. But if the number of projects (or, particularly, device drivers) being ported to Slackware becomes large, then maintaining a shim offers superior economy of effort, compared to patching each project.

In neither case is requiring the Slackware dev team to adopt systemd necessary. Nor is it desirable, as it would replace many well-understood, mature services with poorly-understood, immature systemd subcomponents. Nor would it work, since (I expect) Slackware would not adopt systemd, which would render my Slackbuild useless.

The best way forward is to patch systemd-dependent projects until such time that the systemd interface settles down (if ever) and that the effort of patching projects warrants writing a shim (if ever), and only then writing a shim.

5 members found this post helpful.

Kmscon looks promising, but a better question would be, is multi-seat support that important? If all it uses is the logind daemon and the API library for multi-seat, the shim could have duplicated those functions without incorporating needless extras to gain functionality. However, as stated earlier unless systemd cools off and settles, which doesn't seem likely as the developers seem to wait to keep adding "stuff" to the project, the shim could never work properly.

The problem with the systemd interface still being undocumented should have sent up a plethora of red flags to developers across the board. Steve Gossner wrote a good article on it back in 2005: http://blogs.technet.com/b/stefan_go...api-part1.aspx about avoiding undocumented interfaces. It mostly centered around the interfaces being unreliable, unstable, questionable, and the chance a developer could effectively break complete functionality on a whim and nobody would know until after the fact.

Even then would a shim be necessary? You could at that point, create a static library for libsystemd embedded in each daemon individually and break the project down outright into one project per component. However, i doubt seriously that would ever happen.

1 members found this post helpful.

Since LQ members did not shun participating in this thread, lending legitimacy to it by continuing to discuss it in the scope of this forums purpose, I see no reason to move this thread.

So much for the code settling down any time soon though...

http://linux.slashdot.org/story/14/1...-linux-systems

It seems systemd is adding it's own userspace kernel VT subsystem to deprecate CONFIG_VT called systemd-consoled. I know VT is a amalgamated mess but moving kernel-space stuff into user-space with access to the kernel... that seems a bit dangerous sounding.

In relation to the shim, this means that possibly stabilizing the shim could become harder and even then, how could consoled fit into the shim respectively, or would it be more suitable for uselessd?

To touch on your article...

The current opposition to systemd is sound against the principles of having a monolithic cathedral based project that can not be effectively separated out into the sum of it's parts. This is why many projects like the shim, uselessd, and other init systems like s6, OpenRC, and Runit have become focal points to mainstream. One argument I've even started to make and realize is why can't libsystemd.so be effectively recreated as a static library, libsystemd.a, to effectively break down the project and avoid creating a huge system dependency chain by linking only the most vital parts of the project against a static library upon compile. You could then possibly and maybe effectively isolate logind out completely as a stand-alone project, much less any other part.

If uselessd can strip out the init system itself, and shim can take hold of logind and cgroups, even more could be stripped out. In reality all you would need would be init, logind, and cgroups to get the main levels of functionality, and outside of that you still have eudev.

The amount of misinformation and blatant lies on both sides of the equation will never really be settled. However, the practice of Keep It Stupidly Simple and Using Practical Common-Sense is slowly winning out, however, as long as efforts are being made to undermine existing tools and force projects to systemd, the efforts of breaking down systemd will continue onward, however, until the core project takes a rest and settles down, if it ever will, any efforts are going to be painstakingly slow. We as users just have to keep pushing for alternatives and hope the message gets through.