[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 :: Suivant ]
Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Qu'attends-tu exactement d'une gestion des liens dur dans les gestionnaires de fichiers ? Il me semble qu'ils sont complets à ce niveau là.
Si tu t'attends à ce qu'il puisse te donner tous les nom de liens correspondant à une i-node donnée, sache que ce n'est pas possible sans scanner tout le système de fichier. Cela m'étonnerait qu'ils implémentent cette fonctionnalité qui ne doit guère intéresser qu'une infime partie des utilisateurs et qui aurait une lenteur d'exécution désespérante.
Sinon, il paraît que chez kde, ils construisent des outils pour le "desktop sémantique" en s'appuyant sur les tags. Par contre, je ne sais pas du tout où cela en est, ni si c'est stable, péren ou utilisable. Si quelqu'un pouvait commenter là dessus :-p
[ Répondre ]
Rendons à César...
http://www.ted.com/index.php/talks/sugata_mitra_shows_how_ki(...)
[ Répondre ]
Re: virt-manager
L'argument fallacieux est, selon moi, que tu dises : xml implique java implique gui. gni ??
Ensuite dire que les fichiers textes sont entreprise car Unix l'est et les utilise; c'est tout aussi bof. (Unix qui date d'une époque, où XML n'existait pas/ne pouvait pas exister dans sa forme actuelle). The cfengine project was started in 1993 as a reaction to the complexity and non-portability of shell scripting for Unix configuration management, and continues today. (wikipedia), ça m'a l'air toujours très "enterprise" comme truc les fichiers de conf.
Ensuite dire: des arguments que je considère comme fallacieux : "il me faut des méta outils qui puisse me générer mes fichiers de conf"; alors que tu dis exactement la même chose...
Du beau grand troll.
[ Répondre ]
Re: virt-manager
Je vois que le XML bashing à toujours la cote ici, mais proposer du yaml à la place, c'est un peu stupide (c'est la même chose en plus ambigu/contraignant*)... Par contre, proposer un truc de plus simple, moins contraignant tel que les s-exps comme l'a fait Axioplase ne l'aurait pas été. D'ailleurs, il faudra que tu nous explique en quoi son exemple n'est pas lisible !
Tant que tu y es, tu vas nous expliquer comment tu génère/modifie/parse la configuration YAML de ton parc de 100 serveurs virtualisés. J'espère que tu ne compte pas le faire à la main...
Bref, YAML ça pue encore plus que le XML. À quoi bon ?
*: - niveaux d'indentation déterminants: beurk, vive le copier-coller !
- peu supporté, pas la peine de me sortir le nom d'une bibliothèque YAML, ce truc est 1000 fois moins supporté que le XML.
- comment fait-on pour valider ton yaml avec un schéma ? (même problème pour les s-expr). Cette tâche doit maintenant être faite par le programme lui-même (charger des nouvelle donnée et regarder si "ça passe")...
- avec XML, les noms d'attributs et les noms de tags décrivent généralement ce qu'ils contiennent. Peut-on en dire autant de ton exemple YAML ? Et les S-Exps ? ah bon, c'est pareil ;-)
[ Répondre ]
Re: virt-manager
Les fichiers textes c'est bien pour faire des petites configurations à la mimime et peu nombreuses. Mais si l'on a une multitude de domaines à gèrer avec des particularités de configuration, écrire un générateur xml s'avérera bien plus rapide/facile qu'un générateur de fichiers de configuration. Au lieu de dire XML c'est orienté clickodrome, je dirais que c'est orienté Enterpraise.
Sinon, comme dit plus haut, un des grands intérêts de virt-manager, c'est la libvirt, ses bindings (python,perl,ruby & ocaml (-: ) et ses outils CLI associers. C'est une très bonne idée d'essayer de fédérer l'usage et l'administration de machines virtuelles autour d'une API unique. Et cela, ce n'est clairement pas orienté clickodrome, même si cela favorise l'émergence de GUIs sophistiquées et inter-opérables ;-)
[ Répondre ]
Re: Ça vaut vraiment rien
Dans ce cas là, c'est déja une petite victoire de revaloriser certaines parcelles. Et puis quand il restera mois de parcelles moins chères, la déforestation devra ralentir selon les lois du marché (c'est beau, hein, l'économie).
@benoar, le fait d'utiliser ad-block ne va pas faire disparaître la pub, ni la façon dont les entreprises fonctionne (si ce n'est qu'elles trouveront un moyen encore plus pervasif pour te laver le cerveau).
Moi, cela m'a fait plaisir de savoir que l'argent des annonceurs a été utilisé à des fins écologiques. Même si cela implique la présence de liens sponsorisés sur ma page de recherche, dont je ne prête quasi pas attention et que je ne consulte jamais. Je considère la pub sur internet celle qui a le moins d'influence sur mon cerveaux: surfer n'a rien à voir, au niveau agressivité/sublimination/manipulation, avec se promener en ville ! Je n'ai pas arrêté de me promener en ville pour autant :-P
Je suis étonné aussi que personne ne s'inquiète de cette décision unilatérale de Google. Après, à peine, 3 jours de fonctionnement ! Les autres "custom search" fonctionnent-ils de la même façon (cad reçoivent de l'argent de google) ?
Bon aller, @benoar, la solution pour se débarraser des pubs semblerait être de cliquer systématiquement sur tous les liens sponsorisés !
[ Répondre ]
Re: nVidia
Toutafé, mais, au moins, on n'est pas tributaire d'une seule entreprise qui peut décider à tout moment (réduction des couts) d'arrêter la maintenance de quelque chose qui ne leur apporte plus aucun bénéfice. Quelqu'un de motivé & compétent pourra toujours en faire quelque chose.
[ Répondre ]
Re: PEBKAC ?
La phrase complète était "deviennet vite impossible à faire fonctionner". En considérant que presque à chaque fois qu'un nouveau Xorg ou qu'un noyau est disponnible, il y a une période pendant laquelle le pilote nvidia ne fonctionne pas, ce n'est pas tout à fait faux. Cela arriverait beaucoup moins fréquement si le pilote drm était en upstream dans le noyau.
Après tu peux me reprocher d'avoir upgradé et je te dirai que je n'avais pas le temps ni l'envie de tester avec chaque version de noyau précédent. J'ajouterai aussi que dans le cas que j'ai cité, le module nvidia s'est bien compilé* et que c'est le pilote gfx qui s'est planté. C'est peut-être du au type du cpu utilisé (k6-2), que les noyaux ubuntu récents ne supportent simplement plus (idem pour certains cpu via). Enfin, c'est une pure supposition; je n'ai ni le temps, ni l'envie de déterminer la cause de ce problème.
*: cela ne veut pas dire que la sémantique des api linux utilisées n'a pas changée mais j'en doute.
[ Répondre ]
Re: nVidia
C'est à dire que, ce week-end, j'ai remis à jour un vieux pc, k6-2 + geforce 2mx, en sid. J'ai suivis la procédure du wiki debian pour recompiler le pilote nvidia pour le noyau (2.6.26, Xorg 7.3). Résultat: le pilote gfx me crashe le serveur X -> retour du pilote nv et fini de jouer à crack-attack.
Donc je maintiens, lorsqu'une carte amd achetée aujourd'hui ne sera plus supportée par le pilote proprio, il y a de fortes chances qu'elle fonctionnera pleinement avec le pilote libre. On ne peut pas en dire autant du côté de nvidia.
En ce qui concerne les perfs, je n'ai pas d'avis sur la question. En ce qui concerne OpenGL 3.0, il parraît que ça n'a rien de révolutionnaire (des extensions qui sont intégrées au coeur de la norme et dépréciation de certaines fonctions). J'imagine qu'un code proprement codé pour la v2.1+extensions fonctionne pratiquement tel quel sur la v3.0. Une simple recherche permettra à l'auteur de ce journal d'avoir la liste complète des extensions supportées par un couple pilote/carte. Aussi, d'autres forum internet sont certainement plus appropriés pour poser ce genre de question.
[ Répondre ]
Re: Ca arrive
Sans être un gourou, il faut admettre que dans un kernel panic linux, quand la pile n'est pas corrompue, on a une backtrace assez complète, ce qui permet, avec un peu de déduction, de deviner la source du problème. Pas besoin de chercher pendant des heures un débuggeur, des symboles de débuggage (tiens, ça marche comment avec du code de pilotes tiers ?) et la marche à suivre pour récupérer un dump.
En ce qui concerne la récupération automatique des kernel dumps, certaines distributions on mit cela en place de manière bien conviviale: après le reboot, une petite notification apparaît pour demander d'envoyer le dump à http://www.kerneloops.org/
[ Répondre ]
Re: Ca arrive
Je conseille a tous ceux d'entre vous qui croyez en la perfection du code libre et de Linux (ou du proprio d'ailleurs hein, c'est meme topo)...
Oui et où veux-tu en venir ?
Enfin "on" se doute d'où tu veux en venir, mais là tu manque sérieusement d'un argumentaire. A+
ps: tiens, le xp sp3, est-il déja sorti ?
[ Répondre ]
Re: nVidia
Il faut savoir aussi qu'avec nvidia, les anciennes cartes devienne des citoyennes de seconde zone. Les pilotes "legacy" qui ne sont presque plus maintenus deviennent vite impossible à faire fonctioner sur un Xorg/noyau récent. Au contraire, AMD affiche une réelle volonté d'avoir un pilote libre; cela assure certainement une plus grande pérennité.
[ Répondre ]
Re: aujourd'hui, c'est vendredi -4
>> depuis la 2.16, on ne voit plus grand chose d'affriolant arriver
>J'ai essayé Conduit hier et j'ai été bluffé. Simple à utiliser, puissant et utile. De la bombe quoi.
Conduit est dans gnome maintenant ?
Troll on: avec gnome 3/gtk 3, on aura droit à une réécriture de gnome-games pour qu'il utilise clutter & cie (évolution logique apres le svg) mais quelle est la perspective (j'allais dire vision mais cela aurait fait trop jeu de mots) par rapport à l'utilisateur; mis à part le fait qu'il devra upgrader sa machine ?
[ Répondre ]
Re: aujourd'hui, c'est vendredi -4
Au hasard, quelle est ta distribution* ?
Parce qu'une distrib spécialisée dans la mao (jack, patch rt, low-latency & co) c'est p-ê too much surtout que p-a n'est pas vraiment fait pour cela.
*:Dis moi comment tu t'appelles, je te donnerai l'adresse du bugzilla ;)
[ Répondre ]
[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 :: Suivant ]
Cette page a été générée par Templeet en 0.123s (dont 0.0188 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Re: Petite question: noyau monolithique?
Les pilotes de cartes réseau sont en général assez simple et peu buggués...
Qu'est-ce qui te fais dire cela ? J'aurais tendance à penser qu'ils deviennent de plus en plus complexes à l'instar des cartes: tcp/ip offloading, queue multiples, wifi-n, ...
[...] le support de l'userspace est probablement très bon dans sa globalité en ce qui concerne les coupures impromptues du réseau.
J'imagine que l'intérêt de la démonstration était justement que wget n'en sache rien, c.-à-d. que sa connexion tcp/ip n'a pas été coupée*. En ce qui concerne la gestion des coupures réseaux, c'est clairement une fonction de la pile tcp/ip qui, pour le noyau linux, ne se trouve pas dans l'"userspace" ! Tu peux débrancer-rebrancher ton cable réseau sans que tes connections tcp/ip ne se coupent mais cela ne marchera pas au point de faire un rmmod-insmod.
Le test que tu propose avec le pilote hdd suit aussi la même logique et ne devrait donc pas poser de problèmes majeurs. Le micro-serveur qui s'occuppe du FS n'a qu'a attendre que le pilote se recharge** avant de soumettre la suite de ses ordres. L'idée est justement de séparer les sous-système dépendants en serveur différents et, je suppose que, minix3 gère cette résillience de manière +/- générique pour n'importe quel pilote.
Même si dans l'hypothèse fort improbable que Linus décide d'implementer la possibilité de recharger un pilote sans déstabiliser les couches logicielles qui en dépendent, tu n'obtiendra jamais le niveau de résillience d'un micro-noyau parce qu'il n'y a pas de séparation d'espace mémoire entre les différents pilotes/sous-systèmes et que donc un bug dans un driver peut modifier le comportement d'une autre partie du noyau (dans le pire cas), voir le crasher (dans le meilleur, car je n'aimerais pas avoir mon fs détruit à cause d'un mauvais pilote résaux ou une carte réseaux détruite à cause d'un Xorg foireux ;-)).
*:Effectivement, wget s'en sort plustôt bien quand la connection est _coupée_ en essayant de reprendre le téléchargement. Il y a dans ce cas une nouvelle connection tcp/ip effectuée et la restauration de l'état précédant la coupure est effectué par _l' application_. C'est de très loin un comportement minoritaire parmis toutes les applications réseaux existantes et qui n'est permis que parce que le protocol http/ftp permet cet usage. Rien à voir avec l'exemple qui nous occupe où la connection n'est tout simplement pas coupée...
**:En admettant qu'il ne faille pas dépendre de ce pilote pour recharger le serveur/pilote. Je ne sais pas comment minix3 gère ce cas mais en théorie cela est tout à fait possible, il suffirait d'avoir un serveur "chargeur" qui garderait en mémoire les pilotes à recharger.
[ Répondre ]