[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Making Fedora Core CD #1 Standalone -- Core should continue, but let's define a subset
- From: "Bryan J. Smith" <b j smith ieee org>
- To: fedora-devel-list redhat com
- Subject: Re: Making Fedora Core CD #1 Standalone -- Core should continue, but let's define a subset
- Date: Mon, 24 May 2004 22:35:03 -0400
Chris Chabot wrote:
> Actually that makes me wonder though what this 'core' is of fedora.
> I've seen this core concept mentioned many times in this thread, and
> most ppl do seem enthusiastic about the concept (though there are
> obvious bariers to overcome, problems to solve etc). However i
> haven't seen anyone explain what -they- see as a core.
Well, I'm sure I have confused many.
To start, let me tell you what I think, and where I am coming from.
1. I consider Fedora Core to be Red Hat Linux
2. Fedora Core will bloat to 5, 6 and more CDs
As such, all the legacy needs to be in it, along with anything new.
There is no way to avoid this, without breaking compatibility and
assumptions. Is it a bad thing? That's debateable. There is much
good to adding more and more as part of the "full" install,
Scribus, OpenGroupware.org (OGo), Firefox/Thunderbird, etc...
Now many have suggested, heck I even started out by taking Pritchard's
post, about "rolling back" the size of Fedora Core. Talk of moving
things to Extras, or elsewhere. But by the very nature of Core v.
Extras, there may be legacy/compatibility issues to consider. And
as many have stated, there is the fact that some people want a
full install from media, since Internet bandwidth is still a
premium in many parts of the US (let alone many places outside the US).
So what I'm considering is not touching Core itself. Instead, let's
define the "absolute minimum" of Core. If we can do this by making
sure it is the CD #1 in Core, then it will have minimal impact. If
we need to do it by defining a set of "rules" -- maybe a "sub-
repository" that is still part of Core, but has the contraints that
no package requires any additional Core packages not in it, then
let's do it. I proposed the name "miniCore" or "Quark," but that's
just a temporary reference I make.
So, onto defining what is in "Quark" ...
> A xorg, gnome basics, system-config-packages etc is all nice and
> dandy, but ppl who want to setup a server without X would not be
> pleased by this system at all.
> Or if was a workstation, and the core CD only had those core apps,
> wouldnt you always need the extra's cd's? (for say openoffice,
> mozilla, or whatever is needed)
It's hard to "please everyone." Let's not try to break up Fedora
Core into different CDs for different users. That's a headache
that will only add to the burden. I'm all about minimizing the
packaging burden. Besides, with Fedora's new, distributed nature,
it is not necessary.
No, what I'm talking about is _ultra_basic_ stuff. A basic server.
A basic workstation. _No_ applications. _No_ feature rich services.
You get X and GNOME, *0* apps. Not even the standard GNOME app spread.
You get basic services, enough for a basic file, print or web server,
but with _no_ riches.
And we _really_ need to start defining the _basic_ scripting support
required in Perl, Python and/or PHP, etc... Otherwise, the bloat is
only going to get worst in packages. Yes, it's hard to do it now, but
let's at least _define_ the "recommendations," like Debian did long
For example, packages that require Emacs _only_ because it runs some
Lisp or other interface for just the package script -- stuff like that
has just got to end. Now we can't do it overnight with Core. Trying to
do so would only break compatibiltiy and cause additional re-engineering
But by defining a new set of rules for including in "Quark," we
can lay a new foundation. If you're going to be part of the "Quark"
cornerstone of Fedora, you have to adhere to X, Y and Z. It won't
happen overnight, but luckily we can start by making Quark minimal
I'm sure in 3-5 years, Quark will bloat, and then we'll need a
"sub-Quark" to refresh it. As you may note, the idea here is not to
"reduce" Core, but to slowly replace it with a smaller standard.
Because things bloat. God, if there is one "bad habit" the social
design has, it is the tendency to add yet more and more and more
until many people forget about various things available (there is
no more proof than that the ultimate social design, governments ;-).
So the "workaround" is to let what exists be, but slowly move
people towards a new, smaller version.
> Another question, is there a seperate development cd? (auto*, gcc*
> kernel-source, etc), or is that considered core functionality?
Again, let's not over-complicate this. Remember, I'm all about
_minimal_impact_ and _minimal_re-engineering_ effort.
In a nutshell, let's just let "Core" be as it is. A slowly bloating
reference. With Apt/Yam, we can yank what we need over the Internet.
For those with limited bandwidth, well, they'll just want the full Core.
But for those that want to "start simple," that's what Quark will be.
At least until 3-5 years later when Quark has now bloated. ;-ppp
Ahhh, someone could write a thesis on the natural occurrance of
bloat in software distribution! The key is to not fight the bloat,
as that only breaks compatibility and assumptions. The key is to
introduce a new, smaller distribution until it bloats, and then
So I'm suggesting we do that with "Quark." A sub-set of Core that
is just enough to get a basic file/print/web server running, or a
X workstation with just the bare GNOME interface. Nothing more.
Bryan J. Smith, E.I. -- b j smith ieee org
[Date Prev][Date Next] [Thread Prev][Thread Next]