> Date: Tue, 03 Dec 2013 20:22:16 -0500
> From: Alan Feuerbacher <[email protected]>
> To: BLFS Support List <[email protected]>
> Subject: [blfs-support] Suggestions on Desktop Environment
>
> I'm not far from choosing a Desktop Environment, which BLFS gives you
> choices of KDE, XFCE, LXDE to install.
>
> I use Gnome at work, an old version that comes with Redhat 5, and I
> understand that new versions get mixed reviews in online forums. I have
> no opinion, having no experience except with what comes with my Fedora
> 19 host system.
>
> Why does BLFS not do Gnome? I see that Gnome depends on systemd which
> BLFS does not support. Can anyone give me a few clues about the issues?
>
> I've used KDE before, where I used to work, and I was quite happy with it.
>
> Any comments on the relative merits of the three that BLFS recommends?
> Beyond the brief introductions in the BLFS book?
>
> Alan
Hi Alan,
TLDR: *if* using a Desktop Environment ('DE'), then I'd _suggest_ XFCE for <=
medium-power machines, KDE for >~ medium-power machines, and GNOME for ... er,
I guess if you know/want GNOME.
A side-light on the matter:
----
It can be worth bearing in mind the view, "I run applications, not Desktop
Environments".
I've used KDE, GNOME, and XFCE quite extensively over the years, still
use/encounter them 'in passing' these days - mainly for addressing issues on
folks' machines, or in a VM - but don't use them as the main interface on any
of my own everyday machines.
Instead, I run twm, using its easy X-based customisation to get the interface
layout and behaviour that I want. (I essentially use a (background-)tiled
interface along thin top/left/lower/right borders (any part of which can be
overlaid partly/wholly by application windows - i.e. the icon 'tiles' don't
preclude other objects from the same area of screen real-estate). Oh, and
everything is still available via the usual menu - we didn't forcibly remove
the menu in favour of tiles-only ;) . NB that that outline is not by any
means the only type of approach available).
Part of the reasons for the switch away from DEs, was (and still is) that:
==
* wanted much more control and understanding of what was in the OS;
* DEs tend to be increasingly an OS-within-an-OS (or at least a
'world-within-a-world');
* wanted much more flexibility in the components and behaviour of the
interface;
* was finding oneself heading down the route of sort-of 'reverse-engineering'
DEs in order to try to modify and get them how we wanted them;
* KDE/GNOME at least are prone to lurches from one (half-assed) paradigm to
the next (half-assed) paradigm, all the while proclaiming or insinuating
that the promised land has been reached or is within sight (Real Soon Now
(TM)); 'oh and just forget all that previous- approach/version stuff now -
that was "deprecated-prophets" speaking'.
* Using such DEs often more-or-less force you 'hold your nose' while using
them, given some of the "technologies" that they 'require'.
* Likewise, building such DEs (sort-of) 'from scratch' as in BLFS, tends to
have quite a heavy dependency-chain, that can push you down avenues that you
might not want to go or stay in.
* increasingly, 'Learn ${DE}, and you learn ${DE}': whereas we wanted to dig
deeper into *nix per se.
* DEs can tend to be a bit of a 'golden cage' if you don't want your
time/effort/resources invested in them to be substantially wasted: but the
latter might happen anyhow, with the aforenoted - and seemingly increasingly
frequent and large - lurches.
==
Instead with twm/X, we just pick more-or-less exactly what we want to build,
and can easily not use stuff that we don't want to build: it can be as light
or as heavy a dep-chain as you want. The time/effort/resources invested in
using such a system are much less prone to being substantially wasted by
aforenoted lurches. It's fast- to very-fast, extremely 'clean' as a system,
very easy to understand and control, and easy to take forward to updated
versions.
Btw, this is not a luddite's manifesto - there's e.g. a lot of new
technologies that we do use (and a lot of new/old ideas, from within Linux
and elsewhere, that we'd quite happily see _developed_ - not shoved - into
Linux). Nor is it some deliberately minimalist approach. Also, yes, X itself
is changing and even may end up being partly-replaced. And so on and so forth.
A central point here is not to avoid change, but instead to control it easily,
while still retaining use of a powerful and comprehensive range of os
components and programs.
----
Hope that's of some use, albeit perhaps indirectly.
Regards,
Akhiezer
--
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
