71–80 of 139 posts
Can 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?
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(?!). https://lwn.net/Articles/551969/
Earlier quoted context omitted.
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.
You can now start a zone that's compatible with 64-bit Linux, or one that runs a "hardware" hypervisor, or mix and match the two. That sort of thing?
Earlier quoted context omitted.
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.
There are more UNIX flavours than those ones.
Can 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?
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(?!). https://lwn.net/Articles/551969/
Earlier quoted context omitted.
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, b…
Well, you're feeling nice and smug, as usual. 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.
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…
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.
Earlier quoted context omitted.
Well, you're feeling nice and smug, as usual. Yes I am, because I picked a highly reliable, stable substrate to build my own private infrastructure on.
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, L…
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.
Earlier quoted context omitted.
I'm very sympathetic to that point of view -- UNIX is a paradox where everybody uses it but most people don't really know how to use it. 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…
> 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…
Earlier quoted context omitted.
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: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...
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…
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.
Earlier quoted context omitted.
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…
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.
You have wifi, screen brightness, CPU-hungry background apps, etc. to fix first.