[arch-general] We have lost the desktop war. The reason? Windows 7.

hollunder at gmx.at hollunder at gmx.at
Mon Oct 26 18:10:11 EDT 2009


On Mon, 26 Oct 2009 22:39:54 +0100
Heiko Baums <lists at baums-on-web.de> wrote:

> Am Mon, 26 Oct 2009 19:58:49 +0100
> schrieb <hollunder at gmx.at>:
> 
> > > Unfortunately, fewer and fewer applications are "desktop-agnostic"
> > > these days. To install a gtk2 application I am usually asked to
> > > download half of GNOME or at least libgnomeui and gconf. Gconf is
> > > my personal favourite. Xfce already uses xfconf (btw I love its
> > > description in the repository:"xfconf.. thingie" -- looks like not
> > > only I am confused), why am I supposed to use two different
> > > configuration databases? Why can't people agree on one? Why not
> > > just save configuration in plain files, it has worked before...
> 
> > Well, I guess they try to 'integrate' again, all config in one
> > place, but again only for their bubble.
> 
> Isn't there already an OS with such a terrible, bloated and cryptical
> all config in one place database called registry?
> 
> And wasn't there a principle in Unix/Linux: "Everything is a file."?
> 
> Both were two of many reasons why I completely switched from Windows
> to Linux years ago.
> 
> I really don't understand why now also on Linux configs have to be
> saved in such gconf (still text files) or even worse sqlite databases,
> which make those software nearly unmaintainable and slow. Why not just
> stay with the good old text files which can simply be edited with a
> console text editor?

I think those centralised systems have some benefits over configuration
files spread over the whole system, but the way it is now it is neither.
You still have lots of programs that use config textfiles somewhere and
in addition multiple "centralised" configs for only a bunch of
applications.


> I, too, don't like those dbus, hal, console-kit stuff. I even don't
> like udev with its many, quite complicated udev rules. In the past I
> could simply create a device node for a device and it worked and I and
> the system knew how to access a specific hardware. I of course see
> that udev has some advantages but the way it is designed makes the
> system (the device naming) pretty inconsistent. I don't see the
> advantages of hal and console-kit - I even don't know what they are
> for. Usually hardware can easily accessed by the device files
> in /dev, infos about the hardware can be obtained by lspci and lsusb,
> through /proc etc.. What is console-kit for? I usually have a console
> and can login without such an additional daemon which in my opinion
> only takes system ressources. Not so good on slow computers and also
> not the best on fast computers.
> 
> But regarding the KDE/Gnome dependencies there are some applications
> which don't use these libraries and which are built against pure Qt or
> GTK. See e.g. the Xfce and LXDE applications. They are unfortunately
> not yet perfect but I have the impression that there will be more and
> more such software like Xfburn, Thunar, Mousepad etc. and that those
> developers are open-minded for feature requests. So I guess there's a
> little hope.
> 
> Heiko

I do use some xfce applications, namely thunar and terminal. And guess
what, thunar depends on hal, as well as exo (a library used in many
xfce applications) :(
Well, I'd survive it if I had to switch to something else, but this
would only win the battle, not the war.


More information about the arch-general mailing list