The state of UNIX in general and PLD in particular
Cezary Krzyzanowski
dhubleizh w o2.pl
Nie, 4 Mar 2007, 14:07:13 CET
Dnia 04-03-2007, nie o godzinie 02:46 +0100, Jakub Piotr Cłapa
napisał(a):
> 1. supports only some core libraries and programs and adds several
> optional packages (or package sets --- it doesn't really matter) for
> desktop environments and other big library stuff like Java, Mono, etc,
We choose to be FHS complaint, so no we break it? And what - repatch 15k
+ apps for not being FHS complaint?
> 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.
Next thing is, that some minor tweaks by distro crew (like PLD) can make
the user experience better, like /etc/init.d stuff of VM. Neglect-able
amount of custom work is doable by distro developers and one cannot
expect bundle authors to make it custom work on every possible distro.
> The point of the paper was that the dependencies between libraries are
> not distributed evenly on the dependency graph. It's rather a group of
> loosely coupled clusters (base libs / GNOME libs / KDE libs / Python
> libs) with leaves that are (despite being packages in .so shared
> objects) either not shared or shared by less than 5 programs (think
> OO.org libs). These could be deployed as big packages holding the
> clusters and program bundles containing the leaves. We would loose
> little disk space (and this could be optimized as well by hardlinking
> the libraries already on the system (see also [6]) upon installation or
> even poldek retrieval).
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.
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. 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?
> What we have (and Apple does not) is the ability to patch large amounts
> of software installation routines to make them work in any new system
> layout we can imagine. Hey, we do it on day to day basis to fix many
> packages with differing views (or simply a lack of education) on the
> whole LHS business.
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.
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.
Cz w rny
Więcej informacji o liście dyskusyjnej pld-discuss