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.
[^] # Re: Modestie...
Posté par jym@netbsd . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 10.
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.