On peut pousser le vice plus loin: les toolkits modernes directement sur cet opengl indépendant de X (il faudra mettre au point des bibliothèques pour ce qui manquerait, par exemple, la gestion du curseur).
Déjà, tout le monde n'a pas un moteur de rendu OpenGL, et rien ne prouve qu'OpenGL dure éternellement. En plus, OpenGL a clairement pas été conçu dans cette optique.
Donc pour moi, il faudrait refaire une autre API minimaliste conçue spécifiquement pour la 2d, et l'implémenter directement par dessus DRI (pour les perfs).
La transparence réseau serait un plus; surtout que ça permetrais de gérer proprement une confinement et faire que des applications de privilèges différents s'affichent sans risque sur le même écran (ce qui n'était pas le cas sous mswindows à l'époque où j'ai regardé).
Et on appellerais ça un serveur X.
Je ne sais pas si c'est à DRI de gérer ça, mais il faut maintenant une interface bas niveau qui sache, sur une machine, gérer la présence de plusieurs cartes graphiques différentes avec plus ou moins de "heads", avec plusieurs utilisateurs les partageant.
De quoi tu parle ? De protéger les serveurs X les uns contre les autres ? M'est avis que ça seras dur vu que sous x86 on peine déjà à protéger le kernel contre la carte graphique, faute d'IO-MMU (peut être plus avec les nouveaux processeurs gérant la virtualisation, ou avec le hack de Linus avec le GART auquel j'ai rien capté).
C'est pas tellement necessaire, vu que le tout le monde utilise la libmagic... à la rigueur on peut même se dire que ça dupliquerais des informations disponibles dans l'entête.
Enfin, je suppose qu'on pourrait effectivement dire à cette lib de mémoriser le résultat de ses investigations dans un xattr, mais je m'attends pas à ce que les performances s'envolent (sans parler des problèmes sur les fichiers en lecture seul).
Sinon, même sans hacker la libmagic on pourrais probablement ajouter la mémorisation aux composants des bureaux qui identifient les types de fichiers. Ça serait un peu moins gore, mais pas tellement plus utile.
Pour autant que je me souvienne de mes lectures, il l'était déjà (c'était même censé être un micronoyau au tout début).
Les drivers sont a moitité en espace noyaux et en espace user.
Si je comprends bien, ça ne vaut que pour les pilotes graphique et ça correspond à la répartition des taches actuellement en vigueur entre Linux et Xorg-x11 : http://www.ati.com/products/wp/ATIVistaWDDMWhitepaperfinalv3(...)
(un truc plus intéressant est le scheduler de ressources graphiques pour les systèmes multi-GPU)
C'pas vraiment le débat, mais on est vendredi, alors quitte à dériver... je doit dire que si j'avais pu choisir, j'serais hétéro.
Pas que l'homosexualité me paraisse maléfique, ou moins "conforme à la nature" qu'une glace à la fraise (presque sûr qu'y a plus de singes homos que de congélateurs sauvages), mais faut reconaître que c'est parfois lourd...
Reste que l'intention est bonne, et ça fait plaisir :-).
Non, on reste limité à la notion de fichier. Il y a donc encore la notion de système de fichier qui n'est pas encore totalement abstraite.
Nuance : on est limité à tout ce que peut contenir un fichier. Et comme un fichier peut contenir à peu prêt n'importe quoi, y compris de références (à un site web par exemple), on est pas limité.
Après, effectivement, le site web que Madame Germaine pensait avoir enregistré sur son ordinateur puis retrouvé avec locate:/ est en fait un fichier .desktop, mais ça....
Bon, et ça c'est pour locate:/, le cas d'audiocd:/ qui présente un CD audio sous forme d'un conteneur de musique sous différents formats, ou d'applications:/ montre encore mieux que KIO représente des objets quelque soit leur nature.
Avec WinFS, tu passes à une abstraction compléte de la couche du FS.
[...]
Donc effectivement, on peut voir ça comme une surcouche mais à ne pas confondre avec un Beagle, Kat ou Strigi (peut-être remplaçant de Kat dans KDE 4.0).
Et pourtant, un simple locate:/truc dans n'importe quelle application KDE représente déjà une "abstraction complète du FS", et ce genre de chose est prévu en frontend pour Kat/Strigi/.. .
Tant qu'on en est a parler d'ICC, y'a autre chose à voir à son sujet : les applications ne sont presque jamais testée avec. À cause de ça (et peut être aussi par ce que le compilateur lui même est moins utilisé/testé), un ami qui avait compilée sa Gentoo avec ICC avait une moyenne de trois ou quatre segfault par jour (xine notement aimait vraiment pas).
Pour enfoncer le clou, j'avais fait des essais pifomètriques avec ICC sur un système un peu ancien (Athlon XP Palomino) et c'était un massacre. À croire qu'il ne compile correctement que pour les derniers processeurs.
Suis je le seul à trouver que le langage français gagnerais à être formalisé ?
Ce qui est sur, c'est que tes phrases, pour musicales qu'elles sont, n'ont pas de sens direct.
Si tu a le temps, j'aimerais bien une pierre de rosette "français philosophique"/"français de documentation technique".
L'anti-politiquement correct en tant que politiquement correct est un des avatars de la pensée unique, de même que la subversion est devenue la norme.
=> Non P égal P appartient à U. De même, S(t0) == Non S(t0+1).
Au lieu de figer sa conception du monde et de l'imposer aux autres (1a) ou d'ignorer celle des autres (1b), aujourd'hui en Occident en général et en France en particulier, on brasse et on embrasse toutes les visions du monde, toutes les cultures
=> Les gens vivants dans l'occident "brassent" (acceptent ?) toutes les visions du monde, par opposition à ceux qui rejettent celles différentes de la leur.
Sauf que les deux attitudes sont autant cruellement dépourvues de fond.
=>Le rejet ni l'acceptation n'ont de justification.
Dès lors, face à l'absence de moëlle substantifique, nos écervelés deviennent soit des fanatiques s'autodétruisant (1), voire emportant d'autres dans leur chute intérieure (1a), ou n'ont plus aucune envie de se battre, deviennent mous, incapables, une sorte de mélange de sensations, de sentiments, mais pas de certitudes (2), qui fluctue et se fait balayer par les fanatiques type 1a.
=>En conséquence de quoi, les écervelés (toujours les même gens vivant en Occident ?) se suicident, tuent(1) ou ne font rien (2) et se font tuer.
Heureusement, toute la france n'est pas soumise ni au politquement correct du devoir de pseudo-politiquement incorrect
=>Certains français sont libres du devoir politiquement correct de paraître non politiquement correct.
ni au racisme anti-raciste
=>Ils se refusent également à penser les racistes comme une race infèrieure.
ni à la subversion comme norme
=>Ils résistent également à dire que contester la norme est dans la norme.
ni à l'absence d'ordre moral comme seul ordre moral envisageable
=>Ils ne veulent non plus pas que l'absence d'ordre moral soit le seul ordre moral envisageable.
ni à ses autres avatars. L'espoir est là.
=>Et caetera. Tout ceci me donne une idée positive de l'avenir.
A mon boulot : les seuls ports autorisés étant 80 et 443 (tu imagines bien que le serveur IMAP et SMTP sont sur leurs ports standarts)
Installe un proxy SOCKS chez toi et fait le écouter sur le port 80.
Je sait que c'est pas à la porté de tout le monde, mais je pense que c'est largement à la porté du DLFPien moyen. Pour les autres, voir chapitre suivant.
Chez mes amis : j'installe et configure chez tout le monde mon compte?
Pour le coup c'est utile. Mais au quotidien, la plupart des gens se connectent depuis chez eux et, de mon point de vue, il est légitime d'être surpris de l'attention que reçoivent les interfaces web par rapport au clients "lourds".
Du reste, cette remarque s'applique très mal au sujet initial de la vidéo, mais on avait déjà commencé à en sortir.
AIlleurs que chez moi : sécurité?
Par contre cette phrase je la comprends pas. Tu veut dire que tu trouve plus sécurisé un client fermé, codé dans un mix de langages qui comuniquent le plus souvent en clair et par XML la moindre de tes actions à un serveur les loguant comme ça lui chante, plutôt qu'un bon vieux logiciel comme ont les écrit depuis des decenies ?
Donc, ca n'a peut-etre aucun sens pour toi, mais laisse les gens pour qui ca a un sens tranquille.
Il t'a pas agressé non plus. Il a juste dit qu'il préférait un client "lourd". Ça ne t'empêche pas de faire quoi que ce soit.
Maintenant un navigateur intégré a la page web, c'est aussi plus agréable (parce que c'est intégré justement).
Question de point de vue apparement. Moi je préfère un machin qui me dit ouvrir/enregistrer et permet utilise mon interface favorite bien integré au desktop plutôt qu'un truc dont le comportement et l'allure varient avec chaque page que je visite.
Après ça dépend aussi de si on voit le site comme une oeuvre en elle même ou juste un moyen de comuniquer l'information. Mais remarque, comme quelqu'un l'a dit plus haut, rien n'empêche de proposer les deux.
Philippe Pary:
-donne moi ton nom, je vais parler à ton chef, tu verra qu'il m'installera Fortran91 comme c'était à la fac, je ne peux pas travailler sur du fortran77. alors que toi avec ton Bac+2, t'es qu'une merde, moi je sors de Fac, je sors d'un magistère, d'une thèse
Est- tu sur que cette attaque personnelle est une manière productive de faire évoluer le débat ? Tu prête à cet homme des propos qu'il n'a même pas esquissés, et ce d'une manière moqueuse (et de surcroit déplaisante à lire).
ELLE EST FACE A VOUS cette pseudo-personne donc elle a subit une rotation sur l'axe horizontal de 180° pour etre face a vous. le haut et
le bas reste inchangés suivant cette rotation.
Ouille.
C'est pas une rotation sur l'axe horizontal, sinon mettre le mirroir perpendiculaire à sa position initiale inverserais haut et bas. C'est une symétrie plane.
Le reste conserve un peu de sens, mais ton histoire de référentiels me parrait cheloue... le problème vient pas de ce qu'on définisse la droite et la gauche d'une manière ou d'une autre : il y a bien une "inversion" : met ton miroir sur l'axe nord-sud, place toi en face, montre le du doigt, tu va montrer le nord et le reflet le sud (ou réciproquement).
En fait le problème c'est que le miroir inverse pas "la gauche et la droite", il fait sa pauvre symétrie, et comme il est face à nous ça inverse la position du corps qui nous sert à définir "droitier" et "gaucher".
Donc pour moi la difficulté de la question vient de ce qu'on nous incite à raisonner en de mauvais terme ("inversion de cotés -> rotation" au lieu de la symétrie plane).
Et du coup je comprends pas comment tu peut conclure en raisonnant sur des rotations.
#!/bin/bash
DIRS=`echo \
~/{boulot,brouillons,...} \
~/.kde/share/apps/{akregator,basket,kabc,kopete,kwallet,konversation,konqueror/b
ookmarks.xml} \
~/.kde/share/config/{basketrc,kopete,kopeterc,konversationrc} \
`
for s in $DIRS ; do
echo ===============$s
unison $s ssh://user@serveur_stockage/$s -ui text
done
Ça synchronise Konqueror, basket, Kopete, akregator et tout mes documents... faut juste changer le DIRS suivant ses besoins, lancer le script et maintenir [entrée] apuyé. Quand y'a un conflit il pose la question et demande quelle version conserver.
Si on veut pas utiliser de serveur de stockage, on peut mettre directement le nom du PC "partenaire".
Là ça utilise unison comme backend, donc c'est plutôt adapté à deux postes au plus. Mais je crois que Google (on y revient...) a publié en GSOC un logiciel libre adapté à plus de postes.
Mais je doute que tu puisse coller ton machin de photoshop et l'éditer à l'intérieur de msword. Ou intégrer un logiciel de dessin vectoriel (Karbon14 ici) dans photoshop (càd Krita).
Du reste, inclure un document Koffice dans un autre est, et à toujours été, possible, apparemment là c'est la manière dont ça l'est qui change...
Et une dernière chose qui a vraiment son importance pour moi (je développe des applis web, avec pas mal de javascript, ajax, ...) c'est que je n'ai jamais encore trouvé de debuguer javascript sous safari
[...]
Mais pour safari... (ou même konqueror)
Hum en fait c'est une fonctionalité ^^. Si tu fait le test avec Kmail ça fera pareil.
Le presse papier X contient une référence à la donnée contenue dans l'application et pas une copie. C'est plus économique, mais du coup, quand l'application ferme la référence est perdue.
Si ce comportement te plaît pas, y'a des applications qui quand tu selectionne un truc en gardent une copie pour que ça reste après la fermeture de l'appli source.
En X brut c'est xclipboard, pour KDE klipper s'en charge, et fait bien d'autres choses !
Remarque qu'en terme purement techniques, le comportement d'X a l'air mieux vu qu'il est adaptable.
Mais en terme d'ergonomie, ça serait mieux si on exécutait klipper par défaut sur les distribs grand public... je sait pas quelle est la tienne, si c'en est une, tu peut envisager un rapport de bug.
Contre ça, c'est sûr, y'a rien à faire : si tu a N architecture binairement incompatibles, il te faudras N binaires (quitte à tous les faire tenir dans un seul ELF, comme sous MacOS X).
systemes de gestion de paquets hétérogenes
C'est mieux que pas de paquets ! L'installateur loki marche partout, que je sache. Et y'en a d'autres.
arborescence différente
Tu installe ton truc dans /opt/MonAppli, et tout va bien.
systeme de menus différents[...]oui XDG arrange les choses. C'est adopté partout ?
Si parle des desktop entry, c'est supporté par KDE et Gnome, ce que l'utilisateur débutant utiliseras toujours.
desktops differents
Et même des thèmes de bureau différents... où va le monde ?
Enfin, ceci dit, c'est à la distrib de s'occuper de la cohèrence de ce joyeux bourdel. kgtk et gtk-qt uniformisent le look and feel avec celui de mon bureau KDE ça me suffit bien.
Ou alors, tu fait comme sous windows : ton propre système de skins qui ressemble à rien (cf des applis pourtant populaires, comme Firefox, winamp, microsoft truc player), ou alors tu t'en fout (comme office XP qui ne s'intègre graphiquement qu'au dernier windows).
Bien entendu, dès que tu ne supportes pas un des composants possibles, tu te fais flamme
Et là c'est le drame, parce que quand on te critique tu a envie de te suicider. Donc tu peut pas survivre sous GNU/Linux (ni en démocratie).
tu t'en fous : de toute facon tu te fera flammer "pourriture propriétaire"
Pouriture propriétaire.
le bonheur pour coller une icone dans la systray sous linux (gnome, kde, fluxbox etc). Sous windows, c'est la meme API depuis 1995.
Réjouit toi ! Cette merveilleuse API est disponible sous Linux ! D'ailleurs Miguel de Icaza a annoncé que le prochain Gnome serait codé en api win32 grâce à wine (ou peut-être est-ce google ?).
je parle pas du son
T'a raison, paske alsa ça marche bien, et qu'OSS survit pour la compatibilité.
du clipboard
J'avais vu une foi à quoi ressemblait l'utilisation du presse papier et du "drag&drop" en API win32, et j'ai cru à une farce.
Enfin, je sait pas si l'API X native est mieux, mais je sait qu'elle est standardisée depuis au moins aussi longtemps. D'après FreeDesktop, Gnome et KDE sont d'accord sur la manière de l'utiliser depuis KDE3.
du toolkit
À mon avis doit y'avoir autant de toolkit sous windows, puisque GTK et Qt sont porté. La différence c'est que comme presque tout le monde utilise juste les deux thèmes du systèmes, il suffit de les mettre par défaut dans Qt et GTK pour l'interface ait l'air cohérente.
Si y'avais que deux thème sous Linux, ça serait vite fait d'unifier les widgets. (l'UI c'est autre chose, mais comme sous windows les improbables standards d'IHM se font violer tout les matins...)
Du reste si ton soft est bien, il va se faire packager, même proprio. cf la section non-free de ta distrib. Et si il se fait pas packager, tu est renvoyé à la case loki/inno setup/plopmatic3000. Comme sous win.
Je voudrais savoir comment monté ce dossier sur mon Linux, je crois savoir qu'il faut que j'installe du smb-client.
Normalement, t'a juste à tapper smb:/ dans ton konqueror, et tu verras ton réseau.
lan:/ propose en plus de voir tout les protocoles supportés (samba, mais aussi ftp ou autres).
Ha oui, faut la distrib aussi : j'utilise kde-base/konqueror-3.5.2 sous Gentoo. Mais je pense qu'en l'ocurence c'est plutôt la version de kdelibs qui compte, et là elle est bien patchée : kde-base/kdelibs-3.5.2-r5 .
Peut être que le fix est déjà dans le CVS et à été backporté dans l'ebuild ?
Supprime le débat binaire/libre. Le format binaire ne permet que de mettre en lumière des utilisateurs le problème.
Le seul moyen d'éviter ça serait de faire un kernel générique proposant des trucs qui ne me serviraient pas, de le mettre sur toutes les machines.
Vois pas le rapport. Je te parles uniquement de stabilité des interfaces pour faciliter le travail des développeurs de pilotes, qui sont des plus des mainteneurs que des développeurs.
Bein, pour le coup, le fait que le format soit binaire est justement la source du problème que j'essaie de te présenter : les noyaux changent trop d'un système à l'autre pour pouvoir tous les supporter sans avoir recours à la compilation conditionelle.
il est donc tout à fait possible de faire des évolutions sans toucher aux interfaces, et quand l'interface doit absolument bougée (ce qui normalement ne doit pas arriver souvent lorsqu'elle est pensée), ben suffit d'en faire une nouvelle tout en gardant l'ancienne, par soucis de compatibilité.
Justement, l'argument des developpeurs du kernel est qu'en supprimant les API obsolètes, il empêchent les developpeurs d'utiliser les vieux paradigmes et amélliorent la qualité du noyau.
Supprime le débat binaire/libre. Le format binaire ne permet que de mettre en lumière des utilisateurs le problème.
Le seul moyen d'éviter ça serait de faire un kernel générique proposant des trucs qui ne me serviraient pas, de le mettre sur toutes les machines.
Vois pas le rapport. Je te parles uniquement de stabilité des interfaces pour faciliter le travail des développeurs de pilotes, qui sont des plus des mainteneurs que des développeurs.
Bein, pour le coup, le fait que le format soit binaire est justement la source du problème que j'essaie de te présenter : les noyaux changent trop d'un système à l'autre pour pouvoir tous les supporter sans avoir recours à la compilation conditionelle.
il est donc tout à fait possible de faire des évolutions sans toucher aux interfaces, et quand l'interface doit absolument bougée (ce qui normalement ne doit pas arriver souvent lorsqu'elle est pensée), ben suffit d'en faire une nouvelle tout en gardant l'ancienne, par soucis de compatibilité.
Justement, l'argument des developpeurs du kernel est qu'en supprimant les API obsolètes, il empêchent les developpeurs d'utiliser les vieux paradigmes et amélliorent la qualité du noyau.
Par exemple, la doc mentionne qu'ils sont passé d'un API synchrone a une API asynchrone, pour la gestion de l'usb.
Alors, oui, ils auraient pu faire un API asynchrone dès le début. À condition de savoir dès le début que ce serait le meilleur choix (d'ailleurs je ne sait pas où en est windows de ce point de vu). Et si ils ne maintiennent pas l'ancienne interface c'est paske les gens qui l'utiliseraient nuiraient au performances globales du noyau (peut être à cause du temps passé à attendre, si les I/O sont bloquantes et le kernel monolithique).
C'est pas juste une question d'API, le problème est directement lié au code du pilote. Il faut le réecrire.
les OS proprio montrent clairement le contraire (que ce soit OSX ou Zindows, les interfaces de drivers changent pas tous les mois, sans que cela freine leurs évolutions).
Heu, faut dire que j'aurais du mal à parler des évolutions du kernel windows, vu qu'y a pas de changelog. Mais à priori, le kernel Linux propose bien plus : PaX, Netfilter, la préemption plus ou moins mole, la fourniture d'une émulation wifi logicielle pour factoriser les drivers, Fuse, lm-sensors...
De l'avis de développeur du kernel, les "innovations" de la pile IP toute neuve de microsoft windows vista(tm) sont présentes depuis des lustres sous linux. http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/05/13#tc(...)
Et je suppose qu'il doit y avoir une foule d'exemples similaires (le support du "flag NX" par exemple, "nouveauté" de msw xp sp2).
C'est comme si les intefaces de programmation de n'importe quelle lib bougeait tous les jours, les libs KDE, les libs Qt, les libs Gnome, les libs nimporte-quoi. Dans toutes ces libs il y a une recherche de la stabilité et de la compatibilité.
Pour Qt (et GTK?) c'est diffèrent : on est pas face à un système monolithique qui, si il est mal utilisé, fait planter/ramer tout le système. Qu'une application utilise mal Qt, et elle rameras, sans faire ramer le système.
Après y'a la question de savoir si monolitique c'est bien. Pour moi oui, mais c'est un autre troll.
Du reste, les API Qt/KDE sont bel et bien mise à jour régulièrement, avec même un version majeure tout les deux ans en moyenne (4 en 8ans). Et à mon avis pas mal de changement entre temps puisque par exemple les décorateurs de fenêtre exigent souvent KDE 3.2 .
En fait, tu considère comme des problème des choses qui sont directement liées à la nature de Linux.
Par exemple, le "problème" de compatibilité vient pas uniquement des nettoyages fréquents de l'interface, mais aussi du simple fait que le kernel soit modifiable.
Par exemple, mon kernel il est partiellement préemptible, pas SMP mais avec les 4k stacks, compilé avec un certain GCC...
Le seul moyen d'éviter ça serait de faire un kernel générique proposant des trucs qui ne me serviraient pas, de le mettre sur toutes les machines.
Sauf que c'est comme imposer Gnome/KDE/... à tout le monde : moi j'en veut pas.
il n'est pas impossible de faire de grosses évolutions genre tous les 3 ans
"Release early. Release often. And listen to your customers." (La cathédrale et le bazar)
Comme la GPL, c'est effectivement le choix d'un modèle de développement, mais qui est fondamental. Un kernel qui ne serait pas comme ça ne serait pas Linux : on ne pourrait pas avoir le même feedback.
Donc un logiciel qui t'irai bien, ça serais un logiciel contrôlé par une boite qui fait son truc dans son coin, mais qui après le publierais en libre.
Apparemment, ça ne correspond pas à ce que la plupart des gens apprécient, sinon on serait tous sous Solaris.
J'espère que ça t'auras aidé à comprendre la situation actuelle.
Sinon, y'a d'autre point sur lesquels j'aimerais revenir.
Notement : même si une couche de compatibilité existait dans le kernel, Nvidia/ATI ne pourraient pas l'utiliser, parce qu'en le faisant leur trucs dériverait directement du kernel et que du coup il devraient présenter le code à leur clients.
À cause de ça et pour ne pas dupliquer le code destiné à windows, ils seraient obligés de faire comme à l'heure actuelle, à savoir une couche intermédiaire.
D'ailleurs, il existe déjà quelques mécanismes génériques dans le kernel (ça s'appelle drm pour ce que j'en sait). Simplement nvidia a décidé de refaire son propre truc, parce que ça leur plaisait mieux. Et ATI comme Nvidia ont leur propre agpgart, "juste pour le fun" (tout le monde le désactive).
Donc, de mon point de vue, une couche d'abstraction pour les pilotes graphiques n'aurait que deux utilisateurs potentiels (ATI et Nvidia) qui, à cause de divergences de points de vue et aussi pour des raisons "politiques", ne l'utiliseraient probablement pas.
"bouuh vous filez pas les sources !"
Juste les specs ça serait déjà bien.
Et qu'on vienne pas me dire "gnagnagna les interfaces figées c'est naz, ca tue l'innovation"
Curieuse manière de reprendre les arguments formulés dans stable_api_nonsense.txt du dossier Documentation de ton kernel favori. D'ailleurs c'est un raillerie ou une tentative de discutter ?
c'est juste un aveu de mauvais design
Un aveu que le design est perfectible, nuance. En même temps, c'est plus la reconnaissance d'une loi universelle qu'un aveu à proprement parler.
J'ai pas vraiment compris tous les détails techniques, mais il me semble qu'il s'agit d'une nouvelle très importante.
Lis l'article, il y est juste question de distribuer des rétroportages de drivers récents pour les noyaux des distributions Suse.
En effet, la compatibilité hardware est le problème numéro 1 de linux, au moins en ce qui concerne son adoption massive.
Pas seulement, il y a aussi la compatibilité avec les logiciels, et les différences dans l'interface. Et puis le nom. Et les liens privilégiés entre microsoft et un certain nombre d'acteur du monde l'informatique.
La manière la plus efficace de faire adopter "Linux" serait que microsoft fasse ce qu'a fait apple avec un BSD : une version libre minimale bardée de composants propriétaires qui motoriserais ms windows vista+1. Si ils font bien leur coup, y'a même moyen que l'utilisateur s'en rende pas compte.
Et comme ça y'auras du "Linux" partout, et tu seras content.
Hum l'idée est là, mais l'efficacité serait celle à peu près celle de shake 0.5 .
Pour commencer, Filefrag, à mon avis, a été crée à des fins de déboguage, et pas dans le but d'évaluer l'impact de la fragmentation sur les performances.
Par exemple, il considère que deux "morceaux" distants d'un unique block sont des fragments, alors qu'en pratique la taille du trou peut être négligeable en terme de performances. De même, il ne tient pas compte des liens qui existent entre les fichiers ayant un atime proche, ni de la taille des fragments relativement à celle du fichier, ni de la date des fichiers.
Ensuite, le couple cp/rm a plusieurs inconvénients. Par exemple si ton fichier "A" est hardlinké vers "B" et que tu fait un "cp A TEMP; rm A; cp TEMP A", le lien dur entre "A" et "B" sera perdu. De même, pour les éventuelles métadonnés.
Tu me diras, un "cat A > TEMP" n'auras pas certains de ces inconvénients. C'est vrai, mais il ne géreras pas les fichiers sparses.
Je suppose aussi qu'on pourrait en fait contourner les problèmes liés à filefrag avec un gros script (awk ? perl ?) qui en parserait la sortie et recalculerais des informations de fragmentation plus utilisables. De meme, on pourrait effectivement utiliser ls pour trier les fichier par atime, puis réutiliser les informations extraites par le script parsant filefrag pour calculer (comme je le fait) la position idéale et ainsi de suite.
Les difficultés liées à cp me paraissent plus difficilement contournables... et il faudrais encore s'occuper de la gestion des erreurs, penser à éviter les liens symboliques etc.
Déjà à ce stade, je pense que le code serait beaucoup plus lourd et complexe que celui de shake, tout en ayant des performances moindre, et (au choix) le problème des fichiers sparses ou des métadonnées. Et il resterais encore à tenir compte du coût lié à la copie de gros fichiers, de la différence d'atime dans le calcul des corrélations entre les fichiers... sans parler du fait qu'aparement filefrag soit destiné à Linux uniquement (bon, shake aussi actuellement, mais pas à terme).
Alors que, finalement, shake c'est juste trois fichiers de 300 lignes en C, qui se veulent propres, abondament commentées et documentées dans un joli PDF.
En plus shake vient avec des routines spécialisées, notement un système de copie des fichiers sparse qui essaie de tenir compte d'une évaluation de la lecture anticipée de la plupart des disques, une routine pour modifier le ctime et un joli mode verbose.
Et j'en ai mis un coup à mon /usr/bin sans même le casser !
Mangez-en !
Ceci dit, en toute honnêteté, je doit dire que le choix du langage était aussi guidé par le fait que l'UE soit intitulée "Programation en C" -_^. Il reste que je suis sincère quand j'affirme penser que le langage était adapté.
[^] # 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é à 0.
Donc pour moi, il faudrait refaire une autre API minimaliste conçue spécifiquement pour la 2d, et l'implémenter directement par dessus DRI (pour les perfs).
La transparence réseau serait un plus; surtout que ça permetrais de gérer proprement une confinement et faire que des applications de privilèges différents s'affichent sans risque sur le même écran (ce qui n'était pas le cas sous mswindows à l'époque où j'ai regardé).
Et on appellerais ça un serveur X.
De quoi tu parle ? De protéger les serveurs X les uns contre les autres ? M'est avis que ça seras dur vu que sous x86 on peine déjà à protéger le kernel contre la carte graphique, faute d'IO-MMU (peut être plus avec les nouveaux processeurs gérant la virtualisation, ou avec le hack de Linus avec le GART auquel j'ai rien capté).
[^] # Re: content-type dans le filesystem
Posté par un_brice (site web personnel) . En réponse à la dépêche Le développement d'ext4 a commencé. Évalué à 1.
Enfin, je suppose qu'on pourrait effectivement dire à cette lib de mémoriser le résultat de ses investigations dans un xattr, mais je m'attends pas à ce que les performances s'envolent (sans parler des problèmes sur les fichiers en lecture seul).
Sinon, même sans hacker la libmagic on pourrais probablement ajouter la mémorisation aux composants des bureaux qui identifient les types de fichiers. Ça serait un peu moins gore, mais pas tellement plus utile.
[^] # Re: Tout le monde
Posté par un_brice (site web personnel) . En réponse au journal Un gestionnaire de fenêtre par semaine: Windows Vista Beta 2. Évalué à 3.
Si je comprends bien, ça ne vaut que pour les pilotes graphique et ça correspond à la répartition des taches actuellement en vigueur entre Linux et Xorg-x11 :
http://www.ati.com/products/wp/ATIVistaWDDMWhitepaperfinalv3(...)
(un truc plus intéressant est le scheduler de ressources graphiques pour les systèmes multi-GPU)
[^] # Re: divergence d'opinion
Posté par un_brice (site web personnel) . En réponse au journal Une présidentiable de gauche rencontre une figure emblématique du LL. Évalué à 4.
Pas que l'homosexualité me paraisse maléfique, ou moins "conforme à la nature" qu'une glace à la fraise (presque sûr qu'y a plus de singes homos que de congélateurs sauvages), mais faut reconaître que c'est parfois lourd...
Reste que l'intention est bonne, et ça fait plaisir :-).
[^] # Re: précision
Posté par un_brice (site web personnel) . En réponse au journal Fin du développement de WinFS.. Évalué à 4.
Après, effectivement, le site web que Madame Germaine pensait avoir enregistré sur son ordinateur puis retrouvé avec locate:/ est en fait un fichier .desktop, mais ça....
Bon, et ça c'est pour locate:/, le cas d'audiocd:/ qui présente un CD audio sous forme d'un conteneur de musique sous différents formats, ou d'applications:/ montre encore mieux que KIO représente des objets quelque soit leur nature.
[^] # Re: précision
Posté par un_brice (site web personnel) . En réponse au journal Fin du développement de WinFS.. Évalué à 2.
# ICC
Posté par un_brice (site web personnel) . En réponse au journal Benchmarks de GCC 4.1. Évalué à 1.
Pour enfoncer le clou, j'avais fait des essais pifomètriques avec ICC sur un système un peu ancien (Athlon XP Palomino) et c'était un massacre. À croire qu'il ne compile correctement que pour les derniers processeurs.
Et en plus c'est pas libre.
[^] # Re: Le coup classique contemporain
Posté par un_brice (site web personnel) . En réponse au journal [HS] Recursivité du discours. Évalué à 4.
Ce qui est sur, c'est que tes phrases, pour musicales qu'elles sont, n'ont pas de sens direct.
Si tu a le temps, j'aimerais bien une pierre de rosette "français philosophique"/"français de documentation technique".
=> Non P égal P appartient à U. De même, S(t0) == Non S(t0+1).
=> Les gens vivants dans l'occident "brassent" (acceptent ?) toutes les visions du monde, par opposition à ceux qui rejettent celles différentes de la leur.
=>Le rejet ni l'acceptation n'ont de justification.
=>En conséquence de quoi, les écervelés (toujours les même gens vivant en Occident ?) se suicident, tuent(1) ou ne font rien (2) et se font tuer.
=>Certains français sont libres du devoir politiquement correct de paraître non politiquement correct.
=>Ils se refusent également à penser les racistes comme une race infèrieure.
=>Ils résistent également à dire que contester la norme est dans la norme.
=>Ils ne veulent non plus pas que l'absence d'ordre moral soit le seul ordre moral envisageable.
=>Et caetera. Tout ceci me donne une idée positive de l'avenir.
[^] # Re: c'est déjà possible
Posté par un_brice (site web personnel) . En réponse au journal Un lecteur en ligne en AJAX ?. Évalué à 3.
Je sait que c'est pas à la porté de tout le monde, mais je pense que c'est largement à la porté du DLFPien moyen. Pour les autres, voir chapitre suivant.
Pour le coup c'est utile. Mais au quotidien, la plupart des gens se connectent depuis chez eux et, de mon point de vue, il est légitime d'être surpris de l'attention que reçoivent les interfaces web par rapport au clients "lourds".
Du reste, cette remarque s'applique très mal au sujet initial de la vidéo, mais on avait déjà commencé à en sortir.
Par contre cette phrase je la comprends pas. Tu veut dire que tu trouve plus sécurisé un client fermé, codé dans un mix de langages qui comuniquent le plus souvent en clair et par XML la moindre de tes actions à un serveur les loguant comme ça lui chante, plutôt qu'un bon vieux logiciel comme ont les écrit depuis des decenies ?
Il t'a pas agressé non plus. Il a juste dit qu'il préférait un client "lourd". Ça ne t'empêche pas de faire quoi que ce soit.
Question de point de vue apparement. Moi je préfère un machin qui me dit ouvrir/enregistrer et permet utilise mon interface favorite bien integré au desktop plutôt qu'un truc dont le comportement et l'allure varient avec chaque page que je visite.
Après ça dépend aussi de si on voit le site comme une oeuvre en elle même ou juste un moyen de comuniquer l'information. Mais remarque, comme quelqu'un l'a dit plus haut, rien n'empêche de proposer les deux.
[^] # Re: marf
Posté par un_brice (site web personnel) . En réponse au journal Des standarts reconnus .... Évalué à 10.
[^] # Re: Pas sur
Posté par un_brice (site web personnel) . En réponse au journal CD Fujifilm...pas de lecture possible sous Linux !. Évalué à 10.
Pour savoir de quel type peut bien être ce CD, un peut rendre service.
[^] # Re: Symétrie !
Posté par un_brice (site web personnel) . En réponse au journal [HS] enigme refléchie. Évalué à 7.
C'est pas une rotation sur l'axe horizontal, sinon mettre le mirroir perpendiculaire à sa position initiale inverserais haut et bas. C'est une symétrie plane.
Le reste conserve un peu de sens, mais ton histoire de référentiels me parrait cheloue... le problème vient pas de ce qu'on définisse la droite et la gauche d'une manière ou d'une autre : il y a bien une "inversion" : met ton miroir sur l'axe nord-sud, place toi en face, montre le du doigt, tu va montrer le nord et le reflet le sud (ou réciproquement).
En fait le problème c'est que le miroir inverse pas "la gauche et la droite", il fait sa pauvre symétrie, et comme il est face à nous ça inverse la position du corps qui nous sert à définir "droitier" et "gaucher".
Donc pour moi la difficulté de la question vient de ce qu'on nous incite à raisonner en de mauvais terme ("inversion de cotés -> rotation" au lieu de la symétrie plane).
Et du coup je comprends pas comment tu peut conclure en raisonnant sur des rotations.
# Synchronisation
Posté par un_brice (site web personnel) . En réponse au journal Encore et toujours Google. Évalué à 3.
Ça synchronise Konqueror, basket, Kopete, akregator et tout mes documents... faut juste changer le DIRS suivant ses besoins, lancer le script et maintenir [entrée] apuyé. Quand y'a un conflit il pose la question et demande quelle version conserver.
Si on veut pas utiliser de serveur de stockage, on peut mettre directement le nom du PC "partenaire".
Là ça utilise unison comme backend, donc c'est plutôt adapté à deux postes au plus. Mais je crois que Google (on y revient...) a publié en GSOC un logiciel libre adapté à plus de postes.
[^] # Re: intérêt
Posté par un_brice (site web personnel) . En réponse au journal Un regard sur KOffice 2.0. Évalué à 2.
Du reste, inclure un document Koffice dans un autre est, et à toujours été, possible, apparemment là c'est la manière dont ça l'est qui change...
[^] # Re: Autres navigateurs ?
Posté par un_brice (site web personnel) . En réponse à la dépêche Google de plus en plus proche du libre (?). Évalué à 7.
http://developer.kde.org/summerofcode/soc2006.html
Décidement ils sont partout... enfin tant que c'est pour coder du libre, ça me va.
[^] # Re: .
Posté par un_brice (site web personnel) . En réponse au journal Les Bureaux de demain. Évalué à 9.
Le presse papier X contient une référence à la donnée contenue dans l'application et pas une copie. C'est plus économique, mais du coup, quand l'application ferme la référence est perdue.
Si ce comportement te plaît pas, y'a des applications qui quand tu selectionne un truc en gardent une copie pour que ça reste après la fermeture de l'appli source.
En X brut c'est xclipboard, pour KDE klipper s'en charge, et fait bien d'autres choses !
Remarque qu'en terme purement techniques, le comportement d'X a l'air mieux vu qu'il est adaptable.
Mais en terme d'ergonomie, ça serait mieux si on exécutait klipper par défaut sur les distribs grand public... je sait pas quelle est la tienne, si c'en est une, tu peut envisager un rapport de bug.
[^] # Re: .
Posté par un_brice (site web personnel) . En réponse au journal Les Bureaux de demain. Évalué à 9.
C'est mieux que pas de paquets ! L'installateur loki marche partout, que je sache. Et y'en a d'autres.
Tu installe ton truc dans /opt/MonAppli, et tout va bien.
Si parle des desktop entry, c'est supporté par KDE et Gnome, ce que l'utilisateur débutant utiliseras toujours.
Et même des thèmes de bureau différents... où va le monde ?
Enfin, ceci dit, c'est à la distrib de s'occuper de la cohèrence de ce joyeux bourdel. kgtk et gtk-qt uniformisent le look and feel avec celui de mon bureau KDE ça me suffit bien.
Ou alors, tu fait comme sous windows : ton propre système de skins qui ressemble à rien (cf des applis pourtant populaires, comme Firefox, winamp, microsoft truc player), ou alors tu t'en fout (comme office XP qui ne s'intègre graphiquement qu'au dernier windows).
Et là c'est le drame, parce que quand on te critique tu a envie de te suicider. Donc tu peut pas survivre sous GNU/Linux (ni en démocratie).
Pouriture propriétaire.
Réjouit toi ! Cette merveilleuse API est disponible sous Linux ! D'ailleurs Miguel de Icaza a annoncé que le prochain Gnome serait codé en api win32 grâce à wine (ou peut-être est-ce google ?).
T'a raison, paske alsa ça marche bien, et qu'OSS survit pour la compatibilité.
J'avais vu une foi à quoi ressemblait l'utilisation du presse papier et du "drag&drop" en API win32, et j'ai cru à une farce.
Enfin, je sait pas si l'API X native est mieux, mais je sait qu'elle est standardisée depuis au moins aussi longtemps. D'après FreeDesktop, Gnome et KDE sont d'accord sur la manière de l'utiliser depuis KDE3.
À mon avis doit y'avoir autant de toolkit sous windows, puisque GTK et Qt sont porté. La différence c'est que comme presque tout le monde utilise juste les deux thèmes du systèmes, il suffit de les mettre par défaut dans Qt et GTK pour l'interface ait l'air cohérente.
Si y'avais que deux thème sous Linux, ça serait vite fait d'unifier les widgets. (l'UI c'est autre chose, mais comme sous windows les improbables standards d'IHM se font violer tout les matins...)
Du reste si ton soft est bien, il va se faire packager, même proprio. cf la section non-free de ta distrib. Et si il se fait pas packager, tu est renvoyé à la case loki/inno setup/plopmatic3000. Comme sous win.
# Pas la peine
Posté par un_brice (site web personnel) . En réponse au message Montage d'un dossier partagé Windows sous Linux.. Évalué à 3.
lan:/ propose en plus de voir tout les protocoles supportés (samba, mais aussi ftp ou autres).
Doit y'avoir pareil sous Gnome. Ou peut être pas.
[^] # Re: konqueror aussi ?
Posté par un_brice (site web personnel) . En réponse au journal Vivent les web-master de la SNCF et les programmeur de Safari. Évalué à 1.
http://vleu.net/linuxfr/konqui-sncf-res.png
http://vleu.net/linuxfr/konqui-sncf.png
D'ailleurs j'ai déjà commandé des billets là bas.
Ha oui, faut la distrib aussi : j'utilise kde-base/konqueror-3.5.2 sous Gentoo. Mais je pense qu'en l'ocurence c'est plutôt la version de kdelibs qui compte, et là elle est bien patchée : kde-base/kdelibs-3.5.2-r5 .
Peut être que le fix est déjà dans le CVS et à été backporté dans l'ebuild ?
[^] # Re: Une nouvelle très importante
Posté par un_brice (site web personnel) . En réponse au journal Personne n'en a parlé ? Une interface driver intelligente bientôt sous Linux !. Évalué à 6.
Bein, pour le coup, le fait que le format soit binaire est justement la source du problème que j'essaie de te présenter : les noyaux changent trop d'un système à l'autre pour pouvoir tous les supporter sans avoir recours à la compilation conditionelle.
Justement, l'argument des developpeurs du kernel est qu'en supprimant les API obsolètes, il empêchent les developpeurs d'utiliser les vieux paradigmes et amélliorent la qualité du noyau.
Bein, pour le coup, le fait que le format soit binaire est justement la source du problème que j'essaie de te présenter : les noyaux changent trop d'un système à l'autre pour pouvoir tous les supporter sans avoir recours à la compilation conditionelle.
Justement, l'argument des developpeurs du kernel est qu'en supprimant les API obsolètes, il empêchent les developpeurs d'utiliser les vieux paradigmes et amélliorent la qualité du noyau.
Par exemple, la doc mentionne qu'ils sont passé d'un API synchrone a une API asynchrone, pour la gestion de l'usb.
Alors, oui, ils auraient pu faire un API asynchrone dès le début. À condition de savoir dès le début que ce serait le meilleur choix (d'ailleurs je ne sait pas où en est windows de ce point de vu). Et si ils ne maintiennent pas l'ancienne interface c'est paske les gens qui l'utiliseraient nuiraient au performances globales du noyau (peut être à cause du temps passé à attendre, si les I/O sont bloquantes et le kernel monolithique).
C'est pas juste une question d'API, le problème est directement lié au code du pilote. Il faut le réecrire.
Heu, faut dire que j'aurais du mal à parler des évolutions du kernel windows, vu qu'y a pas de changelog. Mais à priori, le kernel Linux propose bien plus : PaX, Netfilter, la préemption plus ou moins mole, la fourniture d'une émulation wifi logicielle pour factoriser les drivers, Fuse, lm-sensors...
De l'avis de développeur du kernel, les "innovations" de la pile IP toute neuve de microsoft windows vista(tm) sont présentes depuis des lustres sous linux.
http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/05/13#tc(...)
Et je suppose qu'il doit y avoir une foule d'exemples similaires (le support du "flag NX" par exemple, "nouveauté" de msw xp sp2).
Pour Qt (et GTK?) c'est diffèrent : on est pas face à un système monolithique qui, si il est mal utilisé, fait planter/ramer tout le système. Qu'une application utilise mal Qt, et elle rameras, sans faire ramer le système.
Après y'a la question de savoir si monolitique c'est bien. Pour moi oui, mais c'est un autre troll.
Du reste, les API Qt/KDE sont bel et bien mise à jour régulièrement, avec même un version majeure tout les deux ans en moyenne (4 en 8ans). Et à mon avis pas mal de changement entre temps puisque par exemple les décorateurs de fenêtre exigent souvent KDE 3.2 .
[^] # Re: Une nouvelle très importante
Posté par un_brice (site web personnel) . En réponse au journal Personne n'en a parlé ? Une interface driver intelligente bientôt sous Linux !. Évalué à 10.
Par exemple, le "problème" de compatibilité vient pas uniquement des nettoyages fréquents de l'interface, mais aussi du simple fait que le kernel soit modifiable.
Par exemple, mon kernel il est partiellement préemptible, pas SMP mais avec les 4k stacks, compilé avec un certain GCC...
Le seul moyen d'éviter ça serait de faire un kernel générique proposant des trucs qui ne me serviraient pas, de le mettre sur toutes les machines.
Sauf que c'est comme imposer Gnome/KDE/... à tout le monde : moi j'en veut pas.
"Release early. Release often. And listen to your customers." (La cathédrale et le bazar)
Comme la GPL, c'est effectivement le choix d'un modèle de développement, mais qui est fondamental. Un kernel qui ne serait pas comme ça ne serait pas Linux : on ne pourrait pas avoir le même feedback.
Donc un logiciel qui t'irai bien, ça serais un logiciel contrôlé par une boite qui fait son truc dans son coin, mais qui après le publierais en libre.
Apparemment, ça ne correspond pas à ce que la plupart des gens apprécient, sinon on serait tous sous Solaris.
J'espère que ça t'auras aidé à comprendre la situation actuelle.
Sinon, y'a d'autre point sur lesquels j'aimerais revenir.
Notement : même si une couche de compatibilité existait dans le kernel, Nvidia/ATI ne pourraient pas l'utiliser, parce qu'en le faisant leur trucs dériverait directement du kernel et que du coup il devraient présenter le code à leur clients.
À cause de ça et pour ne pas dupliquer le code destiné à windows, ils seraient obligés de faire comme à l'heure actuelle, à savoir une couche intermédiaire.
D'ailleurs, il existe déjà quelques mécanismes génériques dans le kernel (ça s'appelle drm pour ce que j'en sait). Simplement nvidia a décidé de refaire son propre truc, parce que ça leur plaisait mieux. Et ATI comme Nvidia ont leur propre agpgart, "juste pour le fun" (tout le monde le désactive).
Donc, de mon point de vue, une couche d'abstraction pour les pilotes graphiques n'aurait que deux utilisateurs potentiels (ATI et Nvidia) qui, à cause de divergences de points de vue et aussi pour des raisons "politiques", ne l'utiliseraient probablement pas.
Juste les specs ça serait déjà bien.
Curieuse manière de reprendre les arguments formulés dans stable_api_nonsense.txt du dossier Documentation de ton kernel favori. D'ailleurs c'est un raillerie ou une tentative de discutter ?
Un aveu que le design est perfectible, nuance. En même temps, c'est plus la reconnaissance d'une loi universelle qu'un aveu à proprement parler.
[^] # Re: Une nouvelle très importante
Posté par un_brice (site web personnel) . En réponse au journal Personne n'en a parlé ? Une interface driver intelligente bientôt sous Linux !. Évalué à 5.
Pas seulement, il y a aussi la compatibilité avec les logiciels, et les différences dans l'interface. Et puis le nom. Et les liens privilégiés entre microsoft et un certain nombre d'acteur du monde l'informatique.
La manière la plus efficace de faire adopter "Linux" serait que microsoft fasse ce qu'a fait apple avec un BSD : une version libre minimale bardée de composants propriétaires qui motoriserais ms windows vista+1. Si ils font bien leur coup, y'a même moyen que l'utilisateur s'en rende pas compte.
Et comme ça y'auras du "Linux" partout, et tu seras content.
[^] # Re: XFS
Posté par un_brice (site web personnel) . En réponse au journal Shake : secouez vos fichiers, c'est pour leur bien !. Évalué à 1.
[^] # Re: Fragmentation
Posté par un_brice (site web personnel) . En réponse au journal Shake : secouez vos fichiers, c'est pour leur bien !. Évalué à 2.
[^] # Re: ...
Posté par un_brice (site web personnel) . En réponse au journal Shake : secouez vos fichiers, c'est pour leur bien !. Évalué à 10.
Pour commencer, Filefrag, à mon avis, a été crée à des fins de déboguage, et pas dans le but d'évaluer l'impact de la fragmentation sur les performances.
Par exemple, il considère que deux "morceaux" distants d'un unique block sont des fragments, alors qu'en pratique la taille du trou peut être négligeable en terme de performances. De même, il ne tient pas compte des liens qui existent entre les fichiers ayant un atime proche, ni de la taille des fragments relativement à celle du fichier, ni de la date des fichiers.
Ensuite, le couple cp/rm a plusieurs inconvénients. Par exemple si ton fichier "A" est hardlinké vers "B" et que tu fait un "cp A TEMP; rm A; cp TEMP A", le lien dur entre "A" et "B" sera perdu. De même, pour les éventuelles métadonnés.
Tu me diras, un "cat A > TEMP" n'auras pas certains de ces inconvénients. C'est vrai, mais il ne géreras pas les fichiers sparses.
Je suppose aussi qu'on pourrait en fait contourner les problèmes liés à filefrag avec un gros script (awk ? perl ?) qui en parserait la sortie et recalculerais des informations de fragmentation plus utilisables. De meme, on pourrait effectivement utiliser ls pour trier les fichier par atime, puis réutiliser les informations extraites par le script parsant filefrag pour calculer (comme je le fait) la position idéale et ainsi de suite.
Les difficultés liées à cp me paraissent plus difficilement contournables... et il faudrais encore s'occuper de la gestion des erreurs, penser à éviter les liens symboliques etc.
Déjà à ce stade, je pense que le code serait beaucoup plus lourd et complexe que celui de shake, tout en ayant des performances moindre, et (au choix) le problème des fichiers sparses ou des métadonnées. Et il resterais encore à tenir compte du coût lié à la copie de gros fichiers, de la différence d'atime dans le calcul des corrélations entre les fichiers... sans parler du fait qu'aparement filefrag soit destiné à Linux uniquement (bon, shake aussi actuellement, mais pas à terme).
Alors que, finalement, shake c'est juste trois fichiers de 300 lignes en C, qui se veulent propres, abondament commentées et documentées dans un joli PDF.
En plus shake vient avec des routines spécialisées, notement un système de copie des fichiers sparse qui essaie de tenir compte d'une évaluation de la lecture anticipée de la plupart des disques, une routine pour modifier le ctime et un joli mode verbose.
Et j'en ai mis un coup à mon /usr/bin sans même le casser !
Mangez-en !
Ceci dit, en toute honnêteté, je doit dire que le choix du langage était aussi guidé par le fait que l'UE soit intitulée "Programation en C" -_^. Il reste que je suis sincère quand j'affirme penser que le langage était adapté.