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.