The state of UNIX in general and PLD in particular

[Jakub Piotr Cłapa]

Cezary Krzyzanowski wrote:
> Dnia 04-03-2007, nie o godzinie 19:30 +0100, Jakub Piotr Cłapa
> napisał(a):
> 
>> Of course there are such apps (I mentioned them as an example). Kernel 
>> modules (especially on Linux, where almost everything comes with the 
>> mainline kernel) are quite rare and may require some special treatment.
> 
> But not only kernel-related apps. Think apache, or any other very heavy
> used daemon. We give some apps special treatment, like named, which
> comes jailed by default. Some other distros might prefer to choose one
> security pattern (jail, chroot, vserver) and bundle their apps in a
> different way then the original shipped app. Linux is made for such
> cases + PLD is made to tripple or even quaderlupe the amount of packages
> dividing every app to 1mln subapps to fit every configuration need. By
> bundling we kill our main philosophy (think FHS also).

I don't think named is a good example. It could come bundled pretty much 
as it comes today. (the bundle dir would be basicaly chrooted into).

Making it work for Apache and such would be the most difficult part but 
not certainly impossible.

The bundles differ from the current mostly by where the libraries live 
(per app dirs or some system wide "frameworks" versus one common dir) so 
the decision wouldn't be as catastrophic as it seems. Config files 
remain besicaly as they are, maybe /etc could be just renamed to (as on 
OS X) /Library/Preferences but that's cosmetics.

>> There are several main environments and the idea is that their 
>> dependencies are rather not interconnected. This could be measured and 
>> would certainly had to be if we were going to build something like that. 
>> (the usage statistics mentioned as a SoC project could help here)
> 
> This is true like hell, but in desktop environments, like Ubuntu (which
> was AFAIR the system of choice by the papers authors). We aim at server
> environments, where shared /usr from lvm or raid is the core of
> clusters. We don't aim for Normal User (NU) and his ease in application
> installations.

I don't think many share /usr among several different platforms. If they 
do, the OS X answer are fat binaries. This is what you may find 
currently under the name of Universal binaries. They contain two images 
for two processors (PowerPC and Intel) and the same goes for libraries.

/usr/lib/libxml.os + /usr/lib64/libxml.so could be 
/Libraries/Frameworks/libxml/{i386,ia86_64,whatever}/libxml

A funny thing is that apps without the Intel part also work, currently 
Photoshop runs the PowerPC code on Intel by the means of software 
emulation. (built into the kernel) ;]

> Other thing is that poldek is quite easy to handle and a good GUI with
> ratings would solve most of 'our' desktops problems.

The one aspect of bundles (to join many packages into bigger groups) 
could be handled by metapackages in poldek. The part that requires 
package changes would be packaging some rarely used libraries with 
executables that use them. Allowing multiple library versions on the 
same machine would be nice but is a separate problem from bundles and 
AFAIK it's an RPM limitation we don't currently workaround.

> Nevertheless the alternative and ease is tempting. IF one could think of
> a way to ease and automate keeping two distro types (desktop and
> server), so that developers don't have to maintain two sets of 15k
> SPECS, this is an alternative to think of.

A better question IMHO would be if we can do something to move packages 
(maybe only the desktop ones since they are easier) into the other 
scheme. It would be nice to check what trade-offs we would get on 
several typical machines.

>> Which ones?
> 
> Think gajim, think azureus, think Scribus. Think almost all non-GNOME
> GTK app (firefox), Opera. Think vim, emacs, eclipse. Damn man - Linux is
> made by freedom of choice, not bundling IE + explorer together and tell
> the user "Use bundle 1 or bundle 2".

And currently they all require many GNOME or GTK libs. They could just 
require them, so the GNOME superpackage would be needed or they could 
have their own copies. It should be decidable based on the dependency 
graph an some rough usage statistics.

>> If the XML lib is used by only several app that lets bundle it with the 
>> apps (very little disk space will be lost this way).
>> If the XML lib is used by many GNOME apps than bundle it with the GNOME 
>> superpackage.
>> If it's used by more than 100 programs from different environments (say 
>> DBus) than put it in a general desktop bundle.
> 
> True. But how to handle two lines of SPECS - bundling desktop ones, and
> server ones.

The open question is whether we need two lines or can we get away with 
one clever?

>> The reused translations are the core GTK ones, aren't they? I don't 
>> remember any translations with their own package that is required by 
>> other apps.
> 
> Well - GTK provides some default widgets and behaviors like 'Open' or
> file dialogs. But I agree - this is minority. 

But they go with GTK. Who said that library bundles can't have their own 
translations?

>> You've shown 2 examples and say that we need 5 distros. Divide the core 
>> into "core" and "desktop". Getting a little more than needed is not 
>> certainly a big problem. 
> 
> The power of PLD is flexibility - You can build anything custom out of
> it anyway You want. Building an desktop distro is one idea. Maybe it
> could be done in some variant of the way showed in the paper, but this
> is only an idea. There are some other projects, which take PLD as base
> and use it's flexibility to change a little bit - think rescue CD, think
> livecd - which have some dirs static (ro).

I'm not trying to limit this. I know why I use PLD and why I'm a 
developer (unactive recently but still). It's just that maybe our policy 
of breaking everything down to almost a one package --- one file state 
is not the best thing for the desktop. Thinking about a better idea 
shouldn't be a bad thing.

-- 
regards,
Jakub Piotr Cłapa