The state of UNIX in general and PLD in particular

[Jakub Piotr Cłapa]

Cezary Krzyzanowski wrote:
> Dnia 04-03-2007, nie o godzinie 02:46 +0100, Jakub Piotr Cłapa
> napisał(a):
> 
> We choose to be FHS complaint, so no we break it? And what - repatch 15k
> + apps for not being FHS complaint?

And what we gain by FHS compliance? I don't think any external software 
or even packages from other FHS distros will work on PLD.

I wanted to talk about other possible schemes so, for the sake of this 
discussion, we should forget about FHS for a moment.

>> 2. makes use of bundles [3] by means of plain folders (like in OS X), 
>> tar/zip archives (AFAIK like in Mozilla and Java jar files) or 
>> filesystem abstraction (think FiST or FUSE, no known implementations),
>>
>> 3. allows program installation by the means of drag and dropping bundles 
>> containing the program, it's required libraries which are not supplied 
>> with the base system (no DLL/dependency hell!)
> 
> There already are applications that ship that way - bundled and
> containing their own sub directory like OO.org, VM-Ware. In my
> experience it's rarely so, that an app gets just put somewhere and works
> with the whole distro out-of-the-box. Like VM - it is bundled, but the
> kernel module building, module auto-loading doesn't work well.

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.

> Well this is great, but not in multi-user, multi-destkop environmets
> environments. In Mac OSX You don't have a choice - the vendor gives You
> some desktop environment, so it needs only one bundle of libs and other
> apps are clearly 'opt' class - they need their own directory with
> runtime environment. Then again PLD isn't so - there is no MAIN desktop
> environment, if one is needed at all, so You can't possibly choose what
> to bundle what to make shared.

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)

> Life is more complicated - not all applications are one 'bundle'
> friendly, like only KDE friendly or only GNOME friendly. There are apps
> that aim to fit everywhere.

Which ones?

> Moreover there ara apps that use different
> libs to achieve common goal (like many XML-related libs, many types of
> threading abstraction, media handling) so naturally one desktop
> environment would pull *almost* all other deps. Think kaffeine -
> gstreamer + xine backends. And what - now say 'kaffeine will only use
> xine' and make similar decisions for other non 'pure' apps?

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.

> One thing posted in that paper was translation stuff. There are some
> aspects of FHS that suck - like putting applications translation files
> in common dir. It won't be shared anyway. This is stupid - I admit. Then
> again some translations are reused. How to compromise? Make a
> loooonnngggg searching paths? Every new applications adds it's paths to
> translation file paths, binary paths and many, many other? This *will*
> be unmaintainable in longer run.

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.

> Next thing - make the judgement which apps are 'system', which added. On
> server machine X is added, on desktop it clearly is system. So? 5
> different PLD's for every need? Overkill.

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. I carry (on a 40GB laptop drive) 1,3 GB system 
installed printer (CUPS) drivers. I could delete them but then I would 
not be able plug an almost arbitrary printer and have it work without 
any configuration and downloading.

-- 
regards,
Jakub Piotr Cłapa