On Friday 30 March 2012 13:12:19 Ludwig Nussel wrote:
Vincent Untz wrote:
Le vendredi 30 mars 2012, à 07:02 +0400, Ilya Chernykh a écrit :
There is a very much negative review of udisks2 http://igurublog.wordpress.com/2012/03/11/udisks2-another-loss-for-linux/ which claims that udisks2 is a Gnome-specific tool and will render many applications incompatible until rewritten.
If this is true I would very much oppose including udisks2 in openSUSE without a thorough preparation.
What do you think about this?
I didn't even bother to read the blog post because: - your summary of the post makes me feel it's just a rant, and I'm not
interested in rants
It is but you should read it nevertheless. And also the linked blog post that tells why udisks had to be rewritten. Sounds like it got rewritten just for the fun of trying out some new cool libs.
There are several reasons for switching from dbus-glib to GDbus. Most important, dbus-glib is deprecated, its original authors won't maintain it, and it is a security critical component. Second, DGbus offers several things which makes life easier for developers. The o.f.dbus.PropertiesChanged() signal and the ObjectManager come for free when using GDbus, whereas nobody is using these (or limits its use to the absolute necessary) with dbus-glib (nor with QtDBus, as it lacks support therefor). If you look at all the properties exported by udisks, all anounced via a single Changed() signal, you know why PropertiesChanged(...) is much saner. The typical use of Changed() 1. udisks emits Changed() 2. everyone interested calls GetAll() 3. udisks sends all properties to the receivers via unicast. On a typical desktop, there will be several receivers, most probably each instance of a filemanager plus at least a single automounting/device notifier daemon.
- we're not removing udisks, we're simply adding udisks2
- udisks2 and udisks are parallel-installable and can run at the same
time
Which is silly. A simple operation like requesting to mount a disk has to be considered a basic operating system service. It doesn't make sense to have several competing deamons implement that. It also doesn't make sense to change the function signature for that operation all the time. There needs to be a stable API for such a feature. GNOME is not the only user of the function. Think of it like a basic shared library, just implemented via DBus. It's probably fine if Mr. Z decides that the model he used in the backend is suboptimal and that he needs to rewrite everything in order for the disk partitioning front-end of GNOME to be even more prettier. The rewrite should keep the common API parts stable though. Shared library speak: adding new functions is fine, modifying or deleting existing ones is not.
Sorry, you seem to misunderstand udisks(2). It provides first a single point to get notifications about all disk related events, and second an interface to request disk related actions. If you request mounting via udisk1 and udisk2 at the same time, you are asking for trouble, but the same is true for two concurrent requests on udisks1 (which e.g. happens on multiseat with automounting). Neither udisk version is doing any mounting on its own behalve, so nothing to worry about. As you can see, running both versions side by side is fine, and only the needed instance will be started by DBus. Sticking with your library analogy, these are two major versions of the same, binary incompatible, functionaly similar. Install both, if you have to. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org