[CS-FSLUG] PDL report
Jonathan E. Brickman
jeb at joshuacorps.org
Sun Jan 4 14:27:58 CST 2009
In no particular order:
1. core.
1. The core has to have absolute maximum hardware
compatibility, and for a desktop OS for general use, it
cannot require command-line arcana for hard drive
installation or anything else truly vital. This immediately
cuts out all Slackware-based distros I have tried (quite a
few), CRUX, and quite a few others. Interestingly enough,
it leaves in Gobo, as well as Mint and effectively all very
popular distros. I was at least somewhat wrong about Gobo:
its default install is very venerable-and-stable, but it has
current versions and usually leading-and/or-bleeding-edge
versions of everything also. One unusual item: Gobo does
seem to be doing good TTF rendering in KDE 3.5.something, as
well as keeping KDE 4.0.4 and 4.1.something available. KDE
is the default environment in Gobo, although it does appear
to support Gnome too.
2. I have (as others have, I know) routinely switched distros
to find one which will handle whatever hardware I have,
because hardware is so multifaceted, and this is a method
which works.
3. Since PDL does not necessarily need to be a distro, perhaps
it would be most effective if it explicitly set out to be an
adjunct onto several different cores. This would fit users,
mission, flexibility, and compatibility rather well.
4. I now plan to support three 'core' distros as soon as there
is code to distribute: current RH, current Mint (and Ubuntu
and appropriate-versioned Debian), and current Gobo. That
gives us RPM, Deb, and wildcard, which is a very appropriate
spread. SUSE comes immediately after.
2. app-set, security-set.
1. ROX contains a desktop, filemanager and WM, all of which are
very interesting. I won't recommend them until I have
certain additional data, which I am obtaining from their
helpful support folks right now, and have tested them
thoroughly.
2. ROX uses something called 'zeroinstall' for its
distribution. zeroinstall, a separate project, is very
neat: it looks at (effectively) the 'core' of the machine
it is running on to see if needed dependencies are present,
and installs them if they are not -- but zeroinstall's
installations are to its own-controlled trees, not putting
anything at all into /usr, or /usr/lib, or even /usr/local
or /usr/share. Much safer approach; just right for PDL.
3. In my experience, my Linux problem second only to hardware
compatibility, has been WWW compatibility. Over and over
again there is just one plugin which is conflicting with
whatever plugin is required to see whatever it is I am
trying to see. Mint has done this better than anything
else; there are still a few exceptions, but I suspect these
are rare cases where the only way is using a wine-based
win32 wrapper, and I don't know much about this approach
yet. (I am going to use Mint as my archetype for plugin
list, including order; I have seen the config files
involved, and although they are arcane, they are also
boilerplatable.) There is no ROX package for Firefox or
plugins at this time: if ROX is the app-set delivery
method, that will be a central part of the effort involved.
4. ROX does, very selectively, use and modify /var and /etc. I
think this is acceptable, as long as the PDL sets (three
different app-sets, and the security-set) are referred-to as
unique ROX packages. This is very practical given the ROX
architecture.
5. When PDL app-set by ROX materializes, PDL security-set by
ROX will be a slam-dunk, except kernel. But kernel should,
in my opinion, be handled at the core level.
3. A wee bit of glibc version hope, perhaps.
The 'autopackage' people ( http://www.autopackage.org/faq.html )
say that their packages can install onto any distro. If this is
really true, they have to know something about glibc multiversion
solutions. I will try to find out.
J.E.B.
More information about the Christiansource
mailing list