Re: [gentoo-user] udev + /usr

["Canek Peláez Valdés" <caneko@gmail.com>]

On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld <joost@antarean.org> wrote:
> [[snippage]]
>>> I still think Gnome (or any other desktop environment) should not care about
>>> which init-system is being used.
>>
>> And they will not. They will only use some capabilities that a system
>> provides, and use it if available. It's the exact same thing as udev.
>>
>
> [[snippage]]
>
>> a) dbus is not part of the GUI, b) like it or not, it's the
>> standardized IPC mechanism in Linux. If it's available, let's use it.
>
> This is exactly the same attitude of convenience that led to udev
> being abused, and then to the very decisions by udev's maintainer that
> started off the firestorm on this list over the last couple weeks. The
> system is *bloating* at an incredible rate.
>
>>
>>> There are already well-tested and working mechanisms for communication where
>>> needed.
>>
>> I would like for you to be more specific about them.
>
> Sockets, be they UNIX domain sockets, IPv4 or IPv6.
[snip]
> Shared memory:
[snip]
> Pipes:
[snip]

Yeah, but then you need to design, implement and debug a protocol
communication: what part of the wire speaks first, what does it says,
what are the valid responses, etc.

And then, if other component wants to communicate, it has to learn
your little protocol. dbus standardize this. And it uses sockets,
shared memory and pipes as building blocks, I believe,

> Not sure what others there are, but those have existed longer than
> I've been alive, and been standard since the early 1990s.

They are standard in the sense that they are a low level communication
standard API. An IPC is *way* more than that;  dbus is an IPC, because
then you have high level "objects" and "methods", no matter the
language of the two sides of the wire communicating, or even if the
objects live in the same computer or not.

BTW, there *was* an standard that did everything dbus does: ORB, the
Object Request Broker. They tried to use that as IPC years ago, but is
so damn complicated to implement right they decided to better
implement a new standard. The standard is dbus.

> Progress is
> adding new functionality, not reimplementing existing functionality as
> new APIs on top of the existing functionality.

I think you are wrong if you believe that dbus is just "existing
functionality as new APIs on top of the existing functionality". dbus
is a complete IPC system. Neither sockets, shared memory nor pipes are
an IPC, because they lack a well defined protocol. You *can* do the
same you do with dbus if you only use sockets/sharedmem/pipes, but
then you need to do it over and over and over again. Is like the
difference between assembler and C: you *can* do the same with both,
but that does not mean that is actually a good idea to only use
assembler.

> That's little better
> than busywork for people who could be building something actually new.

dbus offers new functionality, like I said.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México