Les installations sur GNU/Linux

  • Canada
  • Windows
  • Mozilla Thunderbird
Un bon article décrivant le problème d'installation sous Linux et
proposant la bonne solution, qui implique un changement de mentalité:
http://www.whiprush.org/2004/08/aha_proof_were_.html

Bien à vous,

--
Stefan "Mitch" Michalowski
a.k.a. DjDelovsky
Email: mitch(à)ptaff.ca
 

Re: Les installations sur GNU/Linux

  • Network
  • Mozilla Thunderbird
stefan michalowski a écrit :

> Un bon article décrivant le problème d'installation sous Linux et
> proposant la bonne solution, qui implique un changement de mentalité:
> http://www.whiprush.org/2004/08/aha_proof_were_.html
>
> Bien à vous,


Un certain "Patrice Lévesque" a répondu tout en bas de l'article...

Ça résume bien ma pensée. On ne peut pas vouloir le beurre et l'argent
du beurre. Si on ne veut pas "comprendre" comment ça marche, on ne
compile pas de programme, et on s'en tient à la version qui vient avec
sa distribution. J'ai Mandrake et je veux me sentir à l'aise "comme dans
Windows", et bien j'utilise les outils Mandrake et les sources de
paquetages Mandrake et c'est tout. Quand je veux installer, ça installe
tout seul et y'a jamais rien de cassé, un point c'est tout.

Si je veux faire mon "ti-joe-connaissant", alors je sors des sentiers
battus et je télécharge d'autres logiciels ailleurs. C'est pas vraiment
plus compliqué, mais il faut quand même vouloir apprendre un peu
lorsqu'on vient d'un "monde extérieur".

--
Benoit St-André
ben(à)benoitst-andre.net
Connaissez-vous Linuxédu-Québec ? http://linuxeduquebec.org
Pièces jointes
 

Re: Les installations sur GNU/Linux

  • Canada
  • Windows
  • Mozilla Thunderbird
Benoit St-André wrote:


> Un certain "Patrice Lévesque" a répondu tout en bas de l'article...


Un commentaire sur la réponse de Patrice: il existe aussi un problème
avec les interdépendances de logiciels et les versions différentes de
ces dit logiciels. C'est ce qu'on appèle le DLL-hell. Donc "" n'est pas
vrai. Linux résoue en partie le problème en permettant la compilation.
Pour le moment, ce n'est pas une solution pratique, car compiler un
logicel prend un temps non-négligeable. Mais dans quelques années, quand
la majorité des machines auront des CPUs à 2-4 core candencé à 10Ghz, la
compilation de KDE prendra une dizaine de minutes...

Ou encore, il y a la solution de MacOS X, soit de mettre tout dans un
repertoire avec un fichier XML qui décrit les dépendances. Si
l'application ne trouve pas ses dépendances en mémoire, elle part les
librairies qui se trouvent dans son sous-répertoire. Ça évite de loader
3 fois en mémoire libxml au prix de l'avoir 20 fois sur le disque.

Ou encore la solution no-install, soit de rouler l'application par le
net avec un système de cache qui permet de fonctionner sans connection.
Les mise à jour se font automatiquement lorsque l'on part l'application.
Il n'y a pas de dépendances à résoudre car les applications sont
compilées statiquement.


> Ça résume bien ma pensée. On ne peut pas vouloir le beurre et l'argent
> du beurre. Si on ne veut pas "comprendre" comment ça marche, on ne
> compile pas de programme, et on s'en tient à la version qui vient avec
> sa distribution. J'ai Mandrake et je veux me sentir à l'aise "comme dans
> Windows", et bien j'utilise les outils Mandrake et les sources de
> paquetages Mandrake et c'est tout. Quand je veux installer, ça installe
> tout seul et y'a jamais rien de cassé, un point c'est tout.
>
> Si je veux faire mon "ti-joe-connaissant", alors je sors des sentiers
> battus et je télécharge d'autres logiciels ailleurs. C'est pas vraiment
> plus compliqué, mais il faut quand même vouloir apprendre un peu
> lorsqu'on vient d'un "monde extérieur".


C'est en effet le point de l'auteur, avec une petite variation, c'est
qu'il dit que c'est notre responsabilité d'encourager les gens à
utiliser les outils Mandrake, RH, SUSE, etc. Et non d'inviter les gens à
compiler à partir de la source... comme certains suggères.

Ciao,

--
Stefan "Mitch" Michalowski
a.k.a. DjDelovsky
Email: mitch(à)ptaff.ca
 

Re: Les installations sur GNU/Linux

  • Canada
  • GNU/Linux
  • Mutt

> Pour le moment, ce n'est pas une solution pratique, car compiler un
> logicel prend un temps non-négligeable. Mais dans quelques années,
> quand la majorité des machines auront des CPUs à 2-4 core candencé à
> 10Ghz, la compilation de KDE prendra une dizaine de minutes...


You wish! la compilation de KDE 3.2 peut-être, mais dans quelques
années, c'est clair que ça va prendre le même temps.



> Ou encore la solution no-install, soit de rouler l'application par le
> net avec un système de cache qui permet de fonctionner sans connection.
> Les mise à jour se font automatiquement lorsque l'on part l'application.
> Il n'y a pas de dépendances à résoudre car les applications sont
> compilées statiquement.


C'est une fausse solution, tu le dis, c'est compilé statique; de plus,
qui veut rouler Emacs à partir du Net? (qui veut rouler Emacs tout court
anyway!) tant qu'à faire un download de 20MB, autant l'installer "une
fois pour toutes", tout compiler statique et voilà plus de problèmes.
En utilisant le no-install, tu es encore plus forcé de compiler
statique, suppose que le site web upgrade son application et que je
n'aie pas les dépendances... de pire en pire les applications dépendent
de glibc, perl, gtk, qt, python, gnome, x11 - alors downloadez xclock et
perdez gratuitement 20MB d'espace disque.





--
--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne(à)ptaff.ca
--------================|================--------
--====|====-- GPG: http://ptaff.ca/k.asc ID 9212A432
--
Pièces jointes
 
Re: Les installations sur GNU/Linux
  • Canada
  • Windows
  • Mozilla Thunderbird
Patrice Levesque wrote:


> You wish! la compilation de KDE 3.2 peut-être, mais dans quelques
> années, c'est clair que ça va prendre le même temps.


Je ne sais pas. La progression des CPUs est assez hallucinantes. Si je
me fie sur le temps de compile du kernel sur les dual Xeon 2.2Ghz qu'on
a ici, 15 minutes serait qqchose d'approchable pour KDE dans le future.
On parle ici non-seulement d'une accélération dû à des GHz de plus mais
aussi à la présence de CPUs additionels. Pour de la compilation de KDE,
c'est doubler la performance instantanèment, voir quadrupler avec un CPU
4-core... (AMD planifie en sortir en 2007).


> C'est une fausse solution, tu le dis, c'est compilé statique; de plus,
> qui veut rouler Emacs à partir du Net? (qui veut rouler Emacs tout court
> anyway!) tant qu'à faire un download de 20MB, autant l'installer "une
> fois pour toutes", tout compiler statique et voilà plus de problèmes.
> En utilisant le no-install, tu es encore plus forcé de compiler
> statique, suppose que le site web upgrade son application et que je
> n'aie pas les dépendances... de pire en pire les applications dépendent
> de glibc, perl, gtk, qt, python, gnome, x11 - alors downloadez xclock et
> perdez gratuitement 20MB d'espace disque.


Je ne dis pas que c'est une bonne solution, mais c'est un moyen d'éviter
le problème, donc une solution. En fait, pour plus de détails, je vous
dirige vers le site d'un projet qui implémente ce genre de technique, ça
s'appèle zero-install:
http://rox.sourceforge.net/phpwiki/index.php/ZeroInstall

Bien à vous,

--
Stefan "Mitch" Michalowski
a.k.a. DjDelovsky
Email: mitch(à)ptaff.ca
 
Re: Les installations sur GNU/Linux
  • Canada
  • GNU/Linux
  • Mutt

> Je ne sais pas. La progression des CPUs est assez hallucinantes. Si je
> me fie sur le temps de compile du kernel sur les dual Xeon 2.2Ghz qu'on
> a ici, 15 minutes serait qqchose d'approchable pour KDE dans le future.
> On parle ici non-seulement d'une accélération dû à des GHz de plus
> mais aussi à la présence de CPUs additionels. Pour de la compilation de
> KDE, c'est doubler la performance instantanèment, voir quadrupler avec
> un CPU 4-core... (AMD planifie en sortir en 2007).


Je ne sais pas. La progression de KDE est assez hallucinante. Si je me
fie sur la vitesse de développement de KDE qu'on a aujourd'hui,
compenser pour la vitesse des CPU serait qqchose d'approchable pour GCC
dans le futur. On parle ici non-seulement d'une décélération due à du
eye candy de plus mais aussi à la présence de modules
additionnels. Pour de la compilation de KDE, c'est diviser par deux la
performance instantanément, voir par quatre avec KDE5 (KDE planifie le
sortir en 2006).



--
--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne(à)ptaff.ca
--------================|================--------
--====|====-- GPG: http://ptaff.ca/k.asc ID 9212A432
--
Pièces jointes
 
Re: Les installations sur GNU/Linux
  • Canada
  • Windows
  • Mozilla Thunderbird
Patrice Levesque wrote:


> Je ne sais pas. La progression de KDE est assez hallucinante. Si je me
> fie sur la vitesse de développement de KDE qu'on a aujourd'hui,
> compenser pour la vitesse des CPU serait qqchose d'approchable pour GCC
> dans le futur. On parle ici non-seulement d'une décélération due à du
> eye candy de plus mais aussi à la présence de modules
> additionnels. Pour de la compilation de KDE, c'est diviser par deux la
> performance instantanément, voir par quatre avec KDE5 (KDE planifie le
> sortir en 2006).


Belle essaie, mais tu ne réussi pas. Il y a plusieurs fautes dans ton
argumentation:

- Premièrement, le eye candy ne change rien à la compilation, ce ne
sont majoritairement que des pngs, au pire des svg. Ça ne ralentit pas
la compilation, on ne génère pas ces images à la compile.

- Deuxièment, ce qui ralentit beaucoup la compilation de KDE c'est
l'étape moc qui génère du code c++ qui est ensuite compilé. Je devine
qu'avec le temps le compilateur moc s'améliorera et donc sera plus
rapide. Donc, non seulement les CPUs seront plus puissants, mais les
compilateurs seront plus efficaces.

- Troisièment, d'ici KDE5 il sera possible de distribuer les tâches
intenses à des ordinateurs sur l'internet, un service que Google offrira
probablement. Un peu comme SETI, mais disponible à tous non-seulement
comme client mais aussi comme serveur de tâches.

- Quatrièment, c'est GNOME qui dominera le marché du desktop. Donc KDE
ne sera pas important ;)

Ciao,

--
Stefan "Mitch" Michalowski
a.k.a. DjDelovsky
Email: mitch(à)ptaff.ca
 
Re: Les installations sur GNU/Linux
  • Canada
  • GNU/Linux
  • Mutt

> Belle essaie, mais tu ne réussi pas. Il y a plusieurs fautes dans ton
> argumentation:
>
> - Premièrement, le eye candy ne change rien à la compilation, ce
> ne sont majoritairement que des pngs, au pire des svg. Ça ne ralentit
> pas la compilation, on ne génère pas ces images à la compile.


Ah non, ajouter des libraries ne ralentit pas la compile. C'est cool,
ça! libcairo va se merger from-the-sky dans le code! je me demande si
c'est déjà comme ça avec pango sous Gnome. Est-ce que c'est ça, du code
"virtual"? :)



> - Deuxièment, ce qui ralentit beaucoup la compilation de KDE
> c'est l'étape moc qui génère du code c++ qui est ensuite compilé.


Peu importe le processus, le temps de compilation reste proportionnel à
la quantité de code -> si j'en ajoute, c'est plus long.



> - Troisièment, d'ici KDE5 il sera possible de distribuer les
> tâches intenses à des ordinateurs sur l'internet, un service que Google
> offrira probablement. Un peu comme SETI, mais disponible à tous
> non-seulement comme client mais aussi comme serveur de tâches.


Hey capitaine, t'es passé d'un dual-core CPU à du networked compiling.
J'ai hâte que tu mentionnes les ordinateurs quantiques dans ton reply,
activés par le web sémantique! c'est certain que tu peux pas avoir tort
en disant ça, mais tu détournes le débat.



> - Quatrièment, c'est GNOME qui dominera le marché du desktop.
> Donc KDE ne sera pas important ;)


Et Slackware va s'appeller "Dropline" :)



--
--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne(à)ptaff.ca
--------================|================--------
--====|====-- GPG: http://ptaff.ca/k.asc ID 9212A432
--
Pièces jointes
 

 

Propulsé par xhtmail