Is there some high-level document or blog post somewhere that outlines the vision of the systemd developers and why they are building these systems? So far I see a variety of projects (of IMHO varying quality) but no attempt at articulating a vision to tie it all together. What's the goal? What problem is all this stuff solving?

Have a look at systemd.conf presentations (and videos https://www.youtube.com/channel/UCvq_RgZp3kljp9X8Io9Z1DA). There are various goals there.

My interpretation would be: universal, global interfaces for all system things. Which is not a bad goal in itself.

Which is not a bad goal in itself.

It's worse than a bad goal. "Universal, global interfaces for all system things" is a goal that is cognitively meaningless.

Not sure why cognitively meaningless. To some extent syscalls are a global, universal interface for all system things. They're just very low level, so they carry very little information.

Dbus is an abstraction that allows actions with rich information and context, and makes it possible to define simple interfaces to potentially complex sets of actions. Systemd and related services fulfill those interfaces.

Why do you think that's a bad goal?

"All system things" is a meaningless statement. Syscalls can actually carry quite a lot of information (just look at signal semantics) and they're not "very low level".

The second paragraph is more wind.

I don't think it's a bad goal. You haven't even specified a goal.

I see what you mean, but I think it's a technicality. There's no good definition that I know of that wouldn't be called either insufficient or scope creep. Can you come up with one that includes interface to date/time, connected devices (with access control), virtual-or-physical screen resolution, packages, system and user services, etc. ? They're not even all administration actions. My best description here is "all system things" even if it's poorly defined - simply because I don't have a better one.

As for syscalls - they can carry a lot of data. That doesn't make it rich, structured information. Sure, everything is just writing/reading bytes at the end of the day. But there's a reason we've got open() function and don't use syscalls directly - rich interfaces are nice. Syscalls are definitely low level (they're defined in the cpu specs, how much more low-level can you get?).

I wouldn't describe it as a technicality, but more of a carte blanche vacuity. What comprises "the system"? Just about everything. Hence "all system things" is really "all everything things". Such underspecified weasel wording is a chief reason for systemd's status at large.

Even your list involves diverse interfaces ranging from real-time kernel primitives to end-user archives (packages), so again, "system things" is more of a justification for perpetual consumption than anything resembling a mission statement or goal.

(Things that merely wrap syscalls would probably be part of a utilities package anyway, a la util-linux.)

Yes, it does include diverse interfaces. And you keep saying the idea of common interface to all (system or everything) things is a bad idea, but not why. So again, why is it bad idea to want a common bus that can talk to all of those things and have interfaces that actually describe high-level, meaningful actions on them?

I can agree systemd situation is bad, but I don't think it's because of technical reasons. Leaving systemd out of it, what's bad about the idea that distributions, backend services, and client applications start using a common bus that has an interface for action "The system timezone is now XXX"? (and similar actions for network configuration, printers, sessions, and "all everything things")

So I'll just say it. I'm switching to FreeBSD. I'm sick of this train wreck. I don't care what they are developing I'm just sick of how they are doing it. I don't want my operating system to have this sort of mid life crisis.

I've kind of been thinking the same thing, this feels like a takeover by the freedesktop people.

And yet it's not an official announcement, hasn't been discussed on any systemd related mailing lists, has no documentation and merely exists as a git repository.

It's almost as if the programmers were experimenting with ideas that are alternatives to kdbus.

I'm appalled. What were they thinking?

You're very right. I let my distrust for freedeskop color my reaction.

Why as a response to this? As far as I can understand they're actually finally addressing some things that people have complained about. kdbus is removed from rawhide, bus1 is not under systemd umbrella as far as I can tell, it's not just a move of existing huge spec into kernelspace, and as the article says "BUS1 is being designed to be a low-level IPC technology that will also provide a high-level interface for applications."

Linux could definitely use some real, simple bus interface, so why would this be bad? (assuming it won't be merged into systemd in the future)

"Linux could definitely use some real, simple bus interface, so why would this be bad? (assuming it won't be merged into systemd in the future)"

Where's the evidence of demand for this from outside the systemd bubble, and why are all of the other existing IPC mechanisms (including those in other operating systems that could be implemented for Linux) unsuitable? The systemd devs really shouldn't be taken solely at their word that doing their favorite thing in another corner of the OS is the best decision for the broader community.

Every big system uses some kind of bus. There's a whole list of buses / rpcs used on Linux and other systems many of which get heavy and tedious at some point. Actual clean low-level bus + high level app layer could be a good solution for a change.

sunrpc, dcom, corba, dbus, xpcom, dci, dcop, rmi, kqueue (kind of), 9p/plumber, ...

All of them try to achieve a similar thing. Some of them can be actually used for remote calls, but a lot are used for local rpc.

They're unsuitable for the same reasons that we're using json instead of asn1, and http instead of custom interactive protocols. It's not that they don't work anymore, but because we learned how to do things better. And if bus1, or something similar could provide a low-level, common basis for more generic technologies, that would be awesome.

Regarding reuse... I don't know if any current system can provide what systemd guys want (pre-init availability and sending uid assurance)

9P and Plumber are nothing like the rest, and kqueue is an I/O multiplexing mechanism.

I'm unsure of why you consider 9P to be outmoded. It certainly can be available pre-init.

You're right, I added plumber and kqueue after writing the comment, forgot to revise the text. (edited) It was more about corba/xpcom being rather heavy. Sure, kqueue is different, but it is a kind of local event/message (yeah, I'm aware it's a stretch).

Sure, 9p can be available pre-init, but it doesn't provide sender verification. (i.e. you can't map the message to local uid) It could be added to the attributes of course, but it's not standard at the moment. Is that not right?

sending uid assurance

This sounds like an attempt to implement security features the kernel already provides.

Why would you need an assurance of a UID, and why would you assume that it would stay accurate? Using UIDs to do manual security features is going to have reliability issues, and if it's for a non-security feature, you don't need an assurance.

Yes it is for security features. Services get your message and if they operate on system resources they need to know who you are so they can either execute some action or not. Sure, this can be pushed to other layers instead (selinux for example), but it doesn't change that the functionality is needed.

This impacts issues like configuring wireless networks without being an admin. (which is what most people want in practice)

I get that you want to use UIDs for these things, but that's wishful thinking. You're assuming properties about a process's UID that are not guaranteed. See setuid(2) for example, or passing an fd from another process.

The reason you leave these things to the kernel is the kernel is the only place that can actually make the proper security determination.

A file-permission analogy: it is a bad idea to stat(2) a file to probe if it's possible to open it. The kernel already provides that capability, which you have to handle anyway. The proper design is to open the file, and handle the EACCES error. Testing first doesn't work because the situation can change between the stat(2) and the open(2).

configuring wireless networks

There are many ways to handle that, which do not require abusing UIDs for security features they weren't designed for.

edit:

No, I absolutely am not agreeing with you. Using UIDs for security outside the kernel (which is where the assurances your new kernel feature would provide will end up) is fundamentally broken. It works inside the kernel because the kernel can lock whatever is necessary.

You are only moving the race condition. You ask your new interface for the sender's UID, an interrupt happens, and the data you got may no longer be valid as the sender called setuid().

sunrpc, dcom, corba, dbus, xpcom, dci, dcop, rmi, kqueue (kind of), 9p/plumber, ...

why not tipc ? it is already there in the kernel, and seemingly well tested at that. why re-invent the wheel ?

Not that I disagree with your sentiment, but why FreeBSD? Out of all the BSDs, they are the most likely to adopt a systemd-like environment[1]. Why not Slackware or Gentoo if you want to stay on Linux without systemd, or else DragonflyBSD or OpenBSD?

I'm not criticizing btw, just asking out of curiosity.

[1] http://www.golem.de/news/systemd-und-launchd-freebsd-gruende...

Switching between the BSDs is very easy, and FreeBSD has the most resources for beginners. In any case, I don't think Hubbard's going to get much traction with his plans.

And the Gentoo devs are big fans of systemd, so while technically you can use it without, given how many tendrils systemd has got into things I think the amount of work it'll be to maintain the USE="-systemd" flag is going to mean it's a second-class citizen. Slackware will keep chugging along, though, as always.

Maybe I'm just wired differently, but I have found OpenBSD to be the easiest to latch on to by far. It has the simplest installer and sanest defaults (again in my own opinion) of all the BSDs, and it's the most similar to Slackware that I've found as well. Its only downsides for me have been hardware compatibility and speed/responsiveness as a desktop OS.

Slackware will keep chugging along, though, as always.

Indeed, they were more or less silent on the whole systemd issue for a while but Eric Hameleers recently mentioned dropping udev in favor of Gentoo's eudev specifically because of what he calls "standards-violating systemd crap"[1] in udev, which means Slackware will be a safe haven for at least the next major version or so.

[1] http://alien.slackbook.org/blog/slackware-live-edition/

A few times now I've seen announcements that systemd is consuming some other aspect of Linux, and every thread devolves into accusations that systemd is eating Linux, and the other side saying that whatever it is just happens to be in-scope for systemd because of how it interacts with some current aspect of systemd.

My question is now: What isn't in scope for systemd?

The way it's described on https://wiki.freedesktop.org/www/Software/systemd/ almost everything is in scope. Everything that's not an end user application can be considered a basic building block of Linux.

That's a ridiculous claim. Systemd is not going to swallow SSL, libjpeg, or GTK. Clearly there are boundaries for it, even if they are a little fuzzy.

I think that's a mis-diagnosis.

Systemd interacts with a many different external components. OK, that means that systemd developers are exposed to a bunch of different components, and work with them frequently. So, they find a pain-point, and they think to themselves "I could improve this." And, because they are competent developers, and it's free/open-source, they do. Sure, the reason the found a pain-point, and chose to contribute is because of their work systemd, but that contribution isn't in-scope for systemd, isn't associated with systemd. It's just them being good citizens and improving the ecosystem.

Now, remember that a significant portion of the systemd developers are also kernel developers, and have been since before systemd existed. So it's not unlikely that because of systemd, they see a way that they think the kernel could be improved. And they're contributing to the kernel anyway, so why not?

That said, many people object to the kind of design decisions made in systemd, and don't like that that those kind of decisions are spreading to the rest of the ecosystem. This isn't systemd taking over, this is the fact that certain prolific individuals, who are systemd developers, are also contributing to other projects; naturally making the same kind of decisions.

From what is in the github repo, i get the impression that this is not related to a RPC/IPC bus at all. Instead it seems to be a systemd analog for IoT/mobile.

Some quick LKML searching etc brings up bus1 references in relation to ARM and devicetree.

It's quite amusing to notice that almost no-one does what you did and actually looks at the original, rather than relying upon someone else, be it some pseudonymous person on the WWW or things like Phoronix, to do the analysis. The systemd people are probably immensely grateful for that, otherwise they'd be having to deal with stuff that would give the cranks a field day like ...

* ... "Kay Sievers is writing a replacement for udev named /usr/bin/org.bus1.devices."

* ... "Kay Sievers is writing a replacement for Dracut init named /usr/bin/org.bus1.rdinit."

* ... "Kay Sievers is writing a replacement for gummiboot that hardcodes support for Microsoft's Boot Manager for Windows." (https://github.com/bus1/boot-efi/blob/c7f3a8a25acc838677b08d...)

* ... "David Herrmann is writing a replacement for kdbus named bus1."

* ... "Kay Sievers is writing a replacement for systemd named /usr/bin/org.bus1.init."

* ... "Lennart Poettering made no comment when asked about Herrmann's bus1 and kmscon, systemd-consoled having been quietly pulled from systemd in July 2015." (https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...)

The simple fact is that it is an IPC mechanism, and it almost certainly indeed is an attempt to come up with a replacement for kdbus, given the latter's withdrawal a while back. It was Herrmann himself who pulled systemd-consoled, and he did so citing the fact that he was working on kdbus. (https://github.com/systemd/systemd/pull/747) It's not shocking to find him working on a successor. The mechanism is currently a filesystem like devpts, containing a pseudo-file named 'bus' that client applications open and perform ioctl()s on. The caveat "currently" is because there's no design documentation there, and the thing is far from finished. There's no guarantee that that will be its final form.

The replacement plug-and-play manager, EFI boot loader, and process #1 programs look like the majority of the project because the test infrastructure for using the new bus, essentially a very feature limited bootstrap system, has been written more quickly than the actual kernel IPC subsystem itself has been.

It's fair to say that this is at roughly the same stage of development as SystemXVI is, albeit that SystemXVI does have design doco (https://github.com/ServiceManager/ServiceManager/blob/master...).