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.
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/
tpierron
On Apr 3, 2:42 pm, Yugo 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.
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.
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.
Blaise Potard
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.
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.
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.
Useur lambda
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.
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.
talon
Alfred Wallace 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
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)
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
Sam Hocevar
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.
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.
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.
