SUMMARY: 3 similar, but distinct, discussions on "Core" changes ...

[Bryan J. Smith]

I just wanted to take the time to introduce this post, possibly as a
reference for others to send when it gets difficult to look at the
similar, but distinct differences between these discussions.

1.  Minimizing, shrinking, splitting up "Core"
2.  386/486/etc... Instruction Set Architecture (ISA) compatibility
3.  A "common denominator" Fedora package set


1.  Minimizing, shrinking, splitting up "Core"

Trying to address the bloating of "Core" at the same time as addressing
the legacy support path of Red Hat Linux (RHL).  This is the discussion
most people assume is always going on.  Be sure it's not #2 or #3 below.


2.  386/486/etc... Instruction Set Architecture (ISA) compatibility

This is _not_ about a "lite" distro.  Numerous vendors are selling
literally millions of "high speed" chips with lots of memory and storage
built around them, but they are "system-on-a-chip" systems.  Most have
an i486 ISA compatible core -- despite being marketed as a "Pentium
II/III class."  They are more than capable of running GNOME so, again,
it's _not_ about a "lite distro."

And yes, Linux runs on _many_ of them today!  These are not just
"speciality" systems, but kiosks, terminals, etc... -- so it makes sense
from an engineering standpoint to offer Fedora while makes it far easier
for engineers to maintain a distro.

To this point, Red Hat has stood by with target i386, optimize for
i686.  That addresses the majority of the modern chips out there within
5-10% of optimal performance, while preserving compatibility.  But it
seems NPTL will force the i486 issue, and the question is should we just
move the "target" higher than i486 and break compatibility?  And should
be just start targetting i486 anyway?

Because of these SoC systems are still around, and _will_ be for years
to come, there is no reason to go beyond targetting i486 IMHO.  Since
none I know of are i386, and i486 offers all sorts of paging and other
capabilities, there is little reason not to move away from i386. 
Combined with the i686 optimizations, it's a great setup, and the
kernel/GLibC is still available in a CPU-optimized version.  

_Furthermore_, with x86-64 now being adopted, there is little sense to
optimize default packages any farther than i486, as most modern systems
are going to be x86-64 in short order, with a x86-64 built distro.


3.  A "common denominator" Fedora package set

Lastly and more eccentric, I'm talking about taking the "minimization"
to a new level.  The idea here is to provide a "common denominator"
Fedora package set.  More than the 90MB "minimal" install, but one that
distro off-shoots, corporations, developers and others can use as a
"base."

It's _not_ an end-user usable distro.  But it _is_ a bootable distro
with a GUI, just enough to fetch everything else via Apt/Yam.  And it
doesn't have too much where people would disagree. 

The Rules:
- All packages must be in Fedora "Core" (no Extras)
- No package included may have a dependency on another included
- If dependency issues arise, work with Fedora "Core" to see the
dependencies are either corrected, changed in a future version,
segmented into multiple packages or just don't use the package (if at
all possible)

The Goals:  "Common Denominator"
- For new off-shoot distros (e.g., should be a subset of Cobind)
- For developers (e.g., want to know what libraries to aim for)
- For corporations (e.g., who will maintain their own internal
repository, and just need a standard, "base" install)

Eventually:  Additional distributed package management tools/support
Ideal/Future:  The package lists would be included as part of "Core" --
e.g.,
 Quark:  Std Desktop --  Minimal
 Quark:  LAN Server -- Directory/Name/Time Server
 Quark:  LAN Server -- File/Print Server
 Quark:  LAN Server -- Kerberos Distribution Center (KDC)
 Quark:  WAN Server -- Directory
 Quark:  WAN Server -- FTP/Web
 Quark:  WAN Server -- Remote Access
 etc...

In every case, the service support is _minimal_, very basic.  The idea
is to start "small" (e.g., PHP is not even included, so the web server
is _basic_), and move from there.  Furthermore, the "Server" components
are easily separated out and not included if desired, for a  "pure"
desktop base.

The Design:  

- Services:
A.  All basic clients/services for authentication, directory and network
access
B.  All basic UNIX bash shell scripting, plus Perl and Python
C.  Console configuration tools (Newt libraries)
D.  Distributed package manager (Apt, possibly Yum)

- GUI:  
E.  Simple GTK+ or Qt-based GUI (elementary GTK+/Qt support)
G.  Perl/Python bindings for GTK+/Qt
H.  GUI configuration tools (GTK+ libraries)
I.  GUI distributed package manager (Synapic)

What window manager is used?  I don't know.  But it _must_ be in Fedora
"Core" itself.  Maybe just XFWM will do (but not the full XFCE
framework), now that XFCE is included in Fedora Core 2.

This is just to get the system "up and running" with a GUI.  All other
customization is done post-install with distributed repository access.


-- 
Bryan J. Smith, E.I. -- b.j.smith at ieee.org