[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 May 2012 17:18:47 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Vision for new platform
On Mon, May 21, 2012 at 10:05:52PM +0200, aep wrote:
> FDO is the way it is, it's a pile of shit, but it's the only
> organization that managed to combine a zillion lines of code to some
> sort of consistent thing.
> Even if the thing is utter crap and only targets a specific audience
> (not me), it's as consistent as you can get.
I meant to address this... actually, a failure in this area is what
motivated me to consider the topic of replacing it again. I guess I
could be misinterpreting what you mean by "consistent", but the FDO
junk is anything but stable and interoperable. Just last week I had to
fight with a Debian upgrade in my spare time for 3 days (getting
almost nothing actually useful done) because NetworkManager,
PolicyKit, and/or ConsoleKit totally broke support for non-GDM
sessions: it started refusing to treat my session as "local", and
ignoring the seemingly correct XML-hell-configuration file requesting
that my user always have access to the network configuration, and so
far the only way I've been able to fix it is to waste >5% of my memory
running GDM.
This isn't the first time this has happened. The FDO junk
*superfically* interoperates with other window managers, desktop
environments or non-environments, etc., but when it comes down to it,
in order for anything to work _right_, you need GNOME. Lots of GNOME.
One example I faced a few years back (eventually stuff got fixed at
some other level so it didn't matter so much) was that XFCE could
automount USB devices, but had no way to control the mount options.
Filenames were not translated to UTF-8 correctly, permissions were
wrong, and 8.3 filenames were treated as ALL CAPS rather than
lowercase (very annoying for using digital cameras that only generate
8.3; this bug still has not been fixed, and seems intentional). But
the core problem is that the configuration of desired mount options
was not at the system level. Instead, the system left the desktop
environment to choose the mount options, subject to policies set by
PolicyKit for what options are allowed. This placed an unnecessary
burden on the desktop environment/file manager to get things right and
provide the right configurability to the user; only GNOME got it
right, so in effect, only GNOME was fully usable with the system.
As far as I can tell, it's still that way, but the defaults are less
broken so I don't care as much (actually I hexedited one binary to fix
the uppercase/lowercase issue... :).
So I take exception to the claim that FDO is "consistent" or "stable".
In my view it's only remotely consistent in one configuration: using
GNOME for everything. And it's completely unstable, constantly
deprecating one way of doing things in place of another (remember HAL?
and now I'm told ConsoleKit is deprecated too...), wasting all the
manpower of all the non-GNOME desktop projects playing catchup to work
with the latest new API so the FDO/GNOME folks can stay on top of
everything.
That's why I think, to be viable and relevant, a replacement needs a
foundation that's not built on the FDO junk (which they can keep
pulling out from under our feet every time some HS/college CS student
gets excited over whatever buzzword IPC mechanism they learned in Java
class) but independently stable.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
