reno a écrit 3881 commentaires

Oui enfin les 'libristes' c'est une étiquette collée sur beaucoup de monde, la question, les auteurs de logiciels veulent-ils une licence qui dit que quand on loue un équipement, le fournisseur du matériel doit mettre a disposition le code source des logiciels qui tournent dessus ou pas?

Pour RMS, je n'ai pas de doute sur son point de vue, pour Linus Torvalds je pense que c'est non: cf ses prises de positions contre les clauses anti-tivoïsation de la GPLv3..

Apres le probleme avec toutes ces nuances: BSD, LGPL(qui en plus a plein de variantes car beaucoup n'aime pas la restriction sur l'édition de lien statique), GPLv2, GPLv3, AGPL, c'est qu'à chaque fois il y a une fragmentation des échanges de code possibles..

J'ajouterai que malheureusement le coté compatibilité purement d'un point de vue juridique a aussi son importance: la GPLv2 est incompatible avec la licence Apache je crois, ce qui est assez absurde..

Je pense que l'argument marketing de BeOS sur le 'pervasive' multithreading avait un fond de réalité technique: c'est bien beau d'utiliser des threads mais c'est très facile de sérialiser tout le bazar si tu as des partie quelque parts dont l'architecture n'est pas adapté..

Comme BeOS était prévu au départ pour un bi-processeur, ils ont vraiment essayé d'exploiter les threads et le résultat était bluffant même sur un mono-processeur.

Ce qui est triste, c'est que maintenant on va vraiment dans le cas ou tout le monde aura un bi-processeur, mais comme le logiciel qui tourne dessus a été optimisé pour un mono-processeur, ce ne sera pas vraiment exploité avant longtemps..

OK, mais est-ce au niveau de X ou au niveau des applications qui utilisent X?

Ayant utilisé BeOS je vois bien ce que tu veux dire (pour ceux qui ne connaissent pas: les GUIs y étaient *beaucoup* plus réactifs que Linux&Windows l'étaient et le sont maintenant), mais je pense que le probleme se situe plutôt dans la façon de coder les applications.

Dommage d'ailleurs, autrement juste amméliorer X permettrait d'avoir la réactivité de BeOS, mais c'est peu probable que ce soit suffisant..

Très sympa ta page, il y a juste un point qui me choque un peu: tu y marques qu'il a fallu attendre XP SP2 pour que Windows ait un firewall: je pense que c'est incorrect: XP en avait un, mais il n'est activé par défaut qu'à partir de SP2..

[ C'était très bête de Microsot d'attendre si longtemps pour l'activation par défaut d'accord.. ]

Je n'aime pas beaucoup Microsoft, mais je pense qu'il faut essayer d'être factuel dans nos critiques (même si les gars de Microsoft ne se privent pas eux de balancer des c..., ce n'est pas une raison pour se rabaisser a leur niveau).

>on peut avec pas mal d'effort sécuriser un windows et le rendre vraiment stable

D'effort? N'exagérons pas: pas plus que pour configurer Linux (la dernière fois que j'ai essayé d'installer un Kubuntu chez moi X ne marchait pas..), mais par contre pour que ça marche bien il faut des connaissances oui: il y a plein de gens qui ont des PCs sous Windows qui marchent vraiment très mal..

Jouer sur un PC, je ne sais pas si c'est un besoin 'très spécifique': ça représente quand même pas mal de monde!

Amusant ça: Francois Revol (le premier post) avait exactement la même critique mais pour les pilotes .. Linux (!), pour être plus précis, ceux qui ont été fait sans les spec du constructeur ou la qualité/complétion n'est pas toujours au rendez-vous non plus..

Comme quoi..

Pour les compilos peut-être, mais en final ce sont les utilisateur qui choisissent: j'ai bossé sur des projets qui mettaient 3 heures à compiler (vive le C++) et si j'avais eu la possibilité d'avoir 30% de temps de compilations en moins pour 5% de perte de perf, j'aurais signé sans problème!

Que le kernel Linux intègre plus de pilote que l'OS Windows, je ne trouve pas cela si etonnant.

Mais si on ajoute les pilotes fourni par le constructeur avec le matériel pour Windows mais non intégré dans Windows, la ça représente quand même beaucoup de pilotes..

Quelqu'un sait-il ce qui est compté pour les périphériques Windows?
Parce que certes avoir le pilote intégré dans l'OS est plus pratique, mais le principal c'est quand même d'avoir le matériel qui marche..

Re-écrire plutôt que de contribuer a l'existant pour une quantité d'homme-heure donnée donne un résultat inférieur sur le plan technique car il y a duplication du code (sauf dans le cas particulier ou l'existant est pourri mais ce n'était pas la raison utilisé pour coder un OS sous license GPL plutot que de contribuer à *BSD).


Sinon pour theora, tu pense à quoi comme meilleur solution technique?

Dirac? Il est très gourmand au niveau CPU donc je ne suis pas convaincu que ce soit une bonne idée de l'utiliser pour diffuser des vidéos sur Internet et les autres formats ont des problèmes de brevets logiciels aux USA.

Tout programme non testé étant habituellement buggé, je comprends bien qu'un des tests soit la recompilation de l'OS en natif.

Mais c'est un test nécéssaire pour la validation pas pour le developpement ou la, tu auras le résultat bien plus rapidement en cross-compilant ce qui diminue notablement le nombre de compilation native nécéssaire..

[[Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).]]

Hein? Et pourquoi les binaires générés par cross-compilation serait de qualité inférieure à ceux généré par compilation 'native'??

On peut préférer compiler de manière native car c'est plus simple à mettre en oeuvre ok, mais la "qualité" des binaires..

Soit dit en passant, ayant travaillé sur des projets C++ qui mettaient *plusieurs heures* a compiler (sans optimisation), je fais partie de ceux qui pensent que la vitesse de compilation est importante, oui.

D'ailleur c'est un argument *pour* la cross-compilation pour les vieilles machines: entre un PC avec un ou plusieurs CPU multi-GHz avec des giga de RAM et un VAX, j'aurais tendance à penser que gcc sur le PC sera plus rapide à compiler que pcc sur le VAX..

Un exemple qui montre bien le coté traditionnaliste d'OpenBSD est qu'ils ont réimplémenté CVS..

Ayant (ab)usé de CVS je comprends ce qui les attire: c'était un logiciel ou si tu as corrompu certaines donnée, tu peux lancer un vi et corriger à la main.

Mais ceci dit je considère quand même que c'est un logiciel qui a fait son temps et si j'avais à choisir un logiciel de gestion de configuration j'irais plutôt voir du coté de Mercurial (git m'a l'air compliqué a utiliser) que de CVS..

>N'est-ce pas choquant ?

Choquant dans quel sens? Surprenant?
Non, c'est cohérent pour RMS..

Réfléchi à ce qu'a impliqué la création de la license GPL par rapport aux logiciels libres qui existaient déjà sous license BSD, MIT: plutôt que de contribuer aux logiciels libre existant, c'est créer une incompatibilité afin d'avoir une license qui (du point de vue de RMS) défend mieux les droits des utilisateurs.

C'est la même chose ici.

On est d'accord ou pas avec RMS, mais il est assez cohérent dans ses actions d'après ce que j'en sais.

Relis ce qu'il a dit: il a marqué 'branché', pas 'lié': il y a plusieurs façon de faire communiquer des programmes et la GPL ne protège que fasse à l'édition de lien..

Oui elles sont facilement désactivable a la compilation avec l'option -ansi, mais les extensions GNU sont presentes par défaut, ce qui n'est pas une bonne idée, je suis d'accord avec toi.

>Fais-la, fais le bench puisque tu sembles aussi sur de toi ...

Ahem, en science c'est à celui qui fait une affirmation de la prouver et non pas le contraire..

Affirmer "[PCC fournit] une vitesse d'exécution environ 10% plus lente [que GCC]" sans benchmark: ca n'a pas grande valeur..

J'imagine que ce chiffre n'est pas sorti au hasard, donc il doit y avoir quelque chose derriere pour le justifier.

Cela dit les besoins d'un OS sont très particulier et Linus lui-même rale relativement souvent contre gcc qui casse du code en 'sur-optimisant'.

>Et en politique, ça lèse tout le monde.

C'est un peu rapide: il n'y a pas si longtemps, et pendant très longtemps, il y avait des quota en politique très stricts: 0% de femmes!
Donc mettre un quota sur une période "courte" (50ans?) pour compenser les effets à long termes du premier (qui a duré des siècles), pourquoi pas?

Dans ce cas et bien d'autres, un quota est un système discriminatoire oui, mais pour combattre des discriminations existante..

Personne ne prétend que les quotas sont idéaux, mais ne rien faire pour lutter contre les discriminations ne l'est pas non plus..

Bof, il n'y a pas que l'archi qui compte pour un téléphone et les critiques que j'ai vue du téléphone utilisant Android étaient loin d'être positive.

On verra bien comme cela va évoluer, mais pour le moment Apple garde l'avantage je pense (sauf si l'utilisateur a besoin d'un téléphone avec un vrai clavier).

Le sujet (la 3D) est intrinsequement difficile..
Maintenant les logiciels libres ne sont pas forcément réputés pour leur facilité d'apprentissage: j'utilise Paint.NET car j'arrive a faire ce que je veux sans trop de difficulté, et pas Gimp (pas essayé les dernières version) car la il faudrait que je lise un manuel..

Je me demande si les améliorations faites par Arjan van de Ven sur le temps de boot ne vont pas être utile à ce sujet.

Après, son Asus EEE 900 a un Atom à 1.6GHz qui explose l'ARM 400MHz niveau performance et beaucoup plus de RAM aussi, mais on charge quand même moins de chose sur un smartphone..

Plus de la moitié contre?
Je me souviens d'un sondage ou 60% des Français étaient pour le mariage homosexuel (mais moins pour l'adoption malheureusement).

Bon ça fait quand même 40% qui on une étrange conception de ce que "Liberté, Egalité, Fraternité" veut dire..

Il a dit le reste de l'OS, ça inclut l'espace utilisateur certe, mais cela inclut aussi les pilotes de périphériques, qui représentent beaucoup de travail!

Pour ce qui est de l'espace utilisateur, certes si ton nouveau noyau offre une interface 'a la Unix' alors tu peux réutiliser l'existant certes, mais cela implique aussi que ces appli n'utiliseront pas les nouvelles fonctionnalités de ton OS (au moins dans un premier temp).

Le problème est que la comparaison est difficile, prends ces exemples la:

1) Normalement les x86 devraient être des grosses bouses au niveau performance comparé a des RISC, mais grace aux investissement monstrueux d'Intel et d'AMD ce n'est pas le cas bien au contraire!

2) DragonFly BSD a été créer avec un système en théorie plus performant que FreeBSD pour l'utilisation du parallélisme, mais comme il y a très peu de contributeurs sur DragonFly BSD, le résultat est que FreeBSD enterre DragonFly BSD sur ce point à l'heure actuelle.

Donc pour pouvoir comparer objectivement les performances d'un micro-noyau et du kernel Linux, il faudrait que l'investissement en effort soit le même dans les deux cas, ce qui n'est pas près d'arriver..

Pas d'accord: par exemple pour l'isolation des onglets, Chrome utilise des processus du système d'exploitation, il ne réinvente pas sa couche.

Peut-tu préciser ou tu vois que Chrome reinvente la roue?

[[- on peut transformer avec xslt... vous avez déjà essayé de maintenir du code xslt ? sérieusement ?]]

J'ai a le faire de temps à autre et je ne dirais qu'une chose: XSLT SUCKS!!!!
A coté, le Perl est un langage super lisible..
Je n'aime pas le Perl, mais je déteste XSLT.

Je pense que tout ceux qui pensent qu'XML est une bonne techno devraient débugger un script XSLT qui ne fait pas ce qu'il faut: après on leur redemande leur avis sur XML..