reno a écrit 3881 commentaires

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..

>Parrot vient de sortir en version 1.0

Quand KDE était sorti en version 4.0, c'était donc qu'on pouvait l'utiliser? Ah, non? ;-)
Je me souviens que quand j'utilisais Java (il y a longtemps), j'étais bien dégouté par les annonces de Sun 'tout nouveau, tout beau' alors qu'ils mettaient des années a corriger des bugs.

J'en avais déduit que la meilleure façon d'évaluer quelque-chose est de regarder la liste des bugs critiques, liste que je n'ai pas trouvée pour Parrot donc je suis d'accord avec Antoine..

Note qu'au moment ou le projet OGD a commencé, il n'y avait pas de cartes dont les spec étaient ouvertes..

Mais depuis effectivement l'interet est plus difficile à voir.

[[ - NVidia aura bientôt Nouveau qui sera libre et utilisable ]]

*Tousse*, utilisable pourquoi faire? De la Full 3D accelléré en matériel avec tout les machins mordernes (shaders) et de la vidéo accélérée?

J'ai un doute que ça vienne bientot dans Nouveau ça, déjà que je ne pense pas que ça y soit dans les drivers OpenSource pour ATI/AMD..

J'ai beau avoir une carte NVidia (à l'époque ATI et NVidia au niveau spec c'était bonnet blanc et blanc bonnet), je trouve qu'il est plus important de contribuer aux pilotes ATI/AMD ou Intel qu'à Nvidia: eux fournissent les spec, donc je sais quelle carte j'achétérai la prochaine fois..

[[ Si tu lis la FAQ de Minix, la BSD a été prise pour faire du proprio. C'est l'intérêt et défaut de la BSD, mais pour Minix les raisons sont claires.
http://www.minix3.ucsc.edu/wikis/minix3/FoireAuxQuestions
1.2.2. Pourquoi n'avez-vous pas utilisé la GPL ?

Nous pensons que la GPL (General Public License) est trop restrictive. Les entreprises qui investissent beaucoup d'argent dans le développement de l'open source ne veulent pas (avec raison) le donner à leurs concurrents.
]]

Faut etre gonflé pour faire ce genre d'affirmation! Je crois qu'a l'heure actuelle le kernel qui a le plus de constributeurs est Linux qui est sous GPL..

Je ne veux pas tout dire que tout OS doit etre sous GPL: utiliser une license BSD peut etre vu comme un moyen de se demarquer de Linux, mais ce n'est pas une raison pour dire n'importe quoi dans une FAQ!!

Déjà que quand j'essaye de convaincre les gens que notre systeme de vote est mauvais on me répond qu'avoir la possibilité de cocher plusieurs case dans un bulletin serait 'trop compliqué' pour les électeurs alors la méthode de Condorcet..