Wild and crazy times for the development tree

[Mike A. Harris]

Paul F. Johnson wrote:

>>>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...

Well actually, I wouldn't completely disagree with his logic.  In
that particular case, if hardware requirements are the greatest
concern, and Fedora has high requirements in the area, it is entirely
possible that Fedora really isn't a good choice for the particular
problem case.  As much as many of us would _like_ to see Fedora be
the end all be all general purpose solution to everything ...  it
sometimes is not.  ;o)

No harm in trying other Linux distributions to see if you can find one
with lower system requirements that allow you to avoid using XP though.


>>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.

A few years ago I set up a Linux solution for a small business, which
was very happy with it for a few years.  I provided support for a
reasonable fee for several years and they didn't need to contact me
very often, so they were happy.  However, the OS eventually went EOL,
and I informed them they really needed to do an upgrade to something
more modern.  They didn't want to take the risk of destabilizing what
worked so well for so long, and so delayed acting on that.  When they
finally contacted me to see if I could update them, was around the
time Fedora came out.  Previously they were using Red Hat Linux, and
I told them I could no longer support their EOL'd RHL box, and that
it would cost them far less to go with RHEL than to be paying me to
update the box every 6 months or so.

They didn't want to pay the subscription for RHEL, even though they
were paying me more than that anyway, and I pointed out that it would
be cheaper for them to do this, and for Red Hat to provide them
support directly.

In similar failed-logic, they considered switching to a Windows based
solution instead, and I told them it'd cost them a lot more to do that,
and it'd cost them a lot more to have someone coming over daily/weekly
to fix the problems they'd have for their particular usage.  They
agreed it could potentially be more costly, but still didn't make the
logic connection that RHEL would be cheaper TCO to them.  They wanted
to keep me on their emergency dialer.  ;o)

In the end, I left the decision up to them to decide to go with RHEL
or Windows, and I passed the administration of the EOL'd box (which was
quite minimal at the time) on to a friend instead, so I wouldn't have
to deal with any eventual security breach or other headache which was
inevitably likely to happen.

In the end, they decided to not make any decision, and I believe they
may still be using the ancient 6.2 based solution.  ;o)

So there's logic, illogic, and an entire new thing which defies
comprehension..  irrational illogic perhaps we could call it.  ;o)

Eventually, the system will likely fall over, and my phone will ring
off the hook.  Thank technology for caller ID!  ;o)


>>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.

Indeed.  There is a tendency in OSS overall it seems for apps/libs/etc.
to sprout more and more dependencies over time just in general.  It is
very observable on the desktop, and in desktopish applications, but it
is also observable at the commandline and underlying OS level too.

Tough problem to solve I think.


>>>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.

Personally, I think it would be confusing as hell to have a single
src.rpm generate binary rpms of which some are in Fedora Core and
others are in Fedora Extras.  That would be made more confusing
since Fedora has separate bugzilla product/etc. for Core and for
Extras (and for Legacy).  Since bugzilla components themselves are
based from the name of the src.rpm, one would have to file a bug
report from a binary package from extras against Fedora Core for the
src.rpm it was built from.

I can think of other complications and confusion that would ensue
as well.  I'm not sure what to suggest to solve those issues however.


>>Anaconda support for additional arbitrary CDs would be nice.
> 
> Well, firstboot does have that sort of support, sort of...

I'm talking about _before_ firstboot though, otherwise it is an
additional step you have to do after the OS is already installed.
That's going to be multiplied times the number of machines you
might have to install on.

I'd very much like to have the ability to install things from Core
and Extras _during_ install, both from the network, and from CD or
DVD.  Additionally, it'd be nice to be able to have Core and Extras
co-reside on a single DVD image (assuming it fits).

Wether this is planned or not, or wether it is feasible or not is
another question entirely.  I have given up on CD based installs
ever since we started producing DVD images, simply because I like
to have one disk installs possible.  Wether it is 1 CD or 1 DVD
I don't really care, but 1 DVD obviously holds more software than
1 CD, so I prefer that. ;o)  If Extras can cram in there too,
fantastic!  If not, a second DVD would be ok I guess.


>>>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,

No, but others have suggested that we move KDE to FE, and provided
some good arguments for how it could be done in a good way that
benefits KDE users a lot, as well as benefiting the distribution by
reducing disk size, and benefitting KDE itself by scaling the number
of external people who could more actively contribute to an Extras
based KDE.

I think that it's worthy of further constructive discussion, but
that it should only be considered for the right reasons.  Some people
would view it in a negative light of KDE being "pushed out", but I
don't think that would really be the case at all.  I mostly use KDE
myself, and if it can be put in Extras in a sane manner, and still
be available at OS install time, and certain other factors sorted out,
then I think it is something worthy of continuing discussion to figure
out all the details without any hasty decisions or actions being made.


> 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 wouldn't say it is counter-productive.  I would however say that there
are a lot of people with strong religious preferences towards GNOME or
towards KDE who would invariably try to provide conspiracy theory spin
on such a consideration.

If there is any serious consideration made for putting KDE in extras
however, then in my opinion at least, the _goals_ would have to be
clearly defined.  ie: "Why?"  or rather "What are the benefits that
we are hoping to achieve by doing this?"

I think there are some worthy benefits to putting KDE in extras, but
I also think that if it is not considered right, not discussed
properly, and not implemented right, then it could be a disaster.

I'd definitely love to see more Fedora contributors actively
contributing directly to KDE in Fedora though, and it seems that
that would be much easier to see happen, if it was in Extras than
it being in Core.

Maybe someone would fix all the bugs in konsole that I've encountered
in the last 5 years then.  ;o)

> 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...

That's an approach I hadn't considered.  If we could move individual
KDE/Qt applications into Extras, that might be a good way to allow
much more active KDE community in the Fedora project.  We do after
all have various GNOME/GTK stuff in extras already too, so why not
have more KDE/Qt stuff there as well?  Heck, there's probably various
stuff that is part of official GNOME that should be pushed to extras
as well, to encourage and enable additional community involvement in
the packages, and also to help reduce Core down in size to help
reduce the number of CDs, etc.


>>>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.

Difficult if not impossible to measure though.  The most likely
suggestion to do such measurements is often web based surveys
or voting galleries, but unfortunately the measurement tools are
almost always inaccurate due to multiple people coming from behind
a single IP address (NAT), and individual people stuffing the polls
from multiple IPs, or even from a single IP.  Additionally, such
polls don't really measure actual usage out there very reliably,
but rather they measure the usage of people who have been made
aware of the survey and actually care enough to vote.  Many people
simply don't ever find out about such surveys, and many people
just don't care enough to vote in popularity contests of that
nature.

As such, you can never really get accurate measurements of usage
IMHO.

Reminds me of a cute paradoxical quote:

"Statistics have shown that 93.8% of all statistical studies are
innaccurate and flawed."


Or something like that... ;o)


>>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!)

One thing that will be nice now, regardless of the length of FC's
schedule, will be modular X.  There's going to be soooooooo much
less work to do updating each component over time, than the huge
mega monolith. ;o)

-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.