The loud complainers

Posted Nov 9, 2012 14:19 UTC (Fri) by oldtomas (guest, #72579)
In reply to: GNOME 3.8 to drop fallback mode by vonbrand
Parent article: GNOME 3.8 to drop fallback mode

I'm one of the (not-so) loud complainers during the 1 -> 2 transition.

I'm using FVWM now.

At that time I went for GNOME mainly for two reasons: QT licensing issues and the promise of less bloat. Ironically, the GNOME of today is even more bloated than KDE, which is quite a feat.

(This isn't intended as offense: I do realize that one person's bloat are the other person's features, and I wouldn't dare to force anyone not to use GNOME, as much as I woldn't like to be forced to use GNOME -- or dbus or whatever).

The feature creep (why has the desktop environment to take over the "mounting" of devices? That' the job of the OS, I thought?) downright scares me.

(I do agree on your other points).

to post comments

The loud complainers

Posted Nov 9, 2012 15:42 UTC (Fri) by dcbw (guest, #50562) [Link] (5 responses)

Not necessarily advocating for it, but mounting stuff isn't always as simple as mount(8). The gnome-mount manpage (which is actually obsolete and has been replaced with something else, but the use-cases are still relevant) reads:

"Mounting a file system into the root file system involves a certain degree of configuration and as such is subject to whatever preferences an user might have. gnome-mount allows the user to control the mount point location, the mount options and what file system to use for mounting a file system. The settings are read from the gconf database (which is per-user) and can also be overridden on the command line using the appropriate parameters."

If you accept that mounting a volume can (a) have user-specific preferences and (b) have specific permissions, then something has to talk to the user session to make those determinations. And a root process reading user settings usually runs afoul of security policy, hence the user-session mounting utilities.

The loud complainers

Posted Nov 9, 2012 22:10 UTC (Fri) by oldtomas (guest, #72579) [Link] (4 responses)

"[...] mounting stuff isn't always as simple as mount(8) [...]"

Most definitely, totally agree. But then, it's a problem to be fixed at the system level, and to try to provide a dektop-independent interface for desktop environments to hook-in -- instead of kludging it at the desktop level.

For one data point, I just finished "fixing" the Gnome metadata of one user: the emblems and comments disappeared just because this user's harddisk changed and the metadata are tucked away in some obscure database in the home directory... tied to the disk's UUID. Eek!

Look, I do understand that the desktop folks want to get things done, but this stacking up of leaky abstraction on top of leaky abstraction just scares me. I prefer to stay clear of that and to think of better alternatives -- if there are any. That's all.

The loud complainers

Posted Nov 9, 2012 22:41 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (3 responses)

There is a desktop-independent interface for desktop environments to hook into: udisks.

The loud complainers

Posted Nov 10, 2012 0:08 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

Yep! And coredump bugs in this software running as root have gone unfixed for years (I know, because I sent the patches, repeatedly: no response whatsoever, like throwing meringues into a black hole. Perhaps udisks2 has fixed it -- perhaps udisks2 was the reason coredump bugs in udisks1 were ignored -- but udisks2 was years from release when I first sent the first of these patches).

These days I don't even bother trying to report bugs in udisks. The maintainer just doesn't care.

Sorry, this is not good maintenance.

The loud complainers

Posted Nov 12, 2012 17:30 UTC (Mon) by zlynx (guest, #2285) [Link]

udisks and upower: these things appear to be very unloved. Someone must have written them and tossed them over the wall then forgotten they exist.

upower is a critical system daemon these days because Gnome won't suspend the laptop on lid close without it. But of course, any tiny difference in sysfs configuration and it dies. It either crashes or does a g_error log and exit. Now who thought doing abort in a power management daemon was a good idea?

This has caused me to have a drained laptop at least three times.

udisks

Posted Nov 11, 2012 15:33 UTC (Sun) by oldtomas (guest, #72579) [Link]

Thanks for the pointer. Unfortunately, it's dbus -- so not for me... (the general approach is in the rivht direction, though).