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.
[^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes
Posté par jym@netbsd . En réponse au journal GNOME seulement compatible avec Linux ?. Évalué à 10.
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.
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.