FC4 good new tech, bad legacy support

Richard Kelsch rich at csst.net
Thu Jun 30 20:50:25 UTC 2005


John Summerfied wrote:

> Christofer C. Bell wrote:
>
>>
>> The Fedora "Objectives" page[1] does state:
>
>
> While the objective page does say these things, the fact is some of 
> those objectives are in conflict.
>
> "leading edge" software is rarely "robust" or "stable."

You base this hypothesis on what?  Leading-edge can be both robust and 
stable.  It just depends on how thorough and patient the programmers 
are.  Otherwise, the programmers need to label their improvements as 
untested betas, not full blown releases.

> "leading edge" compilers likely implement new algorithms, some of what 
> are flawed and some of which are implemented badly.

See previous.  Make a command line switch to use older algorithms or 
newer "untested" algorithms before thinking those new routines are ready 
for release.  Even a race car needs tweaking before it's ready to race.

> "leading edge" compilers often implement new semantics & syntax, 
> perhaps for compilance with new standards. This can cause problems 
> with existing software, and is the reason RH shipped two C compilers 
> for a time - one for the kernel, one for everything else.

Intelligence would dictate that throwing out the old methods "cold 
turkey" to be unwise and arrogant, as those standards committees 
probably rarely get out to breath fresh air and do not comprehend the 
real world.  Weaning people off bad practices is a wiser approach, 
especially if the older methods worked fine for years.

> Whatever one's objectives are, it's the nature of things that they 
> will often not be met: if they're too easy, there's no challenge.

Agreed, but one can find that learning goes better if taken a step at a 
time, rather than making an olympic leap into the deep end.  Much 
improvement can be missed if you jump too far.

> The problems I've had and which I've seen reported here suggest that 
> on FC3 and FC4, the robustness objective is not met, and least, to 
> everyone's satisfaction.

Perhaps not, or maybe it's not paid attention to enough in development.

> If stability and resilience are important, then I still say FC is not 
> the platform of choice.

Then the FC project needs to re-think its objectives, as it has not met 
them satisfactorally in version 4, in my opinion.  Frankly, I think 
everything 4 is can still be achieved without the problems.  Perhaps a 
4.5 might be in order before going all bonzai on a new version.  For 
everything 4 has is magnificent, for everything it is lacking is poorly 
thought out.

> Now, for those with imbedded projects, I think FC and *EL are not good 
> choices. The RH-based packages are created for general-purpose 
> application with many facilities & features not required for many 
> specialist tasks. For those, I suggest looking for a distro targeted 
> to those needs, or building from source. That way, you get to enable 
> the features you want and eliminate much unwanted bloat.

For those uses I might agree on many points.  However, one may also like 
the ease of use RedHat was originally popular for.

> I used to run RHL 6.2 on a Pentium with 64 Mbytes of RAM, but these 
> days my Celeron 1300-based laptop with 256 Mbytes struggles.
>
> And, I used to run a webs server on a 486, 8 Mb RAM and 170 mb of 
> disk. It's probably still possible, provided that I build from source. 
> If I tried to use RHEL or FC, the dependencies would kill me.
>
What I was doing wasn't anything weird or special.  In fact, the 
software I was attempting to install was pretty generic, yet FC4 failed 
(in my opinion) as a Perl development platform.  That's all, and that is 
significant.  Why are some people being so "fanboy" about this?  Isn't 
the intent of Fedora to build a better Linux OS release?  Shouldn't 
every popular use be considered?  All I want is a better Fedora for the 
future, I don't need to worship it or take offense if someone criticizes 
an aspect of it.

>>
>> * "Provide a robust development platform for building software,
>> particularly open source software." - Implies some modicum of
>> stability.
>>
>> * "Establish and implement technical standards for packages to ensure
>> quality and consistency of the operating system." - A clear nod to
>> stability.
>>
>> * "Create an environment where third party packages are easy to add
>> and positive encouragement and support exists for third party
>> packaging." - Stability is required for this goal to be met.
>>
>> * "Form the basis of Red Hat's commercially supported operating system
>> products." - Poor quality assurance in Fedora implies poor quality
>> assurance in Red Hat Enterprise Linux, so poor quality assurance in
>> Fedora better not be happening (and I don't think it is).
>>
>> * Fedora does not want to be "a dumping ground for unmaintained or
>> poorly designed software." - This also implies a robust quality
>> assurance process.
>>
>> Yes, Fedora is "the basis of Red Hat's commercially supported
>> operating system products" and thus it's a moving target -- but this
>> does not imply that a given release is to be viewed as unstable or
>> that people who experience problems should be told to go elsewhere for
>> their Linux experience or to "suck it up and deal."
>>
>> As for the person that said it's advertised on Fedora's page that
>> users can expect to run into show stopping issues with regularity, I'm
>> hard pressed to find that anywhere on the site.  Do you have a pointer
>> to it?  (Hint: It's not there because it's not in Red Hat's interest
>> to discourage people from using their software).
>>
>> [1] http://fedora.redhat.com/about/objectives.html
>>
>
>




More information about the fedora-list mailing list