Gabriel Linder a écrit 175 commentaires

# ps aux | grep X
_x11 15199 4.6 3.2 9692 33180 ?? S 11:44PM 1:05.09 X -br -nolisten tcp (Xorg)
root 3455 0.0 0.1 1768 1060 ?? I 11:44PM 0:04.13 X: [priv] (Xorg)

Wow. Et sans faire tourner de cochonneries supplémentaires en mode kernel.

C'est surtout que j'ai bien assez vu de gens affirmant qu'on pouvait remplacer la license BSD par ce qu'on voulait pour me méfier maintenant (chat échaudé craint l'eau froide).

Euh je n'ai jamais dit qu'il n'y avait pas d'intérêt à les traficoter ou à les ouvrir. Simplement il faut être réaliste : les constructeurs rechignent déjà à livrer leurs specs (la situation évolue ces derniers temps remarque), alors de là à filer les codes sources de leurs firmwares... Sans compter que c'est tellement proche du matériel que l'intérêt et le nombre de personnes capables de les comprendre doit être assez restreint. Probablement qu'avoir le code permettrait de le corriger, mais si un constructeur n'est pas fichu de faire des firmwares fonctionnels pour son matériel il faut changer de constructeur, ou être vraiment passionné par la programmation de firmwares :)

Pour moi seul l'auteur original a le droit de changer la license, et changer la license d'un code juste pour le plaisir de changer de license et maintenir plusieurs arborescences du même code je trouve cela idiot oui.

Et par "(ou pas)" je n'entendais pas une absence de modifications mais une évolution négative.

Le reste ne mérite même pas que je m'y attarde.

Où j'ai dit qu'un seul firmware faisait l'affaire ou serait irremplaçable ? Des projets comme LinuxBIOS ont un intérêt, tout comme ceux visant à remplacer les firmwares de iPods.

Ce dont on parle à la base c'est des firmware de matériel, qui tournent dans un espace mémoire séparé du noyau de l'OS, et qui peuvent donc bien faire leur tambouille dans leur coin comme ils veulent : on s'en fout, ils ne risquent pas de compromettre l'OS. Ce dont OpenBSD ne veut pas, ce sont les blobs tournant en mode kernel comme les pilotes de nvidia.

Je sais pas vous mais moi quand je vois un projet se réclamant d'une license fantaisie comme la WTFPL, j'en cherche un autre...

Non ce que je voulais dire c'est pourquoi changer la license ? Autant laisser le driver sous la license originale vu que la BSD est reconnue comme compatible par la GPL, mais pas l'inverse. Changer la license revient à sciemment chier dans la soupe, à mon avis.

Comparer le firmware d'une carte wifi et celui d'un baladeur me semble inadapté... Le premier est lié au matériel et tu n'interagis pas avec, le second on peut envisager de le remplacer (il est de plus haut niveau qu'un firmware purement matériel comme un BIOS), voilà la distinction que je fais entre les deux.

On s'en fout des firmwares : techniquement ils devraient être intégrés dans une ROM sur le matériel, mais pour faire des économies (ou faciliter les mises à jour ? fausse excuse à mon avis) ils ne le sont pas et doivent être chargés par l'OS. Ils sont plus proches du matériel que du logiciel, ce n'est pas comme un blob qui tourne en espace noyau (ou utilisateur d'ailleurs, peu importe) puisque le firmware n'a pas accès à tout et fait juste sa popote pour faire marcher un périphérique.

Pour avoir suivi ce thread sur la mailing list misc@openbsd.org, je trouve qu'ils ont bien raison, et la chanson m'a bien fait rire.

> Mais maintenant l'ennemi ce n'est plus les firmes qui font du proprio ou le monopole de Microsoft. Non l'ennemi c'est devenu pour quelques personnes la FSF et surtout Stallman.

Le problème c'est aussi la GPL qui a tendance à enrober des codes sous BSD quand ils sont inclus dans un certain kernel, et les devs d'origine (sous BSD donc) ne peuvent ensuite plus reprendre le code amélioré (ou pas) par ceux de l'autre kernel... m'enfin.

Ben si, on parlait de fanboys...

Si tu veux vraiment savoir ce qu'en pensent les fanboys de MS, va voir à la source : http://blogs.codes-sources.com/neodante/archive/2008/04/02/o(...)

Indécrottables.

OpenBSD inclut les blobs propriétaires ati/nvidia dans son kernel pour OpenBSD 4.4, testés avec Quake 3 et xeyes !

http://undeadly.org/cgi?action=article&sid=2008040104011(...)

Plus sérieusement ils sont vraiment en train d'implémenter les DRM (non, pas ceux là... on parle de Direct Rendering Modules, la partie kernel du DRI).

Pour ma part j'ai un 945G/GM et je n'ai aucun souci avec niveau performances/stabilité, que ce soit en 2D, 3D, Composite ou OpenGL. J'utilise le driver xf86-video-intel-2.2.0, çà joue peut être.

Clair, en plus les dalles mates sont bien moins salissantes (meilleure résistance aux postillons et empreintes de doigts, pensez y si vous travaillez en environnement hostile !)

Bon j'ai enfin réussi à télécharger ces images (fini les 503 à tour de bras), c'est pour le moins abusif (tout comme leur CLUF, on m'a déjà ri au nez pour la clause "There is no warranty blablabla" des licenses BSD/GPL, jusqu'à ce que je leur mette le nez dans le CLUF de Windows. Mais baste, je disgresse). Je demanderais demain au boulot si on a reçu ce genre de torchons, mais avec moi ce sera vite vu, ma station de travail étant sous Slackware...

Je modère le forum Linux d'un site de jeux vidéo, et j'ai constaté la même tendance : il y a de plus en plus de jeunes qui s'intéressent à Ubuntu^WLinux, et ne conservent Windows que pour les rares programmes qui leur sont nécessaires (principalement des jeux, parfois Photoshop ou autre win32rie).

Pas d'inquiètude pour l'avenir de Linux ni de Microsoft donc, on sait où ils vont :)

Parce que je n'ai pas pu afficher une seule des images citées ici, et que seul dl.free.fr me joue régulièrement des tours dans ce style ? Encore que là il semble y avoir une raison, je n'ai plus que des 503 Service Unavailable depuis quelques minutes.

Faudra que je repasse plus tard, j'espère qu'il ne faut pas en plus activer le javascript pour récupérer les fichiers...

Dans les griefs tu oublies de mentionner que tout X tourne en root alors que seule une fraction en a besoin, fraction parfaitement identifiée par le projet OpenBSD (leur X tourne avec l'utilisateur _X11 ou un truc du genre, et seule la partie ayant besoin des droits root tourne en root).

D'ailleurs OpenBSD est en train d'implémenter les drm pour avoir enfin l'accélération graphique, ils risquent donc encore une fois de lever quelques lièvres. Je ne sais pas où çà en est, faudra que je regarde.

> Support de la journalisation pour UFS

Ah ? Je ne me rappelle pas avoir vu passer ceci, tu pourrais me dire où tu l'as vu ?

Sinon j'ai ajouté quelques précisions concernant le "Giant Lock", SCHED_ULE, et libthr. Je n'ai pas trop le temps d'organiser tout çà correctement, c'est l'heure du déjeuner, mais notamment le pdf que j'ai mis dans libthr concerne aussi ULE. Je repasserais plus tard si je peux :)

swap ok, / ok, le reste ok... mais /boot, il charge le kernel comment le bootloader (sans parler de son stage2) ? :)

J'avais vu dans la doc que tout est effectivement sérialisé : valgrind émule un CPU et ne fait tourner qu'un thread/process à la fois, mais il les croise (interleave) beaucoup plus fréquemment qu'un CPU normal, ce qui permet quand même de détecter les bugs de synchronisation.

Il est aussi et surtout fortement lié à Linux, même si çà semble s'améliorer dans la 3.3 (cf http://valgrind.org/docs/manual/dist.news.html ) :

Developer-visible changes:
- Internally, the code base has been further factorised and abstractified, particularly with respect to support for non-Linux OSs.

Bientôt peut être un port récent et stable sur BSD, valgrind étant le seul outil indisponible sur cette plateforme et la raison pour laquelle j'ai encore Slackware au taf :)

(oui je sais, j'ai qu'à envoyer des patchs et toussa, surtout maintenant que j'ai fini zelda je vais avoir un peu de temps libre)

Non non, ils se contentent d'importer du code BSD et de le passer en GPL.

À partir du moment où tout le monde ne peut pas avoir accès à la doc, je ne considère pas ceci comme une solution acceptable. Manquerait plus qu'une clause indiquant "Ce NDA n'expire pas, vous devez détruire tout support fournit par <n'importe quelle société> dans l'année qui suit son envoi."

Certes, çà n'empêche pas d'écrire du code GPL. Mais si c'est pour avoir des #define FOOBAR_MAGIC_NUMBER 0x42 /* for compatibility */, c'est pas la peine (je ne dis pas que c'est le cas ici, mais çà pourrait aussi bien, çà s'est déjà vu...)