À mon humble avis, il faut distinguer deux choses :
Dans le cas donné en exemple (la pluie tout ça) on pourrais argumenter qu'on était pas pleine possession de ses moyens, ou que c'est un pari (illégal non ?) ou je ne sait-quoi... je suis pas jusriste mais la nature de l'engagement me parrait chelou.
Dans le cas de l'interdiction de déchifrer les cartes, on peut (pouvait avant DAVDSI ?) brandir le droit à l'ingénierie inverse à fin de compatibilité.
Il utilise le terme viral et ca ne te convient pas. Tu trouves que ça manque de neutralité. Pourtant tu utilises le terme "travaux dérivés" qui est un terme qui à mon avis manque aussi de neutralité.
Le terme de "travail dérivé" ne correspond pas du tout au choix d'un mot parmis plusieurs. C'est un terme précis qui désigne une notion primordiale du copyright.
Si ton travail A n'est pas un travail dérivé de B alors tu n'a pas de compte à rendre à l'auteur de B. Notement tu peut te dispenser de respecter la GPL. C'est aussi simple que ça.
La GPL ne s'applique qu'aux travaux dérivés et est bel et bien "héréditaire". Contrairement à ce que raconte le FUD qui vise à la discréditer.
Nomdediou, moi j'vous dit, pouvoir foutre et retirer les disques SATA sans redémarrer le bousin, ca c'est une put1** de feature comme on les aime !
Y'a moyen de le faire en IDE, faut utiliser hdparm pour éteindre le disque (voir l'interface IDE), puis brancher l'autre et demander au kernel de relire la table des partoches (encore avec hdparm).
Bon, après c'est pas censé marcher, donc y'a les risques touça. Et puis je me souvient plus trop à quoi ça a pu me servir.
Mais ça marche.
Peut être qu'il parle du fork de SourceForge utilisé notement par GNA et Savannah.
Dans ce cas l'URL c'est http://gna.org/projects/savane/ .
Pour avoir utilisé Savannah, j'en profite pour dire que c'est très GNU (ils ont lu le code de mon projet pour trouver des problème dans mon utilisation de la GPL, et y'en avait), sans pubs et roskorisant.
L'annonce va vraiment dans ton sens (traduction du 6ème chapitre mot à mot et à l'arrache) :
Maintenant que nous avons notre propre projet, nous allons pouvoir établir nos règles. Style de code, objectifs, feuille de route, rythme de publication, tout cela sera clairement défini. Nous prévoyons essentiellement de maintenir deux branches, une stable, qui ne seras affectée que par les corrections de bugs majeurs, et une instable, avec les bugs des nouvelles fonctions, évidement seulement ceux qui n'auront pas été décelés.
La correction des bugs est désormais une priorité, étant donné que nous aurons à produire des versions "stables", et pas juste du "brut de fonderie" mal dégrossi, comme nous y étions habitués.
Et la suite c'est encore mieux : il prévoient de structurer la gestion des bugs, documenter le code...
Ce que j'aime bien sur zsh c'est que la complétion "corrige" les fautes de frappes, et qu'en répétant la touche tab, on peut choisir avec quel fichier compléter. C'est possible à activer avec bash ?
Pour les fautes de frappe y'a un truc du genre export CDPATH='.:~:/usr:/opt:/usr/local:/usr/src:/'
shopt -s cdspell
Ensuite si tu est dans / et que tu fait cd linux, il va te mettre dans /usr/src/linux.
Même chose si tu est dans "/usr/src" et que tu tappe "cd ljnux".
Sinon les truc comme
ls plop<10-20>
peuvent se faire avec ls plop{10..20} (en zsh aussi d'ailleurs)
Enfin, faudrais demander à un gourou du bash pour plus de précision.
Par ailleur y a l'inverse des choses dont je ne suis pas sûr qu'elles soient possibles en zsh. Notement l'utilisation de /dev/tcp/ (apparement ils ont genre de netcat à la place); ou les multiples raccourcis emacsiens.
Ceci dit je doit reconaître que la syntaxe pour les redirections m'a l'air bien plus propre, et que j'envisagerais sérieusement de remplacer bash (j'étais resté sur une idée de zsh comme d'un vieux truc pas maintenu, il se révèle plus intéressant que ça).
Tout est dans le comuniqué de Presse : http://www.iliad.fr/presse/2006/CP_11092006_cp3.pdf
Aparement, Free entends fournir par le biais d'une <<Fondation Free>>, une ligne téléphonique (limitée aux appels d'urgence ?), un accès internet bas débit et un accès aux chaînes TNT, tout cela gratuitement.
Impossible de faire tourner un Xnest avec AIGLX activé.
XGL est précisement un Xnest qui fournit GLX_EXT_texture_from_pixmap à partir de l'accélération OpenGL sous-jacente. Et ton cas (jouer avec le développement X) est précisement la raison qui a fait naitre XGLx dans le projet XGL.
Là ou ça devient du marketing sale, c'est que Novell l'a présenté comme le futur de X à des utilisateurs médusés.
À mon avis, Xglx a le mérite d'avoir accéléré le développement des gestionnaires de fenêtres avec compositeurs. C'est une bonne chose.
Ça aussi a crée un fort engouement pour des technologies immatures et mal comprises (avec des reflexions du type "même si compiz sert à rien, l'affichage de firefox iras plus vite").
De toutes manière, le problème est pas l'existence d'XGLx. C'est effectivement un outil utile pour les gens qui, comme toi, ont besoin d'un serveur X à l'intérieur d'un autre serveur.
Le problème c'est plutôt le buzz associé qui noie la reflexion dans un torrent de captures d'écrans.
Ca doit être possible moyennant quelques modifications du noyau.
T'est un bourrin toi ! Suffit de consulter le nombre paquets reçus à intervalle constant.
Ou mieux : tu concocte une jolie règle iptables qui ne matche que les paquets "signifiants" (du style pas DHCP) et tu utilise les outils classiques liés à Iptables.
La première est que Gentoo permet l'usage d'ICC en tant que compilateur du système autant qu'il est possible de le faire.
La deuxième est que, d'après mes propres tests non scientifiques et à mon humble avis, ICC n'a rien d'exceptionnel. Surtout sur les systèmes AMD et sur ceux ayant une ou deux années de vie.
Par ailleurs, l'interêt que j'ai pour Gentoo vient plus de sa "hackabilité" que de ses performances.
C'est volatile.
Sinon, microcode_ctl est acessible sous gentoo par l'ebuild sys-apps/microcode-ctl ; et sous Debian par un paquet au nom similaire. Par contre, j'ai jamais essayé ce que tu va tenter, hésite pas à venir dire ici si ça marche (j'en doute).
Sinon, même pour les gens qui ont un processeur avec l'HT activé au début, un coup de microcode_ctl peut ne pas faire de mal pour corriger les bugs.
Et pour ceux qui se demandent ce que c'est, j'ai cru comprendre que les processeurs x86 actuels étaient en fait des RISC qui fournissaient l'essentiel du jeu d'instructions par émulation. Le microcode codant une partie software de l'émulateur.
Juste un bruit de couloir : la sortie de Vista va imposer un changement majeur dans les APIs de Windows.
T'est sûr de ton coup ? La dernière fois que j'en ai entendu parler, l'idée semblait plutôt être de cacher l'infâme api derrière une bibliothèque tentaculaire. Avec justement le gros avantage de préserver la sacro sainte compatibilité (et même de la renforcer : l'exploitation de ladite bibliothèque étant lié à celui d'une machine virtuelle, les binaires pourront durer encore plus longtemps).
En fait, je devrais au moins permettre d'utiliser les mandatory locks.
Je vais rapidement sortir une 0.25 pour me mettre en conformité avec Savannah, mais la 0.26 auras cette fonctionalité (probablement activée par défaut).
Après avoir obtenu le descripteur de fichier, la première chose que ShaKe fait est de tenter de prendre un verrou dessus (dans investigate (char *name, struct law *l), ligne 93 de judge.c : /* Put the lock */
if (l->locks && -1 == flock (a->fd, LOCK_EX | LOCK_NB))
{
error (0, errno, "%s: failed to acquire a lock", a->name);
goto freeall;
}).
Le problème ne peut donc se poser qu'avec les applications qui n'honorent pas les verrous. Le seul moyen de s'en prémunir serait d'activer le "Mandatory Lock", qui force les applications à respecter le verrous (documenté dans /usr/src/linux/Documentation/mandatory.txt ), mais de mon point de vue c'est un hack et je ne l'activerais que si c'est vraiment nécessaire.
Il y a trois autres sécurité pour éviter les problèmes de corruption :
La fonction capture (struct accused *a, struct law *l), à la ligne 177 de executive.c qui est appellée avant les opérations d'écriture masque les signaux (notement).
Après une opération de défragmentation, il vérifie rapidement que rien ne manque.
À tout moment, une copie du fichier en cours d'écriture est disponible. Si ShaKe échoue (par exemple à allouer la mémoire) il indique son emplacement puis se suicide.
bon, hdc est sensiblement dans les mêmes eaux. (Évidemment le problème, c'est hda, qui carbure à du 5 Mo/s en transfert de gros fichiers au mieux, alors que hdb et hdc tournent à 20~30 Mo/s)
C'est peut être effectivement un cas de fragmentation. Dans ce cas tu pourrais faire un bon client pour shake.
Si t'a le temps, essaie donc shake --no-xattr --new=0 /. Si ça marche mal (y'a du tweaking à faire sur certaines constantes...), essaie de m'envoyer le shake -pvv d'un gros fichier.
Et vérifie que t'a pas une partition ReiserFS3 montée sans notail, c'est le piège.
Du reste, je suis de bonne foi et les ralentissements dont tu parle ne m'affectent pas. Essaie d'autres système des fichiers et ordonanceurs (j'ai Reiser3 sans notail et avec atime, l'anticipatory scheduler). Le problème ne peut venir que de là.
Apparement les modérateurs ont ajouté à ma proposition initiale de dépêche un lien qui présente pourquoi Linux n'a pas besoin de défragmentation.
De mon point de vue, cet article est dans le vrai : dans la quasi-totalité des cas le système de fichier sait se débrouiller tout seul.
ShaKe vise précisement à déceler les seuls cas où le système de fichier échoue.
Il y en a au moins trois :
Premièrement, le cas où le disque est trop plein. Lors de la présentation à mes profs (à la base c'est un projet d'étude à Lyon1), j'avais fourni une image de filesystem qui faisait bien ressortir le problème : http://vleu.net/shake/disk.bin.bz2 . Sur cet exemple (très articiel), les fichiers "gros" (un méga si je me rappelle bien) passaient d'un millier de fragments à quelques uns. Le cas de cet utilisateur montre que ça arrive aussi dans la vraie vie http://forums.gentoo.org/viewtopic-t-463204-postdays-0-posto(...) .
Ensuite, les "fichiers sparses". Quand un programe Linux accède par exemple au 60ème méga octet d'un d'un fichier qui n'en fait que 5, le système de fichier ne génére pas un fichier plein de zeros pour "remplir le trou" mais "saute par dessus". On a alors systèmatiquement deux fragments. C'est une fonctionalité très interessante puisqu'elle fait gagner une quantitée non négligeable d'espace disque. Mais les logiciels de peer to peer (notament) lui causent problèmes car il reçoivent les morceaux dans un ordre plus ou moins aléatoire, ce qui cause de nombreux sauts et une fragmentation importante. Shake détecte ces sauts injustifiés, mais aussi ajoute des sauts dans le cas où il seraient utiles.
Enfin, il y a le problème de l'évolution de la taille et de l'usage des fichiers. ReiserFS (extN aussi je suppose) semble s'arranger pour placer les fichiers d'un même dossier ensemble, et dans l'ordre d'écriture. Mais aussi intelligent soit-il, le système ne peut pas anticiper deux ans d'utilisation, et si par exemple un dossier se voit ajouter une centaine de fichiers après être longtemps resté intact, ou si un fichier grossit sans cesse longtemps encore après avoir été crée, il seras bien obligé de fragmenter.
Il y a aussi d'autres choses, comme le fait que l'ordre d'écriture ne soit pas nécessairement l'ordre de lecture (shake réecrit les fichiers éloignés les un des autres dans l'ordre de lecture) et le fait que de nombreux fichiers restent "sur place" longtemps, fragmentant l'espace libre car le FS ne va pas de lui même les déplacer (shake les réecrit aussi).
Pour résumer : il y a des cas (rares) où les hypothèses que le système de fichier avait fait sur l'utilisateur, ou sur l'usage des fichiers sont fausses. Shake notifie le problème au système de fichier simplement en lui intimant l'ordre de les réecrire. L'efficacité du système de fichier sous jacent est donc justement ce qui fait marcher Shake et cet article va dans mon sens.
Par contre, s'il est donc suceptible d'être utile, ce n'est bel et bien pas au quotidien car ces cas sont rares.
pour trouver un socle commun à des bibliothèques très différentes, il faut aller chercher loin dans l'abstraction. Cela amène facilement à un code complexe, difficile à débugguer et « lent » ;
Je te conseille de lire l'API, et de faire des remarques plus concrètes à son sujet.
Les bibliothèques envisagée ont toutes en commun la capacité de satisfaire l'utilisateur ayant des besoins basiques (une playlist, des fondus, et un peu d'effet sur la vidéo... à priori ça inclue même des applications comme Juk ou Codeine).
La différence est donc que l'API phonon est construite, non pas dans l'optique d'une "N-ième API qui roske", mais dans une API qui permet de faire en 2 lignes de code ce que tout le monde veut faire (essentuellement les taches susnommées). Ce que tout le monde ferais en peut être 2 à 10 lignes avec une autre API.
Les backends ne rajoutent aucun code qui ne serait pas de toutes manière nécessaire à l'utilisation de la bibliothèque et présent dans une dizaine d'applications. Phonon n'a pas fait l'erreur de la "génericité abusive".
Si tu veut le voir par toi même, goto là bas : http://developer.kde.org/documentation/library/cvs-api/kdeli(...)
Ou carrément app-arch/atool qui gère les formats susnommés mais aussi les tar.7z , les rpms , les arj et bien d'autres, le tout par le biais des utilitaires standards (c'est codé en perl par contre, mais ça a l'air relativement propre -_^).
Personellement, j'utilise depuis longtemps le bon vieux hack du "faux main" (que le GNU utilise aussi, au moins dans la gnulib).
Concrètement ça donne des trucs genre
#ifdef DEBUG
int
main (void)
{
__/* mult */
__{
_____assert( 4 == mult(2, 2));
__}
}
#endif
à la fin de tout les fichiers de code C. Et dans le Makefile :
C'est simple, efficace et portable.
Ça fournit aussi un bon endroit pour mettre des exemples de la manière d'utiliser les fonctions. En plus on peut utiliser les outils standards (gdb, valgrind etc) pour explorer ce qu'il se passe quand un test échoue.
Après, je suppose que c'est pas adaptés à tout les cas. Mais pour les petits projets c'est parfait.
Si tu connais plus d'une trentaine de geeks y'a peu de chances -_^.
Enfin, j'aurais dit pareil que toi y'a quelques temps (et je me serais planté, mais faute d'avoir demandé je savais pas).
De toutes manières, pour un geek être homo ou hétéro dans les deux cas ça veut dire vivre seul donc...
J'ai codé recement quelque chose dans cette idée : ça s'appelle blahmatic, et c'est une généralisation du pipotron.
Concrètement: pendant la phase de lecture, après avoir découpé la phrase en mots, il associe à chaque paire de mots consécutifs un troisième.
Ensuite, la phase de génération consiste à prendre deux mots qui étaient en début de phrase et à leur associer l'un des mots qui a suivit le couple, et ainsi de suite jusqu'à une fin de phrase.
Par exemple avec les phrases "Iksaif aime les vaches.", Iksaif aime les chamos., "Le chat aime les souris." et la regexp [[:space:]]
Blahmatic pourrait générer Iksaif aime les vaches. (Iksaif aime)->les, (aime les)->vaches Iksaif aime les souris. (Iksaif aime)->les, (aime les)->souris
C'est sous GPL, y'a une interface SuckingDisplayLibrary, une en ligne de commande et un fichier LisezMoi qui explique tout (notement le principe du wrapper que j'ai utilisé pour ne pas avoir à subir l'API de la susnommée SDL).
Le code se veut lisible et documenté, le coeur du programe (grammar.c) ne fait que 256 lignes, et y'a même un port windows qui va bientôt être ejecté du code source.
Manque plus qu'un corpus adapté, je reconnais n'avoir pas trop cherché...
J'en arrive maintenant au point qui est le même pour la 3D , avec une fenêtre impossible à fermer sans passer par un "Bonjour" , et se terminer par une formule de politesse comme "Merci d'avance" .
La plupart de ces cartes 3D dédient 90% de leur silicium au pipeline 3D.
La méduse est constituée de 95% d'eau. Ça serais dommage de pas la boire.
Plus sérieusement, tu confond l'API et les capacité sous jacentes du hardware que l'API exporte.
Apple et Microsoft semblent déjà avoir reçu le message que la 3D est la voie à suivre et ont fait la transition.
Pour ce que j'en sait, les widgets sont pas principalement dessinés en Direct3d ou OpenGL sur ces systèmes, juste la "composition des fenêtres", et quelques effets.
En tous cas, je suis sur que XGL fait comme ça.
Je ne vois pas ce qui pourrait tuer OpenGL
L'arrivée d'une API gérant mieux la réalitée augmentée, le multithreading des IBM force42 à 512 GPU ou les ports Schriebmann ? Un rachat par Microsoft ? Gordon Freeman ?
Pourquoi réinventer la poudre ? Pourquoi développer une nouvelle AP 2D alors que l'API OpenGL ES existe déjà (la 3D peut dessiner de la 2D) ?
L'API que je parlait d'inventer, c'était celle d'X.
Sinon "la 3d peut dessiner la 2d", je confirme. Par contre l'API 3d est pas nécessairement adaptée à la 2d (si tu me crois pas, fait un mini logiciel de dessin monochrome avec l'api OpenGL, avec une bonne API c'est 40 lignes de C sans subtilités).
[^] # Re: il y a aussi des cartes libres
Posté par un_brice (site web personnel) . En réponse au journal linux et la navigation gps. Évalué à 2.
Dans le cas donné en exemple (la pluie tout ça) on pourrais argumenter qu'on était pas pleine possession de ses moyens, ou que c'est un pari (illégal non ?) ou je ne sait-quoi... je suis pas jusriste mais la nature de l'engagement me parrait chelou.
Dans le cas de l'interdiction de déchifrer les cartes, on peut (pouvait avant DAVDSI ?) brandir le droit à l'ingénierie inverse à fin de compatibilité.
[^] # Re: Stop !
Posté par un_brice (site web personnel) . En réponse au journal La GPL plus business friendly que la BSD ?. Évalué à 4.
Si ton travail A n'est pas un travail dérivé de B alors tu n'a pas de compte à rendre à l'auteur de B. Notement tu peut te dispenser de respecter la GPL. C'est aussi simple que ça.
La GPL ne s'applique qu'aux travaux dérivés et est bel et bien "héréditaire". Contrairement à ce que raconte le FUD qui vise à la discréditer.
[^] # Re: Email de Thorvalds.
Posté par un_brice (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.18. Évalué à 10.
[^] # Re: A l'abordage !
Posté par un_brice (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.18. Évalué à 4.
Bon, après c'est pas censé marcher, donc y'a les risques touça. Et puis je me souvient plus trop à quoi ça a pu me servir.
Mais ça marche.
[^] # Re: ?
Posté par un_brice (site web personnel) . En réponse au journal recherche empaqueteurs. Évalué à 4.
Dans ce cas l'URL c'est http://gna.org/projects/savane/ .
Pour avoir utilisé Savannah, j'en profite pour dire que c'est très GNU (ils ont lu le code de mon projet pour trouver des problème dans mon utilisation de la GPL, et y'en avait), sans pubs et roskorisant.
[^] # Re: Pourquoi pas...
Posté par un_brice (site web personnel) . En réponse au journal Compiz forké. Évalué à 4.
Et la suite c'est encore mieux : il prévoient de structurer la gestion des bugs, documenter le code...
[^] # Re: Zsh Rulez
Posté par un_brice (site web personnel) . En réponse à la dépêche À la (re)découverte de Zsh. Évalué à 2.
export CDPATH='.:~:/usr:/opt:/usr/local:/usr/src:/'
shopt -s cdspell
Ensuite si tu est dans / et que tu fait cd linux, il va te mettre dans /usr/src/linux.
Même chose si tu est dans "/usr/src" et que tu tappe "cd ljnux".
Sinon les truc comme peuvent se faire avec ls plop{10..20} (en zsh aussi d'ailleurs)
Enfin, faudrais demander à un gourou du bash pour plus de précision.
Par ailleur y a l'inverse des choses dont je ne suis pas sûr qu'elles soient possibles en zsh. Notement l'utilisation de /dev/tcp/ (apparement ils ont genre de netcat à la place); ou les multiples raccourcis emacsiens.
Ceci dit je doit reconaître que la syntaxe pour les redirections m'a l'air bien plus propre, et que j'envisagerais sérieusement de remplacer bash (j'étais resté sur une idée de zsh comme d'un vieux truc pas maintenu, il se révèle plus intéressant que ça).
# Le service universel gratuit des télécommunications de Free
Posté par un_brice (site web personnel) . En réponse au journal FTTH@free.fr. Évalué à 4.
http://www.iliad.fr/presse/2006/CP_11092006_cp3.pdf
Aparement, Free entends fournir par le biais d'une <<Fondation Free>>, une ligne téléphonique (limitée aux appels d'urgence ?), un accès internet bas débit et un accès aux chaînes TNT, tout cela gratuitement.
La news FreeNews : http://www.freenews.fr/index.php?itemid=3794
[^] # Re: Plussagement
Posté par un_brice (site web personnel) . En réponse au journal Apercu Enlightenment v17. Évalué à 4.
Là ou ça devient du marketing sale, c'est que Novell l'a présenté comme le futur de X à des utilisateurs médusés.
Ça aussi a crée un fort engouement pour des technologies immatures et mal comprises (avec des reflexions du type "même si compiz sert à rien, l'affichage de firefox iras plus vite").
De toutes manière, le problème est pas l'existence d'XGLx. C'est effectivement un outil utile pour les gens qui, comme toi, ont besoin d'un serveur X à l'intérieur d'un autre serveur.
Le problème c'est plutôt le buzz associé qui noie la reflexion dans un torrent de captures d'écrans.
[^] # Re: Dites...
Posté par un_brice (site web personnel) . En réponse au journal GShutdown 0.1 - Recherche beta-testeurs !. Évalué à 4.
T'est un bourrin toi ! Suffit de consulter le nombre paquets reçus à intervalle constant.
Ou mieux : tu concocte une jolie règle iptables qui ne matche que les paquets "signifiants" (du style pas DHCP) et tu utilise les outils classiques liés à Iptables.
[^] # Re: Performances de Gentoo
Posté par un_brice (site web personnel) . En réponse à la dépêche Gentoo 2006.1 est prête !. Évalué à 3.
La première est que Gentoo permet l'usage d'ICC en tant que compilateur du système autant qu'il est possible de le faire.
La deuxième est que, d'après mes propres tests non scientifiques et à mon humble avis, ICC n'a rien d'exceptionnel. Surtout sur les systèmes AMD et sur ceux ayant une ou deux années de vie.
Par ailleurs, l'interêt que j'ai pour Gentoo vient plus de sa "hackabilité" que de ses performances.
# Pour les vrais...
Posté par un_brice (site web personnel) . En réponse au journal GShutdown 0.1 - Recherche beta-testeurs !. Évalué à 2.
[^] # Re: Strictement aucun probleme pour moi.
Posté par un_brice (site web personnel) . En réponse au journal Noyau: code relatif à l'HyperThreading défectueux?. Évalué à 2.
Sinon, microcode_ctl est acessible sous gentoo par l'ebuild sys-apps/microcode-ctl ; et sous Debian par un paquet au nom similaire. Par contre, j'ai jamais essayé ce que tu va tenter, hésite pas à venir dire ici si ça marche (j'en doute).
Sinon, même pour les gens qui ont un processeur avec l'HT activé au début, un coup de microcode_ctl peut ne pas faire de mal pour corriger les bugs.
Et pour ceux qui se demandent ce que c'est, j'ai cru comprendre que les processeurs x86 actuels étaient en fait des RISC qui fournissaient l'essentiel du jeu d'instructions par émulation. Le microcode codant une partie software de l'émulateur.
[^] # Re: Une autre possibilité
Posté par un_brice (site web personnel) . En réponse au journal Microsoft veut coopérer avec l'équipe Mozilla pour le dev de firefox. Évalué à 0.
[^] # Re: en cours d'utilisation
Posté par un_brice (site web personnel) . En réponse à la dépêche ShaKe, un défragmenteur pour GNU/Linux. Évalué à 2.
Je vais rapidement sortir une 0.25 pour me mettre en conformité avec Savannah, mais la 0.26 auras cette fonctionalité (probablement activée par défaut).
[^] # Re: ^-^
Posté par un_brice (site web personnel) . En réponse à la dépêche ShaKe, un défragmenteur pour GNU/Linux. Évalué à 2.
[^] # Re: en cours d'utilisation
Posté par un_brice (site web personnel) . En réponse à la dépêche ShaKe, un défragmenteur pour GNU/Linux. Évalué à 5.
/* Put the lock */
if (l->locks && -1 == flock (a->fd, LOCK_EX | LOCK_NB))
{
error (0, errno, "%s: failed to acquire a lock", a->name);
goto freeall;
}).
Le problème ne peut donc se poser qu'avec les applications qui n'honorent pas les verrous. Le seul moyen de s'en prémunir serait d'activer le "Mandatory Lock", qui force les applications à respecter le verrous (documenté dans /usr/src/linux/Documentation/mandatory.txt ), mais de mon point de vue c'est un hack et je ne l'activerais que si c'est vraiment nécessaire.
Il y a trois autres sécurité pour éviter les problèmes de corruption :
La fonction capture (struct accused *a, struct law *l), à la ligne 177 de executive.c qui est appellée avant les opérations d'écriture masque les signaux (notement).
Après une opération de défragmentation, il vérifie rapidement que rien ne manque.
À tout moment, une copie du fichier en cours d'écriture est disponible. Si ShaKe échoue (par exemple à allouer la mémoire) il indique son emplacement puis se suicide.
[^] # Re: ^-^
Posté par un_brice (site web personnel) . En réponse à la dépêche ShaKe, un défragmenteur pour GNU/Linux. Évalué à 2.
Si t'a le temps, essaie donc shake --no-xattr --new=0 /. Si ça marche mal (y'a du tweaking à faire sur certaines constantes...), essaie de m'envoyer le shake -pvv d'un gros fichier.
Et vérifie que t'a pas une partition ReiserFS3 montée sans notail, c'est le piège.
Du reste, je suis de bonne foi et les ralentissements dont tu parle ne m'affectent pas. Essaie d'autres système des fichiers et ordonanceurs (j'ai Reiser3 sans notail et avec atime, l'anticipatory scheduler). Le problème ne peut venir que de là.
# Re: Pourquoi Linux n'a pas besoin de défragmentation
Posté par un_brice (site web personnel) . En réponse à la dépêche ShaKe, un défragmenteur pour GNU/Linux. Évalué à 10.
De mon point de vue, cet article est dans le vrai : dans la quasi-totalité des cas le système de fichier sait se débrouiller tout seul.
ShaKe vise précisement à déceler les seuls cas où le système de fichier échoue.
Il y en a au moins trois :
Premièrement, le cas où le disque est trop plein. Lors de la présentation à mes profs (à la base c'est un projet d'étude à Lyon1), j'avais fourni une image de filesystem qui faisait bien ressortir le problème : http://vleu.net/shake/disk.bin.bz2 . Sur cet exemple (très articiel), les fichiers "gros" (un méga si je me rappelle bien) passaient d'un millier de fragments à quelques uns. Le cas de cet utilisateur montre que ça arrive aussi dans la vraie vie http://forums.gentoo.org/viewtopic-t-463204-postdays-0-posto(...) .
Ensuite, les "fichiers sparses". Quand un programe Linux accède par exemple au 60ème méga octet d'un d'un fichier qui n'en fait que 5, le système de fichier ne génére pas un fichier plein de zeros pour "remplir le trou" mais "saute par dessus". On a alors systèmatiquement deux fragments. C'est une fonctionalité très interessante puisqu'elle fait gagner une quantitée non négligeable d'espace disque. Mais les logiciels de peer to peer (notament) lui causent problèmes car il reçoivent les morceaux dans un ordre plus ou moins aléatoire, ce qui cause de nombreux sauts et une fragmentation importante. Shake détecte ces sauts injustifiés, mais aussi ajoute des sauts dans le cas où il seraient utiles.
Enfin, il y a le problème de l'évolution de la taille et de l'usage des fichiers. ReiserFS (extN aussi je suppose) semble s'arranger pour placer les fichiers d'un même dossier ensemble, et dans l'ordre d'écriture. Mais aussi intelligent soit-il, le système ne peut pas anticiper deux ans d'utilisation, et si par exemple un dossier se voit ajouter une centaine de fichiers après être longtemps resté intact, ou si un fichier grossit sans cesse longtemps encore après avoir été crée, il seras bien obligé de fragmenter.
Il y a aussi d'autres choses, comme le fait que l'ordre d'écriture ne soit pas nécessairement l'ordre de lecture (shake réecrit les fichiers éloignés les un des autres dans l'ordre de lecture) et le fait que de nombreux fichiers restent "sur place" longtemps, fragmentant l'espace libre car le FS ne va pas de lui même les déplacer (shake les réecrit aussi).
Pour résumer : il y a des cas (rares) où les hypothèses que le système de fichier avait fait sur l'utilisateur, ou sur l'usage des fichiers sont fausses. Shake notifie le problème au système de fichier simplement en lui intimant l'ordre de les réecrire. L'efficacité du système de fichier sous jacent est donc justement ce qui fait marcher Shake et cet article va dans mon sens.
Par contre, s'il est donc suceptible d'être utile, ce n'est bel et bien pas au quotidien car ces cas sont rares.
[^] # Re: Les Gnomistes m'emmerdent
Posté par un_brice (site web personnel) . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 10.
Les bibliothèques envisagée ont toutes en commun la capacité de satisfaire l'utilisateur ayant des besoins basiques (une playlist, des fondus, et un peu d'effet sur la vidéo... à priori ça inclue même des applications comme Juk ou Codeine).
La différence est donc que l'API phonon est construite, non pas dans l'optique d'une "N-ième API qui roske", mais dans une API qui permet de faire en 2 lignes de code ce que tout le monde veut faire (essentuellement les taches susnommées). Ce que tout le monde ferais en peut être 2 à 10 lignes avec une autre API.
Les backends ne rajoutent aucun code qui ne serait pas de toutes manière nécessaire à l'utilisation de la bibliothèque et présent dans une dizaine d'applications. Phonon n'a pas fait l'erreur de la "génericité abusive".
Si tu veut le voir par toi même, goto là bas : http://developer.kde.org/documentation/library/cvs-api/kdeli(...)
[^] # Re: libarchive + bsdtar
Posté par un_brice (site web personnel) . En réponse au journal Décompression d'archive intelligente. Évalué à 2.
# IFDEFs de porcs
Posté par un_brice (site web personnel) . En réponse au journal Frameworks de test unitaires: retour d'XP. Évalué à 2.
Concrètement ça donne des trucs genre
à la fin de tout les fichiers de code C. Et dans le Makefile :
(à adapter suivant tes dépendances).
C'est simple, efficace et portable.
Ça fournit aussi un bon endroit pour mettre des exemples de la manière d'utiliser les fonctions. En plus on peut utiliser les outils standards (gdb, valgrind etc) pour explorer ce qu'il se passe quand un test échoue.
Après, je suppose que c'est pas adaptés à tout les cas. Mais pour les petits projets c'est parfait.
[^] # Re: pas chez moi
Posté par un_brice (site web personnel) . En réponse au journal sondage, enfin, presque..... Évalué à 6.
Enfin, j'aurais dit pareil que toi y'a quelques temps (et je me serais planté, mais faute d'avoir demandé je savais pas).
De toutes manières, pour un geek être homo ou hétéro dans les deux cas ça veut dire vivre seul donc...
# Blahmatic
Posté par un_brice (site web personnel) . En réponse au journal Google livre ses N-Grammes !. Évalué à 4.
Concrètement: pendant la phase de lecture, après avoir découpé la phrase en mots, il associe à chaque paire de mots consécutifs un troisième.
Ensuite, la phase de génération consiste à prendre deux mots qui étaient en début de phrase et à leur associer l'un des mots qui a suivit le couple, et ainsi de suite jusqu'à une fin de phrase.
Par exemple avec les phrases
"Iksaif aime les vaches.", Iksaif aime les chamos., "Le chat aime les souris." et la regexp [[:space:]]
Blahmatic pourrait générer
Iksaif aime les vaches. (Iksaif aime)->les, (aime les)->vaches
Iksaif aime les souris. (Iksaif aime)->les, (aime les)->souris
C'est sous GPL, y'a une interface SuckingDisplayLibrary, une en ligne de commande et un fichier LisezMoi qui explique tout (notement le principe du wrapper que j'ai utilisé pour ne pas avoir à subir l'API de la susnommée SDL).
Le code se veut lisible et documenté, le coeur du programe (grammar.c) ne fait que 256 lignes, et y'a même un port windows qui va bientôt être ejecté du code source.
Manque plus qu'un corpus adapté, je reconnais n'avoir pas trop cherché...
Mangez-en ! http://vleu.net/blahmatic/blahmatic.tar.bz2 (si y'en a que ça interesse, je peut présenter plus précisement l'implémentation)
J'allais oublier l'exemple : (généré par ./blahmatic langs/sdz/ --talk)
[^] # Re: Futur antérieur..
Posté par un_brice (site web personnel) . En réponse à la dépêche Intel libère ses pilotes graphiques. Évalué à -1.
Plus sérieusement, tu confond l'API et les capacité sous jacentes du hardware que l'API exporte.
Pour ce que j'en sait, les widgets sont pas principalement dessinés en Direct3d ou OpenGL sur ces systèmes, juste la "composition des fenêtres", et quelques effets.
En tous cas, je suis sur que XGL fait comme ça.
L'arrivée d'une API gérant mieux la réalitée augmentée, le multithreading des IBM force42 à 512 GPU ou les ports Schriebmann ? Un rachat par Microsoft ? Gordon Freeman ?
L'API que je parlait d'inventer, c'était celle d'X.
Sinon "la 3d peut dessiner la 2d", je confirme. Par contre l'API 3d est pas nécessairement adaptée à la 2d (si tu me crois pas, fait un mini logiciel de dessin monochrome avec l'api OpenGL, avec une bonne API c'est 40 lignes de C sans subtilités).