Donc les BSD avec leur basesystem c'est quoi si ce n'est pas du libre ?
La base est plus limité mais ça montre qu'il est tout a fait possible d'avoir ce mode d'organisation dans le libre.
Bien sur qu'on peut avoir un modèle de plateforme dans le libre. Il suffit de voir python, ou perl qui ont une bonne compatibilité ascendante ( surtout perl ). Je voulais pas rentrer dans le détail ( mon message était déjà assez long ).
Mais comme tu dis, la base d'un BSD est limité, et en fait, on voit ( selon moi ) qu'on atteint les limites du bénévolat, même si tout le monde n'est pas bénévole, il y a des gens payés pour bosser sur les BSDs à gauche à droite, comme par exemple chez Apple, Netasq. Donc je ne sais pas dans quel mesure est ce que la partie "maintenance" est financé par des boites ( ou on arrive du coup à un modèle de "fédération" pour le financement ).
Et ceci n'aboutit que à implémenter un UNIX, ce qui n'est pas négligeable en soi, loin de la, c'est déjà un immense boulot, mais qui est au moins d'un ordre de magnitude moins que ce qu'on considère comme requis pour un os de bureau moderne ( à savoir genre, avoir un jeu de widget, des services de gestions du réseau, etc ).
À coté, les BSDs ne sont pas connu pour un support matériel à la pointe, et c'est le prix aussi à payer pour le modèle de la cathédrale.
Et enfin en pratique, c'est pas ce qu'on utilise ( avec "on" == "les libristes, notamment ceux que je croise" ), tout comme on utilise pas trop de la Centos 5 sur les stations de travail ( alors qu'au final, ça réponds aux besoins de stabilités exprimés par pas mal de gens si j'en croit ce que j'ai vu sur les listes de Mageia à l'époque )
Donc oui, les BSD se rapprochent de ce modèle de socle, sauf que le socle en question est minuscule, complété par des choses hors du socle ( les ports, etc ), dont l'évolution se fait pas à la même vitesse, ce qui ne colle pas vraiment à la définition. Et qui du coup ne réponds pas au besoin primaire du modèle ( que j'ai pas expliqué plus haut ), à savoir ( selon moi ), le fait de favoriser les développements tierces parties des ISVs.
Pour la compatibilité binaire face à la compatibilité source faudra le dire à Linus alors (https://lkml.org/lkml/2012/12/23/75 ça date de Noël).
Là où il y a un manque de compatibilité c'est plus dans les API disponible et là source ou binaire ça ne marchera
pas il faudra faire évoluer le code.
Sauf que le kernel n'a pas d'API fixe interne, ce qui empêche ( à tort ou à raison, je pense pas qu'il faille en débattre maintenant ) de faire des drivers out of tree.
Et tu as aussi tout l'userspace. Pris isolément, ça va. Globalement, GTK est pas peté tout le temps, QT encore moins. Ensuite, tu as des choses comme la libboost, qui bouge souvent. Ou ruby ( 1.8/1.9 et les modules ). En pratique, tu as toujours un truc qui changent tout les 2 mois dans une distro et ça requiert de recompiler des paquets.
Donc pas Red Hat par exemple ?
Red Hat, c'est pas une distro, c'est une société. Donc soit tu parles de RHEL, et ç'est pas une distro que je qualifierais de bénévole et communautaire. Soit tu parles de Fedora, et 1) c'est pas Red Hat uniquement 2) c'est un truc qui bouge sans arrêt.
Le socle "totalement figé au niveau du support matériel" c'était il y a quelques années, maintenant Debian stable
mets à jour son noyau, mais même avant ce n'était pas pour un problème de compatibilité que le noyau était gardé
mais pour ne pas ajouter de bug.
D'une part, le support matériel, c'est plus que le noyau, c'est aussi xorg, alsa, les pilotes d'imprimantes. mais en effet, je ne savais pas que Debian avait commencé à backporter le kernel dans la stable.
Et comme tu dit, éviter les régressions, c'est une des faces du problème. Ne pas mettre à jour, c'est la méthode la plus simple et la plus économique ( d'un point de vue "besoin de travail" ). Et garder des patchs minimaux permet aussi d'éviter les effets de bord.
En pratique, c'est à des kilomètres de ce que Microsoft fait pour la compatibilité, ou des batteries de test que RH ou Suse déploient. Y a pas grand monde qui se presse pour ne serais que automatiser ça, même si des outils comme autoqa, de Fedora, ou openQA, de Suse, ça existe mais les gens se jettent pas dessus pour améliorer la qualité. Écrire des jeux de tests, c'est pas si dur pour des choses de base, mais c'est chiant. Et même de base, on a souvent rien. Et je pense qu'il faut soit revoir totalement la perception de la chose, soit payer des gens ( donc besoin de thune ).
Personne ne paiera pour du libre. Aucun particulier ne le ferra ou a des montants assez ridicule et de manière
ponctuelle. Les entreprises le font mais les particuliers ne sont pas capables de le faire (les intéressé le font
pas ou peu alors les autres).
On est d'accord. Une des seules manières efficace, c'est l'OEM, ce qui reviens à avoir comme client HP, Dell, etc, et donc à fournir le libre avec du matériel.
Par contre si on arrive à dépasser une masse critique d'utilisateurs et que ces utilisateurs montrent qu'il y a de
l'argent à se faire il y a une dynamique qui va se créer pour un meilleur support et de manière général pour
prendre en compte linux.
Alors pareil, je suis d'accord sur le fait que ça va montrer qu'il y a de l'argent à se faire. Je doute juste sur le débouché. Comme tu as une vision différente, est ce que tu peux détailler selon toi ce qui a arriver, par exemple :
"on arrive à avoir ça, donc les boites vont filer les specs car maintenant, ça leur apporte des clients" ?
( mais pas ça comme exemple, car ça, j'ai déjà une réponse pour dire que j'y croit pas, genre android, qui n'a pas aboutit au fait de recevoir des tonnes de spec hardware )
[^] # Re: Support matériel
Posté par Misc (site web personnel) . En réponse au journal Vous avez demandé le Desktop, ne quittez pas. Évalué à 3.
Bien sur qu'on peut avoir un modèle de plateforme dans le libre. Il suffit de voir python, ou perl qui ont une bonne compatibilité ascendante ( surtout perl ). Je voulais pas rentrer dans le détail ( mon message était déjà assez long ).
Mais comme tu dis, la base d'un BSD est limité, et en fait, on voit ( selon moi ) qu'on atteint les limites du bénévolat, même si tout le monde n'est pas bénévole, il y a des gens payés pour bosser sur les BSDs à gauche à droite, comme par exemple chez Apple, Netasq. Donc je ne sais pas dans quel mesure est ce que la partie "maintenance" est financé par des boites ( ou on arrive du coup à un modèle de "fédération" pour le financement ).
Et ceci n'aboutit que à implémenter un UNIX, ce qui n'est pas négligeable en soi, loin de la, c'est déjà un immense boulot, mais qui est au moins d'un ordre de magnitude moins que ce qu'on considère comme requis pour un os de bureau moderne ( à savoir genre, avoir un jeu de widget, des services de gestions du réseau, etc ).
À coté, les BSDs ne sont pas connu pour un support matériel à la pointe, et c'est le prix aussi à payer pour le modèle de la cathédrale.
Et enfin en pratique, c'est pas ce qu'on utilise ( avec "on" == "les libristes, notamment ceux que je croise" ), tout comme on utilise pas trop de la Centos 5 sur les stations de travail ( alors qu'au final, ça réponds aux besoins de stabilités exprimés par pas mal de gens si j'en croit ce que j'ai vu sur les listes de Mageia à l'époque )
Donc oui, les BSD se rapprochent de ce modèle de socle, sauf que le socle en question est minuscule, complété par des choses hors du socle ( les ports, etc ), dont l'évolution se fait pas à la même vitesse, ce qui ne colle pas vraiment à la définition. Et qui du coup ne réponds pas au besoin primaire du modèle ( que j'ai pas expliqué plus haut ), à savoir ( selon moi ), le fait de favoriser les développements tierces parties des ISVs.
Sauf que le kernel n'a pas d'API fixe interne, ce qui empêche ( à tort ou à raison, je pense pas qu'il faille en débattre maintenant ) de faire des drivers out of tree.
Et tu as aussi tout l'userspace. Pris isolément, ça va. Globalement, GTK est pas peté tout le temps, QT encore moins. Ensuite, tu as des choses comme la libboost, qui bouge souvent. Ou ruby ( 1.8/1.9 et les modules ). En pratique, tu as toujours un truc qui changent tout les 2 mois dans une distro et ça requiert de recompiler des paquets.
Red Hat, c'est pas une distro, c'est une société. Donc soit tu parles de RHEL, et ç'est pas une distro que je qualifierais de bénévole et communautaire. Soit tu parles de Fedora, et 1) c'est pas Red Hat uniquement 2) c'est un truc qui bouge sans arrêt.
D'une part, le support matériel, c'est plus que le noyau, c'est aussi xorg, alsa, les pilotes d'imprimantes. mais en effet, je ne savais pas que Debian avait commencé à backporter le kernel dans la stable.
Et comme tu dit, éviter les régressions, c'est une des faces du problème. Ne pas mettre à jour, c'est la méthode la plus simple et la plus économique ( d'un point de vue "besoin de travail" ). Et garder des patchs minimaux permet aussi d'éviter les effets de bord.
En pratique, c'est à des kilomètres de ce que Microsoft fait pour la compatibilité, ou des batteries de test que RH ou Suse déploient. Y a pas grand monde qui se presse pour ne serais que automatiser ça, même si des outils comme autoqa, de Fedora, ou openQA, de Suse, ça existe mais les gens se jettent pas dessus pour améliorer la qualité. Écrire des jeux de tests, c'est pas si dur pour des choses de base, mais c'est chiant. Et même de base, on a souvent rien. Et je pense qu'il faut soit revoir totalement la perception de la chose, soit payer des gens ( donc besoin de thune ).
On est d'accord. Une des seules manières efficace, c'est l'OEM, ce qui reviens à avoir comme client HP, Dell, etc, et donc à fournir le libre avec du matériel.
Alors pareil, je suis d'accord sur le fait que ça va montrer qu'il y a de l'argent à se faire. Je doute juste sur le débouché. Comme tu as une vision différente, est ce que tu peux détailler selon toi ce qui a arriver, par exemple :
"on arrive à avoir ça, donc les boites vont filer les specs car maintenant, ça leur apporte des clients" ?
( mais pas ça comme exemple, car ça, j'ai déjà une réponse pour dire que j'y croit pas, genre android, qui n'a pas aboutit au fait de recevoir des tonnes de spec hardware )