1. Hdparm ne donne que les performances du disque en début de disque (chez
moi, ça donne 60 MB/sec).
2. En fin de disque, il faut +/- diviser les performances par 2 (chez moi : 32 MB/sec).
3. Tu parles de copies (c'est à dire lecture+écriture). Je suppose qu'il s'agit de copies "mono-disque". Je fais fais souvent des copies mais jamais en mono-disque : c'est bien trop lent. J'ai déjà pu constater que des copies de disque à disque (chez moi sur deux controlleurs ide différent) vont (parfois) 8x plus vite que des copies mono-disque (et ça fait nettement moins de bruit).
4. Tu dis que tu "flirtes" avec moins d'1MB de libre : au prix du GB actuel, on
peut appeler cela de la gourmandise (tu aimes le risque ... un peu trop sans
doute).
5. Oui, il y a de la fragmentation sous Linux (quelques % chez tout le monde, sauf chez toi). Non, on ne passe pas son temps à défragmenter son FS (on le
calibre à ses besoins).
6. Achète-toi un disque externe usb (ou comme moi, récupère un disque IDE
qu'on peut placer dans un container usb) : ça coûte pas cher et ça évite des
trolleries.
J'attends avec impatience ton comparatif sur "quelques" distributions Linux
et Windows XP (et aussi Vista ?) : ça va troller sec !
PS: prends un peu de recul et n'oublie pas aussi les macs, les freebsd, ...
Les avertissements (imposés) sur le tabac permettent plusieurs choses :
- ne pas encourager à fumer : ça, c'est raté.
- disculper les fabricants de cigarettes. Plus moyen de se lancer dans un procès
fleuve contre les fabricants puisqu'on est averti (donc, ces avertissements
servent AUSSI aux fabricants).
- un paquet de cloppes, c'est tout petit. Chez moi, les avertissements sont en
3 langues (fr, de, nl). Donc plus de place pour aussi indiquer "contient aussi des
ogms ou ne contient pas d'ogms". Il y a beaucoup d'additifs dans une cloppe :
mieux vaut ne pas trop savoir quoi (ogm ou pas).
Je sens bien qu'il y a un léger rapport entre Linux et les (détracteurs des) ogms mais
faut quand-même pas tout mettre dans le même panier.
- quand on arrive sur ce site depuis la page francophone du portail
fédéral belge, on tombe sur la version en néerlandais.
- si on a le maleur de démarrer le surf en flash, on n'a droit qu'au
quart gauche de l'écran.
- une fois qu'on a compris ce que signifie "Blindsurfer-versie",
il faut aller tout en bas de la page par enfin sélectionner :
"Naar frans versie" et là, ouf, on revient en français.
- le contenu est très incomplet et imprécis (il n'y a pas de juristes
au gouvernement fédéral ?).
Ce qui m'intéresse ici, ce sont les différentes listes de sociétés
(des "partenaires") qui y sont référencées (soit à l'intérieur du texte
soit dans le catalogue "dealers") :
1. Comment est-ce possible de produire un site d'aussi piètre qualité
si on dispose de tant de partenaires ?
2. Au fond, que viennent faire ces dealers sur un site du gouvernement
belge ? Ont-ils payé pour se retrouver là ? Le gouvernement belge
a-t-il payé pour les y mettre ? Mystère. Notons que tout est possible
en Belgique puisque les deniers publics sont bien utilisés pour
remplir les poches de Bernie Ecclestone (le grand patron de la F1).
Etant donné le sujet (qui tourne grosso-modo sur les aspects sécurité
des systèmes informatiques), que vont penser les braves "moutons (?)" de
belges qui ne savent pas lire entre les lignes : "Ah! Mon dealer habituel
n'est pas dans la liste, donc je dois changer de dealer et aller vers
un qui se trouve sur la liste". Cette liste (de même que les inserts
publicitaires pour divers produits ou sociétés) est qualifiable d'abus
de bien sociaux (on utilise les deniers publics pour enrichir des sociétés
privées en leur faissant de la publicité) comme pour notre cher GP de F1.
Pour moi, ce site est tout simplement illégal et il devrait être supprimé.
Ce site montre aussi que le pouvoir fédéral belge a une vision très
biaisée et très incomplète de l'informatique actuelle. Ce qui en fait
une proie facile pour tous les grands vautours du domaine.
La première transformation est évidente : miroir plus simple permuation
de couleurs. Bon le résultat n'est pas parfait (ça dû être fait sous
Windows à la va-vite).
La deuxième transformation est plus subtile : on part du point rouge
sur le i de debian, on fait une rotation de 45° puis un gros zoom et
on obtient le sac en plastique rouge.
Ca serait marrant de se balader dans le super marché Atac de
Strasbourg habillé avec son tee-shirt debian. Les clients vont-ils
nous prendre pour des membres du personnel ? "Pardon,
Monsieur, le rayon des salades ?". "Juste derrière les revues
Linux mag, ma chère madame".
<<< Dans le monde du Libre, deux comportements sont fréquents parmi les développeurs :
- Les hardcore programmers : "Je peux écrire 1000 lignes de code d'un seul jet, et ça marche direct. Les tests, c'est pour les losers qui savent pas coder."
- Les extrémistes du modèle de développement Open Source : "Des tests ? Pour quoi faire ? C'est mes utilisateurs qui les font !" >>>
D'où viennent ces « statistiques » qui semblent improvisées ? Le monde de l'open-source ne contient pas que des « hardcore programmers » ni des extrémistes de quoique ce soit. Il
y a aussi tout plein de gens sérieux capables non seulement de faire des tests unitaires, mais
aussi des tests de performances, de vérifier que ce qu'on produit n'a déjà pas été fait par quelqu'un d'autre, de vérifier qu'on respecte bien certaines règles (notamment en matière de brevets), etc.
<<< Comme pour la documentation, on touche ici à une des limites du Logiciel Libre : les développeurs sont pour une grande majorité bénévoles, et ne veulent pas s'embêter avec tout ce qui n'est pas fun : documentation, tests, ... >>>
C'est vrai qu'un développeur peut avoir tendance à négliger de documenter correctement son
travail. Mais c'est cela n'a rien à voir avec l'open-source (c'est tout aussi vrai pour des logiciels
propriétaires). En ce qui concerne la documentation en général des produits open-source,
celle-ci existe et est même très bien réalisée. Prenons un exemple : la distribution Knoppix.
Il existe des ouvrages très bien faits sur le sujet. Donc la documentation ne manque pas.
Mieux : celle-ci est réalisée par des documentalistes indépendants du produit (c'est un gage
de qualité).
<<< Dans le monde propriétaire, les méthodes de développement intègrent les tests au développement du logiciel. eXtreme Programming (XP), par exemple, prône l'utilisation intensive de tests, et notamment de tests unitaires. XP recommande même d'écrire les tests avant le code à tester. >>>
L'extreme programming n'a rien à voir avec le monde propriétaire. Cette technique peut
très bien s'appliquer en tout en en partie à n'importe quel produit de dévéloppement, qu'il
soit open-source ou pas.
<<< Mais la plupart des logiciels libres ignorent totalement cette démarche, et se basent sur une démarche qualité incomplète basée sur des Bug Tracking Systems ou Bugzillas : les bugs remontés ainsi sont en général les bugs les plus apparents, mais un bug bien enfoui peut rester non corrigé pendant des lustres. Ce bug très gênant de gconfd est un bon exemple : un bug dans un algorithme de gestion d'arbre présent depuis GNOME 2.0 (juin 2002), signalé fin septembre 2004, corrigé début février. >>>
Les techniques de bug tracking sont utilisées par tout le monde (aussi bien open-source
que propriétaire). Même si, comme vous semblez le prétendre, certains bugs mettent trop
de temps à être corrigés, il ne faut pas en faire une généralité. Certains éditeurs de logiciels
propiétaires permettent de faire remonter les bugs rencontrés. Hélas, on n'a jamais de suivi
de ces bugs ni de leur correction éventuelle.
<<< Et même si un développeur de Logiciels Libres voulait tester son code, avec quoi le ferait-il ? Les ateliers de test libres sont rares (je ne connais que DejaGNU) et peu utilisés, sauf pour quelques projets plutôt faciles à tester (Binutils, Coreutils, Glibc, GCC, uclibc ...). Du côté des langages de script, c'est un peu mieux : beaucoup de programmes Perl sont livrés avec une suite de test et Python a PyUnit (mais est-ce vraiment utilisé par les développeurs ?). Ruby, langage pour XP par excellence, se démarque : l'interpréteur est testé par le rubicon (un vrai jeu de mots d'informaticiens au passage : Ruby doit passer le Rubicon...), et les tests unitaires sont largement utilisés par les développeurs. >>>
Les tests unitaires peuvent être utiles mais sont bien loin d'être toujours efficaces voire
nécessaires. C'est clair, si on part du principe que les développeurs open-source ne sont
capables que de pondre 1000 lignes de code d'une traite sans tester, on doit se poser
quelques questions (à mon avis faire des tests unitaires sur 1000 lignes de code, ça ne
sert pas à grand chose). Par contre, les tests d'intégration (quand il faut assembler les
différentes briques d'un produit), c'est tout à fait autre chose : dans ce cas, même si
les tests unitaires répondent OK, en général, c'est au moment de l'intégration que tout
s'écroule.
<<< Alors que les logiciels propriétaires populaires deviennent de plus en plus robustes (loin est le temps où Windows plantait sans arrêt), il est important d'augmenter la qualité des Logiciels Libres. Cela passe par l'utilisation massive de techniques ayant fait leurs preuves dans l'industrie, mais mal maîtrisées dans la communauté. >>>
Ca m'intéresse de savoir d'où vous tenez ce genre d'information. Expliquez-moi pourquoi
des logiciels propriétaires sont devenus plus robustes. J'ai reçu, il y a 6 mois, une lettre
de ma banque me demandant de ne plus utiliser Internet Explorer mais d'utiliser plutôt
Mozilla ou Opera. Contrairement à ce que vous semblez souligner, les logiciels libres sont
bels et bien utilisés dans le monde industriel (et avec des méthodologies adéquates comme
par exemple Rup). L'open source a vielli, il a mûri et il devient tout à fait fréquentable.
<<< On peut aussi se poser une question plus profonde : Alors qu'avec Perl, Python, Ruby et C#, nous avons des langages permettant de développer efficacement des applications de haut-niveau, pourquoi continuer à développer majoritairement en C/C++, avec lesquels il est nettement plus facile d'introduire des bugs ? Pourquoi ne pas limiter l'utilisation de ces langages aux librairies ? >>>
Chaque langage de programmation a sa spécificité. La facilité qu'on a d'introduire un bug
dans un produit ne dépend pas du langage choisi : un développeur conciencieux en C n'a rien
à voir avec un développeur débutant en Java. L'open source est une bénédiction dans le
sens où elle ne limite pas les choix des développeurs (par exemple : rien que le C pour des « librairies » ) car cela crée un terrain favorable à l'interopérabilité.
<<< Qu'en pensez-vous ? Testez-vous vos applications ? Avec quoi ? >>>
Le monde open-source n'est pas fait que de « hardcore » développeurs ni d'extrémistes
de tout poil ne désirant rien tester : le monde open-source se dirige à grands pas vers un monde professionnel ouvert : voilà le vrai changement.
# hdparm+copie
Posté par Guy Thiry . En réponse au journal Fait n°1 : Linux n'est pas sujet à la fragmentation.... Évalué à 3.
moi, ça donne 60 MB/sec).
2. En fin de disque, il faut +/- diviser les performances par 2 (chez moi : 32 MB/sec).
3. Tu parles de copies (c'est à dire lecture+écriture). Je suppose qu'il s'agit de copies "mono-disque". Je fais fais souvent des copies mais jamais en mono-disque : c'est bien trop lent. J'ai déjà pu constater que des copies de disque à disque (chez moi sur deux controlleurs ide différent) vont (parfois) 8x plus vite que des copies mono-disque (et ça fait nettement moins de bruit).
4. Tu dis que tu "flirtes" avec moins d'1MB de libre : au prix du GB actuel, on
peut appeler cela de la gourmandise (tu aimes le risque ... un peu trop sans
doute).
5. Oui, il y a de la fragmentation sous Linux (quelques % chez tout le monde, sauf chez toi). Non, on ne passe pas son temps à défragmenter son FS (on le
calibre à ses besoins).
6. Achète-toi un disque externe usb (ou comme moi, récupère un disque IDE
qu'on peut placer dans un container usb) : ça coûte pas cher et ça évite des
trolleries.
J'attends avec impatience ton comparatif sur "quelques" distributions Linux
et Windows XP (et aussi Vista ?) : ça va troller sec !
PS: prends un peu de recul et n'oublie pas aussi les macs, les freebsd, ...
[^] # Re: Ah oué ...
Posté par Guy Thiry . En réponse au journal Pas d'OGM dans les assiettes. Évalué à 2.
- ne pas encourager à fumer : ça, c'est raté.
- disculper les fabricants de cigarettes. Plus moyen de se lancer dans un procès
fleuve contre les fabricants puisqu'on est averti (donc, ces avertissements
servent AUSSI aux fabricants).
- un paquet de cloppes, c'est tout petit. Chez moi, les avertissements sont en
3 langues (fr, de, nl). Donc plus de place pour aussi indiquer "contient aussi des
ogms ou ne contient pas d'ogms". Il y a beaucoup d'additifs dans une cloppe :
mieux vaut ne pas trop savoir quoi (ogm ou pas).
Je sens bien qu'il y a un léger rapport entre Linux et les (détracteurs des) ogms mais
faut quand-même pas tout mettre dans le même panier.
# Francorchamps++
Posté par Guy Thiry . En réponse à la dépêche Réactions au site pecephobie.be. Évalué à 4.
Il est mal construit :
- quand on arrive sur ce site depuis la page francophone du portail
fédéral belge, on tombe sur la version en néerlandais.
- si on a le maleur de démarrer le surf en flash, on n'a droit qu'au
quart gauche de l'écran.
- une fois qu'on a compris ce que signifie "Blindsurfer-versie",
il faut aller tout en bas de la page par enfin sélectionner :
"Naar frans versie" et là, ouf, on revient en français.
- le contenu est très incomplet et imprécis (il n'y a pas de juristes
au gouvernement fédéral ?).
Ce qui m'intéresse ici, ce sont les différentes listes de sociétés
(des "partenaires") qui y sont référencées (soit à l'intérieur du texte
soit dans le catalogue "dealers") :
1. Comment est-ce possible de produire un site d'aussi piètre qualité
si on dispose de tant de partenaires ?
2. Au fond, que viennent faire ces dealers sur un site du gouvernement
belge ? Ont-ils payé pour se retrouver là ? Le gouvernement belge
a-t-il payé pour les y mettre ? Mystère. Notons que tout est possible
en Belgique puisque les deniers publics sont bien utilisés pour
remplir les poches de Bernie Ecclestone (le grand patron de la F1).
Etant donné le sujet (qui tourne grosso-modo sur les aspects sécurité
des systèmes informatiques), que vont penser les braves "moutons (?)" de
belges qui ne savent pas lire entre les lignes : "Ah! Mon dealer habituel
n'est pas dans la liste, donc je dois changer de dealer et aller vers
un qui se trouve sur la liste". Cette liste (de même que les inserts
publicitaires pour divers produits ou sociétés) est qualifiable d'abus
de bien sociaux (on utilise les deniers publics pour enrichir des sociétés
privées en leur faissant de la publicité) comme pour notre cher GP de F1.
Pour moi, ce site est tout simplement illégal et il devrait être supprimé.
Ce site montre aussi que le pouvoir fédéral belge a une vision très
biaisée et très incomplète de l'informatique actuelle. Ce qui en fait
une proie facile pour tous les grands vautours du domaine.
Rideau.
# deux transformations mathématiques
Posté par Guy Thiry . En réponse au journal La prochaine Debian "grande distribution"?. Évalué à 6.
de couleurs. Bon le résultat n'est pas parfait (ça dû être fait sous
Windows à la va-vite).
La deuxième transformation est plus subtile : on part du point rouge
sur le i de debian, on fait une rotation de 45° puis un gros zoom et
on obtient le sac en plastique rouge.
Ca serait marrant de se balader dans le super marché Atac de
Strasbourg habillé avec son tee-shirt debian. Les clients vont-ils
nous prendre pour des membres du personnel ? "Pardon,
Monsieur, le rayon des salades ?". "Juste derrière les revues
Linux mag, ma chère madame".
[^] # Re: ...
Posté par Guy Thiry . En réponse au journal Ne m'appelez plus jamais Wi-Fi. Évalué à 3.
spam mais quand-même bien explicite.
[^] # Re: Quels comiques !
Posté par Guy Thiry . En réponse au journal Ne m'appelez plus jamais Wi-Fi. Évalué à 5.
Pour le WI-FI (pardon, l'ASFI) sans internet, c'est facile, ça devient l'ASF.
# Je ne suis pas d'accord
Posté par Guy Thiry . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 8.
- Les hardcore programmers : "Je peux écrire 1000 lignes de code d'un seul jet, et ça marche direct. Les tests, c'est pour les losers qui savent pas coder."
- Les extrémistes du modèle de développement Open Source : "Des tests ? Pour quoi faire ? C'est mes utilisateurs qui les font !" >>>
D'où viennent ces « statistiques » qui semblent improvisées ? Le monde de l'open-source ne contient pas que des « hardcore programmers » ni des extrémistes de quoique ce soit. Il
y a aussi tout plein de gens sérieux capables non seulement de faire des tests unitaires, mais
aussi des tests de performances, de vérifier que ce qu'on produit n'a déjà pas été fait par quelqu'un d'autre, de vérifier qu'on respecte bien certaines règles (notamment en matière de brevets), etc.
<<< Comme pour la documentation, on touche ici à une des limites du Logiciel Libre : les développeurs sont pour une grande majorité bénévoles, et ne veulent pas s'embêter avec tout ce qui n'est pas fun : documentation, tests, ... >>>
C'est vrai qu'un développeur peut avoir tendance à négliger de documenter correctement son
travail. Mais c'est cela n'a rien à voir avec l'open-source (c'est tout aussi vrai pour des logiciels
propriétaires). En ce qui concerne la documentation en général des produits open-source,
celle-ci existe et est même très bien réalisée. Prenons un exemple : la distribution Knoppix.
Il existe des ouvrages très bien faits sur le sujet. Donc la documentation ne manque pas.
Mieux : celle-ci est réalisée par des documentalistes indépendants du produit (c'est un gage
de qualité).
<<< Dans le monde propriétaire, les méthodes de développement intègrent les tests au développement du logiciel. eXtreme Programming (XP), par exemple, prône l'utilisation intensive de tests, et notamment de tests unitaires. XP recommande même d'écrire les tests avant le code à tester. >>>
L'extreme programming n'a rien à voir avec le monde propriétaire. Cette technique peut
très bien s'appliquer en tout en en partie à n'importe quel produit de dévéloppement, qu'il
soit open-source ou pas.
<<< Mais la plupart des logiciels libres ignorent totalement cette démarche, et se basent sur une démarche qualité incomplète basée sur des Bug Tracking Systems ou Bugzillas : les bugs remontés ainsi sont en général les bugs les plus apparents, mais un bug bien enfoui peut rester non corrigé pendant des lustres. Ce bug très gênant de gconfd est un bon exemple : un bug dans un algorithme de gestion d'arbre présent depuis GNOME 2.0 (juin 2002), signalé fin septembre 2004, corrigé début février. >>>
Les techniques de bug tracking sont utilisées par tout le monde (aussi bien open-source
que propriétaire). Même si, comme vous semblez le prétendre, certains bugs mettent trop
de temps à être corrigés, il ne faut pas en faire une généralité. Certains éditeurs de logiciels
propiétaires permettent de faire remonter les bugs rencontrés. Hélas, on n'a jamais de suivi
de ces bugs ni de leur correction éventuelle.
<<< Et même si un développeur de Logiciels Libres voulait tester son code, avec quoi le ferait-il ? Les ateliers de test libres sont rares (je ne connais que DejaGNU) et peu utilisés, sauf pour quelques projets plutôt faciles à tester (Binutils, Coreutils, Glibc, GCC, uclibc ...). Du côté des langages de script, c'est un peu mieux : beaucoup de programmes Perl sont livrés avec une suite de test et Python a PyUnit (mais est-ce vraiment utilisé par les développeurs ?). Ruby, langage pour XP par excellence, se démarque : l'interpréteur est testé par le rubicon (un vrai jeu de mots d'informaticiens au passage : Ruby doit passer le Rubicon...), et les tests unitaires sont largement utilisés par les développeurs. >>>
Les tests unitaires peuvent être utiles mais sont bien loin d'être toujours efficaces voire
nécessaires. C'est clair, si on part du principe que les développeurs open-source ne sont
capables que de pondre 1000 lignes de code d'une traite sans tester, on doit se poser
quelques questions (à mon avis faire des tests unitaires sur 1000 lignes de code, ça ne
sert pas à grand chose). Par contre, les tests d'intégration (quand il faut assembler les
différentes briques d'un produit), c'est tout à fait autre chose : dans ce cas, même si
les tests unitaires répondent OK, en général, c'est au moment de l'intégration que tout
s'écroule.
<<< Alors que les logiciels propriétaires populaires deviennent de plus en plus robustes (loin est le temps où Windows plantait sans arrêt), il est important d'augmenter la qualité des Logiciels Libres. Cela passe par l'utilisation massive de techniques ayant fait leurs preuves dans l'industrie, mais mal maîtrisées dans la communauté. >>>
Ca m'intéresse de savoir d'où vous tenez ce genre d'information. Expliquez-moi pourquoi
des logiciels propriétaires sont devenus plus robustes. J'ai reçu, il y a 6 mois, une lettre
de ma banque me demandant de ne plus utiliser Internet Explorer mais d'utiliser plutôt
Mozilla ou Opera. Contrairement à ce que vous semblez souligner, les logiciels libres sont
bels et bien utilisés dans le monde industriel (et avec des méthodologies adéquates comme
par exemple Rup). L'open source a vielli, il a mûri et il devient tout à fait fréquentable.
<<< On peut aussi se poser une question plus profonde : Alors qu'avec Perl, Python, Ruby et C#, nous avons des langages permettant de développer efficacement des applications de haut-niveau, pourquoi continuer à développer majoritairement en C/C++, avec lesquels il est nettement plus facile d'introduire des bugs ? Pourquoi ne pas limiter l'utilisation de ces langages aux librairies ? >>>
Chaque langage de programmation a sa spécificité. La facilité qu'on a d'introduire un bug
dans un produit ne dépend pas du langage choisi : un développeur conciencieux en C n'a rien
à voir avec un développeur débutant en Java. L'open source est une bénédiction dans le
sens où elle ne limite pas les choix des développeurs (par exemple : rien que le C pour des « librairies » ) car cela crée un terrain favorable à l'interopérabilité.
<<< Qu'en pensez-vous ? Testez-vous vos applications ? Avec quoi ? >>>
Le monde open-source n'est pas fait que de « hardcore » développeurs ni d'extrémistes
de tout poil ne désirant rien tester : le monde open-source se dirige à grands pas vers un monde professionnel ouvert : voilà le vrai changement.