[PLUG] Version creep and patching...

plug_0 at robinson-west.com plug_0 at robinson-west.com
Fri Oct 20 17:54:45 UTC 2006


> > I don't know of any series of standard places one can look if some
> > portion of the kernel documentation is wrong about where to go for 
> > a particular option.  I don't know how to follow library changes, I
> > am not a highly skilled programmer.  Heck, most people aren't
> > programmers at all.
> 
> You shouldn't be trying to compile/run your own kernel then, but really use
> a mainstream distribution targeted at you :) ["and just shell out the
> bucks too, just like you take the 3-year SEARS service plan for the
> fridge!"]

The premise that ordinary people will be put in an increasingly difficult
position over time if they want to compile their own Linux kernel 
from current vanilla sources, is that an ideal premise that most OSS folks 
want to see come true?  The comment, "if you don't know how to do something,
don't do it," isn't the most inviting attitude one can communicate.  
Fedora Core 5 is a mainstream disrtribution even if it's a more bleeding 
edge variant of Linux that is upstream from an enterprise distribution.

> Upgrading is not always a viable solution.  Sometimes you don't know
> what you are breaking.  My Maple 9.0.2 for Linux does not seem to run
> on any Linuce that's newer than Fedora Core 1.  How often is it
> reasonable to do a major upgrade?  It seems that Fedora supports more
> than it's Enterprise cousins, but it turns over so rapidly.  The
> enterprise variants are very limited in new hardware support, so one
> loses on the equipment side of the equation.
> 
> Companies like RH will support old installations for up to 7 years on the
> original installation with fixes only. Perhaps that's what you need?

It's too expensive for me to buy enterprise Redhat and so far I've 
had bad luck trying to use a free enterprise variant.  It looks
like I need to pick a free enterprise Linux variant and move all
my servers to it.
 
> I think dropping 386 support in Slackware 10.1 was the wrong move.

> Why? are you certain that the small slackware community could test the
> new software and features on this hardware properly? If they decided to
> keep maintaining i386, they might waste so many resources on it that
> they effectively kill progress in the rest of the project. If you value
> your project, you keep it alive, but not in suspended animation!

There is nothing new on the 386 these days.  Up until Itanium came out, 
the PC's architecture was simply a superset of the 386's architecture.
I don't think that even Pentium architecture is something that students
are taught about in most computer architecture classes yet.  I've heard
that 386's are slow, why support them?  Well, what is wrong with 
reimplementing the 386 in a low power configuration for embedded 
tasks such as implementing a smart phone?  Some major complaints 
against the modern PC are: it is too loud, it runs really hot, it
consumes too much electricity, it is too patched and complex.  I 
see nothing wrong with a market that focuses on yesterdays hardware
unless that hardware becomes really rare.  There is more old hardware 
than there is new, especially with the rate at which Microsoft has been
demanding more processing power and memory to even install Windows.  I 
bet there is a larger market for an operating system that is current, 
patched, and will run on older equipment than there is for an OS that
requires the latest and greatest dual core system.

As far as companies focusing on rare hardware is concerned: 
http://www.cloud9tech.com/ 
is a good example.  What this company is not doing though is
providing itself a clear migration path when the last color 
computer disappears.  I don't see any attempt to clone it 
with a more powerful and featureful version or even produce
a machine that is 100% compatible using modern electronics.  

In the software arena, I think ReactOS is in trouble because
it focuses on supporting proprietary Windows software when it
could become a proving ground for popular new applications that 
vendors etc. aren't willing or able to write for Linux, open 
source or otherwise.  The level of proprietary software support 
ReactOS has achieved is minimal and unfortunately it isn't 
even stable yet.
http://www.reactos.org/

Concerning the premise that there aren't enough people to work on 
developing the most secure and most patched OS for yesterdays 
hardware, what are the limiting factors?  They're not: an 
inavailability of aging computer systems, a universal lack of 
interest in retro computing, total lack of interest in recycling 
old computers.  If yesterdays computer is one that was even bought
as recently as a year ago new, that means there are a ton of old 
computers around.

     --  Michael C. Robinson

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/



More information about the PLUG mailing list