Rick Moen <rick@linuxmafia.com> wrote: [A good candidate for the "mailing list post of the year award", if there were one.]
I started to realise the magnitude of the problem when I encountered people installing DamnSmallLinux on P4 boxes with 512 MB or 1GB RAM because they seriously thought nothing more complex _could_ work. And why did they think this? They attempted to boot the live-CD image of (say) Ubuntu to run the graphical installer on top of that, it choked on the extreme RAM shortage, and they concluded that installation was impossible. Or the installer completed but then was 'slow' and they couldn't even start to figure out how to decide what to run and not run, because the very concept of doing so was alien.
There's another problem: consider a recent distribution of Linux with, for example, GNOME installed. It has long since past the point at which, not being a GNOME insider, I know what all of the processes do, what the components are and how they interact. When I'm running a straightforward console session I can read a process listing and understand what's running and, just as importantly, why I'm running it. Graphical desktop environments take the level of complexity up enormously, and it isn't simply process-related: read ~/.xsession-errors and consider all of the messages from components one didn't even know existed. One is then faced with the practical question: against which package to submit a bug report. At some point the level of complexity really will have to be reduced to make everything easier to administer and easier to debug. I think those who run simple window managers rather than "desktop environments" are well justified in doing so. For accessibility reasons, this isn't an option for me; it's best to run the accessibility infrastructure, when I do need an X environment, in GNOME (for which it was written).