Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bus1: a new Linux interprocess communication proposal

lwn.net

Post reply on HN
Print view View original

91–100 of 139 posts

Re: Bus1: a new Linux interprocess communication proposal

#91

Post by qwertyuiop924 »

Annatar wrote: post #77
qwertyuiop924 wrote: post #75

Earlier quoted context omitted.

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 think you just have a natural propensity for being smug. 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.

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.

Re: Bus1: a new Linux interprocess communication proposal

#92

Post by tomegun »

qwertyuiop924 wrote: post #45

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…

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.

Re: Bus1: a new Linux interprocess communication proposal

#93

Post by tomegun »

IshKebab wrote: post #48
qwertyuiop924 wrote: post #45

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 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…

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).

Re: Bus1: a new Linux interprocess communication proposal

#94

Post by pjmlp »

saynsedit wrote: post #87
pjmlp wrote: post #85

Earlier quoted context omitted.

The keyword being likely . 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.

This is still irrelevant. 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…

Other than sell software to enterprise customers.

Re: Bus1: a new Linux interprocess communication proposal

#95

Post by cgag »

saynsedit wrote: post #58
pjmlp wrote: post #31

Earlier quoted context omitted.

> UNIX is a paradox where everybody uses it but most people don't really know how to use it. Specially when the majority nowadays has the idea that GNU/Linux == UNIX and never tried to write an actual portable UNIX application.

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.

Have you used FreeBSD? Having played with Free/Open/DragonflyBSD, I came away shocked at how non-portable most software is.

Re: Bus1: a new Linux interprocess communication proposal

#96

Post by deno »

saynsedit wrote: post #86
deno wrote: post #82

Earlier quoted context omitted.

http://lwn.net/Articles/504984/ #Priority Inversion #Latency 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.

I don't buy these arguments... 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. Aga…

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.

Re: Bus1: a new Linux interprocess communication proposal

#97

Post by qwertyuiop924 »

tomegun wrote: post #92
qwertyuiop924 wrote: post #45

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…

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.

Re: Bus1: a new Linux interprocess communication proposal

#98

Post by saynsedit »

deno wrote: post #96
saynsedit wrote: post #86

Earlier quoted context omitted.

I don't buy these arguments... 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. Aga…

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.

Re: Bus1: a new Linux interprocess communication proposal

#99

Post by saynsedit »

pjmlp wrote: post #94
saynsedit wrote: post #87

Earlier quoted context omitted.

This is still irrelevant. 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…

Other than sell software to enterprise customers.

Sure, you're correct on that. Thanks for staying on topic.

Re: Bus1: a new Linux interprocess communication proposal

#100

Post by saynsedit »

cgag wrote: post #95
saynsedit wrote: post #58

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.

Have you used FreeBSD? Having played with Free/Open/DragonflyBSD, I came away shocked at how non-portable most software is.

Any examples? Even Debian packages include custom patches.
Post reply on HN