[cumbria_lug] New distro advice
Michael Saunders
mike at aster.fsnet.co.uk
Tue Feb 17 14:57:04 GMT 2004
On Sat, 14 Feb 2004, Roger Cope wrote:
>
> I want core 2 because it is supposed to provide better kernel
> performance than core 1 and my server is currently only just
> acceptable under RedHat 9
Well, firstly, it's not the distro that's providing "better kernel
performance". You can achieve that with any distro and a 2.6.2 tarball
(and likely have better stability without the zillions of unproven
patches rolled in).
Secondly, FC on a _server_? Unless there's some very specific Red
Hat-only config tool or feature you absolutely cannot live without,
it's not the best choice for a number of reasons. Most crucially, it's
not officially supported by RH, so security updates won't always be
made available as quickly as possible (been OK so far though). Then
there's the 5 - 7 months of "support", after which the distro is
EOLed; that's not much use for production servers and Debian's 2+ year
cycle is far more appropriate.
> In the meantime, I have just realised that the black box that I have
> been using as a doorstop is actually a working laptop, which gives
> me a spare machine to put Fedora Core 1 on.
Hope that laptop has a decent spec then! I've still got mixed feelings
about FC 1. It's polished, that's for sure, but then again so is
WinXP. However, it's by far the slowest and most bloated Linux distro
I've encountered in six years of Linux use -- there's been absolutely
no effort to maintain Linux's image as a fast, compact and svelte OS.
This is becoming a big hindrance to Linux desktop adoption. Looking
around mailing lists and Web forums, it's not uncommon to see messages
from newcomers who are complaining about Linux being "slow" and
"sluggish". Of course, others reply pointing out that Linux per se
isn't slow; it's other components. But this is the image it has.
The trade-off is performance vs usability -- everyone agrees on that.
But take the graphical bootup of FC1: it's meant to give a better
impression of Linux by insulating users from the cryptic boot
messages. That's cool! But... Starting up X (why not a quick VGA
splash?) adds a considerable amount to the already poor boot time.
The end result could be a _WORSE_ initial impression!
A few people in the know understand this, and can see where it's
heading, but most developers assume that it's not a problem. Well, if
the modern user-friendly Linux distros booted and ran much faster than
Windows, its desktop uptake would increase dramatically. But it's
getting slower and slower, and more bloated, and we have a problem
here. Microsoft will be doing its best to improve performance (or user
perception of it) in Longhorn; desktop Linux could look abysmal then.
One of the main problems is that developers, being geeks to start
with, typically have fast boxes. They don't consider that there are
hundreds of millions of ~500 MHz ~64MB RAM boxes out there, still
running NT4 or Win98. They'd be great to target: "You can either
upgrade your hardware for WinXP, or spend nothing and use Linux!".
Except, of course, running GNOME/KDE, Mozilla and OpenOffice.org on
those is out of the question. Even with 128MB it's poor (RH recommend
256 for FC). How did we get into this position? When did desktop Linux
become all about chasing Moore's Law, ignoring the potential for large
scale migrations, ignoring 3rd world countries, and just
overengineering as much as possible?
Yes, you can hack one of the mainstream distros to run IceWM, AbiWord
et al. but it's not pretty and not ideal. Debian and Slackware are
superb for older machines, but they're hard to install and use. When
someone wants to install Linux on an old 200 MHz, 32MB box, what do we
tell them? I've yet to find a decent answer, and that's a bad sign!
But it's hard to go back. Packing in redundant functionality and
features, pointless overabstraction, sloppy coding -- it's all putting
us in a bit of a hole. GNOME is by far the worst in terms of
overengineering; there's no thought of efficiency and elegance in the
design, just whimsical decisions and features du jour. Yeah, a config
system really should eat up 20 megs of RAM... (Sheesh.)
In closing, we could find ourselves in trouble when Longhorn ships
unless changes are made. The KDE team is working on improving
performance and memory overhead, so it's a start.
M
--
Michael Saunders
www.aster.fsnet.co.uk
More information about the Cumbria
mailing list