<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1252"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:700FE8E0-46F3-463F-8BE5-5C891236ED6A@ofb.biz"
type="cite">
<blockquote type="cite">Here is a new distro model I am proposing.
<br>
<br>
• 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>
</blockquote>
<br>
I think this makes a lot of sense, so long as you don't dump
packaging altogether. Frankly, packaging is the one thing I think Linux
has gotten most right. Especially with dpkg and apt-get, though RPM
works well enough.
<br>
</blockquote>
In my Slackware years, I longed for better packaging. Then I noticed
the rub with RPM and .deb packages: internal bugs, and inter-package
conflicts due to unforseen combinations of packages. I'm thinking now
of <i>supporting</i> specific sets of RH and deb packages, for
commercial items and wide-distribution binaries like OpenOffice; but I
don't like depending on them anymore. I have seen too many systems
hosed by bad distro-included (and even distro-recommended) packages.<br>
<br>
And I think RH and deb support belongs in chroot jails. That should
reduce the hosery by a lot.<br>
<blockquote cite="mid:700FE8E0-46F3-463F-8BE5-5C891236ED6A@ofb.biz"
type="cite">
<blockquote type="cite"> • 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.
<br>
</blockquote>
<br>
This might be a bit draconian, I think. If a person adds a third
party application that needs a new library, etc., it would probably be
bad if the application can't count on a globally available location
that won't be wiped out.
<br>
</blockquote>
If third-party apps, using special libraries, were supported only in
chroot jails, this would be no problem at all. <br>
<blockquote cite="mid:700FE8E0-46F3-463F-8BE5-5C891236ED6A@ofb.biz"
type="cite"> I'm going to make several such comparisons here, but
here's the first: I'd observe very closely the Mac OS X installation
and upgrade processes. They are the least troublesome I know --
certainly the most oriented toward giving the average user something
that is stable and prone to avoid failure.
<br>
<br>
<blockquote type="cite"> • Web browser is Firefox. No packages
per se: just filesystem tree copies. Ditto OpenOffice. Ditto
Thunderbird. This is the app-set. 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>
</blockquote>
<br>
Ok, here is number two. Not entirely dissimilarly, check out what
Apple does with its application packages. They are essentially
glorified folders that to the user appear to be single file
applications. If you somehow merged that with your idea, but kept some
package management, you'd have a real winner.
<br>
<br>
What's really good about it: I've yet to meet a person who doesn't
like the one drag installation of most Mac OS X apps (i.e. click the
icon, drag it into the applications folder, bang, it works.).
<br>
</blockquote>
Ah. This reminds me of an idea some people tried in a distro years
ago, long defunct I think. They didn't prefer /usr/bin, /usr/lib,
/usr/share at all. They had something like /OpenOffice, and /Firefox,
et cetera, a completely revamped filesystem tree. The problem was no
source was written for the new filesystem tree; the problem was solved,
reportedly, by a dense forest of symbolic links. I think that if rpm's
and deb's are supported in chroot jails, we come as close as possible
to (a) avoiding the symlink-forest problem and (b) supporting existing
standards. <br>
<br>
I cannot imagine a general-market Linux system today which would
support neither rpm nor deb; commercial distributors just have to have
a packaging standard to deliver efficiently, and those two are
well-known. But if we say that all rpm's and deb's when installed,
will go into special chroots made for them, we can build fences around
destructive package bugs rather efficiently, and it also makes it
easier to identify those bugs and fix them on a per-system basis as
needed.<br>
<br>
I could easily imagine a packaging system specific to this new distro
model, designed for non-distro folks desiring to deliver their product
in a more friendly fashion than chroot; we could call them .pac's, and
give them a /package tree for such a purpose. .pac's would have to be
verified and approved by the distro maintainers, before end-users would
be able to install them; we would need to set up some sort of
encryption-based coding system for the verification. And GUI could be
straightforwardly made a la OS X, for installation.<br>
<br>
But the point is that the distro itself doesn't depend on the .pac
system. The distro uses much larger sets. A single large set is far,
far easier to debug than five hundred packages half of which may or may
not be present, and half of which may have been installed in many
different orders.<br>
<blockquote cite="mid:700FE8E0-46F3-463F-8BE5-5C891236ED6A@ofb.biz"
type="cite"> Principle: if installing software is made harder and
not easier, even if it nets a more secure, stable system, you won't get
users to adopt it. Linux is already harder to install software on than
Mac OS X or Windows, though at the net gain of easy updates. If you can
keep the easy updates *and* make it easier to install, you go a long
way towards a real world desktop.
<br>
</blockquote>
Makes sense to me. .pac will be part of 0.4 :-)<br>
<blockquote cite="mid:700FE8E0-46F3-463F-8BE5-5C891236ED6A@ofb.biz"
type="cite"> The Mac OS X model is really good to expand on. It
might even be worth integrating something into the default file manager
like this. Say you use Nautilus (a good idea, I suspect). Add some
"magic" that detects when a new app bundle is dropped into the
Application folder (whether an upgrade or entirely new product) and it
could register it with the package manager and run any user profile
(etc.) updates necessary to make everything run smoothly.
<br>
<br>
Or, for the sake of simplicity, simply follow Apple's model
verbatim. The first time a new version of an app runs for a given, it
checks to update its config files, etc. On second thought, this model
is probably better. The other advantage is that while installing in
/Applications is strongly encouraged, it isn't mandatory to make things
work. I think in the long run, flexibility will pay off on a desktop.
Users like flexibility.
<br>
</blockquote>
Agreed. The catch is the delicate Unix-type system hierarchy. Tell
me, you clearly know more OS X than I: my vague impression thus far (I
have just a few hours on it tops) has been that OS X has effectively
two filesystem hierarchies, the Unix/BSD and the user-oriented. Is
this factual? <br>
<blockquote cite="mid:700FE8E0-46F3-463F-8BE5-5C891236ED6A@ofb.biz"
type="cite">
<blockquote type="cite"> • Firewall and antimalware will need
updates at rates different than core and app-set. This is the
security-set. 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>
</blockquote>
<br>
I've yet to see an OS that could accomplish this. It'd be
interesting if it did, but I wonder if it is possible. After all, don't
you need scripting to update configuration files and such?
<br>
</blockquote>
Sort of. Bearing in mind that the security-set now contains firewall,
antimalware, and kernel, there will have to be some programmatical
modding, because kernel doesn't go in without boot manager, and boot
manager requires mods. But firewall and antimalware could be set up
for configuration (modding) at the user-level, and explicitly not at
the system-level. If this were done, no scripting of those would be
necessary, because at the system-level all would be explicitly and
exclusively the standard boilerplate each time. If we have to modify
the antimalware and/or firewall to make this feasible, so be it; the
modification will be for a very good purpose, i.e., the stability and
longevity of the system! If Firefox and Adobe Reader have to go in the
security-set also (seems increasingly likely), we might have to do very
careful system-level modding, depending on how much Mozilla and Adobe
decide to mess with the minds of their users; they seem to love to take
good things and cause bugs by altering them unnecessarily.<br>
<br>
And I could see a distro-standard of system-level reconfiguration
scripts, complete with Foresight-style database of changes made. But
this comes later. Right now we are talking about a workstation, DHCP
through whatever wired and/or wireless NICs are present, naught else.
Once it works well out of the box as such, we can build on it. This is
in fact what Microsoft does, without the database; their server OSes
are simple DHCP workstations, until changes are made.<br>
<blockquote cite="mid:700FE8E0-46F3-463F-8BE5-5C891236ED6A@ofb.biz"
type="cite">
<blockquote type="cite"> • We should maintain three app-sets,
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>
</blockquote>
<br>
Very interesting idea. I suppose relatively analogous to the Debian
arrangement?
<br>
</blockquote>
There might be an analogy in some of the Debian folks' minds, but
frankly, if it's there, I have not seen it work :-) In this model, on
an "Infra" system, it needs to be possible to install the latest
Firefox from .pack. Debian does not seem to include such a concept in
reality, as I study the glibc version listings for Debian at
distrowatch.com.<br>
<blockquote cite="mid:700FE8E0-46F3-463F-8BE5-5C891236ED6A@ofb.biz"
type="cite">
<blockquote type="cite"> • 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).
<br>
</blockquote>
<br>
It'd probably pay to observe RHEL closely on this. They have a 7
year life cycle in which they backport security updates rather than
passing out major upgrades. With that in mind, they must do something
like this.
<br>
</blockquote>
I agree they are doing something; but I have no clue what, and it has
driven me up the wall :-) I have a RHE3 server onto which I really
wanted to install the current Free Pascal...but the nearest binary rpm
available was RHE4, which means I would have to find some way to get a
system to have FP cross-compile itself for an ancient glibc, to make it
happen. Bleaugh :-)<br>
<br>
I do want to know what happens if one puts an ancient glibc in a chroot
with an ancient-glibc-based binary, on a new system. Does it work?
Does it crash the kernel (a joke, a joke)? Is there a way to get it to
work?<br>
<blockquote cite="mid:700FE8E0-46F3-463F-8BE5-5C891236ED6A@ofb.biz"
type="cite"> Good stuff! I'll be interested to hear more.
<br>
<br>
-Tim
<br>
</blockquote>
This is a very interesting project for me; I am wondering if it might
be almost as practical as it sounds right now :-) A good source-based
distro should be able to do most of the -set building work. I hope the
Lord permits it to be done, I think that if done well it would
constitute a good example. I think I have just enough hardware to
begin preliminary work, in a virtual machine, fairly soon. Otherwise,
in a month or two I am hoping to have better hardware :-)<br>
<br>
J.E.B.<br>
</body>
</html>