<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Found some inconsistencies. Fixed.<br>
<br>
Here is a new distro model I am proposing. <br>
<br>
<ol type="a">
<li>Image-only installation, instead of package-installs.
This is becoming the new standard in both Linux and Windows, and it
produces a more predictable result, because packages often break at
bare-hardware-install due to timing and power management and simplified
install-time drivers and other factors.<br>
<br>
</li>
<li>The <b>core</b> is built by our own mod of a solid
source-based distro, plus binary proprietary drivers. We could perhaps
use Sabayon to build the core, although I would have to go out and test
every well-reported source-based distro before reaching an opinion on
my own. All function which ships with vanilla XP, <u>omitting
graphical desktop, web
browser, email client, office suite, and security items including
firewall and antimalware</u>, are part of the core. GUI config
utilities are included and fully functional, but we steer very clear of
those which are dependent on specific desktop environments. I think
probably GTK+ is stable, common, and compatible enough, to be
considered the standard GUI API set for config utilities.<br>
<br>
</li>
<li>Updates of the core are done all at once, in very large chunks,
initially not more than every six months, to be extended to not more
than once per year after the team gets its act together. These are
filesystem tree wipes and recopies, not programmatic package installs,
and they will leave /home alone. We'll have to design the elements so
that we can leave /home alone without destructive changes. I am
multiply told that if I take the hard drive out of this Linux Mint PC
and put it into another with different video card, different
motherboard, different network card, et cetera, it will reconfigure
itself automatically for the most part. This is not the old Unix way,
but it is increasingly the modern Linux way, and it is much better; I
am not interested in respecting time-wasting hobbyist-traditions, no
matter how old they are. <br>
<br>
</li>
<li>The obvious question to this approach, is what about
system-wide application updates? I suggest that as a matter of
principle, we should disrecommend them. No system-wide Firefox plugins
or OpenOffice plugins or others to be installed by the users will be
respected through updates. In general they don't happen much now,
because the app designers aren't aiming to support them. I suggest
that if we don't support them, we end up with a much more stable and
reliable tool overall, one in which we can fix a huge number of
problems by simply installing one of the large system packages, the
rest of which are named below. Obviously, plugins in user profiles (in
/home) will stay put. User profiles might need work after a major
update, but not the system as a whole: a big plus.<br>
<br>
</li>
<li>Web browser is Firefox. No packages per se: just filesystem
tree copies. Ditto OpenOffice. Ditto Thunderbird. Ditto GUI desktop
environment. This is the <b>app-set</b>.
If possible, everything is under an /app tree, to make system upgrades
and debugging as simple as possible. Updates of the app-set are done
just like updates of the core, with filesystem tree wipes and
recopies. <br>
<br>
</li>
<li>Firewall and antimalware will need updates at rates different
than core and app-set. This is the <b>security-set</b>. The
temptation is to follow tradition, and make this in part a
programmatical mod of the core. I would like to do literally whatever
we have to do, to avoid this temptation. Programmatical mods are the
principal achilles-heel of distro packages. The security-set, like the
app-set, needs to be a tree-copy install, not a programmatical mod.
Otherwise we open the door to unpredictable bug-causality. I think it
can be done.<br>
<br>
</li>
<li><b>We should maintain three app-sets</b>, vaguely matching
desktop usage patterns we see in real-world users, scaling according to
hardware age. We could label them perhaps "Infra", "Chroma", and
"Ultra", in order to avoid denigration of those who prefer the oldest.
Right now I would put GUI 'links' in "Infra", and Firefox 3 in "Chroma"
and "Ultra". OpenOffice 1.1 in Infra, 2.4 in Chroma, 3.0 in Ultra. We
could plan on an eventual fourth, "Xray", if an interest develops.<br>
<br>
</li>
<li>There is good question as to desktop environment(s) to include.
At this time at least, in my experience, it is necessary to include
both KDE and Gnome in Ultra, because some KDE apps just don't run
decently under Gnome. It may be possible to support only XFCE in
Chroma, and perhaps EDE (or whatever Puppy uses!) in Infra. I would
like to include Chroma's and Infra's desktop environments in Ultra,
because there will be users who prefer more minimalistic tools which
are distro-built to work well.<br>
<br>
</li>
<li>There is also the <b>dev-set</b>. This is gcc and all other
development tools used for compiling the rest of the above, including
the kernel. There is just one of these, which includes the source code
for all three app-sets. Hobbyists can use this compile anything they
want for the /usr/local tree, but we don't otherwise touch about the
/usr/local tree at all. This approach of one huge dev-set actually
makes things much simpler for hobbyists, actually, because they don't
have to spend time with missing dev-packages. I don't know if it's
practical to do so, but I would love to see the whole dev-set in its
own tree, /dev. It would simplify system-debugging and updates quite a
lot.<br>
<br>
</li>
<li>The longevity issue has to be handled using an agreed-upon
paradigm
added to the above. The glibc situation is our largest liability. We
need someone who really understands the practical issues involved, who
is willing to dedicate to helping us. Without such a person I
don't think we should start; without such a person, in my perspective
at least, we would simply be making a second Linux Mint. Before we
start, I want to know precisely why we might not want to try to
recompile OpenOffice 2.4 for glibc 2.2; I want to hear about strategies
for using old glibc versions, and upgrade risks, and hardware concerns
if there are any (I frankly do not know, I think I might have heard
something once).</li>
</ol>
<blockquote cite="mid:495C4CF3.50501@joshuacorps.org" type="cite"><br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
ChristianSource FSLUG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Christiansource@ofb.biz">Christiansource@ofb.biz</a>
<a class="moz-txt-link-freetext" href="http://cs.uninetsolutions.com">http://cs.uninetsolutions.com</a></pre>
</blockquote>
<br>
</body>
</html>