shbrol a écrit 519 commentaires

… trop de problèmes, comme la non interdiction d'un nom de fichier ayant le même nom et pas la même extension.

Oops… tu voudrais que le systeme interdise deux fichier avec le même nom, mais une extension différente, dans le même répertoire, c'est bien ça ?
Et aussi pour foo.h, foo.cc et foo.o ?

Comme dans l'esprit IPV6, tout est accessible de partout, cela conduirait à utiliser du ssl partout, alourdissant et ralentissant les échanges locaux. Adieu les transferts à 100 Mo/s de mes réseaux Gigabit !

Heu… la j'ai peur. On ne peut pas monter un parefeu en IPv6, qui cacherait les services internes qui doivent rester privés ?

les USA dépensent le double de la France dans la santé, pour un résultat désastreux.

Désastreux parce que tu prends le point de vue des malades. Maintenant, si tu regardes du coté des médecins, pharmaciens, etc. le système américain est bien meilleur : deux fois plus de pognon en circulation…

si la longueur est supérieur à la taille de ton fichier, tu te doutes qu'il y a un problème non?

Exemple donnée plus haut : sur le disque, le fichier est compressé, et tu le lit directement via une bibliothèque qui fait la décompression a la volée. Cette bibliothèque ne te donne pas la taille réelle des données (souvent elle ne le peut pas). Donc la taille du fichier sur disque ne donne aucune information pertinente, elle sera probablement inférieure à la longueur lue, sans que ça pose de problème.

En C++, del, c'est une fonction peut-être ?

Tu veux dire delete ?
(j'ai pas fait de C++ depuis longtemps…, les choses ont peut-etre changé)

Moi je connaissais "milieu de gamme" et pas "moyen de gamme"….

et au bout de la DIN, un clavier Model-M !

Il y a aussi readahead / readahead-fedora, qui fait du préchargement des fichiers utilisés au boot, sans réallocation sur le disque (pas besoin d'ext4).

Je n'ai pas essayé e4rat, parce que je ne voulais pas modifier la partition, donc je ne peux pas comparer. Mais readahead-fedora a divisé mon temps de boot par 2 (et ce n'est pas un sentiment, bootchart, toussa..)

Mais comment, ce n'est pas possible, ta principale motivation pour remplacer Solaris par Debian Sparc c'était juste que CDE c'était moche et vieux ? Moi qui croyait que c'était pour la beauté du libre ! Quelle désillusion après tant d'années ;)

Certes, mais comme tu es bien élevé, tu ne te plaignais pas !

Effectivement, il y a une erreur sur la citation, il fallait lire :

"Monde de merde!"

Pourtant les bugs mentionnés ne concernent pas les clavier qui se blo

Et si tu essayait "Ze Nitram", parce qu'il te prend l'envie d'une particule ?

Pour l'administration, l'état civil, les notaires, il y a une différence entre Zenitram, Zénitram et Zènitram.

Pour faire rectifier un accent dans l'état civil, il faut passer par le procureur de la république.
Et si jamais tu rencontres ce genre de problème avec l'administration, je te souhaite bon courage pour leur expliquer que c'est pareil…

AMHA, le problème ne vient pas de FAT, mais de l'implémentation par dessus qui suppose qu'il n'est pas nécessaire de trier les noms de fichier par ordre alphabétique après lecture du répertoire.

Dans mes lointains souvenirs, les résultats de readdir(3) ne sont pas fournis dans l'ordre alphabétique sur un système de fichier ext, donc le problème serait le même.

(et aussi peut être l'option -f de ls ?)

Parce que cela permettra aux vendeurs de machine à voter de faire de l'argent, alors qu'ils ne peuvent pas dans le système actuel.
Sinon, effectivement, ça ne sert à rien.

Personne n'a d'arguments satisfaisant pour justifier le vote électronique. Ca permet de gagner quelques heures au dépouillement, mais franchement voilà. Economiquement, c'est pas sûr que ça coûte moins cher…

Ben si, l'intérêt du vote électronique, c'est de faire gagner de l'argent aux vendeurs de machines à voter…

Si la rentabilité long terme avait la moindre importance, ca se saurait…

Interessant : j'ai exactement les mêmes symptomes à la maison actuellement (LiveBox 2).

Pour completer la liste des gros fournisseurs, il y a aussi xlc (IBM) et acc (HP).

Parce que ca colle bien à la formation et au calibre des étudiants qu'on trouve dans cette école. Dans une autre vie, j'y ai trouvé deux stagiaires qui ont été embauchés par la suite. Il y en a un qui traine par ici, il devrait se reconnaitre ;)

Hmmm, comment te dire... je parlais de la durée de remplissage du cache, ou cat et dd sont équivalent.

J'ai vidé le cache, puis l'ai rempli avec dd. Ensuite, je l'ai vidé à nouveau, puis rempli avec cat. Les deux remplissage ont une durée équivalente, de l'ordre de la dizaine de seconde.
Par contre, si on ne vide pas le cache entre les deux remplissage, alors le deuxieme est immédiat (et on voit donc une différence).

J'ai bien mis l'option "bs=1M" à dd, je n'ai pas vu de différence notable pour le temps de chargement par rapport a cat, sur mon exemple particulier.
Et cat est plus sympa, parce qu'on peut charger plusieurs fichier avec une seule commande, pour dd c'est un appel par fichier.

Je crois que ca n'apporte rien d'utiliser dd, j'ai fait l'essai avec dd et cat, et le resultat est identique. Peut etre pour éviter un UUOC ?

Et j'ai fait une boulette dans ma correction de syntaxe dd, ce n'est pas "-i mylib.so -o /dev/null" mais plutot "if=mylib.so of=/dev/null" ... bref, cat c'est plus simple...

Il me reste maintenant a mesurer le temps de démarrage de l'appli avec/sans cache chargé, merci a tous pour votre aide.

Excellent, maintenant je sais remplir et vider mon cache, merci beaucoup.
Je vais commencer par ca avant de sortir l'artillerie.