Earlier quoted context omitted.
> Flux. 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.
Well yeah, most of the libc API is older than Linux.
Bus1: a new Linux interprocess communication proposal
41–50 of 139 posts
Re: Bus1: a new Linux interprocess communication proposal
#42Earlier quoted context omitted.
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…
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…
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
"because, like, you know, man. Linux!"
[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
Re: Bus1: a new Linux interprocess communication proposal
#43Can someone please explain what's wrong with the classical UNIX sockets and pipes that they need to invent and (re)invent dbus, bonobo, now bus1?
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…
I've seen that done several times, with defined request and response message formats.
Re: Bus1: a new Linux interprocess communication proposal
#44Earlier quoted context omitted.
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…
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 so…
Re: Bus1: a new Linux interprocess communication proposal
#45Have 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.
Re: Bus1: a new Linux interprocess communication proposal
#46Earlier quoted context omitted.
Another alternative i have seen aired it to use TIPC. A protocol that has been in the kernel since 2.6. http://tipc.sourceforge.net/tipc_linux.shtml
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
Re: Bus1: a new Linux interprocess communication proposal
#47"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". what a bunch of jokers :)
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…
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.
Re: Bus1: a new Linux interprocess communication proposal
#48No. 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…
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.
Re: Bus1: a new Linux interprocess communication proposal
#49"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". what a bunch of jokers :)
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…
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.
Re: Bus1: a new Linux interprocess communication proposal
#50No. 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…
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…
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.