reno a écrit 3886 commentaires

Impressionant, merci.

Le mieux avec Python, c'est que meme quand on ne connait pas le language, on arrive tres bien a lire les programmes..

Interressant.

Est-il possible de construire une 'macro' qui rajouterai le '% locals' de la fin?
ie d'avoir au final 'putf("prenom: %(prenom)s nom: %(nom)s")' ?

Sinon de toute façon je trouve cette forme interressante meme si c'est un peu curieux de devoir rajouter le 's' a la fin plutot qu'au debut (a la printf), encore mieux serait de ne pas avoir a mettre de specifieur format pour les affichages par defaut..
Par exemple %20s(name) %03d(age) si tu veux preciser la taille
mais %(name) et %(age) autrement..

>mais bon, ca s'arrete la.

Bin non, cela ne s'arrete pas la: comme dit plus haut, il y a la securite, la gestion des ressources, la reactivite..

>moi je trouve ca "tout pourri" l'architecture par process.

C'est ton droit mais quelles sont tes justifications? La seule que j'ai vue dans ton post c'est la vitesse, personellement cela fait longtemps que je trouve les navigateurs suffisamment rapide en temps normal, alors maintenant j'aimerai qu'ils soient robustes:
-si un site web fige/plante le moteur de rendu, il ne fige/plante pas tout le navigateur mais juste l'onglet
-si un site web fait consommer 100% du CPU ou trop de memoire, que le navigateur me permette de trouver lequel facilement.

>la gestion des resources quand elle est faite dans l'appli via des threads c'est bien plus pointu

Ah? Pourtant c'est Chrome qui fournit de base un moyen simple de voir le cpu et la memoire utilisee par chaque onglet, pas Firefox (enfin pas de base en tout cas).

Mouai, je trouve que cela reste quand même assez mauvais par rapport a ce qui pourrait être fait:
"%{prenom} %{nom} a %03d{age}."
cela serait quand même plus lisible que d'avoir d'un coté les "insert de formatage" de l'autre les variables référencées..

Je crois que c'est possible en Ruby (mais sans la souplesse des convertisseur a la printf malheureusement).

Tu confonds Gecko et Firefox.. Je n'ai pas dit que Gecko était mauvais mais que l'architecture mono-process de Firefox était mauvaise oui.

De plus tu te contredis: tu dis qu'il est impossible de réécrire les millions de ligne mais que les developpeurs sont en train de faire le multi-process, ce qui est bien la preuve que c'est possible d'avoir une architecture correcte sans tout réécrire (de la même manière que Chrome a réutilisé Webkit sans tout réécrire non plus).

Quand a ton histoire de matériel, je te répondrais que l'intérêt principal de l'utilisation de plusieurs processus n'est *pas* d'exploiter les CPU multicoeurs/SMP (c'est juste un bonus) mais que cela permet d'avoir une meilleur gestion des ressources (et d'identifier les sites web pourris qui font consommer beaucoup de mémoire ou de CPU), une meilleure réactivité (pas d'onglet qui fige tout le navigateur) et une meilleur sécurité, besoins qui ne sont pas récents..

La raison pour laquelle les dev de Firefox implémentent maintenant les changements c'est que quand Chrome est sortie cela a mis en lumière que l'architecture de FF était pourrie..

Mauvaise architecture --> changer architecture pas utiliser des rustines..

J'espère que la version 4 de Firefox adoptera une architecture 'a la Chrome' plutot que de conserver leur architecture actuelle qui est toute pourrie..

Bof, les graphistes ce sont les memes qui ont poussé pour le Flash..
Leur interets (faire joli) sont opposés au mien (acceder a l'information le plus simplement possible).

Mmm: si tu fais un accès a un tableau avec un index invalide en C le comportement que tu as est indéfini.
Il doit y en avoir d'autre..

Le GC temps réel de la JVM d'IBM est propriétaire oui, mais l'implementation de SuperCollider est GPL.

Et pour le GC qui coopère avec la mémoire virtuelle j'ignore si l'auteur en a fait une implémentation libre mais de toute manière ses patches pour le noyau Linux ont été rejeté, ce GC n'est donc pas utilisable actuellement en effet.

Voici un lien qui parle d'un GC compatible avec le temps réel vendu par IBM (MetroNome):
http://lambda-the-ultimate.org/node/2034

Le seul language avec une implementation libre que je connais avec un GC temps reel est SuperCollider:
http://supercollider.sourceforge.net//

Comme autre ammélioration possible: un GC qui 'interagit' avec le systeme de mémoire virtuel d'un OS (nécéssite qu'il soit modifié en conséquence donc pas utilisé a l'heure actuel) pour reduire les conséquence qu'une fuite mémoire a avec un GC classique:
http://lambda-the-ultimate.org/node/2391

Juste pour ceux qui ne saurait pas, un ramasse-miette conservatif peut avoir des inconvénients: certaines données peuvent etre confondue avec des pointeurs et le résultat est que certains programmes *correctes* consomment des quantité de mémoire excessive (probleme existant surtout en mode 32bit).

Ce n'est pas qu'un probleme théorique: j'ai vu plusieurs message sur le newsgroup de D d'utilisateurs qui se plaignaient d'une consommation excessive de mémoire qui était tombé dans ce cas la (D utilise aussi le Boehm GC).

L'avantage du ramasse miette Boehm est qu'il est mature et fonctionne avec du C (enfin si le C n'est pas trop crade: pointeur XOR-és: aucun GC ne peut traiter cela pourtant c'est possible en C) mais cela n'en fait pas (et de loin) le top au niveau ramasse-miette..

Je pense notamment qu'il ne doit pas etre tres temps reels (meme s'il est incrémental d'après wikipedia).

Le besoin de diffuser le son en réseau, c'est très vieux: exemple les terminaux légers.

Pour les casques, je pense qu'effectivement avant c'était fait par le matériel, mais d'un autre coté avoir une gestion flexible des "sources sonores" est un besoin ancien aussi: cf l'utilisation de plusieurs cartes sons.

A priori tres perfectible:
Pour tester KDE, je vous conseille néanmoins d'avoir un pilote de carte graphique correct, le nouveau thème Air se repose assez bien sur les effets de transparence (la barre des tâches est carrément horrible quand la composition n'est pas activée).

Comme j'aime bien troll^W débatre, il y a un contrepoint de "L'innovation dans les interfaces graphiques est la clé de l'adoption de Linux" ici:
http://lwn.net/Articles/338103/

Et il est vrai que l'innovations dans les LL se traduit souvent par
1) un abandon de la version actuelle (plus installé très rapidement par beaucoup de distributions qui foncent toutes vers le 'tout nouveau, tout beau')
2) une nouvelle version qui a souvent des regressions par rapport a l'ancienne.

Bref un beau bazar pour les utilisateurs..
Sachant que souvent les developpeurs ne veulent pas faire évoluer progressivement leur logiciels: Netscape, KDE, etc car ils considèrent que c'est trop de travail.

Bref "l'innovation" a un cout tres important: l'instabilité.

Personellement je prefere les amméliorations successives et j'espere que les bureaux sous Linux y arriveront un jour, même si j'ai un doute: nous sommes en 2009 et il y *encore* des débats sans fin sur .. le son (entre autre!) alors que c'est quelque-chose qui n'évolue plus de manière significative depuis longtemps..

> le test d'un tel noyau "patché à chaud" n'est pas pertinent.

Ah? Pourtant si tu ne peux meme pas te permettre le temps d'un reboot c'est que le service est critique, si ton noyau se plante parce que le noyau modifié par le 'ksplicing' fait n'importe quoi, ton service tu peux l'oublier..

Je trouve la fin de ton post amusant: ce n'est pas une alternative a upgrader un noyau, mais cela permet de faire la meme chose (corriger un bug, une faille de sécurité), tu ne remarque pas comme une contradiction?

Je trouve cela curieux qu'ils pensent autant de bien de ce projet..

Certes c'est une prouesse technique mais elle n'est pas sans inconvénients: les kernels 'normaux' (ceux de Linus ou des distribs) sont très fortement utilisés et donc testé ce qui fournit une certaine assurance de robustesse, un kernel "ksplicé" peut très etre unique (!) donc a valider *tres, tres* soigneusement..

> Il faut faire la copie dans le même répertoire sinon, cela ne sert à rien.

D'accord.

>L'important est la taille de la fenêtre de temps où tu n'as ni l'ancien fichier, ni le nouveau. Le rename est considéré comme très court,

Plus exactement le rename est considéré comme 'atomique' donc normalement l'ordinateur t'assure que tu as soit l'ancien soit le nouveau (ne fonctionne qu'en local pas par NFS).

>>En pratique, la création ajustée manuellement de partitions DOS avec fdisk ne devrait pas concerner la majorité des utilisateurs (je pense). On en a besoin lorsque on ne souhaite pas dédier l'ensemble du disque à OpenBSD<<

Et moi je pense que ceux qui utilisent les OS alternatifs, il y en a une majorité qui font du multiboot et donc qui ne peuvent pas scratcher tout le disk, donc nous sommes en contradiction.

Quelqu'un a t'il des statistiques sur l'utilisation du multiboot?

>>Sinon je tient à dire que pour un utilisateur habitué, la simplicité et la concision de cet installeur s'avère confortable<<

Pour un utilisateur habitué quasiment tout est simple..
C'est bien plus difficile de fournir un outil simple a utiliser pour un nouvel utilisateur!

Bof si tu veux mon avis, l'auteur a voulu booster l'impact de son article en utilisant un affirmation spectaculaire "l'email se meurt" mais je doute qu'il ait des preuves, voire que ce soit vrai..

Les grandes forces de l'email c'est de pouvoir faire des discussions asynchrones, et sur une longue période.
Je ne vois pas beaucoup de remplaçant à ça.. Des compléments (nouveau ou pas) oui: chat, wiki,.. mais de la a dire que ça va tuer l'email..

>C'est comme photoshop: des cas très marginaux. Dans mon entourage très peu de monde a le besoin de jeux.

Il y a marginal et marginal: le nombre de joueur sur ordinateur est très, très supérieur à ceux qui ont besoin de Photoshop: un Paint.NET (puisqu'on parle de Windows) satisfera une très grande partie de ceux qui font de la retouche d'image (beaucoup qu'un Gimp aussi d'ailleurs car l'interface est bien plus simple a apprendre).

Maintenant ok, l'utilisation d'Internet arrive loin devant le jeux et donc aussi l'utilisation de Photoshop.

[[ Non sérieusement, ils ont pas été malin sur zfs, ils auraient voulu que ça soit vraiment le fs utilisé partout, ils l'auraient mis sous BSD/MIT, ou au moins double licence GPL/CDDL. Mais non ils ont voulu utiliser ZFS comme faire-valoir à OpenSolaris, et du coups les BSD ont pondu hammerfs et linux pondra btrfs à moyen terme. ]]

Bof, HammerFS c'est du DragonFlyBSD uniquement pour le moment il me semble, non?
Et comme il n'y a pas grand monde qui utilise DragonFlyBSD, je pense que Sun n'en a rien à faire (et ce d'autant plus que ZFS, lui, a été porté sur FreeBSD donc il n'est pas du tout évident que HammerFS soit porté sur FreeBSD).

Pour le reste, je ne voit pas pourquoi tu les critiques, c'est leur choix de gagner du fric avec ZFS et DTrace, et alors?
Pourquoi ne pas respecter leur choix? Ils l'ont fait conciemment..

Cela me parait très *arrogant* de prétendre dire à Sun comment ils doivent gagner leur fric..

Certes on aurait bien plus de 'jouets' si tout était sous BSD|GPL, mais c'est celui qui investi qui choisit la license, point.

En absolu oui, les *BSD sont très vivant ok, mais en relatif quand on compare l'adoption des *BSD par rapport à Linux, ce n'est pas si impressionant que ça..

DTrace? ZFS?

Le son fonctionne peut-être mieux aussi: ils se sont concentrés sur OSS, plutôt que d'avoir n-solutions..

Je n'ai pas dit que voter en utilisant un systeme de Condorcet était compliqué, j'ai dit que c'était dure a *comprendre* comment on obtenait le résultat final.

Je pense que la plupart des gens veulent comprendre comment les résultats sont comptabilisés, bon courage pour expliquer la méthode de Condorcet!

Et la méthode par approbation est toujours moin biaisée que celle qu'on a actuellement..

Tu réponds à coté de la plaque: ce n'est pas la partie sur la restriction de la GPL qui m'a fait bondir: objectivement elle met des restrictions (bien intentionnée certes, mais ce sont des restrictions), mais c'est de dire que les entreprises ne contribuent pas à cause des restrictions de la GPL alors que le noyau qui a le *plus* de contributeurs est le kernel Linux qui est sous GPL.

Donc la GPL n'empeche pas les entreprises de contribuer, affirmer le contraire dans une FAQ c'est très, très tendencieux.

Il y a certes des exception notoires:
-Sun qui a volontairement créer une license incompatible avec l'existant GPL mais compatible avec les OS *BSD, mais est-ce a cause de la GPL ou bien de la concurrence avec RedHat et Novell?

-Microsoft: sans commentaire, enfin si un: l'opposition de Microsoft a la GPL est un très bon argument *en faveur* de la GPL.

Mais le fait demeure, le noyau qui a le plus de contributeurs est sous GPL..