Re: 9p/plumber to replace D-Bus?
Le 08.12.2014 18:59, Marty a écrit :
On 12/08/2014 10:43 AM, email@example.com wrote:
Le 08.12.2014 14:18, Marty a Ã©critÂ :
I almost tagged this off-topic but it's directed toward ordinary
users (with developer backgrounds). I first raised this on
modular-debian but I want to get some ideas from a wider audience.
I'm starting to get familiar with Plan 9 and D-Bus, to compare how
try to solve the same set of problems.
Plan 9 concepts attempt to solve Unix problems in a very different
way than Opendesktop.org. For people wanting to return to the
Unix concepts, 9p/plumber (or an updated version) seems like a
fit going forward, for basic IPC purposes. 9p is already in Linux,
probably could be ported to the other Debian ports.
I realize I just have to convince millions of people to re-plumb
core OS in a short period of time, but recent history teaches us
that this is entirely feasible! Thus emboldened, I would even deign
to give users a choice in the matter, but realistically, this would
probably be an experimental project.
You won't convince anyone if you do not build a PoC. Especially
developers giving their time literally for free.
Asking questions is a nice way to learn how you could do that PoC,
anyway. Asking and trying.
If this proves feasible, that's what I hope to do. I just want to
if anyone thinks it's a good idea, before I commit time and
My knowledge of all of the issues is sketchy at best.
Oh. Then, I doubt it's useful since my opinion is that dbus is useless
(my opinion, which depends on my uses of my computers).
Because I do not see why my softwares should discuss between them
without asking me.
I am ok if I explicitly plug one in another, but I do not want my
computer to do things behind me: every time something tries to guess
what I'm doing, it fails (speaking about that, I should learn about how
to customize that stupid ACPI stuff to stop stopping my screen when I'm
watching videos). I did not stopped using DEs and IDEs for nothing
(slowdowns, crashes, losing time dragging mouse here and there to type
text in right place, etc)...
Now... well, my opinion is that if applications have to have an IPC to
discuss with another, then why not, but I think that the link should be
obvious and explicit.
For example, I think dconf is stupid: you change the configuration, for
example with a unified tool, and this affects many softwares. Why not.
But, dbus is not needed for that: OSes are already able to send signals
(that's how postgreSQL works to reload configuration for example).
That's how I think applications I use discuss with my window manager
(i3): they use signals, described not by linux, but by X11 protocol. It
works, it's lightweight, and it does not imply having a daemon for such
a trivial thing (few lines of C does the job I guess).
If you need communication on more specialized thing (go to next song,
send file by mail), you will anyway have to establish a real protocol,
that emitter can build, and receiver understand.
So, having a daemon for non-specialized IPCs seems weird for me. Nice,
you can send messages to the whole system. But, if no application minds
about or understand your message, is not it plain stupid? Plus, it's not
portable (anyone have seen dbus on windows? not sure, but I doubt it's
on *BSD, too) unlike sockets.
I think sockets are good enough, and not that hard to use. Open a file
descriptor, read, write, and close. If you need non-blocking accesses,
then you need 3 more lines of C, that you can move into a dedicated
I do not only think, I now have a proof about that: did not used
sockets since school (~8 years ago). Yesterday I wanted to at least
start a project (a text editor without UI at all, like mpd is a music
player without UI) and, in less than 4 hours, have built my own C++
socket class, and trivial client/server (they just send/receive, for
now. Just a start, still have the protocol to build.) which I can reuse
very easily for future uses.
I don't want to end up reinventing any wheels.
Forget what people says about reinventing the wheel.
It's good to so: it allows you to understand why wheels are built the
way they are. It's thanks to someone which explained how to reimplement
OOP features in C that I finally were able to understand my first uses
of the C++ keyword class (I do not say that it allowed me to understand
OOP concepts, only how, internally, a class works, which is a
prerequisite for me to learn more things. Writing clean code have no
link with using C, asm, or Java: it's about coding modules which
contains functions and not whole programs. ).
But, yes, it takes time.
Could an IPC bridge/shim mechanism connect to a new IPC model while
and DE's migrate from D-Bus, or support both optionally? I can see
updated version of Plumber might be needed, and things might be
simplified by other aspects of the Plan 9 paradigm, like
namespaces and treating everything as a file.
Multi-seat PC and other
anachronisms probably have to go away.
As Lisi asked, what about choice? How could you say that those are
Perl guys are used to say this: "there is more than one way to
it". This can be applied to so many things.
PC as time-sharing system was the anachronism that caused Bell Labs
scrap Unix, if I understand the history correctly. That's why I think
it's a broken model that not survive. For me the choice is the option
not to be tied to that broken model forever.
Well... this model is still very used in enterprises. I do not speak
about those old mainframes which are still bought by very huge
corporations (at least, I've heard so) but, what about everyone having
sessions on a distant computer to use a software? How was it called...
terminal server I think? Still used.
My point here is, that you can only know what *you* need, and I am not
sure that you really know what you need, because only this is very hard.
Knowing what other needs... I don't think many people are able to.
Usually, before writing a software, someone tries to make what the user
wants more clear. Hard enough, and never perfect.
I could also mention the fact that, when you have a physical server,
you will make it more useful if you run more than one server on it,
which is really about time sharing, if you consider the guests as users
(they use physical computer's time, right?).
So, I strongly disagree: nowadays, time sharing is still important,
because the more costly is energy, not hardware, and idle hardware is
energy waste. We could argue that it's what the cloud buzz word is
about, finally: selling time. Sharing time.
You just use a low-power device, and take the time of stronger
computers, somewhere else to do your tasks.
Now, if you think multi-user OSes are not that good, I think there is
an OS with a different kernel somewhere (not Linux, not *BSD, not Hurd,
not Windows, not ReactOS...) which wants to build a single user system.
Can't remember the name, I only remember that when someone on linuxfr
described it, I was really sceptical, because there will obviously be
tons of security issues with such a system.
About anachronism... you should read about what is the minitel*, and
then, consider thinking about how most people uses their computers
I started out designing terminals back in the stone age of computers,
so I would have hard time giving up ttys and serial ports. :)
Which I assume gave us minicom, right? Long live Minitel!
The reference about the minitel is simply that, it was a terminal
linked to French ancestors of what we currently could name... say...
facebook. Some people on French websites speaks about Minitel 2.0,
instead of Web 2.0. I really like this comparison. Full of irony, and
when you see people's choice, so true. But, it was their choice. If they
do not limit my own options, I absolutely don't care.
It was more a joke than something else anyway, to show that many people
does not really mind about having choice, because when they are given
some freedom (modern computers + whole internet allows people to acquire
more freedom, when they can access those, by acquiring knowledge. At
least, it's what I think.) they do not try to use it.
Freedom have a huge cost: you must be searching for alternatives, you
must build your own opinion, and when things are not how you would like
them to be, you have to build your way or improve what exists.
This is how I see freedom: a very costly thing (but, it have huge