BUS1: A New Linux Kernel IPC Bus Being Made By Systemd Developers

[Delgarde]

It is competing with Unix-like systems by embracing Unix, extending it, and then extinguishing it. It's becoming so different that even applications like NetworkManager are literally impossible to port to other Unix-like systems (not a hyperbole).

And you know why that is? It's because all the work is being done by Linux developers. Why would (for example) the NetworkManager developers waste time on an OS they don't use, when the people who do use that OS clearly don't care enough to help out?

[jacob]

Sure, why not? You've made your own shell, sound API, display server and protocol, your own init system, what harm is there adding yet another non-Unix technology to Linux?

Right you are. Linux must not be allowed to ever introduce any new technology unless UNIX gets its first. </sarcasm>

[cjcox]

b) i really don't understand why Linux does not use XFS as default.

xfs is considered the default "worthy" filesystem in RHEL (or CentOs) 7 (the "god" Linux distro)

Bonus: Name adjectives starting with the letter 'd' that mean something positive (it's harder than you think)

[GreatEmerald]

xfs is considered the default "worthy" filesystem in RHEL (or CentOs) 7 (the "god" Linux distro)

Also default for /home on openSUSE.

[przemoli]

Well. People who actually stand behind Linux as such are also behind SystemD.

Its long past time when SystemD was small project spearheaded by its original creator or two of them.

Now pretty much everybody involved with servers, embedded, mobile, desktop... develop SystemD. Cause its so much better. (Right. I-Know-Unix-Best will claim otherwise. But SystemD is to SysV init-LIKE systems like shell pipe to C. You will know C is inferior if You know what Unix is about )

[tinko]

It is competing with Unix-like systems by embracing Unix, extending it, and then extinguishing it. It's becoming so different that even applications like NetworkManager are literally impossible to port to other Unix-like systems (not a hyperbole). And even many large software projects have entire OS-specific teams dedicated to removing all the stupid Linuxisms developers put in the code.

It's in a league of its own because it's not Unix anymore. And making your own non-standard IPC will ensure future applications written for Linux will never work on anything but Linux. It was more sensible for systemd developers to try to base their work off of DBUS.

You do realize that there is no inherent value to Unix, right? There is not a moral principle that says: A good person must not let his OS deviate from Unix. Unix was developed in the 70s. Many ideas have been taken into the design of Linux, but in other aspects it deviated or will deviate. If the KDBUS situation is proof for anything, than for the fact that design choices are discussed controversially. Some design choices lead to incompatible APIs. There have been reasons for those decisions, even though you might not know/not understand/not agree with some decisions.
It is a fact that Linux is leading in virtually every area outside of The Desktop (tm) and that the development model, which includes the way choices are made, has prevailed, even though every party has and will always have the option to fork Linux and lead it into another direction.

[unixfan2001]

And there we go again with the lies, misinformation and general FUD!

1. systemd is probably the most UNIXy concoction since forever. The fact that some people are too thick to understand this (while simultaneously screaming "UNIX!!" from the top of their lungs) doesn't change that one bit.

2. The reason TIPC isn't the established kernel IPC standard is mainly efficiency and a lack of progression towards modern desktop infrastructure (nor was it ever even created for that purpose).
For one thing, KDBUS can pass references of data between processes rather than copying the data wholesome. TIPC can't do that. The sending process can also copy data directly into the receiver's process queue, as part of a user space only, single-copy operation. Neither of those things is being offered by the current TIPC codebase.

nslay

Did you hear all that on slashdot?
Nothing of what you're saying is remotely true. In fact, in can be easily disproved by the dozens of software packages regularly ported from GNU/Linux to other OS'. While it's true that there are some differences in the way GNU/Linux works to, say, the way a BSD works, most of those differences are the very same kind you'll find when comparing AIX to Solaris or DragonFlyBSD to FreeBSD. UNIX isn't exactly a tight standard anymore.

[unixfan2001]

Bonus: Name adjectives starting with the letter 'd' that mean something positive (it's harder than you think)

How about "delicious"? Dateless? Dazzling? Dashing? Daring? Dauntless? Dandy?

Unless I'm missing something, I don't see what's so hard about that.

[xeekei]

Maybe BUS1 will be better than KDBUS. Hopefully Linus won't hang up on the fact that Kay Sievers is involved.

[uid313]

3.) We are in the 21st century, is been long gone the 80's people, we don't have use anymore for text passing IPC we need structured complex data passing systems with with marshalling and proper binding types and a fragging API, for passing text around and polling them Pipes and Sockets/ poll combo are enough.

Why not just a dead simple, bare bones, minimalistic, fast text-based IPC implemented in the kernel.
Then userspace applications can implement structured complex data passing over it using a library, example JSON or BSON.