[Rule-list] About RH 8 not supporting 486

Colin Mattoon cjm2 at lewiston.com
Tue Oct 22 04:24:30 EEST 2002


On Tue, 22 Oct 2002 00:17:12 +0200
Marco Fioretti <m.fioretti at inwind.it> wrote:

I think Mr. Fioretti summed this up perfectly, but there is one
additional nagging concern that I have. By the way, I'd also like to
apologize for any line wrapping problems with earlier posts. I think I
fixed it now.

The focus is on the deprecation of the i386 and i486 processors. And
that's pretty much a "done deal." Less obvious is that a very high
percentage of i586 machines are also now off limits to Red Hat users.
Most of the used Pentium 1 machines I find are equipped with between 8
and 32 MB RAM. Adding RAM is certainly an option for some, but the
fact is that it is increasingly difficult to find 72 pin memory -- and
when you find it -- it is considerably more expensive per megabyte
than 168 pin SDRAM. Locally, I have found it impossible to purchase
anything less than pairs of new 64 MB EDO RAM, unless one wants to
scavenge a few used 8 MB FP chips. I don't think very many people in
North America will opt to spend $100 USD (or more) for RAM to exercise
the privilege of installing Red Hat 8.0 on a Pentium 1 75 Mhz machine,
when they can buy a replacement with an 800 Mhz processor from
Walmart.com for $200.00 USD.

So, as demand for i586 compatibility in Red Hat's North American
market
quickly slips away, there is no  real incentive for them to continue
compiling the rest of the distribution for anything less than i686
compatibility. Mandrake has used Pentium optimization as a marketing
tool against Red Hat for several years. With no real i586 user base
left, I would anticipate Red Hat will begin to compile the entire
distribution for the i686 or better in an attempt to win back some of
the Mandrake market through "one-ups-man-ship."

I assume, if this happens, it won't matter whether the Rule-Project
Miniconda and Slinky installers can keep pace with Red Hat's minimum
installation requirements, because the distribution itself will no
longer run on the older processors.  I ran into this about three years
ago, while trying to work around Mandrake's requirements. I could get
5.3 to "sort of" work on a 486DX and the next release completely
defeated me :-)

Later,

Colin Mattoon

> Hello, everybody!
> 
> Man, one cannot go to bed early *one* night without his favourite
> project being sabotaged by some corporation...  :-)
> 
> I've read (almost) all messages here and on the psyche list about
> this issue before commenting. My answer and proposals for the list
> follow. Before that, however, thanks a thousand to Michael for
> raising the issue on the psyche list, and coming up with a solution!
> 
> Any feedback is ... due, more than welcome, isn't it?
> (even because the final form of the text below will almost *have* to
> end up on the web site as the "official" position of the project,
> right?)
> 
> Brace yourself, this is one long message, but it is an important
> issue!
> 
> 	Ciao,
> 		Marco Fioretti
> 
> Background
> 
>         On Oct 20 2002 Michael Fratoni, the author and main
>         maintainer of the RULE project installers miniconda and
>         slinky, started a very interesting discussion on the psyche
>         mailing list, asking why there is no more an i386 kernel in
>         the stock RH 8.0 CDs: for the RULE project this is a
>         problem, because the current install procedure assumes that
>         the standard CDs do carry the kernel for older CPUs: in
>         general, this is also a problem for everybody who needs
>         modern Red Hat on old hardware.
> 
> Why did this happen?
> 
>         If a 386 CPU is the base line, there are really a _lot_ of
>         combinations of CPU, main boards and peripherals to
>         consider. Red Hat is a for profit company: it is just
>         natural, and perfectly reasonable, that they focus on,
>         optimize for, and support, the hardware used by the majority
>         of their paying users.
> 
> Why is it bad?
> 
>         Of course, this means that running the latest Red Hat on
>         obsolete hardware just a bit more difficult: the RULE
>         project home page and FAQ already explain in detail why this
>         is not an irrelevant or good thing.
> 
> What should Red Hat do?
> 
>         As already mentioned, there is no point in asking to RH
>         official support for old hardware. We really hope, however,
>         that Red Hat:
> 
>         o   will keep a 386 kernel around, both on the updates
>         server, and in the official CDs starting from 8.1 (others
>         have already noted that space is not really an issue here:
>         just put a huge UNSUPPORTED label on it, and keep going)
> 
>         o   in general, will keep it as easy as possible for
>         external developers to customize every new release for
>         "corner cases" like those of interest to RULE (this second
>         point may be much more important for RH than it could seem
>         at a first glance: a RULE user may not bring any money to
>         RH, but allowing as many future sysadmins as possible to
>         practice RH before they can afford the HW for any other OS
>         is an entirely different thing,
> 	isn't it? Just think to when they become old enough to sign
> 	their first purchase order.
> 
> What should Red Hat users do?
> 
>         Nothing, if they are satisfied with the performances of
>         their box.
> 
>         Come to play with RULE if they want to make it faster: even
>         if we don't say it explicitely, why optimize only old PCs?
>         In other words, having a 1 GHz CPU is no excuse for not
>         making it run like a 2 GHz one...
> 
> What should the RULE project do?
> 
>         Michael Fratoni, excellent as always, has already announced
>         some workarounds and future plans to deal with this issue.
>         In parallel, others have asked to just switch to another
>         distibution as the base for the project, and/or to start a
>         new one from scratch.
> 
> 	My thoughts on this issue (when I say "we" I count myself in,
> 	of course!):
> 
> 	1) I'M HAPPY THAT RH KICKED OUR BUTT, causing more people talk
>            on the list these days: maybe we've been counting on
>            Michael working for us a bit too much (including myself)
> 
> 	2) Judging from the number of list members (~100) and from the
> 	   average time we talk on this list we still have not enough
> 	   mass/average competence/free time/whatever to create and
> 	   above all maintain a whole distro from scratch (if I'm
> 	   wrong, just tell me, and I'd be really happy!)
> 
> 	3) Above all, I am still convinced that many of the reasons
> 	   for the project as structured today remain valid. I refer
> 	   specifically to the fact that many of the problems with
> 	   today's SW are born *before* it is packaged for this or
> 	   that distro. Everybody keeps telling " install the Gthing
> 	   from GNOME or the Kthing from KDE, and the whole mountain
> 	   of dependencies that come along": the packaging format is
> 	   marginal.
> 
> 	   At the same time, there is *nothing* that integrates lean
> 	   applications at INSTALL time to give real functionality
> 	   without spending weeks reading tons of manuals. EX:
> 	   mutt+abook+fetchmail+procmail+w3m+(2/3 shell scripts) =
> 	   same functionality as Evolution or Kmail, from multiple
> 	   accounts to clickable URLs, but show me one distribution
> 	   where they are configured to work together from the first
> 	   login!
> 
> 	   This is an area (shell scripting + advanced post-install
> 	   configuration) where we *can* make a difference, and which
> 	   is, by its own nature, highly portable across distros.
> 
> 	4) **Personally**, I will continue to work for RULE on RH
> 	   because I have no spare HW, and because I have to use only
> 	   RH Linux in my paid job, and hope that Michael will keep
> 	   miniconda and slinky current, since without them RH on old
> 	   HW is impossible from the beginning. Another important
> 	   reason to stay with RH (IMHO) is the one pointed out by
> 	   Colin, i.e. to remember to an important corporation that
> 	   there are people who cannot afford the full thing, and that
> 	   RH should at the very least not make their life
> 	   deliberately harder.
> 
>         5) Project-wise, we can and should (as already said in the
> 	   FAQ) keep as much of our work as we can portable.
> 
> 	6) Summarizing, I highly recommend that, at least for the
>            short/medium term, we keep RH as the base distro: again,
>            for very pragmatical reasons (old Winston used to say
> 	   "slowly but surely"), not to start yet another
>            distro war on what is a side issue, after all
> 
> 	7) (shameless plug) Please go to
> 	   http://www.rule-project.org/en/sw/dan.php and help me to
> 	   port the DAn tool to RH 8.0 and other distros: I'm sure
> 	   we'll all learn a lot about figthing bloat from it,
> 	   including how much of it is RH's fault, and how much comes
> 	   from the pristine sources...
> 
> 	8) Somebody mentioned the possible need to just recompile all
> 	   RPMs for i386: much ligther than creating a new distro, but
> 	   fully useful only after sorting out dependencies and
> 	   configuration as already explained. In the meantime, don't
> 	   forget it, and offer to the list a script to do it
> 	   automatically from a base RH install with gcc only, and
> 	   stock source CDs...
> 
> 
> 
> _______________________________________________
> Rule Project HOME PAGE:  http://www.rule-project.org/rule/
> Original Rule Development Site http://savannah.gnu.org/projects/rule/> 
Original RULE mailing list: Rule-list at nongnu.org, hosted at http://mail.nongnu.org/mailman/listinfo/rule-list
> 
> 


_______________________________________________
Rule Project HOME PAGE:  http://www.rule-project.org/rule/
Original Rule Development Site http://savannah.gnu.org/projects/rule/
Original RULE mailing list: Rule-list at nongnu.org, hosted at http://mail.nongnu.org/mailman/listinfo/rule-list




This full static mirror of the Run Up to Date Linux Everywhere Project mailing list, originally hosted at http://lists.hellug.gr/mailman/listinfo/rule-list, is kept online by Free Software popularizer, researcher and trainer Marco Fioretti. To know how you can support this archive, and Marco's work in general, please click here