jym@netbsd a écrit 11 commentaires

Je ne crois pas trop au tout espace utilisateur pour les drivers...

Ça tombe mal: c'est ce qui se passe avec Xen (au moins sur amd64): tout tourne en userland (oui, le kernel Unix est aussi en ring 3), et ça marche encore, avec un overhead qui ne dépasse pas le pourcent.

Tu vas m'expliquer que le succès commercial d'Androïd c'est parce que les acheteurs de smartphones cherchaient un système à noyau Linux?
Non. C'est une décision technique prise par Google.
Et je ne pense pas que les acheteurs de produits Apple cherchaient après un système BSD non plus. Voilà.

Pourquoi s'en réduire aux acheteurs de produits Apple? Si leurs ingés ont fait un choix sur un OS plus qu'un autre, cela fait bien partie du succès de cet OS aussi. Voilà.

Ni Carbon ni Cocoa ne viennent de BSD. Mais je suppose qu'ils ne sont pas représentatifs de ce qui fait Mac OS X?

Un système forme un tout. Vouloir le réduire à ce qu'il a de visuel est un non sens. On rétorquera que ni Dalvik ni Java ne viennent de Linux... Mais je suppose qu'ils ne sont pas représentatifs de ce qui fait Android?

Par contre --oserai-je dire comme d'habitude?--, on voit un énorme complexe ressortir de BSDistes, qui veut qu'une phrase dans laquelle on a "BSD" et "GPL" et qui n'est pas un Troll en faveur de BSD est forcément une attaque en règle contre BSD, contre laquelle il faut riposter!

s/BSD/GPL/. Vu la quantité de personnes qui se sentent obligées de répondre aux commentaires de Tannenbaum en jetant des "mauvaise foi", "grand guignol qui n'a rien compris au monde" et co, la paille dans l'oeil du voisin, la poutre dans le vôtre, tout ça, tout ça.

Il dit que les systèmes BSD sont populaires, la preuve: MacOS X. C'est sacrément gonflé! Ce ne sont pas les utilisateurs qui ont décidé que "BSD c'est mieux", c'est une décision technique faite pas une seule boite.

Que dire d'Android alors.

Et la partie reprise de NetBSD n'est pas si grande.

Chiffres? Au lieu d'assertions à l'emporte pièce?

Coté Apple, vous savez ce qui tourne dans les time Capsule et les Airport (extreme inclus)? Quid d'iOS au fait?

Mais avec un modèle bazar, on a plus de contributeurs et on avance plus vite dans les fonctionalités au moins quantitativement parlant. Question de choix!

Tordons le cou au modèle bazar. Il ne faut pas faire l'amalgame entre "progrès" et "changement".

Si BSD caÿsimal, quelqu'un pourrait-il expliquer pourquoi y'a-t-il tant d'investissement (qui chiffre en millions aussi, comme Linux...) sur des projets licence Apache/BSD/MIT, style:
- Android (qui n'a de GPL que le kernel, et encore... cela dépend des bouts)
- les projets de la fondation Apache
- Chromium, V8
- Nginx, LLVM, PostgreSQL, Memcache, Redis, Node.js, Wayland...

Décidément, ici, vous avez un peu trop tendance à assumer que libre == Linux == GPL. Certains ne doivent pas survivre quand un VLC passe de GPL à LGPL...

Ça a l'air bien pkgsrc, et c'est présenté comme portable, mais est-ce que ça fonctionne aussi ailleurs que sur netbsd ?

Cela marche bien pour les paquets conçus "proprement", c'est à dire qui n'utilisent pas une API trop spécifique à un OS par exemple, ou qui n'ont pas de dépendances proprio.

Généralement ces paquets sont tagués "For XXX only", ce qui lève un warning au make. Mais il arrive que certains passent entre les mailles du filet, on ne peut pas tout tester. Le buildbot en attrape beaucoup. Les ptit's gars de pkgsrc soumettent souvent des corrections upstream quand elles ne demandent pas trop d'effort.

Suivant le degré de portabilité, cela ira du "marche sans problème" à "marche pas du tout." On peut pas faire tout juste du premier coup, n'en déplaise à ceux qui font du Minix (iMil et bapt, si vous me lisez :o ).

Les plus galères sont pour moi les applications lourdes, particulièrement graphiques. Ayant dû porter pkgsrc pour compiler (cross-compiler aussi, si si) tout un tas d'applications, c'est clairement les gtk+, firefox, glib... qui pètent. Souvent sur des symboles non résolus, des erreurs de compilation, ou des fonctionnalités manquantes (par exemple, la dernière VM Javascript de Firefox s'en sort très mal ailleurs que sur x86). Dernièrement, j'ai découvert Vala, qui même s'il fait du source-to-source (C à la fin), le code généré est pas forcément... correct pour autre chose que du i386 (alignement).

Perso, le plus pénible avec pkgsrc est le bootstrap, qui fait un peu "réservé aux initiés". Pas tant dans la complexité (c'est deux lignes de commandes à taper: un téléchargement, et ./bootstrap), mais dans le fait que quand on sait pas, il faut chercher un peu. Cela rebute pas mal.

C'est surtout pour permettre des versions propriétaires d'Android ...je pourrais te retourner l'argument en soulignant qu'ils n'ont pas repris un noyau BSD, pourtant ça leur aurait simplifié la vie: perfide, efficace et sans aucun fondement comme l'insinuation ci-dessus à propos de la supposée mauvaise qualité des API linux.

C'est de bonne guerre, vu les insinuations permanentes que "BSD is dying" ici...

Le fait de ne pas choisir un système BSD est un choix pragmatique. Rien à voir avec les APIs, ni le fait de vouloir faire du proprio ou je ne sais quoi d'autre.

Quant à la perfidie, tout dépend de qui l'observe: on pourrait causer de la viralité de la GPL. Ou même de cancer, puisqu'on aime bien troller ici.

Justement, l'argument avancé par Lennart c'est qu'Avahi le fait de base sans configuration/intégration. En résumé, je compile/installe/lance Avahi et c'est chrooté sans les mains !

La majorité des daemons qui font de la séparation de privilèges font du chroot... par exemple, OpenSSH le fait depuis belle lurette (UsePrivilegeSeparation), et par défaut.

Avoir un init différent n'apporte rien du tout sur le plan commercial (ça fait chier les admins de devoir réapprendre un nouvel outil, d'avoir encore plus d'hétérogénéité pour pas grand chose etc ...). Quand Harald Hoyer (mainteneur d'init chez RH) a importé Upstart dans Fedora, il avait envisagé de réécrire son propre framework entre autre et ne l'a pas fait parce que le mainteneur d'Upstart était actif dessus et que Canonical avait promis de faire évoluer rapidement le soft.
Au moment où Lennart s'intéresse à l'init, il se rends compte que plus personne bosse sur Upstart (entre temps, James Scott Remnant a même changé d'employeur), que tout le monde est bloqué sur la couche de compatibilité sysV (en gros, on a un init plus complexe, tout aussi abandonné que son prédécesseur et sans aucun gain).

C'est pas une question d'APIs et d'opensource alors, mais de man power. Y'a t-il des engagements de Poettering à ce niveau? Vu l'état de maturité relative de ce qu'il a conçu avant, c'est un peu prématuré...

Désolé de te décevoir, il n'y a pas de complot du grand méchant RedHat pour impose SA solution, ça serait très con de démarrer une nouvelle implémentation alors que RHEL6.x a été publiée avec Upstart (et qu'ils devront le maintenir pendant 10 ans)

Pourquoi ne pas avoir plutot cherché à contribuer à upstart et l'améliorer plutot que de laisser un quidam de chez eux réinventer la roue? Que je sache, upstart est open source et GPL... c'est pas la force de l'open source tant clamé ici, justement?

Erreur de design? Bullshit, comme dit juste au dessus, y'a le code, ca se change.

Dernier point, au sujet du troll pdm BSD/Linux/Windows qui " justifie" ( alors qu'il n'a pas à se justifier, il fait du code libre comme il l'entend ) les orientations de Lennart:
Moi, ce que je ne comprends pas , c'est que le public pour son affichage a rejeté totalement le modèle client serveur. Le protocole X11 est incapable d'évoluer en parallèle avec les architectures des machines depuis l'invention de la carte accélératrice 3D ( 1996 ? ).

Et ce grand public se rue sur tout ce qui n'utilise pas X11.

Exactement. Et c'est bien là le gros problème: considérer qu'en se concentrant sur des APIs "Linux" va soulager le développeur et éventuellement règlera l'adoption de Linux sur le desktop... c'est être aveugle. Les signalfd, cgroups et consort... sont des mécanismes tellement bas niveau système qu'ils sont invisibles pour l'utilisateur, tout comme le sont (devraient?) être les systemd, PA et compagnie.

Le desktop est essentiellement un marché tourné plus vers des consommateurs que des utilisateurs système: ce que l'on attend de lui, c'est qu'il "juste marche", et éventuellement avoir une certaine confiance dans sa consommation ("une assurance comme quoi mon achat marchera avec le minimum d'effort.")

Unix et dérivés (groupe dans lequel j'inclus les distribs GNU/Linux) ont culturellement choisi de ne pas avoir d'interface graphique (essentiel moyen d'interaction avec l'utilisateur) comme partie intégrante de l'OS (là où un Windows ou un MacOS X ont fait le choix contraire, au plus tôt). Ajoutons la relative lenteur de X à évoluer, saupoudrons de whatmille couches de GTK/QT/wxwidtruc/xcbidule et de plusieurs desktop/window managers, et on a là l'échec retentissant des Unix libres comme OS grand public. S'il y a un endroit ou il faudrait faire du nettoyage, c'est là dedans.

Je doute que choisir de coder avec les APIs propres à Linux changera grand chose à cet état de fait. Pour ça, il y a un système qui s'est clairement démarqué, Android, qui a su en l'espace de 2 ans conquérir une PdM qui est a plusieurs ordres de grandeurs de ce qu'ont pu faire des distribs Linux en 15 ans. Il a su percer sans se concentrer sur du discours "pur Linux et oublie le reste", sans avoir d'Avahi, PA, ou encore systemd. C'est même le contraire tiens, ils ont carrément refait la libc, une JVM, forké le kernel, refait une bonne partie du système, et ça a marché. Hmm.

Personnellement, je pense que la place de GNU/Linux sur le desktop "classique" est game over. Il y avait un créneau à l'époque du ras de bol Windows XP, Apple a su trouver sa niche, et est maintenant au chaud.

Quant aux trolls à deux balles sur "mon bébé est encore un des seuls à faire du chroot pour se protéger", il faudrait qu'il sorte un peu pour voir ce qui se fait ailleurs (pas que chez les BSD, très loin de là): serveurs FTP, named, ntpd, syslogd... après, que chaque distro l'utilise ou pas, c'est une question de configuration/intégration (comme Avahi, aussi).

Je reste convaincu que le buzz + le forcing qu'il fait est appuyé par son employeur, qui veut fédérer à lui les efforts communautaires sur ses solutions tout en dépréciant toutes les alternatives qui ne souhaitent pas s'aligner (Ubuntu, Debian, *BSD, etc), qui sont des concurrents, ni plus ni moins.

Rien empêche de "refactorer" le code en conséquence.

Oui bien sûr, "yaka faukon".

La licence BSD permet de fermer le code, elle permet aussi son passage sous GPL.

Précisons un peu cette notion de "passage sous GPL". La BSD permet de redistribuer du code en respectant les règles de la GPL, mais cela ne rend pas le code pour autant GPL, qu'il soit inclus ou pas dans du code GPLisé. La BSD n'est pas copyleft, on ne retire pas un copyright "comme ça" sans accord de son auteur.

Pour finir, elle a le mérite d'être courte (n'en déplaise à certains), je pense qu'on peut se permettre de la lire:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

C'est assez clair, pourtant? L'inclusion/mélange de code BSD dans du code GPL est tout à fait permis (sans affecter le reste et se faire des noeuds au cerveau), ca ne veut pas dire pour autant que le copyright disparaisse par magie.

Lennart n'a jamais été fermé à la discussion

Allez donc lire les mails, on se demande s'il fait des efforts pour comprendre l'opinion de joss?

Il aurait pu déjà commencer par utiliser la libevent au lieu de se servir des trucs genre timerfd, signalfd et epoll. Visiblement, ca lui est passé au dessus de la tête.

il a réussi à mettre tout le monde d'accord au sein du mastodonte FHS

C'est vrai que c'est gagné d'office.

C'est fascinant. En quoi Lennart "pousse-t-il" les gens à s'aligner sur ses idées ?

Vous n'avez manifestement pas lu les liens de l'article...

Il leur met un flingue sous la gorge ?

C'est pénible les argumentations à l'extrême. Pas la peine d'aller jusque là.

C'est difficile d'accepter que l'on a des idées et qu'on les défend ?

Si la défense consiste à attaquer d'autres projets, il y a un problème fondamental de communication et de respect d'autrui.

C'est difficile d'accepter que les propos de Lennart sont exactement du même type que les votre ?

Euh, non, je n'accepte pas.

Certes, chacun voit midi à sa porte. Plus que les propos, c'est l'attitude qui est répréhensible. Surtout quand elle est éprise d'une certaine mauvaise foi. Adopter une attitude "codez avec les APIs de mon OS chéri sans réfléchir, ignorez le reste du monde", c'est un reproche maintes fois entendu contre d'autres systèmes, et qui continue de poser des problèmes. Manifestement, la leçon n'a pas été apprise.

CoLinux, UML etc ....

Raté, ce sont des port usermode d'un OS. Ce que n'est pas rump, qui est surtout une architecture kernel. J'invite à lire le site du projet un peu plus en détail. Voir le 3e commentaire sur le post du blog, par exemple.

Le problème c'est que Microsoft ou Apple t'empêche d'être intéropérable, alors qu'avec fd.o, tu as des specs librement implémentables et discutés dans un espace neutre (ils sont où les gens de NetBSD sur fd.o ?), pour les APIs noyaux, il n'y a quasiment plus aucun effort de standardisation et c'est fort regrettable. Je pense pas que côté *BSD, on soit aussi irréprochable que tu le dit.

Houla, j'ai jamais dit que les BSD sont irréprochables. Etant développeur NetBSD, c'est difficile de me convaincre du contraire, je connais bien leurs qualités et aussi... leurs défauts.

Microsoft et Apple n'empêchent pas de réimplémenter leurs specs: ca ne pose pas de problème à Wine.

La coopération avec fd.o est parfois pénible, pour les mêmes raisons qu'avec la Linux Foundation d'ailleurs (voir le débat de la FHS sur la ML NetBSD). C'est une entité qui s'est imposée d'elle même étant donné le bordel qu'est l'écosystème de distributions Linux, et le manque d'homogénéité entre les distribs. Pour certains de ces standards (pas tous, heureusement), ils sont clairement pensés vers le "dénominateur commun": ouf, Linus a accepté de merger mon travail dans vanilla, c'est bon, c'est standard. Même si c'est fait en vitesse, et que cela amène à casser des fonctionnalités -- bienvenue, CONFIG_SYSFS_DEPRECATED_V2). Ca n'est que quand le bordel devient ingérable qu'on commence à se poser des questions. Bon.

Voyez vous, un standard n'est pas une bête spécification qui dit "si vous voulez telle fonctionnalité, utilisez telle API." C'est un travail collaboratif entre plusieurs acteurs qui a un historique, et suit une démarche de rationalisation: ca doit rester stable dans le temps, et pas évoluer au gré des vents et des caprices d'un quidam qui a une nouvelle idée à rajouter dans le kernel parce que c'est bien. On se plaint régulièrement de la lenteur de POSIX à évoluer: c'est le propre même d'un standard, qui demande une certaine réflexion.

Là ou le bat blesse, c'est que le monde FLOSS s'y prête mal; à cause des egos forts; du droit discrétionnaire de certains à disposer de leur bébé (le cas de la glibc est criant -- et un OS sans libc, ca va pas loin); du manque de moyens et d'investissement.

Qu'il y ait peu de devs BSD qui collaborent avec fd.o est un fait; personnellement c'est un problème qui existe entre différents projets FLOSS: la coopération demande des ressources, et des projets critiques ont déjà du mal à staffer en développeurs. Vu que personne ne veut payer pour ca au final...

Quant aux standards imposés façon "politique du fait accompli", cela refroidit beaucoup, et n'incite pas à collaborer. L'épopée HAL a servi de leçon, perso j'ai eu ma dose de debugging avec cette horreur. Faudrait comprendre qu'on a pas 1500 développeurs et que tous ne peuvent se permettre de réécrire la pile IP lundi, USB pour le mardi, et changer 3 fois les API du scheduler parce que ca nous chante.

Après, c'est une question de design: quand le système est bien conçu, enrichir en fonctionnalités n'est pas tellement couteux, ni comme contourner le problème.
Même si le "modèle systemd" arrive à s'insinuer partout avec ses linuxeries, c'est pas comme si on avait des compat_linux ou Linuxulator. Si cela en devient tellement pénible que le système est difficile à exploiter, on se tournera vers ailleurs. D'ici là que systemd s'impose partout, on sera passé à autre chose, et l'OS (au moins coté client) se bornera à être une couche pour lancer un web browser.

En parlant de web browser, cette histoire d'API "forcing fonctionnalité" me rappelle les pleurs des libristes pour le support de l'accélération graphique matérielle sous Linux. Sauf que cette fois, ils étaient pas du bon coté de la barrière.

Chercher l'erreur...

Y'en a une belle: pousser des gens à s'aligner sur ses idées sans discernement (ie. admettre que les objectifs de GNOME ne sont pas ceux de Lennart), pour ensuite déprécier le travail des autres en les tournant en dérision (toy OS), c'est pas le meilleur moyen pour se faire respecter.

Que je sache, on fait pas du forcing pour imposer les APIs BSD partout. Et pourtant, ca ferait pas de mal d'avoir un vrai sysctl, une interface proplib et pas whatmilles ioctl(), etc.

Au fond la remarque de je ne sais plus qui est juste : dans les fais personne ne se préoccupe d'une interopérabilité totale. Ça n'existe pas. Dans les faits presque tout le monde se fiche de HaïkuOS et de Hurd. L'interopérabilité dans le monde Unix ça veut dire : BSD et Linux, et c'est tout.

Le problème, c'est que compatible "Linux" ne veut rien dire. Déjà que c'est le bordel actuellement (s'assurer une compatibilité binaire correcte entre Debian/Mandriva/Gentoo/Redhat/Suse/Ubuntu passe forcément par de la recompilation, et pourtant c'est "Linux"), ca n'a pas l'air de s'arranger. Et je parle même pas d'Android, c'est pourtant "Linux" aussi.