Because then they don't have to deal with Torvalds "we don't break userspace" stance. Especially as the devs involved seems to hate maintaining API compatibility...
You couldn't send credentials nor file descriptors to other processes without UNIX sockets. I would argue that allowing for that kind of decoupling of permissions and file access is very much in the spirit of the UNIX philosophy. Quite frankly, there are some problems you simply wouldn't be able to solve without them (in runC, the underlying runtime that Docker wraps, we use them quite extensively).
AFAIK, there's no good way to "broadcast" messages without bouncing through a user space co-ordinator. The current primitives just don't match this kind of need. Presumably, this inefficiency could be a bottleneck for some cases and eliminating the extra step might help, plus a kernel implementation could be simpler (no extra daemons, etc.)
1) They want better performance over the existing solutions. For better or worse applications are [arguably] abusing the heck out of D-Bus. Using regular files might help with huge messages, but it's a lot of overheard for many small messages.
2) They want the ability to insert a broker that manages permissions among the peers, but have the kernel enforce those permissions on a per message basis so the broker doesn't become a bottleneck. That's not easy to with the filesystem.
I mean, strictly speaking it's theoretically possible using the file system considering that in practice the only real broker would be systemd with a fixed set of policies, so theoretically the traditional Unix model of user, group, and supplementary groups would suffice by assigning users and processes into the proper groups, and binding message files into protected group-readable directories. But for whatever pretense, people want the solution to implement a system of opaque, ephemeral identifiers/capabilities.
It sort of reminds me of SMF, launchd, systemd, and similar changes. For example, I was installing Solaris 11.3 on a VM yesterday and was trying to figure out how to set the hostname. You used to set it by storing the hostname to /etc/nodename. Now it's stored in some opaque tree data structure deep in the bowels of SMF, which you set with some long and impenetrable command-line utility invocation. You can still set /etc/nodename; if no hostname is configured then SMF will initialize the hostname from /etc/nodename and delete the file. It boggles the mind.
> * efficiently support n-to-n communication. * be well-suited for both unicast and multicast messages. * guarantee a global message order. * avoid any in-kernel buffering and rather transfer data directly from a sender into the receiver's mappable queue (single-copy).
The downside of the alternatives that you mention is that they're not available as kernel features in Linux. Bus1 is inspired by that previous work and aims to make a new attempt at inclusion in the kernel, which they believe is required to provide the features they're targeting:
> A user-space implementation of bus1 (or even any bus-based IPC) was considered, but was found to have several seemingly unavoidable issues.
> o To guarantee reliable, global message ordering including multicasts, as well as to provide reliable capabilities, a bus-broker is required. In other words, the current linux syscall API is not sufficient to implement the design as described above in an efficient way without a dedicated, trusted, privileged process that manages the bus and routes messages between the peers. (...)
A good example is that Linux distros, Android, and OS X all have their own non-POSIX IPC mechanisms. Applications are somehow voting with their feet and not using Unix domain sockets and pipes.
It leaves me scratching my head because I don't think serialization is that hard a problem. But it seems that most people want IPC with structured data. Android is a bit of a special case because it's a single-language OS.
"Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."
Eh? The majority of modern POSIXy software runs on at least Linux, Mac OS X, and FreeBSD.
In fact, Mac OS X is the most widely deployed UNIX-like system ever. What you're a claiming to be true probably more applies to Mac OS X than Linux.
I honestly haven't seen a recent package that was accidentally not portable in the long-term across the various modern UNIX-like systems because of confusion of Linux for POSIX.
You were asserting that the majority of programmers think Linux == UNIX and have never tried to write a portable application.
Thst is clearly false as the majority of programmers probably confuse Mac OS X for UNIX and most modern unix-like software is portable to at least Linux, Mac OS X, and FreeBSD. Portable is more general than "portable across every UNIX that has existed."
Increasing the specificity of your argument mid-way to avoid the incorrectness of your initial general argument isn't very genuine.
But yes, your revised second statement is probably correct: most UNIX programmers have never tried writing portable code across "DG/UX, Solaris, HP-UX, Aix, FreeBSD, Red-Hat, Debian" exactly because there is no practical reason for it.
> It leaves me scratching my head because I don't think serialization is that hard a problem.
It is a hard problem, at least if you want to achieve concision, make it parseable, and support schema upgrade.
> "Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."
And good riddance. File systems are almost universally terrible [1]. Threading with shared state is also a terrible idea because it's too general, not to mention the poor APIs used to manage them.
IPC is something that's still unfortunately undergoing constant revision, and the structured binary vs. text wars unfortunately both have merit. I think structured text output via a domain-specific language (DSL) is really the proper answer, somewhat like how a REPL works. This DSL is ultimately simple to construct within C since it would be lisp-like in its structure so it doesn't need an IDL compiler, although its textual syntaz shouldn't be lisp-like.
stdin can then nicely format DSL output for the user. Best of all worlds between text, binary, and structured formats.
> Serialisation is its own problem. Should have nothing to do with IPC.
Yes and no. There's significant utility to standardizing serialization in your IPC layer. IPC consists of exchanging domain-specific messages, so the message types can be specified in a header shared between endpoints, and data gets serialized in a standard format.
The IPC API then simply reduces to sending/receiving data to/from endpoints, like channels in CPS. And ideally it should be higher-order so you can send an endpoint to another endpoint.
So you don't need to standardize the serialization, but then you just get a plethora of incompatible formats.
Because the automotive industry wants to move from QNX to Linux, and wants to use dbus like they used QNX IPC beforehand. Thus we have projects like streaming video over dbus(?!).
> Large automotive companies have built huge systems on top of QNX
> messages, creating large libraries used by their applications.
> They would like to be able to use those libraries
> on Linux, but often don't know that there is
> a way to get the QNX message API for Linux. It is called SIMPL
> and it works well.
And the reason this is more prevalent on QNX is that it's a microkernel based platform. Here, in Linux, there's the debate what should be allowed into the kernel, whereas that question is pretty much never asked for QNX. You also don't get discussions about circumventing the kernel network stack to avoid context switches, to name a prominent example. Microkernels also lend themselves better to multikernel designs where you aim to make better use of all the available cpu cores by reducing sharing.
In Binder's case, it makes RPC between different languages significantly easier.
You can't pass file descriptors over sockets.
You can't do RPC over pipes.
Anonymous sockets can only be shared with children.
Named sockets require write permission and a filesystem.
SysV is prone to resource leaks.
Binder has authentication, shared memory, reference counting, weak references, dead object notifications.
The descriptors and authentication part is key, as it allows Android's trusted system_server to open a device or socket for an untrusted process such as an App if it has user permissions. The receiver of a binder request can check the requester's PID/GID and with confidence from the kernel.
Most importantly, I don't think it's healthy to think of POSIX as being done. Some experimentation and discovery of better APIs and better systems should be encouraged.
gah, I'm driving myself crazy; I swear I saw somewhere a diagram of the Taxonomy of Unix IPC Mechanisms, with most of them crossed out and replaced simply with binder, please help me find it!
How do you pass a file descriptor through a socket? They just take bytes?
If you mean "I send some bytes that describes the file to open, and keep my processes in sync manually", of course you can do that, but true passing would allow a number of cool things.
Nice. I've used that book and recommend it to people but I've never seen that before. I don't know how I would find it, either, since it doesn't appear to be indexed anywhere.
AF_INET sockets don't do FD passing or credentials.
There was a patch to add an AF_BUS socket family some years ago that sounded like a pretty general solution but the network maintainer said "over my dead body".
The link used here is a subscriber link, which means an existing subscriber decided to make this post available to the entire HN community during its non-free period.
If you find this content useful, and you aren't already a LWN subscriber, you should consider becoming one!
Is there a reason this couldn't be done as a new socket type (initialized by socket()) instead of either a dedicated new system call and/or the device node they're doing now? I'm not sure it'd be important to do that instead, I'm just curious if there's an obvious rationale I'm missing.
It's not a particularly good fit for the socket API. In particular, communication is unidirectional at its most basic and uses something a lot like seL4's "reply capabilities". It's a very nice, if counterintuitive, design, and it can give an asymptotic memory usage reduction, but it means that sendto and recvfrom don't work the usual way.
I believe one of the original proposals in this design space was AF_BUS[1], which was actually in fact a new socket address family. But that design used domain sockets, which were extended to support multicast -- and it was rejected as making an already complex path more complicated, among other reasons.
TIPC is very good protocol, I was working on very robust systems built on it.
Just a quick list of features, from Wikipedia:
Location transparency of services in a network
Auto-discovery mechanism
Reliable transport
Standard socket interface support
Connectionless, connection-oriented and multicast messaging
Subscription to network events
"To create a new node, an application performs any of the various ioctl() operations that accept a handle, passing the special reserved handle number of "3".
That's the thing about Linux: they have literally not one, but multiple armies of "programmers", and yet even after 20+ years of an absolutely furious development pace, basic things like inter-process communication still do not work desirably. Startup/shutdown? Yep, you know it already, it's still in flux (SMF in illumos has been humming along for a decade now). Filesystems? Flux. Observability? Flux. libc, what libc, that comes from GNU, flux. libstdc++, yeah we just decided to implement a "version 3 of that", flux. Debugging format? You have to rip out your runtime linker in order to get DWARF 2 support (DWARF 2 has been available for 23 years now), so, flux. Virtualization? Wait, which one of the 56 not-quite-right virtualization solutions do I mean, because Linux people are flapping with that and nobody can get it right? Flux.
The illumos kernel has been stable for decades now. Teams of five people here, three people there, four people over there, they roll up their sleeves, look at the issues the customers have had and are actually having now, professional engineers with formal education and insight, and in two years they have a working product which only needs a small fix here or there, and is tenable decades into the future. It goes to show that the number of programmers does not a quality, working product make.
For example: it's 2016, and my Linux filesystems in Vertica suddenly go into read-only mode, nobody knows why yet. In 2016! I cannot believe I just typed that, but it's true.
I've been running ZFS since 2006 both professionally and privately on Solaris and SmartOS at several large companies and I have never seen it go into read-only mode. The team which designed ZFS was only five people, not an army.
Bryan Cantrill summed it up so profoundly when, upon showing SmartOS running Linux applications, he ran /native/bin/dtrace and proclaimed:
The Linux libc API changed a couple of times in the 1990s (a.out → ELF, libc5 → libc6, etc), but the Linux kernel ABI (what libc uses to talk to the kernel) has been stable since practically the beginning. Linus detests breaking anything that talks to the kernel and considers it massively unprofessional, to the point that even a terrible API will be set in stone if anything uses it.
Yeah but is it possible to run very old binaries on a current kernel? Unlikely. What about binaries compiled on a newer system than your own? Even less likely.
On SunOS, I can install a driver built on SunOS 5.5.1 (Solaris 2.5.1) on the latest illumos or Solaris-based OS, without recompilation, thanks to the device driver interface / device driver kit ("DDI / DDK"). Solaris 2.5.1 came out in 1993; illumos came out, well, today (multiple commits every day).
It will always be in flux because it reflects what Illumos doesn't have: A userbase as diverse and large as Linux, of which a large proportion have competing needs and wishes and the ability to change it at will. This is not just about license either, but about the availability of people who understand the kernel.
I'm sure we could have something cleaner with a single, coherent team. But we also would have something that'd be useful to far fewer people.
Linux wins not by being best at everything. It has plenty of ugly warts. It wins by being accessible ranging from e.g. my ability to just take a job 20 years ago to port it to a custom x86 board with no bios or hard drive, because everything I needed was easily available, to the ability to hire any of a "an army" of past or current kernel developers to help solve my problems or do my custom development, to the ability for people to just write "yet another filesystem" and have actual real people try to use it and give feedback and contribute code.
The most important part of the success and value of Linux is that community. Without the community, it'd have little to offer over any number of other kernels that are better in some areas, worse in others.
But with it, it stands head and shoulder above all kinds of technically very impressive solutions because I can do things with and to Linux that I can't do, or can't do cheaply enough or in short enough time, with alternatives (and yes, that can be because of lack of knowledge of alternatives, but that too is part of the community/network effect).
Don't underestimate the importance of people.
> The team which designed ZFS was only five people, not an army.
And that's great. But the whole ZFS saga is also an illustration of how licensing early on can hamper adoption (KDE vs Gnome is another good illustration of how important license is; and how lasting the effect can be even after the licensing issues are sorted)
to the ability to hire any of a "an army" of past or current kernel developers to help solve my problems or do my custom development
Aha, you mean like redhat and IBM did, where there are now "kernel developers" who can't find their way out of a wet paper bag, and spend more time arguing with paying customers back-and-forth in redhat's bug system, because they don't have a clue where the problem is? When you have some spare time, please do peruse https://bugzilla.redhat.com/index.cgi, in order to have a look at what your presumption looks like in the real world...
to the ability for people to just write "yet another filesystem"
...Because we need more beta filesystems instead of not having to worry about data integrity, right? And because it's just too much fun to be solving the same problem over and over and over again, but never quite get it right? So that for example, on Linux, we can have things like these:
/var/log/messages.1:2267:(redacted) kernel: VxVM vxio V-5-0-1266 Subdisk disk_42f7-01 block 108279824: Uncorrectable write error
/var/log/messages.1:2270:(redacted) kernel: lost page write due to I/O error on VxVM14000
/var/log/messages.1:2411:(redacted) kernel: VxVM vxio V-5-0-1266 Subdisk disk_42f8-01 block 108003336: Uncorrectable write error
...which ext3, which was on this Veritas disk group, wasn't able to recover, let alone detect. In the 21st century. Because community. I last saw a problem like this on Solaris ten years ago, since it has been a solved problem since 2006 there. Bryan is correct, I do have clean water, and even modern medical care facilities!
The most important part of the success and value of Linux is that community. Without the community, it'd have little to offer over any number of other kernels that are better in some areas, worse in others.
The two of us (both with several decades of UNIX system administration experience under our belt) just wasted one hour trying to get a simple NFS share to work on RHEL 6.5, and it still doesn't work, with mount(2) returning "incorrect mount option" without saying which; and that was with us carefully following both redhat's official documentation and many examples on the InterNet.
Because, you know, man. Like, Linux! And stuff.
I have zero interest in how much of a community Linux has (99.99% of them are former Microsoft(R) Windows(R) users, with the corresponding mentality to match).
When I use a computer, I use it to get work done. All I wanted to do in the aforementioned NFS fiasco is to test my code, so I could get work done.
On Solaris / illumos, all I do is
zfs set sharenfs=on pool/filesystem
and then I access that on any client, without even worrying about mounting it, like so:
ls -l /net/nfs_server/filesystem
without caring if it's NFS 2, NFS 3, or NFS 4 (like I have to on Linux, whose implementation of NFS is so dumb that it actually offloads that on to the system administrator to worry about)[1][2].
I could have had my tests long done and the code deployed by now. I could have had work done if it weren't for that same community not having a freaking clue how to make things JustWork(SM), and if it weren't for the
Ah, my apologies for that: I did not realize that shoddy NFS software is due to my incompetence. I also apologize that I wasn't able to get something which kind-of worked in RHEL 5 to work in RHEL 6.5 because things which are completely unnecessary on UNIX (like worrying about separate portmapper service) and which were in userland are now suddenly in the kernel. But only for NFS 4. Because the documentation is actually unclear on whether that's the case for NFS 2 and 3. And because the NFS protocol specifies that client and the server should auto-negotiate which version they will use. Because of course the community can't figure out where what should be, so flux. Again.
I guess it's really snobby of me to except things which work on UNIX according to specification to behave the same way on Linux. Because Linux is cool. And it's great. And it has the biggest, bestest community. And because I don't appreciate just how great that is, instead being focused on getting work done with computers.
Now let's rehash inter-process communication again. Because it's fun rehashing things which work in other operating systems, over and over and over in Linux. Because Linux is cool like that.
I've decided to stop interacting with Annatar, it's not worth the rage. Especially when he starts misrepresenting GNU/Linux technology that you are deeply into the development of (runC and containers in my case).
Part of engineering a good solution is being able to recognize when you are in knee deep, and that it's not the best solution, and ditch it. That's what turns a good engineer into a great one, because then she or he turns around and builds the solution. You might not believe the grandpa here, but you're in knee deep, if not deeper.
On a personal note, I'm happy that you've stopped interacting with me. Good luck.
> Aha, you mean like redhat and IBM did, where there are now "kernel developers" who can't find their way out of a wet paper bag,
No, I mean like I can find any number of actual maintainers with a known track record and make them an offer to pay to have work done. Been there. Done that. Got good results.
> in order to have a look at what your presumption looks like in the real world...
It's not a presumption. It's actual experience in finding people to do work.
> ...Because we need more beta filesystems
Not everything is about need. While I work full time with Linux, a lot of what I use my computer for is fun, experimentation, learning. So yes: We need more beta filesystems. It's great that people experiment and learn. Everyone should try their hand at kernel changes, to learn - it's not magic.
> ...which ext3, which was on this Veritas disk group, wasn't able to recover, let alone detect. In the 21st century. Because community. I last saw a problem like this on Solaris ten years ago, since it has been a solved problem since 2006 there. Bryan is correct, I do have clean water, and even modern medical care facilities!
So use Solaris then, if you have so many problems with Linux. We're not forcing you to use Linux. It's not a dictatorship. I'll happily admit to all kinds of warts in Linux - I explicitly made the point that Linux has plenty.
> I have zero interest in how much of a community Linux has
Good for you. Meanwhile, for me, the community makes all the difference in making sure that I, e.g., has a decent sized hiring pool at all levels when I need developers, or which means that pretty much no matter what I try to do, there are people who have done it before I can ask questions of.
To me, that matters far more than avoiding a few warts.
This warrants a reply of its own, since it is the core idea of my essays: it is the very difference between a stable, working, reliable product and Linux: the people. The right people. Competent people. People with the neccessary education, experience, and insight.
If if ever need heart surgery, I guarantee you that I won't go to the local shaman, no matter how happy he will be to perform the operation voluntarily and for free. Same goes for the local exorcist. If I ever need one, I'll get my surgery done by a specialist in cardiology, because they have been formally educated, formally trained, and have the requisite experience to operate on a human heart. And in the case of illumos / SmartOS, they will even do it gratis, like "medical doctors without borders" organization does. Right people for the job. For some reason, people here and at large believe that when it comes to inter-process communication, NFS, or writing operating system kernels anyone can do it.
Why exactly people believe that computer science is different from surgery, I haven't discovered yet, but based on empirical evidence of Linux and other crappy software, I have a hypothesis, and since the sample size is large, I might have a theory soon...
But 99% of what we do are not that of heart surgery. Much of it is playing. Much of it is experimenting. Much of the actual work needs flexibility, familiarity and community more than it needs technical excellence.
Which is why I wrote what I did.
Your reply manages to turn it entirely on its head.
People believe computer science is different from surgery because it is: Nobody dies when my half-assed experiments with OpenGL crashes. Nobody dies if my laptop crashes.
There are certainly niches where it is life and death. Let others take care of that - I don't want anything to do with it.
But 99% of what we do are not that of heart surgery. Much of it is playing. Much of it is experimenting.
And it shows. However, just because you can get something to work, in some way, does not suddenly make you (or anyone else) a professional. Case in point:
...Nor does it make your playful experiment fit for production where people like me are trying to get work done.
"I got something to work. Because Linux! Because community! Um... I think I'll go get a job as a computer professional now. What could possibly go wrong? Linux is so awesome!"
People believe computer science is different from surgery because it is: Nobody dies when my half-assed experiments with OpenGL crashes. Nobody dies if my laptop crashes.
An operating system's kernel is an extremely complex, special piece of software. A bug in such software can cause many people to die, which is why someday you might see disclaimers about running a nuclear facility and fitness of purpose. (Interprocess communication, the original topic, is part of an operating system's kernel.) Writing and diagnosing such software requires very deep insights, which very few have, even among computer professionals. Additionally, it absolutely and without fail requires formal education in the problem domain, it requires experience, and it requires apprenticeship, and I'm writing about physical one on one mentorship. It's not something one can pick up "from the community", never has been, and never will be, and if anybody tells you any different, they're either dangerously ignorant, or lying to you for the purpose of their own agenda.
Experimenting is all good and well, but when the entire armies of you start deploying your experiments in production and it becomes a trend and then the rest of us are, in fact, forced to take on such jobs because there aren't better ones, then it becomes a systemic problem. Not to mention that armies of you are currently in the process of artificially driving salaries down and it will be years before the market self-corrects, so make that a double whammy.
Now, me, I don't so much mind that cheap Linux labor is artificially driving salaries down, since cream always rises to the top, as they say, but I do so very much mind being forced by contract to work with things like ext3, which is based on concepts from the past century and which have since been long abandoned elsewhere, or that my really cool super slick database becomes unstable because of your experiment ticking underneath it (and before you ask, if it were up to me, I'd never put my database on your experiment). I mind even more when your (plural) experiements end up causing a priority 1 incident in the wee hours in the morning, when I'm busy getting my beauty sleep. In my case, you see, it's "because client contract!" Slightly different slant on things than in your case. Welcome to the industry.
ZFS/SMF/zones etc are due to the engineering excellence at Sun though, I'd be interested to know of the innovation/improvements since Oracle slammed the door on OpenSolaris.
Not only is it on par, it's revolutionary. I'm referring to imgadm(1M) and vmadm(1M) in particular.
The guys didn't have to get out of Oracle to reinvent the wheel: the engineering they did is sound and tenable enough for decades into the future, so they built upon it.
Well, you're feeling nice and smug, as usual. And after vomiting upon seeing this, I don't blame you.
OTOH, some of the above you mentioned isn't bad. Linux's "just a kernel" philosophy can be useful, and allows people to experiment with new inits (s6, runit, &c) and new systems that come in handy.
And go see Brendan Gregg's talk on Linux tracers. It's not as simple is dtrace, given the tracing war hasn't been won, but it's at a place where you CAN do most of the things dtrace does.
Yeah, not arguing that, but you also have some really weird, misguided ideas. Like your understanding of bytecode. I think you just have a natural propensity for being smug.
As for using Linux, I'm not dropping Linux until LX-branded zones can run Steam, and my game library. And I don't see that happening for a while yet.
It may not be ideal for infrastucture, but if you want a UNIX on your desk, for all its flaws, Linux is pretty hard to beat.
That's fine for you. Mac has traditionally been a very good option. However, I hear Apple's been making it difficult in the lastest updates. For me, anyways, it's academic, as I can't afford apple hardware.
Yep, I understand that not everybody can afford it. To me, it's was a pure, dirty capitalist investment thing: that system paid for itself hundreds of times over with all the time and effort I've saved not having to mess with it. Best money I've ever spent, what with all the time I've saved, and all the jobs I obtained with it.
Have you looked at alternatives to GNU/Linux, like PC-BSD or FreeBSD? Did you find those inadequate / too much overhead?
I already explained: As much as I love Linux for some reasons, and would love to move away from it for many others (broaden my horizons, escape systemd), I play video games. Right now, games barely get a Linux release. If I'm on BSD or Solaris, you can forget it. And while LX-branded zones are good, I think BSD is a better system for my needs, and in any case I doubt they're good enough to get the games talking to my GPU properly. And I'd love to avoid putting another layer between the games and the hardware if I have to. I remember using Wine.
And I'd love to avoid putting another layer between the games and the hardware if I have to. I remember using Wine.
I agree, that makes perfect sense.
and in any case I doubt they're good enough to get the games talking to my GPU properly.
Now that's a whole different story: NVIDIA provides Solaris-native packages for their drivers, and they JustWork(SM). Way back in the day, NVIDIA engineers were stunned that they didn't have to produce a completely recompiled driver for every Solaris release: thanks to device driver interfaces/driver development kit[1], one could develop the driver on an ancient version of Solaris and have it work flawlessly on the latest-and-greatest one.
When I wrote that I'm using Mac OS X, that was the truth, but it wasn't the entire truth: I am typing this on my intel-based workstation I put together myself, with Solaris 10 running on it. And it has an NVIDIA GTX 980 accelerator, the top of the line model one could buy at the end of 2014. Downloaded the driver from NVIDIA's site, installed it with pkgadd(1M), and it JustWorks(SM)[2]:
> pkginfo -l NVDAgraphics NVDAgraphicsr
PKGINST: NVDAgraphics
NAME: NVIDIA Graphics System Software
CATEGORY: system,graphics
ARCH: i386
VERSION: 343.22,REV=2014.09.11.17.06
BASEDIR: /usr
VENDOR: NVIDIA Corporation
DESC: X and OpenGL Drivers for NVIDIA Quadro graphics
INSTDATE: Dec 04 2014 22:37
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 188 installed pathnames
30 shared pathnames
2 linked files
42 directories
7 executables
405482 blocks used (approx)
PKGINST: NVDAgraphicsr
NAME: NVIDIA Graphics System Device Driver
CATEGORY: system,graphics
ARCH: i386
VERSION: 343.22,REV=2014.09.11.17.06
BASEDIR: /
VENDOR: NVIDIA Corporation
DESC: Kernel Drivers for NVIDIA Quadro graphics
INSTDATE: Dec 04 2014 22:37
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 6 installed pathnames
3 shared pathnames
3 directories
52151 blocks used (approx)
However, all of that is not to say you could play games on Solaris. If they were really optimized for Solaris, then they would fly, as Solaris is really, really, really fast, especially on intel. But since they aren't, and that's not realistic right now (and might never be realistic), I completely understand where you're coming from.
As for Mac, OS X has plenty of major and indie titles in the Apple app store. But, it's for people who are actually willing to pay for that.
I was really concerned with a) driver perf, and b) how the drivers worked in an LX-branded zone. Steam and the Humble Bundle will leave me set for games.
And now, because you didn't ask for it, Game Reccomendations:
Have you tried out TIS-100? You can get it through Steam, and maybe a few other places, it runs on Mac, and I'm willing to bet it'll run in an LX-brand. It bills itself as "the assembly language puzzler nobody asked for," and has a focus on minimal instruction count, maximum speed, and paralellism. You should know by this point if you're interested.
You also may want to check out Xonotic, which is an arena FPS with a relatively lively community, which may compile on Solaris. Think a mixture of Quake and UT.
I didn't ask for it, but I love the clues you drop... "TIS-100"? "Xonotic"? My interest is further piqued, now I have to go and research...
Apropos Qt, it is not for the faint of heart: even on platforms it officially supports, it is very hard to build, at least it was last I had to do it professionally, back in 2013. Qt is really unprofessional as a product, I remember it involved a lot of hacking and coercion of the build engine to get it to build. And it's monstrously large.
Post scriptum:
ah, "Xonotic" is a fork of "Nexuiz". Okay, that's clear now.
"TIS-100" is a puzzle game. So these are individual titles, not technology which enables running on a different operating system. "The Ur-Quan Masters" used to build and run superbly on Solaris; it showcased just how good of a gaming platform Solaris could be if the code is good and clean.
lx-brand could be made to work, this screenshot shows it's possible:
I haven't researched how to translate that into the lx-branded zone though (what the package equivalents would be), primarily because I viewed even the above as too much work: for example, the desktop would have to be brought over to somewhere with an X server. I don't see how it could be made to start on the bare metal's display when it's running in one of the hypervisor's zones?
Yes, that's why I said game reccomendations. I've been meaning to check out UQM for a while now.
Xonotic should run on Solaris. DarkPlaces, the engine codebase, is fairly portable last I checked.
TIS-100 runs atop Mono, but it's probably not using GPU heavily, so it'll probably run in an LX brand if you can get X up and running. As for running X11 on LX, the answer is both simple in its phrasing and hellish in its implications: X Forwarding.
I kid. Although it does seem like X forwarding is the easiest option. Luckily, you're not forwarding over the net, so you should be fine.
But yeah, it's nice to have a simple discussion about running video games in ways not intended, and what games are good, after spending a while explaining why systemd is a bad idea for the 15th time, because some people are still taken in by the sparkly unit files, and aren't paying attention to the beast lurking below the surface. (If such people are reading this thread, I'll give you a hint: Separation of concerns is a good thing, and if the process will panic the kernel if it crashes, I want it doing the job it's required to do. AND NOTHING ELSE.)
You are probably right. But it sounds in very similar way to the Year of Linux Desktop in contrast to Windows Desktop or Linux Gaming in contrast to Windows Gaming. "Linux is all the better! But we don't have all the drivers, because of those pesky hardware companies. But we don't have all the software, because of those pesky software companies. But we don't have all the preinstalls, because of those pesky OEMs."
It might be better, but you can't strike out network effects. Because then you just end up with another rant why your thing is superior to that other thing everyone is using.
I am wondering if good old things are not just predestined to be unpopular. Probably only new things can get popular (even if they are just miserable copies of great old ideas). Next generation is more inclined to pick up something from the news than from history books. Next generation has their new lingo, so they will not understand easily old lingo. Next generation is cheaper to employ than older generation, so it's easier to get more in terms of quantity. Most (young?) people want everything, even if mediocre, now, than having few perfect things now, few perfect things later. The world belongs to the youth.
Hehe, that was the only part of this article I didn't particularly love. This is how it works:
A handle ID is a 64bit integer. If lowest bit (BUS1_NODE_FLAG_MANAGED) is set it is a handle ID allocated by the kernel (the only mode currently supported). If the second lowest bit (BUS1_NODE_FLAG_ALLOCATE) is set a new handle should be allocated by the kernel, otherwise the handle ID must refer to an existing handle.
No. Nonononononononono. We were ALMOST FREE! Just get these high-level abstractions out of my effing kernel. They don't belong there. Linus said as much himself. The only reason kdbus, this thing's predecessor, got so much as a glance is that Linus trusts Greg KH. A trust I would now consider somewhat misplaced. This is yet another piece of crap that was tacked on by systemd nonsense. It's non-portable, and they want us to use it upstack.
Have these people lost their effing minds? Do they think we don't care about compatability? Just because Lennart said "screw POSIX" doesn't mean you should do it.
I agree. I can't see any real reason for this to be in the kernel. Is it faster? Does it need access to memory in some way you can't do in userspace? The only practical reason I can think is if it is in the kernel you can 100% rely on it being present and available. Userspace processes can be killed.
So perhaps the real solution is to provide some kind of mechanism for userspace processes that act like kernel drivers, in that they are definitely running all the time, but actually run in userspace.
The reason this is in the kernel is that DBus is slow (according to Linus, because it could have been written better by monkeys with typewriters), and Lennart wanted it in the kernel/systemd, and Greg KH agreed, and Linus trusts Greg.
The announcement email from David Herrmann explains that they did consider a user-space implementation, and lists the reasons why they decided that it had to be in-kernel:
The reasons are mostly performance reasons. As I said in my other post, IPC latency is way down in the priority list of things to optimize (relatively to network and disk latency).
Unless the application is a HPC parallel computation that is IPC bound, Bus1 has no performance justification. If the main justification for a modern kernel IPC mechanism is performance, I'd much much much more trust a proposal coming out of the HPC community than the desktop experience community.
You’re ignoring the fact that Bus1 is based on binder, not dbus, so performance (mostly power efficiency) apparently was an issue—on Android.
So now you have two ends of the spectrum where this effort does matter, performance wise.
This only leaves the middle (desktop), but there are other reasons why that evil desktop crowd wants IPC in kernel, however high on a ‘priority list’ they might be.
My point still stands. I don't think it's very likely that the main power hog in a mobile phone is the IPC mechanism. Unless IPC is happening in a tight loop, on the order of millions if times per second, it's just not common enough to really make a dent.
You have wifi, screen brightness, CPU-hungry background apps, etc. to fix first.
For priority inversion it seems dbus-daemon is at fault here, not user-space message routing in general. It's just as easy to have two message routing processes, one for low priority messages and one for high priority messages.
As far as 4 context switches versus 2 with regards to latency. A context switch takes microseconds... This is vastly smaller than the 250ms UI response time.
Again, this looks like a solution looking for a problem.
Fixing wifi or screen before working on micro-problems in the kernel for the sake of global power efficiency is founded in every kind of logic. It's literally Amdahl's Law: reducing power usage in a component that already has the most minimal power usage is a waste of effort for no noticeable effect. The cost-benefit ratio is indefensible. This is insanity.
You seem to be fixated on this idea that this is purely a performance optimization. You’ve made it your strawman. But that is in fact only one minor point.
Linux is lacking a coherent IPC system and the necessary primitives to build one. That’s the bottom line.
No I very much did not make it my strawman. Look at the original announcement email, they themselves list performance as their main motivation.
Please, I can argue down any allegedly rationale for creating Bus1. Try me. You have yet to put forth any convincing argument.
The real bottom line is Linux already has a coherent IPC system but third parties don't like it and are irrationally fixated with an in-kernel solution that reflects their grand idea of what a coherent IPC system should look like. It's childish, it's bad engineering, and it's a waste of effort.
I would say it is to create the primitives needed for a multicast-capable (n-to-n) local IPC system. Obviously in such a way that it is safe, reliable, predictable, scalable, fast and lightweight.
You can create a multicast-capable (n-to-n) IPC system in such a way that is safe, reliable, predictable, scalable, fast and lightweight in user-space. Kernel is not required!
* I don't see a time-slice accounting for the bus broker as an issue. If it's a system daemon, you can define away the problem. What's the use case for doing time-slice accounting where ignoring the system daemon's usage matters?
* for priority inheritance, have multiple daemons for each message priority level. Only privileges processes can use the high-priority message router, but can optionally use the low-priority message router when they want to inherit the priority of their sender.
* like I said, context switching is irrelevant since context switching is not the bottleneck in event latency nor in power usage.
* if FD accounting is important, move it out of the broker and make it p2p with broker coordination.
* kernel and LSM hooking feels like a feature looking for a use-case. If anyone really wants to do that, I'm sure the specific use case can be accommodated. Not every user space program need be trackable via LSM.
* for side channel and message ordering, why is this a core feature of the transport layer? I don't think all applications need this and if they do, something simpler and more specific to the application protocol could be developed. Generalized message ordering guarantees as part of the transport layer seems like it violates end-to-end design. A robust application protocol will end up ensuring this on its own anyway.
There you have it. I'm sorry but you don't have a strong case. Linus is even more opposed to this than I am and is probably better about system design than I am as well.
I don't get what you are trying to achieve with this discussion. You didn't provide any serious alternative, you just say that the issues don't matter to you.
Obviously, if you do not care about any of the features, then you should not be using bus1. But that does not mean that others don't care, so why are you objecting so strongly to us providing a solution to these problems?
Firstly, if you don't want a bus IPC with multicast messaging, then use something else. But if you DO want that, then you cannot ignore message ordering, that is the whole point (otherwise you could just use repeated unicast instead).
If you want message ordering you cannot split things into several daemons, or you break the order (unless you add some more communication on top). Same with p2p (side-channel) communication for FDs.
The broker is basically doing work on behalf of the sender, but without proper time-slice accounting it is not accounted accordingly. Obviously in many cases that does not matter, but you cannot simply ignore the problem if you want a general, lasting solution.
It is true that performance is not the main feature, but that is not to say that it does not matter at all (to anyone, ever), so you cannot simply brush it aside, proposing a solution that would have (almost by definition) hundreds of percent worse performance (as you are just doing more round-trips, even ignoring the context switching). To say that IPC latency is "not the bottle neck" only makes sense if you have a specific use-case in mind. With sufficiently low latency, we open up the possibility of using IPC for things that could only be done in-process today. This is not the MAIN purpose, but ignoring it is short-sighted.
I just got an email today from people asking about the LSM hooks, so there certainly is interest, and this (like the message order) is not something you can bolt on top.
I have not seen Linus comment on this, please give a link if you have. Whatever reservations he had about kdbus should not apply to bus1.
Look, there are plenty of things that could be improved on bus1, and I'm sure some careful review will find things we could and should do differently, but please at least spend more than five seconds looking into what we did and thinking about the problem. We want a multicast IPC system, but we want one done properly. You cannot simply say that doing one that is several times slower, doesn't do proper resource accounting, gets the message order wrong and cannot integrate with LSM is "good enough for me" and expect that to be the end of it.
The original point is that this doesn't have to be a kernel. None of the current rationale gives any use-cases for the features you're offering, you're just saying "this feature requires kernel support" well what is the use case for that feature? Maybe there is another way that doesn't require kernel support.
Multicast messaging as your main motivation for a message ordering layer when that layer has drastic effects on performance and operational characteristics is a strange proposition. I'm willing to argue that 99% of application protocols will have no use for baked-in multicast as you've implemented it. What exactly is the killer use case for multicast messaging with side-channel aware causal message ordering? What prevents an application that cares about this from ordering incoming messages according to a lamport clock itself?
I see no downside to these features in general, it's just that the justification for putting it in the kernel is weak. Kernel code has an infinitely high maintenance cost and it's not clear bus1 is the end-all messaging layer you want it to be. There are lots of past failed examples, inotify, dnotify, and fanotify come to mind...
>The real bottom line is Linux already has a coherent IPC system but third parties don't like it and are irrationally fixated with an in-kernel solution that reflects their grand idea of what a coherent IPC system should look like. It's childish, it's bad engineering, and it's a waste of effort.
One should think the goals are conflicting, but they are not. The secret is that the order is partial, as you say, but from userspace's point of view it is indistinguishable from a total order. The only messages that are not well ordered are messages that can never interact, so it is not possible to observe the lack of order from userspace. I wrote up how it works here: https://github.com/bus1/bus1/wiki/Message-ordering
As long as processes communicate only via Bus1, yes, it is not possible, but there are plenty of other IPC systems on unix that can make the lack of total order manifest. Advertising it as a total order doesn't seems like a great idea.
proc1 sends a message to proc2 via bus1, then sends a signal to proc3 via a shared memory channel by incrementing a counter in shared memory; proc3 sees the message and signals proc4 via bus2;
There is no partial ordering between proc1->proc2 and proc3->proc4 as the memory channels are invisible to bus1, but Proc2 and proc4 can detect the total ordering violation by using another counter in shared memory.
Right, we only enforce the _order_ of message delivery, not the _time_ of deliver. I.e., consider the sequence of messages received on each peer, these sequences each respect a global, total order on all messages. But there are no timestamps on them, and no way to compare sequences from separate peers.
The two main reasons I know/care about (there may be more) are that it can be much faster (zero copy, reduced context switches) and also guarantee the message isn't changed while reading (by sealing the originating buffer).
The last is something you need kernel help to enforce.
There's no case for this usually marginal speed benefit.
Most programs are dealing with vastly slower bottlenecks. Like network or disk latency. IPC latency is so far down the list of priorities in terms of things to optimize.
Not to mention that regular user-kernel-user buffer copying is plenty fast now, especially since the buffers will likely be cache-resident. Zero-copy is mostly hype without performance numbers to back it up. Don't need this complex message sealing mechanism.
I don't see anything described that can't be done in a userspace library through shared memory. Maybe security is a concern, where we don't trust some nodes that might be exploited not to be able to screw with the shared memory? But then zero-copy would be off the table for the same reasons, no?
See the ksummit announcement elsewhere in this thread. The list of issues is given there. We could get 95% of the way in userspace, but not all the way (the issues are by no means obvious or trivial, so take a look at the announcement).
Exactly! They should just use the Android Binder IPC that was merged some years ago and was widely heralded as a pinnacle of open development, good design and especially security. (Getting Binder standardized in the next revision of POSIX is surely a mere formality.)
I thought the interesting part of kdbus was the "memory sealing" - you could take a shared memory buffer, write to it, then "seal" it (so no further changes were allowed) and share it with another process. I believe you cannot efficiently do that in userspace. That doesn't seem to be part of this proposal.
memory sealing can be used by anything that can do fd passing, which bus1 does (as does UDS). That code is already upstream and was not really tied to kdbus.
What's high-level about bus1? This has nothing to do with systemd, and very little (apart from history) to do with kdbus.
As to portability, this is a linux kernel module, but there is nothing really inherent to linux about it, so porting it to another kernel should not be a lot of work if that is interesting to anyone.
What's high level? They're providing a message bus. That's not an IPC primitive. That's very high-level.
As for systemd, I gathered there was a connection to kdbus, which was Lennart's baby. Thusly, I gathered it needed init to cooperate, the same way kdbus did, and any non-bus1-aware init just wouldn't work with apps that used bus1.
As for portability, what other OS will implement this muck? None of them. It's portable the same way systemd is: "apps that depend on us are portable, so long as every os copies all our stuff, and re-implements all our APIs"
Forcing other OS's to implement your stuff isn't portability.
None of QNX IPC, Mach IPC, Minix3 IPC, Solaris Doors, NT LPC or Android Binder is portable, and all of them are used by low-level user-space on their respective platform. But if Linux developers add a new IPC mechanism for similar purposes, it must be useless "muck"?
NT doesn't have to worry about compat. Neither do Android apps. QNX, Mach, and Minix3 are microkernels, and that IPC isn't used by high-level userland in the UNIX compatible systems. Doors is something I have similar objections to.
But if bus1 is a successor to kdbus, it's not intended to be used by low-level userland, it's built for highlevel userspace. Like systemd, this is trying to coax high-level userland to be incompatible with other unixes.
The fact that no unixes other than the originating one, if the orginator was a unix, has picked up any of these systems speaks volumes about why you shouldn't use it in highlevel userland.
Please look at the code. bus1 is no more high-level than UDS.
You 'gather' a lot about how this works, please look at the code/docs before writing things. 'kdbus' was Lennart's baby? Look at who wrote the code, who submitted it upstream, etc.
bus1 needs init's cooperation in the same way UDS does. It is simply a nonsensical statement, bus1 is simply a transport, what apps do on top is a different topic.
When I said that bus1 should be reasonably portable, I meant exactly that: the code of bus1 itself should be easy to port to other OSs. Whether apps that use bus1 are easy to port to systems without bus1 depends on how what they do and what is available on the other systems in question...
Well, that's not what you said, but portability, I'll accept.
The fact that Bus1 doesn't need init cooperation is good.
However, Bus1 is MUCH higher level than UDS. UDS is a two-way bytestream between two processes. Bus1 as much more complicated system, designed to send structured binary messages, and includes a permissions system, sealing, and a lot of other complexity. It doesn't belong in the Kernel any more than DBUS.
As for kdbus not being Lennart's baby, and that I should look at who wrote the code, I did. I direct you to https://lwn.net/Articles/580194/, where Lennart not only takes credit for KDBus, but also says it's application-level, implying it is intended to be used in high-level userland.
High-level abstractions for applications don't belong in the kernel.
There is not really a permission system in bus1 any more than fd passing is a permission system. What bus1 gives you is the primitives to build a permission system though.
There is no sealing in bus1.
The payload of a bus1 message is exactly the same as the payload of a UDS message: unstructured binary data. bus1 is (like UDS) just a transport, it would be up to the consumer to add structured payload if they wish.
kdbus is higher level than bus1, don't confuse the two. kdbus is still not at the application level though, there would have to be a userspace component inbetween.
High-level abstractions for applications don't belong in the kernel, I agree. But that is a strawman, bus1 is not doing that at all.
The whole point of capability based security is that there is no permission system, because permissions are implicit in the capabilities. So this is much simpler than e.g. SysV message queues.
138 comments
[ 2.4 ms ] story [ 201 ms ] threadWell, for starters they're a bolt-on that doesn't fit with the actual classic Unix philosophy.
http://www.thomasstover.com/uds.html
2) They want the ability to insert a broker that manages permissions among the peers, but have the kernel enforce those permissions on a per message basis so the broker doesn't become a bottleneck. That's not easy to with the filesystem.
I mean, strictly speaking it's theoretically possible using the file system considering that in practice the only real broker would be systemd with a fixed set of policies, so theoretically the traditional Unix model of user, group, and supplementary groups would suffice by assigning users and processes into the proper groups, and binding message files into protected group-readable directories. But for whatever pretense, people want the solution to implement a system of opaque, ephemeral identifiers/capabilities.
It sort of reminds me of SMF, launchd, systemd, and similar changes. For example, I was installing Solaris 11.3 on a VM yesterday and was trying to figure out how to set the hostname. You used to set it by storing the hostname to /etc/nodename. Now it's stored in some opaque tree data structure deep in the bowels of SMF, which you set with some long and impenetrable command-line utility invocation. You can still set /etc/nodename; if no hostname is configured then SMF will initialize the hostname from /etc/nodename and delete the file. It boggles the mind.
* Inotify events are coalesced. Great for notifications, may be bad for discrete messages.
* The sender may want information about # of messages sent, synchronous delivery, etc.
Some call-outs for you:
> * efficiently support n-to-n communication. * be well-suited for both unicast and multicast messages. * guarantee a global message order. * avoid any in-kernel buffering and rather transfer data directly from a sender into the receiver's mappable queue (single-copy).
The downside of the alternatives that you mention is that they're not available as kernel features in Linux. Bus1 is inspired by that previous work and aims to make a new attempt at inclusion in the kernel, which they believe is required to provide the features they're targeting:
> A user-space implementation of bus1 (or even any bus-based IPC) was considered, but was found to have several seemingly unavoidable issues.
> o To guarantee reliable, global message ordering including multicasts, as well as to provide reliable capabilities, a bus-broker is required. In other words, the current linux syscall API is not sufficient to implement the design as described above in an efficient way without a dedicated, trusted, privileged process that manages the bus and routes messages between the peers. (...)
https://github.com/bus1/bus1/wiki/Message-ordering
But this paper makes a good quantitative case for POSIX not meeting the needs of modern computing: https://news.ycombinator.com/item?id=11652609
A good example is that Linux distros, Android, and OS X all have their own non-POSIX IPC mechanisms. Applications are somehow voting with their feet and not using Unix domain sockets and pipes.
It leaves me scratching my head because I don't think serialization is that hard a problem. But it seems that most people want IPC with structured data. Android is a bit of a special case because it's a single-language OS.
"Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."
Specially when the majority nowadays has the idea that GNU/Linux == UNIX and never tried to write an actual portable UNIX application.
In fact, Mac OS X is the most widely deployed UNIX-like system ever. What you're a claiming to be true probably more applies to Mac OS X than Linux.
I honestly haven't seen a recent package that was accidentally not portable in the long-term across the various modern UNIX-like systems because of confusion of Linux for POSIX.
I don't miss my days of writing portable POSIX code across DG/UX, Solaris, HP-UX, Aix, FreeBSD, Red-Hat, Debian and the respective #ifdefs.
You were asserting that the majority of programmers think Linux == UNIX and have never tried to write a portable application.
Thst is clearly false as the majority of programmers probably confuse Mac OS X for UNIX and most modern unix-like software is portable to at least Linux, Mac OS X, and FreeBSD. Portable is more general than "portable across every UNIX that has existed."
Increasing the specificity of your argument mid-way to avoid the incorrectness of your initial general argument isn't very genuine.
But yes, your revised second statement is probably correct: most UNIX programmers have never tried writing portable code across "DG/UX, Solaris, HP-UX, Aix, FreeBSD, Red-Hat, Debian" exactly because there is no practical reason for it.
It is a hard problem, at least if you want to achieve concision, make it parseable, and support schema upgrade.
> "Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."
And good riddance. File systems are almost universally terrible [1]. Threading with shared state is also a terrible idea because it's too general, not to mention the poor APIs used to manage them.
IPC is something that's still unfortunately undergoing constant revision, and the structured binary vs. text wars unfortunately both have merit. I think structured text output via a domain-specific language (DSL) is really the proper answer, somewhat like how a REPL works. This DSL is ultimately simple to construct within C since it would be lisp-like in its structure so it doesn't need an IDL compiler, although its textual syntaz shouldn't be lisp-like.
stdin can then nicely format DSL output for the user. Best of all worlds between text, binary, and structured formats.
[1] https://danluu.com/file-consistency/
Yes and no. There's significant utility to standardizing serialization in your IPC layer. IPC consists of exchanging domain-specific messages, so the message types can be specified in a header shared between endpoints, and data gets serialized in a standard format.
The IPC API then simply reduces to sending/receiving data to/from endpoints, like channels in CPS. And ideally it should be higher-order so you can send an endpoint to another endpoint.
So you don't need to standardize the serialization, but then you just get a plethora of incompatible formats.
https://lwn.net/Articles/551969/
http://www.qnx.com/news/pr_2471_1.html
And now I notice it was almost ten years ago! Nevertheless, too little too late...
You can't pass file descriptors over sockets. You can't do RPC over pipes. Anonymous sockets can only be shared with children. Named sockets require write permission and a filesystem. SysV is prone to resource leaks.
Binder has authentication, shared memory, reference counting, weak references, dead object notifications.
The descriptors and authentication part is key, as it allows Android's trusted system_server to open a device or socket for an untrusted process such as an App if it has user permissions. The receiver of a binder request can check the requester's PID/GID and with confidence from the kernel.
Most importantly, I don't think it's healthy to think of POSIX as being done. Some experimentation and discovery of better APIs and better systems should be encouraged.
gah, I'm driving myself crazy; I swear I saw somewhere a diagram of the Taxonomy of Unix IPC Mechanisms, with most of them crossed out and replaced simply with binder, please help me find it!
Good that my code doesn't know this. It would stop working.
> The descriptors and authentication part is key, [...]
If by "authentication" you mean "checking PID/UID/GID", we already have both in unix sockets.
If you mean "I send some bytes that describes the file to open, and keep my processes in sync manually", of course you can do that, but true passing would allow a number of cool things.
You can:
http://man7.org/tlpi/code/online/dist/sockets/scm_rights_sen...
I've seen that done several times, with defined request and response message formats.
Ergo, POSIX wasn't the end.
AF_INET sockets don't do FD passing or credentials.
There was a patch to add an AF_BUS socket family some years ago that sounded like a pretty general solution but the network maintainer said "over my dead body".
http://lwn.net/Articles/504970/
If you find this content useful, and you aren't already a LWN subscriber, you should consider becoming one!
More info is here: https://lwn.net/op/FAQ.lwn#subs
Subscription prices are here: https://lwn.net/subscribe/Info
[1] https://lwn.net/Articles/504970/
http://tipc.sourceforge.net/tipc_linux.shtml
Just a quick list of features, from Wikipedia:
what a bunch of jokers :)
The illumos kernel has been stable for decades now. Teams of five people here, three people there, four people over there, they roll up their sleeves, look at the issues the customers have had and are actually having now, professional engineers with formal education and insight, and in two years they have a working product which only needs a small fix here or there, and is tenable decades into the future. It goes to show that the number of programmers does not a quality, working product make.
For example: it's 2016, and my Linux filesystems in Vertica suddenly go into read-only mode, nobody knows why yet. In 2016! I cannot believe I just typed that, but it's true.
I've been running ZFS since 2006 both professionally and privately on Solaris and SmartOS at several large companies and I have never seen it go into read-only mode. The team which designed ZFS was only five people, not an army.
Bryan Cantrill summed it up so profoundly when, upon showing SmartOS running Linux applications, he ran /native/bin/dtrace and proclaimed:
I have clean water!!!
And while all that is constantly changing, its still possible to compile very old user space software and run it in on a current kernel.
On SunOS, I can install a driver built on SunOS 5.5.1 (Solaris 2.5.1) on the latest illumos or Solaris-based OS, without recompilation, thanks to the device driver interface / device driver kit ("DDI / DDK"). Solaris 2.5.1 came out in 1993; illumos came out, well, today (multiple commits every day).
Is the same possible on GNU/Linux?
I'm sure we could have something cleaner with a single, coherent team. But we also would have something that'd be useful to far fewer people.
Linux wins not by being best at everything. It has plenty of ugly warts. It wins by being accessible ranging from e.g. my ability to just take a job 20 years ago to port it to a custom x86 board with no bios or hard drive, because everything I needed was easily available, to the ability to hire any of a "an army" of past or current kernel developers to help solve my problems or do my custom development, to the ability for people to just write "yet another filesystem" and have actual real people try to use it and give feedback and contribute code.
The most important part of the success and value of Linux is that community. Without the community, it'd have little to offer over any number of other kernels that are better in some areas, worse in others.
But with it, it stands head and shoulder above all kinds of technically very impressive solutions because I can do things with and to Linux that I can't do, or can't do cheaply enough or in short enough time, with alternatives (and yes, that can be because of lack of knowledge of alternatives, but that too is part of the community/network effect).
Don't underestimate the importance of people.
> The team which designed ZFS was only five people, not an army.
And that's great. But the whole ZFS saga is also an illustration of how licensing early on can hamper adoption (KDE vs Gnome is another good illustration of how important license is; and how lasting the effect can be even after the licensing issues are sorted)
Aha, you mean like redhat and IBM did, where there are now "kernel developers" who can't find their way out of a wet paper bag, and spend more time arguing with paying customers back-and-forth in redhat's bug system, because they don't have a clue where the problem is? When you have some spare time, please do peruse https://bugzilla.redhat.com/index.cgi, in order to have a look at what your presumption looks like in the real world...
to the ability for people to just write "yet another filesystem"
...Because we need more beta filesystems instead of not having to worry about data integrity, right? And because it's just too much fun to be solving the same problem over and over and over again, but never quite get it right? So that for example, on Linux, we can have things like these:
...which ext3, which was on this Veritas disk group, wasn't able to recover, let alone detect. In the 21st century. Because community. I last saw a problem like this on Solaris ten years ago, since it has been a solved problem since 2006 there. Bryan is correct, I do have clean water, and even modern medical care facilities!The most important part of the success and value of Linux is that community. Without the community, it'd have little to offer over any number of other kernels that are better in some areas, worse in others.
The two of us (both with several decades of UNIX system administration experience under our belt) just wasted one hour trying to get a simple NFS share to work on RHEL 6.5, and it still doesn't work, with mount(2) returning "incorrect mount option" without saying which; and that was with us carefully following both redhat's official documentation and many examples on the InterNet.
Because, you know, man. Like, Linux! And stuff.
I have zero interest in how much of a community Linux has (99.99% of them are former Microsoft(R) Windows(R) users, with the corresponding mentality to match).
When I use a computer, I use it to get work done. All I wanted to do in the aforementioned NFS fiasco is to test my code, so I could get work done.
On Solaris / illumos, all I do is
and then I access that on any client, without even worrying about mounting it, like so: without caring if it's NFS 2, NFS 3, or NFS 4 (like I have to on Linux, whose implementation of NFS is so dumb that it actually offloads that on to the system administrator to worry about)[1][2].I could have had my tests long done and the code deployed by now. I could have had work done if it weren't for that same community not having a freaking clue how to make things JustWork(SM), and if it weren't for the
"because, like, you know, man. Linux!"
[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
[2] Nursie ↗ You exhibit a weird mixture of snobbery and incompetence. How odd. Annatar ↗ Ah, my apologies for that: I did not realize that shoddy NFS software is due to my incompetence. I also apologize that I wasn't able to get something which kind-of worked in RHEL 5 to work in RHEL 6.5 because things which are completely unnecessary on UNIX (like worrying about separate portmapper service) and which were in userland are now suddenly in the kernel. But only for NFS 4. Because the documentation is actually unclear on whether that's the case for NFS 2 and 3. And because the NFS protocol specifies that client and the server should auto-negotiate which version they will use. Because of course the community can't figure out where what should be, so flux. Again. cyphar ↗ I've decided to stop interacting with Annatar, it's not worth the rage. Especially when he starts misrepresenting GNU/Linux technology that you are deeply into the development of (runC and containers in my case). Annatar ↗ Part of engineering a good solution is being able to recognize when you are in knee deep, and that it's not the best solution, and ditch it. That's what turns a good engineer into a great one, because then she or he turns around and builds the solution. You might not believe the grandpa here, but you're in knee deep, if not deeper. vidarh ↗ > Aha, you mean like redhat and IBM did, where there are now "kernel developers" who can't find their way out of a wet paper bag,
I guess it's really snobby of me to except things which work on UNIX according to specification to behave the same way on Linux. Because Linux is cool. And it's great. And it has the biggest, bestest community. And because I don't appreciate just how great that is, instead being focused on getting work done with computers.
Now let's rehash inter-process communication again. Because it's fun rehashing things which work in other operating systems, over and over and over in Linux. Because Linux is cool like that.
On a personal note, I'm happy that you've stopped interacting with me. Good luck.
No, I mean like I can find any number of actual maintainers with a known track record and make them an offer to pay to have work done. Been there. Done that. Got good results.
> in order to have a look at what your presumption looks like in the real world...
It's not a presumption. It's actual experience in finding people to do work.
> ...Because we need more beta filesystems
Not everything is about need. While I work full time with Linux, a lot of what I use my computer for is fun, experimentation, learning. So yes: We need more beta filesystems. It's great that people experiment and learn. Everyone should try their hand at kernel changes, to learn - it's not magic.
> ...which ext3, which was on this Veritas disk group, wasn't able to recover, let alone detect. In the 21st century. Because community. I last saw a problem like this on Solaris ten years ago, since it has been a solved problem since 2006 there. Bryan is correct, I do have clean water, and even modern medical care facilities!
So use Solaris then, if you have so many problems with Linux. We're not forcing you to use Linux. It's not a dictatorship. I'll happily admit to all kinds of warts in Linux - I explicitly made the point that Linux has plenty.
> I have zero interest in how much of a community Linux has
Good for you. Meanwhile, for me, the community makes all the difference in making sure that I, e.g., has a decent sized hiring pool at all levels when I need developers, or which means that pretty much no matter what I try to do, there are people who have done it before I can ask questions of.
To me, that matters far more than avoiding a few warts.
This warrants a reply of its own, since it is the core idea of my essays: it is the very difference between a stable, working, reliable product and Linux: the people. The right people. Competent people. People with the neccessary education, experience, and insight.
If if ever need heart surgery, I guarantee you that I won't go to the local shaman, no matter how happy he will be to perform the operation voluntarily and for free. Same goes for the local exorcist. If I ever need one, I'll get my surgery done by a specialist in cardiology, because they have been formally educated, formally trained, and have the requisite experience to operate on a human heart. And in the case of illumos / SmartOS, they will even do it gratis, like "medical doctors without borders" organization does. Right people for the job. For some reason, people here and at large believe that when it comes to inter-process communication, NFS, or writing operating system kernels anyone can do it.
Why exactly people believe that computer science is different from surgery, I haven't discovered yet, but based on empirical evidence of Linux and other crappy software, I have a hypothesis, and since the sample size is large, I might have a theory soon...
Which is why I wrote what I did.
Your reply manages to turn it entirely on its head.
People believe computer science is different from surgery because it is: Nobody dies when my half-assed experiments with OpenGL crashes. Nobody dies if my laptop crashes.
There are certainly niches where it is life and death. Let others take care of that - I don't want anything to do with it.
And it shows. However, just because you can get something to work, in some way, does not suddenly make you (or anyone else) a professional. Case in point:
http://meta.serverfault.com/questions/6229/frustration-when-...
...Nor does it make your playful experiment fit for production where people like me are trying to get work done.
"I got something to work. Because Linux! Because community! Um... I think I'll go get a job as a computer professional now. What could possibly go wrong? Linux is so awesome!"
People believe computer science is different from surgery because it is: Nobody dies when my half-assed experiments with OpenGL crashes. Nobody dies if my laptop crashes.
An operating system's kernel is an extremely complex, special piece of software. A bug in such software can cause many people to die, which is why someday you might see disclaimers about running a nuclear facility and fitness of purpose. (Interprocess communication, the original topic, is part of an operating system's kernel.) Writing and diagnosing such software requires very deep insights, which very few have, even among computer professionals. Additionally, it absolutely and without fail requires formal education in the problem domain, it requires experience, and it requires apprenticeship, and I'm writing about physical one on one mentorship. It's not something one can pick up "from the community", never has been, and never will be, and if anybody tells you any different, they're either dangerously ignorant, or lying to you for the purpose of their own agenda.
Experimenting is all good and well, but when the entire armies of you start deploying your experiments in production and it becomes a trend and then the rest of us are, in fact, forced to take on such jobs because there aren't better ones, then it becomes a systemic problem. Not to mention that armies of you are currently in the process of artificially driving salaries down and it will be years before the market self-corrects, so make that a double whammy.
Now, me, I don't so much mind that cheap Linux labor is artificially driving salaries down, since cream always rises to the top, as they say, but I do so very much mind being forced by contract to work with things like ext3, which is based on concepts from the past century and which have since been long abandoned elsewhere, or that my really cool super slick database becomes unstable because of your experiment ticking underneath it (and before you ask, if it were up to me, I'd never put my database on your experiment). I mind even more when your (plural) experiements end up causing a priority 1 incident in the wee hours in the morning, when I'm busy getting my beauty sleep. In my case, you see, it's "because client contract!" Slightly different slant on things than in your case. Welcome to the industry.
The guys didn't have to get out of Oracle to reinvent the wheel: the engineering they did is sound and tenable enough for decades into the future, so they built upon it.
OTOH, some of the above you mentioned isn't bad. Linux's "just a kernel" philosophy can be useful, and allows people to experiment with new inits (s6, runit, &c) and new systems that come in handy.
And go see Brendan Gregg's talk on Linux tracers. It's not as simple is dtrace, given the tracing war hasn't been won, but it's at a place where you CAN do most of the things dtrace does.
Yes I am, because I picked a highly reliable, stable substrate to build my own private infrastructure on.
As for using Linux, I'm not dropping Linux until LX-branded zones can run Steam, and my game library. And I don't see that happening for a while yet.
It may not be ideal for infrastucture, but if you want a UNIX on your desk, for all its flaws, Linux is pretty hard to beat.
I chuckled when I read that, and I want you to know that I appreciated it.
but if you want a UNIX on your desk, for all its flaws, Linux is pretty hard to beat.
I have Mac OS X for UNIX on the desktop. Works like a charm, and never gets in the way of what I'm trying to do.
Have you looked at alternatives to GNU/Linux, like PC-BSD or FreeBSD? Did you find those inadequate / too much overhead?
I agree, that makes perfect sense.
and in any case I doubt they're good enough to get the games talking to my GPU properly.
Now that's a whole different story: NVIDIA provides Solaris-native packages for their drivers, and they JustWork(SM). Way back in the day, NVIDIA engineers were stunned that they didn't have to produce a completely recompiled driver for every Solaris release: thanks to device driver interfaces/driver development kit[1], one could develop the driver on an ancient version of Solaris and have it work flawlessly on the latest-and-greatest one.
When I wrote that I'm using Mac OS X, that was the truth, but it wasn't the entire truth: I am typing this on my intel-based workstation I put together myself, with Solaris 10 running on it. And it has an NVIDIA GTX 980 accelerator, the top of the line model one could buy at the end of 2014. Downloaded the driver from NVIDIA's site, installed it with pkgadd(1M), and it JustWorks(SM)[2]:
However, all of that is not to say you could play games on Solaris. If they were really optimized for Solaris, then they would fly, as Solaris is really, really, really fast, especially on intel. But since they aren't, and that's not realistic right now (and might never be realistic), I completely understand where you're coming from.As for Mac, OS X has plenty of major and indie titles in the Apple app store. But, it's for people who are actually willing to pay for that.
[1] http://docs.oracle.com/cd/E19253-01/816-4854/
[2] http://www.geforce.com/drivers/results/105347
And now, because you didn't ask for it, Game Reccomendations:
Have you tried out TIS-100? You can get it through Steam, and maybe a few other places, it runs on Mac, and I'm willing to bet it'll run in an LX-brand. It bills itself as "the assembly language puzzler nobody asked for," and has a focus on minimal instruction count, maximum speed, and paralellism. You should know by this point if you're interested.
You also may want to check out Xonotic, which is an arena FPS with a relatively lively community, which may compile on Solaris. Think a mixture of Quake and UT.
Apropos Qt, it is not for the faint of heart: even on platforms it officially supports, it is very hard to build, at least it was last I had to do it professionally, back in 2013. Qt is really unprofessional as a product, I remember it involved a lot of hacking and coercion of the build engine to get it to build. And it's monstrously large.
Post scriptum:
ah, "Xonotic" is a fork of "Nexuiz". Okay, that's clear now. "TIS-100" is a puzzle game. So these are individual titles, not technology which enables running on a different operating system. "The Ur-Quan Masters" used to build and run superbly on Solaris; it showcased just how good of a gaming platform Solaris could be if the code is good and clean.
lx-brand could be made to work, this screenshot shows it's possible:
https://www.perkin.org.uk/posts/whats-new-in-pkgsrc-2013Q2.h...
I haven't researched how to translate that into the lx-branded zone though (what the package equivalents would be), primarily because I viewed even the above as too much work: for example, the desktop would have to be brought over to somewhere with an X server. I don't see how it could be made to start on the bare metal's display when it's running in one of the hypervisor's zones?
Xonotic should run on Solaris. DarkPlaces, the engine codebase, is fairly portable last I checked.
TIS-100 runs atop Mono, but it's probably not using GPU heavily, so it'll probably run in an LX brand if you can get X up and running. As for running X11 on LX, the answer is both simple in its phrasing and hellish in its implications: X Forwarding.
I kid. Although it does seem like X forwarding is the easiest option. Luckily, you're not forwarding over the net, so you should be fine.
But yeah, it's nice to have a simple discussion about running video games in ways not intended, and what games are good, after spending a while explaining why systemd is a bad idea for the 15th time, because some people are still taken in by the sparkly unit files, and aren't paying attention to the beast lurking below the surface. (If such people are reading this thread, I'll give you a hint: Separation of concerns is a good thing, and if the process will panic the kernel if it crashes, I want it doing the job it's required to do. AND NOTHING ELSE.)
It might be better, but you can't strike out network effects. Because then you just end up with another rant why your thing is superior to that other thing everyone is using.
I am wondering if good old things are not just predestined to be unpopular. Probably only new things can get popular (even if they are just miserable copies of great old ideas). Next generation is more inclined to pick up something from the news than from history books. Next generation has their new lingo, so they will not understand easily old lingo. Next generation is cheaper to employ than older generation, so it's easier to get more in terms of quantity. Most (young?) people want everything, even if mediocre, now, than having few perfect things now, few perfect things later. The world belongs to the youth.
Have these people lost their effing minds? Do they think we don't care about compatability? Just because Lennart said "screw POSIX" doesn't mean you should do it.
So perhaps the real solution is to provide some kind of mechanism for userspace processes that act like kernel drivers, in that they are definitely running all the time, but actually run in userspace.
The reason this is in the kernel is that DBus is slow (according to Linus, because it could have been written better by monkeys with typewriters), and Lennart wanted it in the kernel/systemd, and Greg KH agreed, and Linus trusts Greg.
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...
Unless the application is a HPC parallel computation that is IPC bound, Bus1 has no performance justification. If the main justification for a modern kernel IPC mechanism is performance, I'd much much much more trust a proposal coming out of the HPC community than the desktop experience community.
So now you have two ends of the spectrum where this effort does matter, performance wise.
This only leaves the middle (desktop), but there are other reasons why that evil desktop crowd wants IPC in kernel, however high on a ‘priority list’ they might be.
You have wifi, screen brightness, CPU-hungry background apps, etc. to fix first.
It’s not about tight loops.
Also this idea that you have to fix wifi chip or screen before you can add anything to the kernel doesn’t seem to be founded in any kind of logic.
For priority inversion it seems dbus-daemon is at fault here, not user-space message routing in general. It's just as easy to have two message routing processes, one for low priority messages and one for high priority messages.
As far as 4 context switches versus 2 with regards to latency. A context switch takes microseconds... This is vastly smaller than the 250ms UI response time.
Again, this looks like a solution looking for a problem.
Fixing wifi or screen before working on micro-problems in the kernel for the sake of global power efficiency is founded in every kind of logic. It's literally Amdahl's Law: reducing power usage in a component that already has the most minimal power usage is a waste of effort for no noticeable effect. The cost-benefit ratio is indefensible. This is insanity.
Linux is lacking a coherent IPC system and the necessary primitives to build one. That’s the bottom line.
Please, I can argue down any allegedly rationale for creating Bus1. Try me. You have yet to put forth any convincing argument.
The real bottom line is Linux already has a coherent IPC system but third parties don't like it and are irrationally fixated with an in-kernel solution that reflects their grand idea of what a coherent IPC system should look like. It's childish, it's bad engineering, and it's a waste of effort.
* for priority inheritance, have multiple daemons for each message priority level. Only privileges processes can use the high-priority message router, but can optionally use the low-priority message router when they want to inherit the priority of their sender.
* like I said, context switching is irrelevant since context switching is not the bottleneck in event latency nor in power usage.
* if FD accounting is important, move it out of the broker and make it p2p with broker coordination.
* kernel and LSM hooking feels like a feature looking for a use-case. If anyone really wants to do that, I'm sure the specific use case can be accommodated. Not every user space program need be trackable via LSM.
* for side channel and message ordering, why is this a core feature of the transport layer? I don't think all applications need this and if they do, something simpler and more specific to the application protocol could be developed. Generalized message ordering guarantees as part of the transport layer seems like it violates end-to-end design. A robust application protocol will end up ensuring this on its own anyway.
There you have it. I'm sorry but you don't have a strong case. Linus is even more opposed to this than I am and is probably better about system design than I am as well.
Obviously, if you do not care about any of the features, then you should not be using bus1. But that does not mean that others don't care, so why are you objecting so strongly to us providing a solution to these problems?
Firstly, if you don't want a bus IPC with multicast messaging, then use something else. But if you DO want that, then you cannot ignore message ordering, that is the whole point (otherwise you could just use repeated unicast instead).
If you want message ordering you cannot split things into several daemons, or you break the order (unless you add some more communication on top). Same with p2p (side-channel) communication for FDs.
The broker is basically doing work on behalf of the sender, but without proper time-slice accounting it is not accounted accordingly. Obviously in many cases that does not matter, but you cannot simply ignore the problem if you want a general, lasting solution.
It is true that performance is not the main feature, but that is not to say that it does not matter at all (to anyone, ever), so you cannot simply brush it aside, proposing a solution that would have (almost by definition) hundreds of percent worse performance (as you are just doing more round-trips, even ignoring the context switching). To say that IPC latency is "not the bottle neck" only makes sense if you have a specific use-case in mind. With sufficiently low latency, we open up the possibility of using IPC for things that could only be done in-process today. This is not the MAIN purpose, but ignoring it is short-sighted.
I just got an email today from people asking about the LSM hooks, so there certainly is interest, and this (like the message order) is not something you can bolt on top.
I have not seen Linus comment on this, please give a link if you have. Whatever reservations he had about kdbus should not apply to bus1.
Look, there are plenty of things that could be improved on bus1, and I'm sure some careful review will find things we could and should do differently, but please at least spend more than five seconds looking into what we did and thinking about the problem. We want a multicast IPC system, but we want one done properly. You cannot simply say that doing one that is several times slower, doesn't do proper resource accounting, gets the message order wrong and cannot integrate with LSM is "good enough for me" and expect that to be the end of it.
Multicast messaging as your main motivation for a message ordering layer when that layer has drastic effects on performance and operational characteristics is a strange proposition. I'm willing to argue that 99% of application protocols will have no use for baked-in multicast as you've implemented it. What exactly is the killer use case for multicast messaging with side-channel aware causal message ordering? What prevents an application that cares about this from ordering incoming messages according to a lamport clock itself?
I see no downside to these features in general, it's just that the justification for putting it in the kernel is weak. Kernel code has an infinitely high maintenance cost and it's not clear bus1 is the end-all messaging layer you want it to be. There are lots of past failed examples, inotify, dnotify, and fanotify come to mind...
Finally, He said what we're all thinking!
> o scale with the number of CPUs available [...]
It seems to me that these two goals are conflicting. If they give up the first goal then suddenly the need of a broker disappear.
edit: quoting from the message linked by parent.
edit2: by reading the description of the ordering guarantees, it seems that they actually only guarantee partial ordering.
There is no partial ordering between proc1->proc2 and proc3->proc4 as the memory channels are invisible to bus1, but Proc2 and proc4 can detect the total ordering violation by using another counter in shared memory.
The last is something you need kernel help to enforce.
Most programs are dealing with vastly slower bottlenecks. Like network or disk latency. IPC latency is so far down the list of priorities in terms of things to optimize.
Not to mention that regular user-kernel-user buffer copying is plenty fast now, especially since the buffers will likely be cache-resident. Zero-copy is mostly hype without performance numbers to back it up. Don't need this complex message sealing mechanism.
As to portability, this is a linux kernel module, but there is nothing really inherent to linux about it, so porting it to another kernel should not be a lot of work if that is interesting to anyone.
As for systemd, I gathered there was a connection to kdbus, which was Lennart's baby. Thusly, I gathered it needed init to cooperate, the same way kdbus did, and any non-bus1-aware init just wouldn't work with apps that used bus1.
As for portability, what other OS will implement this muck? None of them. It's portable the same way systemd is: "apps that depend on us are portable, so long as every os copies all our stuff, and re-implements all our APIs"
Forcing other OS's to implement your stuff isn't portability.
But if bus1 is a successor to kdbus, it's not intended to be used by low-level userland, it's built for highlevel userspace. Like systemd, this is trying to coax high-level userland to be incompatible with other unixes.
The fact that no unixes other than the originating one, if the orginator was a unix, has picked up any of these systems speaks volumes about why you shouldn't use it in highlevel userland.
You 'gather' a lot about how this works, please look at the code/docs before writing things. 'kdbus' was Lennart's baby? Look at who wrote the code, who submitted it upstream, etc.
bus1 needs init's cooperation in the same way UDS does. It is simply a nonsensical statement, bus1 is simply a transport, what apps do on top is a different topic.
When I said that bus1 should be reasonably portable, I meant exactly that: the code of bus1 itself should be easy to port to other OSs. Whether apps that use bus1 are easy to port to systems without bus1 depends on how what they do and what is available on the other systems in question...
The fact that Bus1 doesn't need init cooperation is good.
However, Bus1 is MUCH higher level than UDS. UDS is a two-way bytestream between two processes. Bus1 as much more complicated system, designed to send structured binary messages, and includes a permissions system, sealing, and a lot of other complexity. It doesn't belong in the Kernel any more than DBUS.
As for kdbus not being Lennart's baby, and that I should look at who wrote the code, I did. I direct you to https://lwn.net/Articles/580194/, where Lennart not only takes credit for KDBus, but also says it's application-level, implying it is intended to be used in high-level userland.
High-level abstractions for applications don't belong in the kernel.
There is no sealing in bus1.
The payload of a bus1 message is exactly the same as the payload of a UDS message: unstructured binary data. bus1 is (like UDS) just a transport, it would be up to the consumer to add structured payload if they wish.
kdbus is higher level than bus1, don't confuse the two. kdbus is still not at the application level though, there would have to be a userspace component inbetween.
High-level abstractions for applications don't belong in the kernel, I agree. But that is a strawman, bus1 is not doing that at all.
The whole point of capability based security is that there is no permission system, because permissions are implicit in the capabilities. So this is much simpler than e.g. SysV message queues.