
Bus1: a new Linux interprocess communication proposal - b3h3moth
https://lwn.net/Articles/697191/
======
philips
Previous discussion:
[https://news.ycombinator.com/item?id=12309590](https://news.ycombinator.com/item?id=12309590)

~~~
b3h3moth
I'm sorry, I didn't see it before!

------
Aissen
Discussions from last week:
[https://news.ycombinator.com/item?id=12309590](https://news.ycombinator.com/item?id=12309590)

Not that there was anything constructive, since most people did not read the
article & ksummit email.

~~~
bryanlarsen
Anybody interested should read the comments and participate in the discussion
on the original post at LWN.

------
nullspace
I'm not a kernel engineer or an operating systems engineer so this may be a
naive question. This line was confusing to me:

> This is achieved using local clocks at each peer that are synchronized in a
> manner similar to that used for Lamport clocks.

From Linux's perspective, it's just running on one machine with one system /
module that determines the time of the machine right? Why do two peers need to
have their local logical clock?

From my understanding, clocks are a problem for distributed systems that can't
share a single clock without significant latency and loss of availability. Why
is this a problem for Linux as well?

------
api
Part of the reason OS IPC is stagnant is that it's not that interesting or
useful.

I feel like the folks making these and other (kdbus) proposals are still
thinking in terms of a "box." Boxes are dying. Almost everything interesting
these days is distributed across networks with boxes being mere commodity
hosts.

This is true in any modern data center or cloud infrastructure, and here it's
often done via things like Kubernetes plus a pub sub bus and a clustered
database.

It's also IMHO going to be true of any future next generation "decentralized"
personal computing platform. All the interesting work I see in that space also
takes the form of distributed systems that try to abstract away the box and
deliver a kind of formless global cloud where boundaries are cryptographic.

In both cases the box is dying because it is unreliable and doesn't scale.

The trouble with local IPC is that its APIs are not going to be the same as
network IPC. As a result programmers have to think about local vs remote to
make use of it. So they won't.

That leaves only the local system services use case, which is already served.

~~~
mmastrac
Are "boxes" really dying though? Android shipped 1 billion devices in 2014
[1]. That's a lot of market for a standardized bus with lots of processes on a
single box. I don't see that changing any time in the next five years, and
maybe beyond.

Linux is way too popular to not consider all the use cases. And "interesting"
is not a good yardstick for where effort should be spent.

[1] [http://www.cnet.com/news/android-shipments-
exceed-1-billion-...](http://www.cnet.com/news/android-shipments-
exceed-1-billion-for-first-time-in-2014/)

~~~
api
Today's mobile devices are mostly dumb terminals for the cloud. It's a
portable always on VT100 for the 21st century. Web sites and apps are like
giant VT macros. All the interesting stuff is elsewhere.

As they get more powerful I could see apps doing more interesting things
locally, but in doing this they will mostly be talking to distributed systems
over a network. (E.g. peer to peer net in apps.)

The last bastion of the box is PC, but that is also a mature and stagnant
platform whose use cases are mostly served by what is already there.

