Le 09/03/2019 à 21:48, Arnt Karlsen a écrit :
On Sat, 9 Mar 2019 18:12:55 +0100, Didier wrote in message
<[email protected]>:
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
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
