Ce gars-là est fou. Qu'on le lapide, et vite!

Apple didn't invent the idea storing all application-related files in
one place. I think I read somewhere that an early version of RISCOS
did it this way, but Apple has adopted this idea very nicely, and
Windows isn't too far behind. The basic idea is that most files for an
application are stored in one single place. The application NeoOffice,
for instance, has a directory (anywhere you want to put it, really)
called NeoOffice.app. Under that directory are all of the binaries and
data files associated with the base install of that app. Some
structure is imposed so that MacOS knows where to look to find things,
but the main idea is that if you want to run or manage this app, there
is this one place to look. Installing or uninstalling is a matter of
drag-and-drop. Running the application is simple too--double-click on
the directory, and the right thing happens, with the folder acting as
a representative, to the user, of whatever is in the folder. For the
end user, this keeps things painfully simple.

Windows isn't too bad on this front. Under the Program Files
directory, you find most of your major apps. The only thing they're
missing is the directory-as-proxy mechanism. You have to know a little
more in order to find the executable and run it, if you haven't
already got a link to it somewhere.

Linux, unfortunately, sticks to its UNIX heritage of spreading things
out all over the file system. Executables to in /bin, /sbin, or
/usr/bin or /usr/local/bin. Shared objects go into /usr/lib or
somewhere under /usr/local. Configuration files (all plaintext; see
below) go somewhere under /etc or somewhere under /usr/local. There is
a standard that describes in detail how things should be structured,
but it's much too brittle. In theory, conventions, even complex ones,
can be strictly followed, and everything works out well. But this is
an example of a convention that adds just enough complexity and
confusion that it doesn't get followed consistently, and the one left
holding the bag is the end-user who can't figure out where their files
are when something goes wrong. I've been using Linux a lot longer than
MacOS, but while I can easily find whatever I want pertaining to an
app in MacOS, I am clueless about Linux. And I've even installed a
good number of Gentoo systems. The distinction is that the UNIX way is
logical but arbitrary. The Apple way, on the other hand, is simply
intuitive. That's why it's easier to remember and use.

Here, like for most of this article, I'm going to be pragmatic and
suggest that Linux people adopt a Microsoft-like strategy: If you see
someone doing something in a way that works better, adopt it. So, the
solution for Linux systems is to gradually deprecate all of this /bin,
/usr, /etc confusion (except perhaps for the most basic of system
tools like find and ifconfig) and adopt a system that collects all
files of each app into its own directory. And this should be done even
if there is some redundancy! I think one of the ideas behind the UNIX
way is that many apps will share resources. This was a good thing in
the 1970's when resources were scarce. Today, however, this sharing
often results in version conflicts that break apps and make life hard
for users. Think of the users and make things intuitive, even if it
results in some minor increase in complexity or redundancy for
software developers.


http://theosib.livejournal.com/1742.html

Le mardi 3 avril 2007 20:42, Yugo s'est exprimé de la sorte sur
fr.comp.os.linux.debats :

> Ce gars-là est fou. Qu'on le lapide, et vite!
>
[SNIP tout le reste]

Que n'avez vous pas compris dans *francophone* ?

--
@+
Doug - Linux user #307925 - Slackware Rul3z ;-)
Faites comme ptilou, destructurez vos textes :
http://doug.letough.free.fr/ptiloutron/

On Apr 3, 2:42 pm, Yugo <y...@noemailaddress.com> wrote:
> Apple didn't invent the idea storing all application-related files in
> one place.I think I read somewhere that an early version of RISCOS
> did it this way, but Apple has adopted this idea very nicely, and
> Windows isn't too far behind.
Tiens, ça me rappelle un truc ça :

Une invention n'appartient pas tant à son auteur, qu'à celui qui la
vends le mieux.

Le Tue, 03 Apr 2007 14:42:03 -0400, Yugo a écrit:

> Ce gars-là est fou. Qu'on le lapide, et vite!

[snip]

> Here, like for most of this article, I'm going to be pragmatic and
> suggest that Linux people adopt a Microsoft-like strategy: If you see
> someone doing something in a way that works better, adopt it. So, the
> solution for Linux systems is to gradually deprecate all of this /bin,
> /usr, /etc confusion (except perhaps for the most basic of system tools
> like find and ifconfig) and adopt a system that collects all files of
> each app into its own directory. And this should be done even if there
> is some redundancy! I think one of the ideas behind the UNIX way is that
> many apps will share resources. This was a good thing in the 1970's when
> resources were scarce. Today, however, this sharing often results in
> version conflicts that break apps and make life hard for users. Think of
> the users and make things intuitive, even if it results in some minor
> increase in complexity or redundancy for software developers.

Bah, on a déjà eu ce débat (et en français) il y a quelques mois. Certains
avaient la même opinion que ce type, d'autres non. Je pense qu'il y a une
différence de philosophie profonde dans la façon de gérer les logiciels
suivante l'OS.

Pour windows c'est un peu l'anarchie la plus complète. C'est au
distributeur du logiciel de se démerder pour mettre ses trucs aux bons
endroits sans tout péter, vu que le mécanisme prévu pour est de toute
façon beaucoup trop merdique pour être utilisable. Le seul truc utilisé de
façon à peu près standard est la base de registre, qui est une horreur.

Sous MacOSX, c'est un système mixte : il y a une façon standardisée
d'installer les logiciels sans tout péter, avec un système de paquets
comme sous linux, et il y a aussi la façon (traditionnelle de MacOS pré-X),
avec le gros blob binaire qui contient tout ce qu'il faut pour qu'il
fonctionne et qui s'installe simplement en copiant.

Sous BSD ou GNU/linux, le principe de la distribution qui centralise la
gestion des paquets permet une gestion harmonieuse des dépendances
logicielles et ainsi notamment d'économiser pas mal d'espace disque, mais
elle est par contre très coûteuse en moyen humain.

Personnellement, je reste convaincu que les grosses distributions style
debian peuvent encore se permettre de continuer à faire de la liaison
dynamique généralisée, mais c'est beaucoup moins vrai pour les plus
petites distrib, style les BSD.

Ainsi parla Yugo :
> Ce gars-là est fou. Qu'on le lapide, et vite!
>
> ...

Pas tout compris, mais si l'idée est bien "un logiciel = un répertoire",
ce gars-là a un bon sens fou.

Le Wed, 04 Apr 2007 12:11:17 +0200, Useur lambda a écrit:

> Ainsi parla Yugo :
>> Ce gars-là est fou. Qu'on le lapide, et vite!
>>
>> ...
>
> Pas tout compris, mais si l'idée est bien "un logiciel = un répertoire",
> ce gars-là a un bon sens fou.

ça sous-entend que dans ce répertoire dévolu au logiciel, on place les
configurations et données des utilisateurs. Pas pratique pour les
sauvegardes.

Alfred Wallace <aWallace@wallace.com> wrote:
> Le Wed, 04 Apr 2007 12:11:17 +0200, Useur lambda a écrit:
>
> > Ainsi parla Yugo :
> >> Ce gars-là est fou. Qu'on le lapide, et vite!
> >>
> >> ...
> >
> > Pas tout compris, mais si l'idée est bien "un logiciel = un répertoire",
> > ce gars-là a un bon sens fou.
>
> ça sous-entend que dans ce répertoire dévolu au logiciel, on place les
> configurations et données des utilisateurs. Pas pratique pour les
> sauvegardes.

Ca n'a rien de nécessaire. Il me semble bien que Windows met tout ce qui
concerne le logiciel dans un dossier de "Program Files" et par contre
les données des utilisateurs dans un dossier de leur propre "Documents
and Settings", ce qui est parfaitement raisonnable.

En fait le vrai problème est de savoir ce qu'on fait des dépendances,
par exemple les librairies partagées. Dans le cas de Windows, on peut
compter sur la présence d'un certain nombre de DLL, qui sont là grace à
Microsoft et qui ne changent pas trop ou pas du tout. Microsoft fait
très attention à préserver la compatibilité des applications. Donc le
logiciel doit venir avec simplement les librairies partagées qui ne sont
pas "standard".

Dans le cas de Linux, étant donné la modificationnite sauvage qui règne
parmi ses développeurs, si on veut fournir un logiciel garanti
fonctionner, il faut qu'il vienne avec la totalité des librairies
partagées qu'il va utiliser (*). Ce qui pose un problème, non pas tant de
place perdue sur le disque, ce qui est négligeable, que de place perdue
en mémoire pour plusieurs copies résidentes de la même librairie
partagée. Par contre ça règle d'un coup le problème de "DLL hell". La
question est donc de savoir quel compromis est souhaitable.

(*) ou le compiler statique, ce qui est probablement bien plus
performant, ou ne laisser en liaison dynamique que des librairies dont
on est absolument sur qu'elles existent à peu prés à l'identique sur
toutes les machines Unix. Par exemple c'est ce que fait Java de Sun, il
est lié avec très peu de librairies, et celles là extrêmement usuelles.
niobe% ldd java
java:
libz.so.3 => /lib/libz.so.3 (0x2808e000)
libpthread.so.2 => /lib/libpthread.so.2 (0x280a0000)
libc.so.6 => /lib/libc.so.6 (0x280c7000)



--

Michel TALON

On Wed, 4 Apr 2007 12:50:19 +0000 (UTC), Michel Talon wrote:

> (*) ou le compiler statique, ce qui est probablement bien plus
> performant

Ça dépend ce que l'on entend par « performant ». Un facteur souvent
sous-estimé est le temps que met un exécutable à se charger en mémoire
car son code n'est pas relogeable : il faut récrire toutes les adresses
des fonctions et variables non-locales. Dans le cas d'une bibliothèque
partagée, un mmap() sur le fichier, et hop le code est en mémoire et
prêt à être utilisé.

Je simplifie un peu, mais c'est la raison pour laquelle on voit pas
mal de binaires, notamment des programmes KDE dont le code compilé
est souvent très gros (C++ oblige), fournir une bibliothèque
libtoto_support.so qui n'est utilisée que par le programme toto (qui se
résume alors à un appel à toto_main() depuis main()) mais qui permet
d'accélérer énormément le chargement de l'exécutable en mémoire.

Sam.
--
echo "creationism" | tr -d "holy godly goal"