Wild and crazy times for the development tree

[Paul F. Johnson]

> Hi,

>  
> > A *much* reduced core size (5 CDs + rescue is getting a bit much) and
> > large reduction in the overall memory overhead. I know FC is fantastic,
> > but given you need 128Mb for a text only version and 512Mb for a desktop
> > environment, it's becoming hard to justify to the powers that be that
> > using Linux over WinXP is that good an option.
> 
> Are you implying that the only reason one would choose Linux over
> Windows XP, is because it has lower memory and system requirements?

In part, yes. On a voluntary basis, I work for a local charity with some
pretty low end boxes (I think the highest spec machine is P3-366 or
thereabouts), all with 256Mb of memory. Linux runs fine on them.
However, due to the pointy haired boss (and he actually has pointy
hair!) reading distrowatch and seeing that 512Mb is recommended and has
said that given that, why can't he have his XP box and because of that,
we should have XP boxes. I know there is a massive problem with the
logic in that...

> That is one particular usage case scenario that might tilt the scales
> of a given rollout to a Linux based solution over an XP based one, but
> there are far far more other reasons for using Linux over XP than just
> "lower memory/disk footprint".

Yep. I completely agree. Memory is dirt cheap and if wasn't for me
giving my time free, the cost of Linux support would probably mean it is
more economical to go with the Borg and OOo.

> Having expressed this though, I also agree with you completely, in that
> it would be nice to see the overall memory footprint reduced in a sane
> manner without tossing out desired functionality, etc.

It would be interesting to see if the biggest of the hogs is the desktop
environment. I have noticed that while gnome is far better than previous
incarnations, it has somewhat become, well, bloated.

> > Slack 10 can run (text only) in 18Mb with a desktop environment in 64Mb
> > - Debian (sorry for swearing on this list) is a whole lot smaller than
> > FC in terms of memory again.
> 
> Sure, different distributions focus on different areas, with some
> levels of overlapping.  I don't think it is even possible at all
> to make a complete one-size-fits all distribution however, because
> different people have different and often conflicting
> goals/requirements.

True. If we leave aside Slack and concentrate on Debian, SuSE and
Mandriva (in otherwords, the closest thing to competition of the big
distros), Mandriva looks to have the same sort of memory requirements to
functionality ratio as FC, yet SuSE and Debian have smaller footprints
and arguably, greater functionality.

I'm not going to get into the argument over if Debian should be included
(as stable), I'm using it as not only is it one of the most revered, but
is the basis for the likes of Umbunto and Knoppix.

> > I think it was suggested that ISOs are made of FE. It may be time to do
> > this, but with quite a lot from FC moved to it. For example, gcc-gnat,
> > gfortran, objc and anything *not* mono/mcs (in other words, beagle,
> > fspot etc) should, IMHO, be in extras - and yes, I do use gfortran and
> > gnat. The OOo language packs should also be moved out - just keep in
> > french, german, spanish and any big userbases.
> 
> IMHO, moving more and more stuff out of Core and into Extras is an
> overall good idea, so long as the infrastructure is present in
> _advance_ to make it easy to install the stuff that has moved to
> Extras, both at OS install time and later, and without requiring
> mandatory network access.  ie:  Fedora Extras on CD, kindof like
> powertools was before, but with anaconda support for that.

That would be a perfect solution and with another 9 months between FC5
and 6, is probably doable. 

I've noted the comments about the src.rpms and the "not rocket science"
to move them over to Extras once they've been built. I can see both
points of view there. I would say it would probably be easier for the
likes of gnat and gfortran as well as non-core mono pieces to have them
built in Extras than build in core and shift across.

> Anaconda support for additional arbitrary CDs would be nice.

Well, firstboot does have that sort of support, sort of...

> > The same applies to Qt and KDE - quite a lot of the material in there
> > should be in extras, Qt (standard + devel) and some of the kde system
> > should be in Core. We also have a number of different database systems
> > in Core. Could a case not be made for trimming it down to MySQL and
> > postgresql with the rest again going to FE?
> 
> I use KDE mainly, but with mostly GTK apps.  Moving KDE to Extras would
> be ok I guess, so long as I can still choose to install it at install
> time, and not have to mess around a lot post install.

I'm not suggesting a whole sale shift of KDE to FE, that would be silly
and very counter productive (just look what happened when it was
suggested that RH would be gnome only and how that was blown out of
proportion!). I'm saying the likes of kedu, kgames and quite a good
chunk of the kde-internet stuff being shifted out. Keep knode, kopete,
kwifi and akregator and possibly kirc. When koffice was shifted out, it
hardly caused a riot...

> > 9 months is a long time for a release. Perhaps an interim release at the
> > 5 month stage would be an advantage.
> > 
> > Obviously, these are just ideas *but* they do answer a growing number of
> > criticisms of FC.
> 
> The only reason there might be growing numbers of criticisms of FC,
> is that the userbase is expanding, so it makes sense that as the
> number of users increase in volume that the number of both praises
> and criticisms will increase in volume proportionately.

True. It would be interesting to see the proportions of people using
what distro would be. Okay, that's probably a who can pee higher sort of
thing, but it would be interesting.

> It makes more sense to base the release date off the features planned
> for that release and an estimate of how much time is required to
> obtain those features.  That includes in-house developed features,
> and accounting for upstream release dates of various software that
> are desired in the release.

True. Given the improvements in FC5 and all the hard work, bug reports
and the late inclusion of mono, I was happy with 9 months. If the
changes to reduce the footprint without costing the functionality took 9
months, I doubt you'd hear that many moans as well. What you don't want
is the rush job which FC2 and FC4 felt like (I'm not saying they were
either!)

> That's much more important IMHO than arbitrary dates picked because
> some people want a faster release cycle or longer release cycle for
> their own individual preferences/desires.

Couldn't agree more. I want FC to succeed and it will only do that as
part of a wider balancing act.

TTFN

Paul
-- 
"ein zu starker starker Anblick kann Sie toten. Sie gegen gerade uber
den Rand mit dem festen Wissen des Wege vor Ihnen" - Linus Tordvals