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
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...
Essayez de comprendre les utilisateurs windows qui essayent Linux et ne peuvent installer le RPM de leur programme parce que lbxbidule.so.1 n'est pas satisfait et que cette librairie est impossible a installer.Forcément ca énerve.
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...
Essayez de comprendre les utilisateurs windows qui essayent Linux et ne
peuvent installer le RPM de leur programme parce que lbxbidule.so.1
n'est pas satisfait et que cette librairie est impossible a
installer.Forcément ca énerve.
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...
Essayez de comprendre les utilisateurs windows qui essayent Linux et ne peuvent installer le RPM de leur programme parce que lbxbidule.so.1 n'est pas satisfait et que cette librairie est impossible a installer.Forcément ca énerve.
Emmanuel Florac
Le Sat, 20 Jan 2007 16:15:55 -0500, Yugo a écrit :
Sauf que tu ne te sers pas Reiserfs pour les données, mais seulement là où ça n'a aucune importance, pour l'OS.
Je suppose que ton OS ne fait pas 16 To? D'autre part, s'il est vrai que Ext3 ne supporte pas plus de 16 To et que XFS a été conçu pour répondre à ces besoins particuliers et peu communs, peut-on prétendre pour autant que Ext3 est pourri, comme tu le fais depuis belle lurette?
Pourri, non, nettement moins performant, oui.
Il est moins vite, soit, mais il est reconnu plus sûr. Et pour les gens en général sur ce groupe, c'est tout ce qui compte.
Chacun voit midi à sa porte. Personnellement j'utilise des ordinateurs outrageusement dépassés, mais pour d'autres usages la performance est importante.
Bien que des recherches soient en cours -- ou aient été faites, puisque le document date de 2005 -- pour rendre Ext3 plus performant, je doute que la fiabilité soit un tant soit peu compromise pour des progrès significatifs en termes de rapidité.
Dans les benchmarks cités par les dévs d'ext4 dans Linux mag de ce mois, les performances affichées d'ext2/3/4 sont énormément supérieures à tous les autres FS dans tous les cas de figure. Je suis parfaitement prêt à croire qu'il y ait eu des améliorations notables, et même qu'ext3/4 soit désormais plus rapide que les autres, mais je ne crois pas à la magie : xfs ayant une courbe de performance qui colle au plus près le matériel sous-jacent, il n'y a tout simplement pas moyen d'aller beaucoup plus vite que lui (mais très légèrement, c'est possible).
Quant à la question de la fiabilité, j'y réfléchirai. Cependant je ne peux pas dire avoir rencontré de nombreux problèmes avec xfs (en tout et pour tout, 1 seul, en fait), sur environ 500 machines et sur environ 3 ans.
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Le Sat, 20 Jan 2007 16:15:55 -0500, Yugo a écrit :
Sauf que tu ne te sers pas Reiserfs pour les données, mais seulement là
où ça n'a aucune importance, pour l'OS.
Je suppose que ton OS ne fait pas 16 To? D'autre part, s'il est vrai que
Ext3 ne supporte pas plus de 16 To et que XFS a été conçu pour
répondre à ces besoins particuliers et peu communs, peut-on prétendre
pour autant que Ext3 est pourri, comme tu le fais depuis belle lurette?
Pourri, non, nettement moins performant, oui.
Il
est moins vite, soit, mais il est reconnu plus sûr. Et pour les gens en
général sur ce groupe, c'est tout ce qui compte.
Chacun voit midi à sa porte. Personnellement j'utilise des ordinateurs
outrageusement dépassés, mais pour d'autres usages la performance est
importante.
Bien que des recherches soient en cours -- ou aient été faites, puisque
le document date de 2005 -- pour rendre Ext3 plus performant, je doute que
la fiabilité soit un tant soit peu compromise pour des progrès
significatifs en termes de rapidité.
Dans les benchmarks cités par les dévs d'ext4 dans Linux mag de ce mois,
les performances affichées d'ext2/3/4 sont énormément supérieures à
tous les autres FS dans tous les cas de figure. Je suis parfaitement prêt
à croire qu'il y ait eu des améliorations notables, et même qu'ext3/4
soit désormais plus rapide que les autres, mais je ne crois pas à la
magie : xfs ayant une courbe de performance qui colle au plus près le
matériel sous-jacent, il n'y a tout simplement pas moyen d'aller beaucoup
plus vite que lui (mais très légèrement, c'est possible).
Quant à la question de la fiabilité, j'y réfléchirai. Cependant je ne
peux pas dire avoir rencontré de nombreux problèmes avec xfs (en tout et
pour tout, 1 seul, en fait), sur environ 500 machines et sur environ 3 ans.
--
Il y a toujours un bug de plus.
Loi de Lubarsky.
Le Sat, 20 Jan 2007 16:15:55 -0500, Yugo a écrit :
Sauf que tu ne te sers pas Reiserfs pour les données, mais seulement là où ça n'a aucune importance, pour l'OS.
Je suppose que ton OS ne fait pas 16 To? D'autre part, s'il est vrai que Ext3 ne supporte pas plus de 16 To et que XFS a été conçu pour répondre à ces besoins particuliers et peu communs, peut-on prétendre pour autant que Ext3 est pourri, comme tu le fais depuis belle lurette?
Pourri, non, nettement moins performant, oui.
Il est moins vite, soit, mais il est reconnu plus sûr. Et pour les gens en général sur ce groupe, c'est tout ce qui compte.
Chacun voit midi à sa porte. Personnellement j'utilise des ordinateurs outrageusement dépassés, mais pour d'autres usages la performance est importante.
Bien que des recherches soient en cours -- ou aient été faites, puisque le document date de 2005 -- pour rendre Ext3 plus performant, je doute que la fiabilité soit un tant soit peu compromise pour des progrès significatifs en termes de rapidité.
Dans les benchmarks cités par les dévs d'ext4 dans Linux mag de ce mois, les performances affichées d'ext2/3/4 sont énormément supérieures à tous les autres FS dans tous les cas de figure. Je suis parfaitement prêt à croire qu'il y ait eu des améliorations notables, et même qu'ext3/4 soit désormais plus rapide que les autres, mais je ne crois pas à la magie : xfs ayant une courbe de performance qui colle au plus près le matériel sous-jacent, il n'y a tout simplement pas moyen d'aller beaucoup plus vite que lui (mais très légèrement, c'est possible).
Quant à la question de la fiabilité, j'y réfléchirai. Cependant je ne peux pas dire avoir rencontré de nombreux problèmes avec xfs (en tout et pour tout, 1 seul, en fait), sur environ 500 machines et sur environ 3 ans.
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Emmanuel Florac
Le Sat, 20 Jan 2007 22:08:21 +0000, Miod Vallat a écrit :
D'un autre côté, vu comment on en est toujours à chercher des raisons valables à Sylpheed d'exister («pourrir la vie des gens» n'en est pas une), ce n'est peut-être pas plus mal.
Arf :) Qu'est ce qu'il a de si moche, Sylpheed ?
Au fait, tu seras au salon sur le stand OpenBSD ?
-- Writing about music is like dancing about architecture. Frank Zappa
Le Sat, 20 Jan 2007 22:08:21 +0000, Miod Vallat a écrit :
D'un autre côté, vu comment on en est toujours à chercher des raisons
valables à Sylpheed d'exister («pourrir la vie des gens» n'en est pas
une), ce n'est peut-être pas plus mal.
Arf :) Qu'est ce qu'il a de si moche, Sylpheed ?
Au fait, tu seras au salon sur le stand OpenBSD ?
--
Writing about music is like dancing about architecture.
Frank Zappa
Le Sat, 20 Jan 2007 22:08:21 +0000, Miod Vallat a écrit :
D'un autre côté, vu comment on en est toujours à chercher des raisons valables à Sylpheed d'exister («pourrir la vie des gens» n'en est pas une), ce n'est peut-être pas plus mal.
Arf :) Qu'est ce qu'il a de si moche, Sylpheed ?
Au fait, tu seras au salon sur le stand OpenBSD ?
-- Writing about music is like dancing about architecture. Frank Zappa
Nicolas George
Raphael Durand , dans le message <45b36ed8$0$21142$, a écrit :
Essayez de comprendre les utilisateurs windows qui essayent Linux
'M'en fous. J'ai fait l'investissement d'apprendre un système qui marche bien, et cet investissement est amplement rentabilisé par le temps que j'y ai gagné, et l'énervement que j'ai évité.
Si d'autres n'ont pas l'intelligence de voir l'intérêt d'un tel investissement, tant pis pour eux.
Raphael Durand , dans le message
<45b36ed8$0$21142$7a628cd7@news.club-internet.fr>, a écrit :
Essayez de comprendre les utilisateurs windows qui essayent Linux
'M'en fous. J'ai fait l'investissement d'apprendre un système qui marche
bien, et cet investissement est amplement rentabilisé par le temps que j'y
ai gagné, et l'énervement que j'ai évité.
Si d'autres n'ont pas l'intelligence de voir l'intérêt d'un tel
investissement, tant pis pour eux.
Raphael Durand , dans le message <45b36ed8$0$21142$, a écrit :
Essayez de comprendre les utilisateurs windows qui essayent Linux
'M'en fous. J'ai fait l'investissement d'apprendre un système qui marche bien, et cet investissement est amplement rentabilisé par le temps que j'y ai gagné, et l'énervement que j'ai évité.
Si d'autres n'ont pas l'intelligence de voir l'intérêt d'un tel investissement, tant pis pour eux.
Nicolas George
Jerome Lambert , dans le message , a écrit :
Et ce n'est toujours rien, pas plus que 20Mo de ram à notre époque où la moindre machine neuve en embarque 1Go.
Ça représente néanmoins une seconde de chargement depuis le disque dans les bons cas, à multiplier par le nombre d'applications.
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...
Même avec du suspend, tout ce que tu utilises ne peut pas toujours être dans le cache.
Jerome Lambert , dans le message <51h90nF1je6luU1@mid.individual.net>, a
écrit :
Et ce n'est toujours rien, pas plus que 20Mo de ram à notre époque où la
moindre machine neuve en embarque 1Go.
Ça représente néanmoins une seconde de chargement depuis le disque dans les
bons cas, à multiplier par le nombre d'applications.
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...
Même avec du suspend, tout ce que tu utilises ne peut pas toujours être dans
le cache.
Et ce n'est toujours rien, pas plus que 20Mo de ram à notre époque où la moindre machine neuve en embarque 1Go.
Ça représente néanmoins une seconde de chargement depuis le disque dans les bons cas, à multiplier par le nombre d'applications.
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...
Même avec du suspend, tout ce que tu utilises ne peut pas toujours être dans le cache.
Miod Vallat
D'un autre côté, vu comment on en est toujours à chercher des raisons valables à Sylpheed d'exister («pourrir la vie des gens» n'en est pas une), ce n'est peut-être pas plus mal.
Arf :) Qu'est ce qu'il a de si moche, Sylpheed ?
Par exemple, proposer des réglages par défaut stupides, puis persister à les utiliser même quand l'utilisateur les a modifiés.
Au fait, tu seras au salon sur le stand OpenBSD ?
Il n'y a pas de stand BSD à ce salon cette année.
D'un autre côté, vu comment on en est toujours à chercher des raisons
valables à Sylpheed d'exister («pourrir la vie des gens» n'en est pas
une), ce n'est peut-être pas plus mal.
Arf :) Qu'est ce qu'il a de si moche, Sylpheed ?
Par exemple, proposer des réglages par défaut stupides, puis persister à
les utiliser même quand l'utilisateur les a modifiés.
D'un autre côté, vu comment on en est toujours à chercher des raisons valables à Sylpheed d'exister («pourrir la vie des gens» n'en est pas une), ce n'est peut-être pas plus mal.
Arf :) Qu'est ce qu'il a de si moche, Sylpheed ?
Par exemple, proposer des réglages par défaut stupides, puis persister à les utiliser même quand l'utilisateur les a modifiés.
Au fait, tu seras au salon sur le stand OpenBSD ?
Il n'y a pas de stand BSD à ce salon cette année.
Jerome Lambert
Jerome Lambert , dans le message , a
Et ce n'est toujours rien, pas plus que 20Mo de ram à notre époque où la moindre machine neuve en embarque 1Go.
Ça représente néanmoins une seconde de chargement depuis le disque dans les bons cas, à multiplier par le nombre d'applications.
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...
Même avec du suspend, tout ce que tu utilises ne peut pas toujours être dans le cache.
Bof: je laisse toujours les applications actives, sans document ouvert quand je ne travaille pas avec elles, donc elles sont (quasi) constamment en ram, et au réveil tout est directement opérationnel, en tout cas bien plus rapidement que si je devais tout fermer, éteindre, démarrer et tout relancer.
Jerome Lambert , dans le message <51h90nF1je6luU1@mid.individual.net>, a
Et ce n'est toujours rien, pas plus que 20Mo de ram à notre époque où la
moindre machine neuve en embarque 1Go.
Ça représente néanmoins une seconde de chargement depuis le disque dans les
bons cas, à multiplier par le nombre d'applications.
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...
Même avec du suspend, tout ce que tu utilises ne peut pas toujours être dans
le cache.
Bof: je laisse toujours les applications actives, sans document ouvert
quand je ne travaille pas avec elles, donc elles sont (quasi)
constamment en ram, et au réveil tout est directement opérationnel, en
tout cas bien plus rapidement que si je devais tout fermer, éteindre,
démarrer et tout relancer.
Et ce n'est toujours rien, pas plus que 20Mo de ram à notre époque où la moindre machine neuve en embarque 1Go.
Ça représente néanmoins une seconde de chargement depuis le disque dans les bons cas, à multiplier par le nombre d'applications.
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...
Même avec du suspend, tout ce que tu utilises ne peut pas toujours être dans le cache.
Bof: je laisse toujours les applications actives, sans document ouvert quand je ne travaille pas avec elles, donc elles sont (quasi) constamment en ram, et au réveil tout est directement opérationnel, en tout cas bien plus rapidement que si je devais tout fermer, éteindre, démarrer et tout relancer.
Emmanuel Florac
Le Sun, 21 Jan 2007 14:32:00 +0000, Miod Vallat a écrit :
Par exemple, proposer des réglages par défaut stupides, puis persister à les utiliser même quand l'utilisateur les a modifiés.
mmmh, d'accord. C'esdt pour ça que j'utilise Claws alors :)
Il n'y a pas de stand BSD à ce salon cette année.
Rhôôô mais comment ça se fait ?
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Le Sun, 21 Jan 2007 14:32:00 +0000, Miod Vallat a écrit :
Par exemple, proposer des réglages par défaut stupides, puis persister
à les utiliser même quand l'utilisateur les a modifiés.
mmmh, d'accord. C'esdt pour ça que j'utilise Claws alors :)
Il n'y a pas de stand BSD à ce salon cette année.
Rhôôô mais comment ça se fait ?
--
Le commissaire : Comment vous appelez-vous?
Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas
besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut
vous intéresser.
Prévert,"les enfants du Paradis".
Le Sun, 21 Jan 2007 14:32:00 +0000, Miod Vallat a écrit :
Par exemple, proposer des réglages par défaut stupides, puis persister à les utiliser même quand l'utilisateur les a modifiés.
mmmh, d'accord. C'esdt pour ça que j'utilise Claws alors :)
Il n'y a pas de stand BSD à ce salon cette année.
Rhôôô mais comment ça se fait ?
-- Le commissaire : Comment vous appelez-vous? Garance : Moi je ne m'appelle jamais, je suis toujours là. J'ai pas besoin de m'appeler. Mais les autres m'appellent Garance, si ça peut vous intéresser. Prévert,"les enfants du Paradis".
Nicolas George
Jerome Lambert , dans le message , a écrit :
tout cas bien plus rapidement que si je devais tout fermer, éteindre, démarrer et tout relancer.
Non pertinent : on n'est pas en train de comparer les mérites respectifs de la veille et de l'extinction.
Avec ou sans veille, un ordinateur est plus réactif quand les applications utilisent moins de mémoire. C'est une telle évidence que je ne comprends pas comment des gens comme Michel ou toi peuvent ne pas la voir.
Jerome Lambert , dans le message <51hbr3F1k47eqU1@mid.individual.net>, a
écrit :
tout cas bien plus rapidement que si je devais tout fermer, éteindre,
démarrer et tout relancer.
Non pertinent : on n'est pas en train de comparer les mérites respectifs de
la veille et de l'extinction.
Avec ou sans veille, un ordinateur est plus réactif quand les applications
utilisent moins de mémoire. C'est une telle évidence que je ne comprends pas
comment des gens comme Michel ou toi peuvent ne pas la voir.
tout cas bien plus rapidement que si je devais tout fermer, éteindre, démarrer et tout relancer.
Non pertinent : on n'est pas en train de comparer les mérites respectifs de la veille et de l'extinction.
Avec ou sans veille, un ordinateur est plus réactif quand les applications utilisent moins de mémoire. C'est une telle évidence que je ne comprends pas comment des gens comme Michel ou toi peuvent ne pas la voir.
talon
Nicolas George <nicolas$ wrote:
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.
Totalement faux. Un disque peut débiter 40 Mo/s, donc en une seconde amener toutes les librairies partagées de KDE en mémoire. Par contre la résolution dynamique des symboles prend plus de temps. C'est la cause *majeure* de la lenteur de démarrage des applications KDE, dont certaines prenaient plusieurs secondes à démarrer quand les machines étaient moins puissantes. John Dyson avait fait des benchmarks se scripts "configure" qui lancent une grande quantité de shells, il y avait des différences tout à fait significatives sur le temps total d'exécution entre shell statique et dynamique.
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.
Ce qui est une catastrophe, parceque ça implique qu'on se trouve nécessairement lié à une "distribution", c'est à dire une grosse organisation. Dans le monde Linux il n'y a que Debian qui a les moyens en homme suffisants pour vérifier cette cohérence d'ensemble, les dérivés, comme Ubuntu profitant du millier de développeurs Debian. Et encore avec son millier de développeurs, ce système paralyse totalement Debian. Des systèmes moins bien dotés, comme FreeBSD n'ont pas les moyens de faire les vérifications extensives nécessaires.
Au fait, tu ne te plaignais pas il y a quelques temps du temps de boot ?
Depuis Ubuntu Edgy, je ne me plains plus du temps de boot sous Linux. Sous FreeBSD il est grosso modo similaire. Windows boote plus vite, mais tout n'est pas fonctionnel loin de là quand le "desktop" apparaît.
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
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.
Totalement faux. Un disque peut débiter 40 Mo/s, donc en une seconde
amener toutes les librairies partagées de KDE en mémoire. Par contre la
résolution dynamique des symboles prend plus de temps. C'est la
cause *majeure* de la lenteur de démarrage des applications KDE, dont
certaines prenaient plusieurs secondes à démarrer quand les machines
étaient moins puissantes. John Dyson avait fait des benchmarks se
scripts "configure" qui lancent une grande quantité de shells, il y
avait des différences tout à fait significatives sur le temps total
d'exécution entre shell statique et dynamique.
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.
Ce qui est une catastrophe, parceque ça implique qu'on se trouve
nécessairement lié à une "distribution", c'est à dire une grosse
organisation. Dans le monde Linux il n'y a que Debian qui a les moyens
en homme suffisants pour vérifier cette cohérence d'ensemble, les
dérivés, comme Ubuntu profitant du millier de développeurs Debian.
Et encore avec son millier de développeurs, ce système paralyse
totalement Debian. Des systèmes moins bien dotés, comme FreeBSD n'ont
pas les moyens de faire les vérifications extensives nécessaires.
Au fait, tu ne te plaignais pas il y a quelques temps du temps de boot ?
Depuis Ubuntu Edgy, je ne me plains plus du temps de boot sous Linux.
Sous FreeBSD il est grosso modo similaire. Windows boote plus vite, mais
tout n'est pas fonctionnel loin de là quand le "desktop" apparaît.
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.
Totalement faux. Un disque peut débiter 40 Mo/s, donc en une seconde amener toutes les librairies partagées de KDE en mémoire. Par contre la résolution dynamique des symboles prend plus de temps. C'est la cause *majeure* de la lenteur de démarrage des applications KDE, dont certaines prenaient plusieurs secondes à démarrer quand les machines étaient moins puissantes. John Dyson avait fait des benchmarks se scripts "configure" qui lancent une grande quantité de shells, il y avait des différences tout à fait significatives sur le temps total d'exécution entre shell statique et dynamique.
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.
Ce qui est une catastrophe, parceque ça implique qu'on se trouve nécessairement lié à une "distribution", c'est à dire une grosse organisation. Dans le monde Linux il n'y a que Debian qui a les moyens en homme suffisants pour vérifier cette cohérence d'ensemble, les dérivés, comme Ubuntu profitant du millier de développeurs Debian. Et encore avec son millier de développeurs, ce système paralyse totalement Debian. Des systèmes moins bien dotés, comme FreeBSD n'ont pas les moyens de faire les vérifications extensives nécessaires.
Au fait, tu ne te plaignais pas il y a quelques temps du temps de boot ?
Depuis Ubuntu Edgy, je ne me plains plus du temps de boot sous Linux. Sous FreeBSD il est grosso modo similaire. Windows boote plus vite, mais tout n'est pas fonctionnel loin de là quand le "desktop" apparaît.
