Le 09/03/2019 à 21:48, Arnt Karlsen a écrit :
> On Sat, 9 Mar 2019 18:12:55 +0100, Didier wrote in message
> <42982bbd-6ccc-6ed4-2bcc-4d969319c5e6@???>:
>
>>     I find it comic that dbus, which is a middleware restricted to a
>> single host, builds a unique id to identify this host. We know that
>> the systemd team likes to catch up everything to control it from
>> their blob, even if it looks like pure crap. This makes me think the
>> intention is probably not surveillance, but lock-in because here is
>> the core of their busyness model.
>>
>>     They claim that this isn't UUID (Unix Unique ID). And they are
>> right even if it matches the acronym, because it is best named
>> Useless Unique ID.
> ..so, do we drop that Useless Unique ID scheme from our dbus,
> or do we drop dbus?
>
> ..and, do we help keep Useless Unique ID, Useless, e.g. with
> cron jobs?
>
>
    I'm balancing. I'm rather in favour of denoucing applications which
try to use the machine-id. But, while it's easy as long as they do it by
reading a file; it'll be impossible when they obtain it from libsystemd.
Hence the necessity to fool them with a random number.  Another method
could be to always invoke the suspect applications from inside a fresh
VM with a fresh random machine-ID.

    I disliked dbus even before people spoke of systemd and I'm afraid
dbus becomes some day the way to force systemd on us.  I'd like to drop
it right away, but my usual DE (xfce) uses it.

    But I'm modestly and slowly working to escape it: I'm writing a
little application to monitor hot-plug storage in a GUI, of course
without dbus, but also without libudev and/or gvfs. I'm almost done -
now trying to make sense out of a gtk2 tutorial. I also have a few ideas
to replace udev by a script, provided devtmpfs is enabled in the kernel.

    Didier