So what? If you don't trust your distribution about things like that you shouldn't run it in the first place.
I think you are mixing up terms here. "Verifiable Systems" does not mean that you have some kind of registration, but that you can verify that a system is in exactly the state it should be.

I will answer that with a question: What is bad about having all the components you need for a basic system in one source tree to make it much more convenient to create such a system, without having to test relationships between the components and possible incompabilities over and over again?
After all, no one is complaining about Busybox either, though it does the same on a smaller level and is much more un-UNIXy with doing everything in just one binary.

2 members found this post helpful.

Nah, T3's been a high quality poster here for many years. I expect it was just a bit of frustration showing through.

Change is tough. Clearly.

All hail upstream.

And that is the point: systemd has started as an init system, but has also be come a larger project (which includes systemd the init system) which provides building blocks for building a basic Linux system. While Runit, OpenRC, S6 and others may be an alternative for use as init system, there is currently no alternative to the systemd project. Regardless how many init systems you provide, regardless how good those init systems are, developers are not only using systemd as an init system, they use it to build a system, while other developers use it as common base to make their work easier (Gnome, KDE, upower, ...).
That inherently means: as long as there is no alternative to systemd as a "Linux construction kit" that is compatible to the the interfaces systemd already provides (and the latter part is at least worked on already by the OpenBSD developers), systemd will win in the long run, no matter how much it allegedly adheres to the UNIX principle or not (which comes up again, but still I got no real answers to my previous questions about that).

3 members found this post helpful.

Busybox isn't being force-fed into nearly every major distro as the default. Its just good for embedded systems. And it claims nothing else.

2 members found this post helpful.

Being force fed is a strong word. I closely monitored the process of Debian deciding about their future init system and there was extensive discussion about, with lots of testing, questions asked and answered, with a very close win (in the end the CTTE head had to decide) for systemd. Calling that force fed is way beyond reality.
By the way, Busybox is default on almost all distributions for being the basic system inside the initrd (if one is used). Not because it is force fed, but because it is convenient: It provides all the needed building blocks in one source tree and there is no competitor with the same functionality. I have used Busybox many times for small single purpose systems exactly for that reason, it makes the developing life much easier. As does systemd.

In the end it comes down to the developers of a distro on what they base their distro.
Undoubtedly for Slackware this will be SysV with separate daemons as long as that is viable, I hope for Gentoo it will be OpenRC with separate daemons as long as viable, but other developers have decided to make their life easier and use systemd. Users that don't use distros like Gentoo, CRUX or LFS have usually no vote in that decision and can either switch distros or switch to become a developer themselves.

Which one you choose is totally up to you.

http://landley.net/toybox/about.html

I have an EFD reader that uses this. Its a "competitor" to busybox.

edit: It's only a competitor for certain use cases. Still worth a look.

Thanks for that, didn't know about Toybox. Anyways, as the status page shows it is not as complete as Busybox yet: http://landley.net/toybox/status.html
So may be worth a look in the future (or for use cases it already has enough features for).

For a few weeks now, I have been using OpenRC on Manjaro (Arch derivative), with the help of a guy that uses Gentoo and has ported it.
I find OpenRC to be quite simple and intuitive to use.
Using it with eudev, also from Gentoo.

However there can be said to be a case for using deprecated components like Consolekit, but as long as it works..

1 members found this post helpful.

Maybe ConsoleKit needs to be forked out like Timidity did when it died into Timidity++ with something like ConsoleKit, ConsoleKit2, ConsoleKit-ng, etc.

So far you can still use ConsoleKit or even HAL for the same purpose and HAL has been used for BSDs for a while and hasn't had a meaningful update for years now, so my guess is ConsoleKit is still going to be useful for a while to come.

Anyway, regardless what tools systemd comes with or provides, yes, it is being rammed down our throats unlike BusyBox or even the standard kernel.org and GNU toolkits. So far there's no evidence that's says the standard kernel.org and GNU toolkits are not invalidated for usage. Until those tools are invalidated, then systemd's usage, in my opinion, is not a valid excuse.

1 members found this post helpful.

ConsoleKit will be useful as long developers decide to actually use it. Nowadays less and less developers do that, some because Consolekit is not maintained anymore, some because they don't want to maintain two different codepaths (see Martin Gräßlin's comments about the mess that the startkde script is compared to the systemd solution), so I am with turtleli here: Rather than forking Consolekit IMHO it would be better to support the OpenBSD people with their project in implementing substitutes for the systemd components that are used by the desktops.

I have difficulties to understand this. At first, what have the GNU tools to do with systemd? Also, are you saying because other tools exist there is no valid use-case for systemd?

And again, about the "rammed down your throat": I see you using LFS with Runit and Slackware with SysV, but not distros that use systemd, so where is it specifically rammed down your throat?

Yes and that choice, Tobi, is being slowly taken away.

As far as the argument... You said it yourself Tobi that systemd is going to provide all the tools necessary to run the OS.

Right now the GNU tools and kernel.org tools run the OS.

So which is it going to be? 0pointer or GNU+kernel.org? Answer the question.

1 members found this post helpful.

Yes, you just said that you want to take it away, you don't want people to run systemd because you deem it not be a valid solution. Isn't that the same as LP saying that people shouldn't use BSD because he doesn't see that as valid OS anymore?
The GNU tools? Seriously? Which of them? Find, grep, gawk, ... . You must mix up something there.
The question is inherently wrong. Right now you have kernel+sysvinit+GNU(+Xorg/TinyX/Wayland+KDE/GNOME/XFCE/*box).
Obviously systemd developers want that to be kernel+systemd+GNU(+$theRest), while I like it be kernel+OpenRC+GNU(+$theRest) and you obviously kernel+Runit+GNU(+$theRest).

I can't see systemd and GNU overlap.

1 members found this post helpful.

Yeah. Not seeing how systemd will affect the GNU tools. They aren't going to replace glibc or gcc or anything like that.

What do you think specifically is going to be obsoleted regarding GNU?

I mean, I don't want systemd, because I'm comfortable with the way things are. But I see the merit in programmers that write the system tools latching on to something new that makes things easier for them. I'll learn to admin the damned thing, but I will not be happy about it.

Thats really what it comes down to isnt it? You will have to learn it, so go ahead and learn it. The argument is over. It's getting implemented in most cases whether you like it or not.

3 members found this post helpful.

I trust you've watched this video:

http://www.youtube.com/watch?v=_2aa34Uzr3c

While I don't see it consuming glibc, gcc, or some of the various libraries and some utilities like gawk and others (how the hell could systemd even have it's own libc and compiler is actually intangible), systemd, however, is aiming to be the Core OS of the system or more or less a shell-less sealed off hypervisor running a Linux kernel to which all programs and applications run in their own userspace using cgroups as execution containers with limited permissions across the system using virtual filesystems per application installation.

We even have an OS distribution based on that concept called Core OS.

https://coreos.com/

And another called Android OS.

While for the moment all aspects of systemd are able to be optional, what would happen if that right to opting out of a service vanished? We used to be able to extract udev, now we can't hardly do that because of all the mess of software it creates, and if we want separated udev we have to use eudev. We can't opt out of journald, so what makes you think eventually we won't be able to opt out of networkd, or logind, or whatever else? And yes, Tobi it is a conglomerate project, but the goal of that project is not the goal of the sum of it's parts.

3 members found this post helpful.