mais que se passe-t-il dans fr.comp.os.linux.debats ?
318 réponses
professeur Méphisto
fr.comp.os.linux.debats est vide chez moi depuis trois jours ? Je
m'inquiète ! Où sont les trolls ?
[ ] ils se sont tous entre-tués ?
[ ] ils sont devenus raisonnables ?
[ ] la fosse à trolls sentait les pieds et il fallait aérer ?
[ ] ils ont migré pour vista ?
[ ] etch est sorti en stable ?
[ ] ils sont tous ici pour boire une mousse ?
[ ] c'est chez moi que c'est cassé ?
Méph'
attention, suivi à la buvette, faut pas pousser non plus
Mon portable core2duo du boulot charge aussi comme un fou au démarrage au niveau I/O disque surout, le cpu est à 0.
Et après, certains pourtant compétents techniquement viennent nous venter ici les mérites du modèle windows où toutes les applications sont liées statiquement avec leurs bibliothèques, pour éviter à l'utilisateur les questions de dépendances, arguant que 20 Mo de disque, de nos jours, ce n'est rien...
"Laurent C." , dans le message <slrner4mtj.3vj.laurent@wks02.chez.oim>,
a écrit :
Mon portable
core2duo du boulot charge aussi comme un fou au démarrage au niveau I/O disque
surout, le cpu est à 0.
Et après, certains pourtant compétents techniquement viennent nous venter
ici les mérites du modèle windows où toutes les applications sont liées
statiquement avec leurs bibliothèques, pour éviter à l'utilisateur les
questions de dépendances, arguant que 20 Mo de disque, de nos jours, ce
n'est rien...
Mon portable core2duo du boulot charge aussi comme un fou au démarrage au niveau I/O disque surout, le cpu est à 0.
Et après, certains pourtant compétents techniquement viennent nous venter ici les mérites du modèle windows où toutes les applications sont liées statiquement avec leurs bibliothèques, pour éviter à l'utilisateur les questions de dépendances, arguant que 20 Mo de disque, de nos jours, ce n'est rien...
pehache grmpf
"Nicolas George" <nicolas$ a écrit dans le message de news: eouco9$2tsi$
"Laurent C." , dans le message
Mon portable core2duo du boulot charge aussi comme un fou au démarrage au niveau I/O disque surout, le cpu est à 0.
Et après, certains pourtant compétents techniquement viennent nous venter ici les mérites du modèle windows où toutes les applications sont liées statiquement avec leurs bibliothèques,
Dans DLL, le "D" signifie quoi, au juste ?
pour éviter à l'utilisateur les questions de dépendances, arguant que 20 Mo de disque, de nos jours, ce n'est rien...
Justement, les dépendances qui n'en finissent pas sont un des trucs pénibles que l'on rencontre sous Linux. Du fait aussi de l'évolution rapide et perpétuelle des différents composants logiciels.
Par ailleurs ce n'est pas parce qu'une appli est linkée statiquement qu'elle est entièrement chargée en mémoire au lancement.
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message
de news: eouco9$2tsi$2@nef.ens.fr
"Laurent C." , dans le message
Mon portable
core2duo du boulot charge aussi comme un fou au démarrage au niveau
I/O disque surout, le cpu est à 0.
Et après, certains pourtant compétents techniquement viennent nous
venter ici les mérites du modèle windows où toutes les applications
sont liées statiquement avec leurs bibliothèques,
Dans DLL, le "D" signifie quoi, au juste ?
pour éviter à
l'utilisateur les questions de dépendances, arguant que 20 Mo de
disque, de nos jours, ce n'est rien...
Justement, les dépendances qui n'en finissent pas sont un des trucs pénibles
que l'on rencontre sous Linux. Du fait aussi de l'évolution rapide et
perpétuelle des différents composants logiciels.
Par ailleurs ce n'est pas parce qu'une appli est linkée statiquement qu'elle
est entièrement chargée en mémoire au lancement.
--
pehache
enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply
http://pehache.free.fr/public.html
"Nicolas George" <nicolas$ a écrit dans le message de news: eouco9$2tsi$
"Laurent C." , dans le message
Mon portable core2duo du boulot charge aussi comme un fou au démarrage au niveau I/O disque surout, le cpu est à 0.
Et après, certains pourtant compétents techniquement viennent nous venter ici les mérites du modèle windows où toutes les applications sont liées statiquement avec leurs bibliothèques,
Dans DLL, le "D" signifie quoi, au juste ?
pour éviter à l'utilisateur les questions de dépendances, arguant que 20 Mo de disque, de nos jours, ce n'est rien...
Justement, les dépendances qui n'en finissent pas sont un des trucs pénibles que l'on rencontre sous Linux. Du fait aussi de l'évolution rapide et perpétuelle des différents composants logiciels.
Par ailleurs ce n'est pas parce qu'une appli est linkée statiquement qu'elle est entièrement chargée en mémoire au lancement.
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
pehache grmpf
"professeur Méphisto" a écrit dans le message de news:
Y'a quoi dans IE7 que FF ne fait pas par défaut ? Ceci est une vraie question.
Le support des active-x.
et un point de plus pour FF !
Pour augmenter la sécurité et avoir 10 points de plus, FF devrait interdire d'aller sur internet.
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
"professeur Méphisto" <professeur.mephisto@wanadouille.fr.invalid> a
écrit dans le message de news:
pan.2007.01.20.22.12.11.442787@wanadouille.fr.invalid
Y'a quoi dans IE7 que FF ne fait pas par défaut ? Ceci est une vraie
question.
Le support des active-x.
et un point de plus pour FF !
Pour augmenter la sécurité et avoir 10 points de plus, FF devrait interdire
d'aller sur internet.
--
pehache
enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply
http://pehache.free.fr/public.html
"professeur Méphisto" a écrit dans le message de news:
Y'a quoi dans IE7 que FF ne fait pas par défaut ? Ceci est une vraie question.
Le support des active-x.
et un point de plus pour FF !
Pour augmenter la sécurité et avoir 10 points de plus, FF devrait interdire d'aller sur internet.
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
Nicolas George
"pehache grmpf" , dans le message , a écrit :
Dans DLL, le "D" signifie quoi, au juste ?
Une couche de complexité qui, bien utilisée, pourrait apporter de grands services. Manque de bol, windows ne s'en sert pas correctement, et récupère tous les inconvénients et aucun avantage.
Justement, les dépendances qui n'en finissent pas sont un des trucs pénibles que l'on rencontre sous Linux.
Comme je viens de le démontrer, l'autre solution est pire.
Du fait aussi de l'évolution rapide et perpétuelle des différents composants logiciels.
Personnellement, je trouve que c'est une force.
Par ailleurs ce n'est pas parce qu'une appli est linkée statiquement qu'elle est entièrement chargée en mémoire au lancement.
Non, mais ça dit que les parties qui doivent l'être ne seront pas déjà présentes en mémoire. Et c'est bien là qu'est le problème.
"pehache grmpf" , dans le message <51gsskF1kiaieU1@mid.individual.net>,
a écrit :
Dans DLL, le "D" signifie quoi, au juste ?
Une couche de complexité qui, bien utilisée, pourrait apporter de grands
services. Manque de bol, windows ne s'en sert pas correctement, et récupère
tous les inconvénients et aucun avantage.
Justement, les dépendances qui n'en finissent pas sont un des trucs pénibles
que l'on rencontre sous Linux.
Comme je viens de le démontrer, l'autre solution est pire.
Du fait aussi de l'évolution rapide et
perpétuelle des différents composants logiciels.
Personnellement, je trouve que c'est une force.
Par ailleurs ce n'est pas parce qu'une appli est linkée statiquement qu'elle
est entièrement chargée en mémoire au lancement.
Non, mais ça dit que les parties qui doivent l'être ne seront pas déjà
présentes en mémoire. Et c'est bien là qu'est le problème.
Une couche de complexité qui, bien utilisée, pourrait apporter de grands services. Manque de bol, windows ne s'en sert pas correctement, et récupère tous les inconvénients et aucun avantage.
Justement, les dépendances qui n'en finissent pas sont un des trucs pénibles que l'on rencontre sous Linux.
Comme je viens de le démontrer, l'autre solution est pire.
Du fait aussi de l'évolution rapide et perpétuelle des différents composants logiciels.
Personnellement, je trouve que c'est une force.
Par ailleurs ce n'est pas parce qu'une appli est linkée statiquement qu'elle est entièrement chargée en mémoire au lancement.
Non, mais ça dit que les parties qui doivent l'être ne seront pas déjà présentes en mémoire. Et c'est bien là qu'est le problème.
Nicolas George
"pehache grmpf" , dans le message , a écrit :
Pour augmenter la sécurité et avoir 10 points de plus, FF devrait interdire d'aller sur internet.
Dommage qu'outlook n'interdise pas d'aller sur les news.
"pehache grmpf" , dans le message <51gt5cF1k7bjcU1@mid.individual.net>,
a écrit :
Pour augmenter la sécurité et avoir 10 points de plus, FF devrait interdire
d'aller sur internet.
Dommage qu'outlook n'interdise pas d'aller sur les news.
Pour augmenter la sécurité et avoir 10 points de plus, FF devrait interdire d'aller sur internet.
Dommage qu'outlook n'interdise pas d'aller sur les news.
pehache grmpf
"Nicolas George" <nicolas$ a écrit dans le message de news: eovet7$2ka3$
"pehache grmpf" , dans le message ,
Dans DLL, le "D" signifie quoi, au juste ?
Une couche de complexité qui, bien utilisée, pourrait apporter de grands services. Manque de bol, windows ne s'en sert pas correctement, et récupère tous les inconvénients et aucun avantage.
Justement, les dépendances qui n'en finissent pas sont un des trucs pénibles que l'on rencontre sous Linux.
Comme je viens de le démontrer, l'autre solution est pire.
Du fait aussi de l'évolution rapide et perpétuelle des différents composants logiciels.
Personnellement, je trouve que c'est une force.
C'est une force sur certains points, et un handicap sur d'autres.
C'est une force pour le développeur, ou pour celui qui veut toujours être à la pointe de tout. Pour l'utilisateur final moyen, par contre, ça se discute. Cet utilisateur final préfère la stabilité de son environnement de travail à la disponibilité permanente de nouvelles fonctionnalités.
Quand il rapporte un problème dans l'application "machin-2.5" et qu'on lui répond "Ah mais là pour résoudre ça il faut utiliser la libtruc-1.5.0.6a-2 plutôt que la libtruc-1.4.20.3b-8", alors à la limite il veut bien mettre à jour la nouvelle libtruc. Du coup "Machin-2.5" fonctionne. Mais quand quelques jours après il constate que l'appli "bidule-1.7" ne fonctionne plus et qu'on lui dit "Ah oui c'est normal, libtruc-1.5xxx semble incompatible avec bidule-1.7, sans que l'on sache bien pourquoi. Il faut revenir à libtruc-1.4xxx ou antérieur, ou bien mettre à jour bidule-1.7 vers bidule-1.8beta9, mais comme son nom l'indique c'est une version beta et il y peut-être encore des trucs pas stables (mais chez moi ça marche)..."
Là il pète un peu les plombs, l'utilisateur moyen...
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message
de news: eovet7$2ka3$1@nef.ens.fr
"pehache grmpf" , dans le message
<51gsskF1kiaieU1@mid.individual.net>,
Dans DLL, le "D" signifie quoi, au juste ?
Une couche de complexité qui, bien utilisée, pourrait apporter de
grands services. Manque de bol, windows ne s'en sert pas
correctement, et récupère tous les inconvénients et aucun avantage.
Justement, les dépendances qui n'en finissent pas sont un des trucs
pénibles que l'on rencontre sous Linux.
Comme je viens de le démontrer, l'autre solution est pire.
Du fait aussi de l'évolution rapide et
perpétuelle des différents composants logiciels.
Personnellement, je trouve que c'est une force.
C'est une force sur certains points, et un handicap sur d'autres.
C'est une force pour le développeur, ou pour celui qui veut toujours être à
la pointe de tout. Pour l'utilisateur final moyen, par contre, ça se
discute. Cet utilisateur final préfère la stabilité de son environnement de
travail à la disponibilité permanente de nouvelles fonctionnalités.
Quand il rapporte un problème dans l'application "machin-2.5" et qu'on lui
répond "Ah mais là pour résoudre ça il faut utiliser la libtruc-1.5.0.6a-2
plutôt que la libtruc-1.4.20.3b-8", alors à la limite il veut bien mettre à
jour la nouvelle libtruc. Du coup "Machin-2.5" fonctionne. Mais quand
quelques jours après il constate que l'appli "bidule-1.7" ne fonctionne plus
et qu'on lui dit "Ah oui c'est normal, libtruc-1.5xxx semble incompatible
avec bidule-1.7, sans que l'on sache bien pourquoi. Il faut revenir à
libtruc-1.4xxx ou antérieur, ou bien mettre à jour bidule-1.7 vers
bidule-1.8beta9, mais comme son nom l'indique c'est une version beta et il y
peut-être encore des trucs pas stables (mais chez moi ça marche)..."
Là il pète un peu les plombs, l'utilisateur moyen...
--
pehache
enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply
http://pehache.free.fr/public.html
"Nicolas George" <nicolas$ a écrit dans le message de news: eovet7$2ka3$
"pehache grmpf" , dans le message ,
Dans DLL, le "D" signifie quoi, au juste ?
Une couche de complexité qui, bien utilisée, pourrait apporter de grands services. Manque de bol, windows ne s'en sert pas correctement, et récupère tous les inconvénients et aucun avantage.
Justement, les dépendances qui n'en finissent pas sont un des trucs pénibles que l'on rencontre sous Linux.
Comme je viens de le démontrer, l'autre solution est pire.
Du fait aussi de l'évolution rapide et perpétuelle des différents composants logiciels.
Personnellement, je trouve que c'est une force.
C'est une force sur certains points, et un handicap sur d'autres.
C'est une force pour le développeur, ou pour celui qui veut toujours être à la pointe de tout. Pour l'utilisateur final moyen, par contre, ça se discute. Cet utilisateur final préfère la stabilité de son environnement de travail à la disponibilité permanente de nouvelles fonctionnalités.
Quand il rapporte un problème dans l'application "machin-2.5" et qu'on lui répond "Ah mais là pour résoudre ça il faut utiliser la libtruc-1.5.0.6a-2 plutôt que la libtruc-1.4.20.3b-8", alors à la limite il veut bien mettre à jour la nouvelle libtruc. Du coup "Machin-2.5" fonctionne. Mais quand quelques jours après il constate que l'appli "bidule-1.7" ne fonctionne plus et qu'on lui dit "Ah oui c'est normal, libtruc-1.5xxx semble incompatible avec bidule-1.7, sans que l'on sache bien pourquoi. Il faut revenir à libtruc-1.4xxx ou antérieur, ou bien mettre à jour bidule-1.7 vers bidule-1.8beta9, mais comme son nom l'indique c'est une version beta et il y peut-être encore des trucs pas stables (mais chez moi ça marche)..."
Là il pète un peu les plombs, l'utilisateur moyen...
-- pehache enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply http://pehache.free.fr/public.html
Nicolas George
"pehache grmpf" , dans le message , a écrit :
C'est une force pour le développeur, ou pour celui qui veut toujours être à la pointe de tout. Pour l'utilisateur final moyen, par contre, ça se discute. Cet utilisateur final préfère la stabilité de son environnement de travail à la disponibilité permanente de nouvelles fonctionnalités.
Rien ne l'oblige à installer les nouvelles versions. S'il veut un environnement de travail fiable, il prend une distribution bien finalisée avec un support sur le long terme, comme Debian stable ou Ubuntu LTS.
"pehache grmpf" , dans le message <51gukqF1jo54aU1@mid.individual.net>,
a écrit :
C'est une force pour le développeur, ou pour celui qui veut toujours être à
la pointe de tout. Pour l'utilisateur final moyen, par contre, ça se
discute. Cet utilisateur final préfère la stabilité de son environnement de
travail à la disponibilité permanente de nouvelles fonctionnalités.
Rien ne l'oblige à installer les nouvelles versions. S'il veut un
environnement de travail fiable, il prend une distribution bien finalisée
avec un support sur le long terme, comme Debian stable ou Ubuntu LTS.
C'est une force pour le développeur, ou pour celui qui veut toujours être à la pointe de tout. Pour l'utilisateur final moyen, par contre, ça se discute. Cet utilisateur final préfère la stabilité de son environnement de travail à la disponibilité permanente de nouvelles fonctionnalités.
Rien ne l'oblige à installer les nouvelles versions. S'il veut un environnement de travail fiable, il prend une distribution bien finalisée avec un support sur le long terme, comme Debian stable ou Ubuntu LTS.
talon
pehache grmpf wrote:
pour ?viter ? l'utilisateur les questions de d?pendances, arguant que 20 Mo de disque, de nos jours, ce n'est rien...
Justement, les d?pendances qui n'en finissent pas sont un des trucs p?nibles que l'on rencontre sous Linux. Du fait aussi de l'?volution rapide et perp?tuelle des diff?rents composants logiciels.
Je suis entièrement d'accord avec ça. D'ailleurs ça explique le succés considérable de PC-BSD dans le monde BSD. Les gros composants sont fournis comme blocs indépendants. http://www.pcbsd.org/
Par ailleurs ce n'est pas parce qu'une appli est link?e statiquement qu'elle est enti?rement charg?e en m?moire au lancement.
Absolument, ça s'appelle la pagination à la demande. D'ailleurs il y a un autre avantage, il n'y a pas besoin de faire des résolutions dynamiques de symboles au chargement, donc les applications démarrent plus vite. Et si on utilise plusieurs copies du programme, il n'y a bien qu'une seule version du segment de texte en mémoire, exactement comme pour les librairies partagées. Le grand gourou (John Dyson) du système de VM de FreeBSD, qui est de loin meilleur que celui de Linux, a toujours maintenu que le linking *statique* était préférable au linking dynamique pour les programmes qui sont beaucoup utilisés et en grand nombre, comme les shells. Evidemment, le prix à payer est que l'on risque d'avoir plusieurs copies des librairies en mémoire et donc il faut envisager d'avoir plus de mémoire pour que ça fonctionne bien. Là encore le prix de la mémoire a baissé de façon dramatique, donc ce n'est pas forcément très grave. En outre quand on utilise des librairies partagées, certes le segment de texte est partagé, mais évidemment pas les données correspondantes, qui peuvent représenter beaucoup plus d'espace. Et enfin dans un système comme les PBI de PC-BSD, de gros programme "self-contained", il n'est pas nécessaire que les programmes soient liés statiques. On peut trés bien avoir un PBI pour KDE qui contient tous les exécutables de KDE et toutes les librairies partagées, et qui peut être remplacé en bloc, sans se préoccuper de ce qui se passe ailleurs.
La situation calamiteuse, c'est ce qu'on rencontre avec des systèmes comme gnome, qui dépendent de librairies partagées dans des systèmes complètement différents, comme mozilla ou firefox. Si on upgrade mozilla, il est fort possible que certains composants de gnome ne marchent plus. Je le sais, ça m'est arrivé. Et pour couronner le tout, les librairies partagées en question sont situées dans un emplacement complètement non standard, tel que /usr/lib/firefox/components/libmozgnome.so ce qui ne facilite pas la sauvegarde. Voilà ce qui se passe quand un système à base de librairies partagées est conçu par des clowns.
pour ?viter ?
l'utilisateur les questions de d?pendances, arguant que 20 Mo de
disque, de nos jours, ce n'est rien...
Justement, les d?pendances qui n'en finissent pas sont un des trucs p?nibles
que l'on rencontre sous Linux. Du fait aussi de l'?volution rapide et
perp?tuelle des diff?rents composants logiciels.
Je suis entièrement d'accord avec ça. D'ailleurs ça explique le succés
considérable de PC-BSD dans le monde BSD. Les gros composants sont
fournis comme blocs indépendants.
http://www.pcbsd.org/
Par ailleurs ce n'est pas parce qu'une appli est link?e statiquement qu'elle
est enti?rement charg?e en m?moire au lancement.
Absolument, ça s'appelle la pagination à la demande. D'ailleurs il y a
un autre avantage, il n'y a pas besoin de faire des résolutions
dynamiques de symboles au chargement, donc les applications démarrent
plus vite. Et si on utilise plusieurs copies du programme, il n'y a bien
qu'une seule version du segment de texte en mémoire, exactement
comme pour les librairies partagées.
Le grand gourou (John Dyson) du système de VM de FreeBSD, qui est de
loin meilleur que celui de Linux, a toujours maintenu que le linking
*statique* était préférable au linking dynamique pour les programmes qui
sont beaucoup utilisés et en grand nombre, comme les shells.
Evidemment, le prix à payer est que l'on risque d'avoir plusieurs copies
des librairies en mémoire et donc il faut envisager d'avoir plus de
mémoire pour que ça fonctionne bien. Là encore le prix de la mémoire a
baissé de façon dramatique, donc ce n'est pas forcément très grave. En
outre quand on utilise des librairies partagées, certes le segment de
texte est partagé, mais évidemment pas les données correspondantes,
qui peuvent représenter beaucoup plus d'espace. Et enfin dans un système
comme les PBI de PC-BSD, de gros programme "self-contained", il n'est pas
nécessaire que les programmes soient liés statiques. On peut trés bien
avoir un PBI pour KDE qui contient tous les exécutables de KDE et toutes
les librairies partagées, et qui peut être remplacé en bloc, sans se
préoccuper de ce qui se passe ailleurs.
La situation calamiteuse, c'est ce qu'on rencontre avec des systèmes
comme gnome, qui dépendent de librairies partagées dans des systèmes
complètement différents, comme mozilla ou firefox. Si on upgrade
mozilla, il est fort possible que certains composants de gnome ne
marchent plus. Je le sais, ça m'est arrivé. Et pour couronner le tout,
les librairies partagées en question sont situées dans un emplacement
complètement non standard, tel que
/usr/lib/firefox/components/libmozgnome.so
ce qui ne facilite pas la sauvegarde. Voilà ce qui se passe quand un
système à base de librairies partagées est conçu par des clowns.
pour ?viter ? l'utilisateur les questions de d?pendances, arguant que 20 Mo de disque, de nos jours, ce n'est rien...
Justement, les d?pendances qui n'en finissent pas sont un des trucs p?nibles que l'on rencontre sous Linux. Du fait aussi de l'?volution rapide et perp?tuelle des diff?rents composants logiciels.
Je suis entièrement d'accord avec ça. D'ailleurs ça explique le succés considérable de PC-BSD dans le monde BSD. Les gros composants sont fournis comme blocs indépendants. http://www.pcbsd.org/
Par ailleurs ce n'est pas parce qu'une appli est link?e statiquement qu'elle est enti?rement charg?e en m?moire au lancement.
Absolument, ça s'appelle la pagination à la demande. D'ailleurs il y a un autre avantage, il n'y a pas besoin de faire des résolutions dynamiques de symboles au chargement, donc les applications démarrent plus vite. Et si on utilise plusieurs copies du programme, il n'y a bien qu'une seule version du segment de texte en mémoire, exactement comme pour les librairies partagées. Le grand gourou (John Dyson) du système de VM de FreeBSD, qui est de loin meilleur que celui de Linux, a toujours maintenu que le linking *statique* était préférable au linking dynamique pour les programmes qui sont beaucoup utilisés et en grand nombre, comme les shells. Evidemment, le prix à payer est que l'on risque d'avoir plusieurs copies des librairies en mémoire et donc il faut envisager d'avoir plus de mémoire pour que ça fonctionne bien. Là encore le prix de la mémoire a baissé de façon dramatique, donc ce n'est pas forcément très grave. En outre quand on utilise des librairies partagées, certes le segment de texte est partagé, mais évidemment pas les données correspondantes, qui peuvent représenter beaucoup plus d'espace. Et enfin dans un système comme les PBI de PC-BSD, de gros programme "self-contained", il n'est pas nécessaire que les programmes soient liés statiques. On peut trés bien avoir un PBI pour KDE qui contient tous les exécutables de KDE et toutes les librairies partagées, et qui peut être remplacé en bloc, sans se préoccuper de ce qui se passe ailleurs.
La situation calamiteuse, c'est ce qu'on rencontre avec des systèmes comme gnome, qui dépendent de librairies partagées dans des systèmes complètement différents, comme mozilla ou firefox. Si on upgrade mozilla, il est fort possible que certains composants de gnome ne marchent plus. Je le sais, ça m'est arrivé. Et pour couronner le tout, les librairies partagées en question sont situées dans un emplacement complètement non standard, tel que /usr/lib/firefox/components/libmozgnome.so ce qui ne facilite pas la sauvegarde. Voilà ce qui se passe quand un système à base de librairies partagées est conçu par des clowns.
--
Michel TALON
Nicolas George
Michel Talon, dans le message <eovnbv$2ivo$, a écrit :
il n'y a pas besoin de faire des résolutions dynamiques de symboles au chargement, donc les applications démarrent
Complètement négligeable par rapport au surcoût de chargement des bibliothèques depuis le disque.
Evidemment, le prix à payer est que l'on risque d'avoir plusieurs copies des librairies en mémoire et donc il faut envisager d'avoir plus de mémoire pour que ça fonctionne bien.
La situation calamiteuse, c'est ce qu'on rencontre avec des systèmes comme gnome, qui dépendent de librairies partagées dans des systèmes complètement différents, comme mozilla ou firefox. Si on upgrade mozilla, il est fort possible que certains composants de gnome ne marchent plus.
C'est pour ça qu'il ne faut jamais upgrader ce genre de gros morceaux autrement qu'avec un système de paquets assurant une vérification de l'intégrité de l'ensemble.
Au fait, tu ne te plaignais pas il y a quelques temps du temps de boot ?
Michel Talon, dans le message <eovnbv$2ivo$2@asmodee.lpthe.jussieu.fr>,
a écrit :
il n'y a pas besoin de faire des résolutions
dynamiques de symboles au chargement, donc les applications démarrent
Complètement négligeable par rapport au surcoût de chargement des
bibliothèques depuis le disque.
Evidemment, le prix à payer est que l'on risque d'avoir plusieurs copies
des librairies en mémoire et donc il faut envisager d'avoir plus de
mémoire pour que ça fonctionne bien.
La situation calamiteuse, c'est ce qu'on rencontre avec des systèmes
comme gnome, qui dépendent de librairies partagées dans des systèmes
complètement différents, comme mozilla ou firefox. Si on upgrade
mozilla, il est fort possible que certains composants de gnome ne
marchent plus.
C'est pour ça qu'il ne faut jamais upgrader ce genre de gros morceaux
autrement qu'avec un système de paquets assurant une vérification de
l'intégrité de l'ensemble.
Au fait, tu ne te plaignais pas il y a quelques temps du temps de boot ?
Michel Talon, dans le message <eovnbv$2ivo$, a écrit :
il n'y a pas besoin de faire des résolutions dynamiques de symboles au chargement, donc les applications démarrent
Complètement négligeable par rapport au surcoût de chargement des bibliothèques depuis le disque.
Evidemment, le prix à payer est que l'on risque d'avoir plusieurs copies des librairies en mémoire et donc il faut envisager d'avoir plus de mémoire pour que ça fonctionne bien.
La situation calamiteuse, c'est ce qu'on rencontre avec des systèmes comme gnome, qui dépendent de librairies partagées dans des systèmes complètement différents, comme mozilla ou firefox. Si on upgrade mozilla, il est fort possible que certains composants de gnome ne marchent plus.
C'est pour ça qu'il ne faut jamais upgrader ce genre de gros morceaux autrement qu'avec un système de paquets assurant une vérification de l'intégrité de l'ensemble.
Au fait, tu ne te plaignais pas il y a quelques temps du temps de boot ?
Jerome Lambert
"Laurent C." , dans le message ,
Mon portable core2duo du boulot charge aussi comme un fou au démarrage au niveau I/O disque surout, le cpu est à 0.
Et après, certains pourtant compétents techniquement viennent nous venter ici les mérites du modèle windows où toutes les applications sont liées statiquement avec leurs bibliothèques, pour éviter à l'utilisateur les questions de dépendances, arguant que 20 Mo de disque, de nos jours, ce n'est rien...
Et ce n'est toujours rien, pas plus que 20Mo de ram à notre époque où la moindre machine neuve en embarque 1Go. Je me pose aussi la question du démarrage: à part pour les mises à jour, je n'éteins *jamais* mes machines, préférant de loin le suspend-to-disk...
"Laurent C." , dans le message <slrner4mtj.3vj.laurent@wks02.chez.oim>,
Mon portable
core2duo du boulot charge aussi comme un fou au démarrage au niveau I/O disque
surout, le cpu est à 0.
Et après, certains pourtant compétents techniquement viennent nous venter
ici les mérites du modèle windows où toutes les applications sont liées
statiquement avec leurs bibliothèques, pour éviter à l'utilisateur les
questions de dépendances, arguant que 20 Mo de disque, de nos jours, ce
n'est rien...
Et ce n'est toujours rien, pas plus que 20Mo de ram à notre époque où la
moindre machine neuve en embarque 1Go. Je me pose aussi la question du
démarrage: à part pour les mises à jour, je n'éteins *jamais* mes
machines, préférant de loin le suspend-to-disk...
Mon portable core2duo du boulot charge aussi comme un fou au démarrage au niveau I/O disque surout, le cpu est à 0.
Et après, certains pourtant compétents techniquement viennent nous venter ici les mérites du modèle windows où toutes les applications sont liées statiquement avec leurs bibliothèques, pour éviter à l'utilisateur les questions de dépendances, arguant que 20 Mo de disque, de nos jours, ce n'est rien...
Et ce n'est toujours rien, pas plus que 20Mo de ram à notre époque où la moindre machine neuve en embarque 1Go. Je me pose aussi la question du démarrage: à part pour les mises à jour, je n'éteins *jamais* mes machines, préférant de loin le suspend-to-disk...
