[blfs-support] Suggestions on Desktop Environment

akhiezer lfs65 at cruziero.com
Wed Dec 4 03:26:25 PST 2013

> Date: Tue, 03 Dec 2013 20:22:16 -0500
> From: Alan Feuerbacher <alanf00 at comcast.net>
> To: BLFS Support List <blfs-support at linuxfromscratch.org>
> 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 

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 
* wanted much more flexibility in the components and behaviour of the 
* 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 

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.




More information about the blfs-support mailing list