Puis aujourd'hui je doute que PulseAudio, systemd et autres soient si gênants sauf cas assez particuliers…
Pareil que IE 6. Ça ne gênait absolument pas les utilisateurs, sauf cas assez particulier d'un ou deux sites(par ailleurs totalement oubliable pour les dits utilisateurs)
Prenons le cas du démarrage, c'est une étape qui dépend énormément du noyau et de ce qu'il fait en interne
Pas trop non. Enfin dans la mesure ou le noyau respecte les normes POSIX, le démarrage peut être accompli de moult façons différentes. La plupart des scripts écrits en SystemV fonctionnent sur plusieurs Unix différents, avec parfois un renommage de périph ici ou là.
il est donc je pense logique de faire une application propre pour chaque noyau pour bénéficier au mieux de ses capacités
C'est tellement logique que personne ne le fait. La plupart des scripts de démarrage fonctionnent très bien même si tu changes ton noyau. Encore qu'avec DBus/hald et autres network manager on se rapproche dangereusement du moment ou mise à jour du noyau = mise à jour de l'init. Ce qui serait une vraie catastrophe.
Par contre les commandes shell comme rm, mv et autres sont indépendants du noyau en soit, ce qui rend la compatibilité pour ces commandes utiles.
Le problème est justement des commandes shell, comme route, ifconfig, dhcpcd qui ont un comportement bizarre quand il y a network manager derrière.
À quoi sert un noyau avec des différences de *BSD (donnant des avantages au premier sur le dernier et inversement), si on ne peut pas les exploiter par peur de brusquer la communauté ?
Personne ne t'interdit de les utiliser. C'est juste qu'il y a des personnes qui veulent ne pas les utiliser. Pour des raisons diverses. La compatibilité est une des raisons, la stabilité du système (au niveau API), la prédictibilité, la flexibilité, la maintenance en sont d'autres. Honnêtement avec des API qui changent en permanence (DBus, HAL, Alsa) des daemons qui viennent casser des comportements séculaire d'UNIX sans rien apporter de fondamental, juste un peu de confort pour l'utilisateur et une absence récurrente de doc, on a clairement pas envie de sortir des clous et d'adapter l'OS à son besoin. Or c'est supposé être ça la force de Linux.
Et je trouve pour l'instant que cette linuxification touche les couches concernés par le noyau de manière assez forte (donnant un intérêt à faire dans son coin, la compatibilité étant utile pour les couches plus hautes et indépendantes du noyau). Typiquement PulseAudio et systemd entrent dans ce cadre.
Pour info PulseAudio est userland et SystemD va chatouiller le hardware. Donc dire qu'ils sont tous les deux dans le même cas c'est un poil contradictoire.
Je ne suis donc pas d'accord avec la compatibilité à tout prix que semblent vouloir les *BSD
Les *BSD ne veulent pas la compatibilité à tout prix,
- OpenBSD en a rien à battre
- NetBSD pleure un peu parcequ'ils n'ont pas la dev team assez fournie pour patcher l'ensemble de leurs ports assez vite pour mettre à jour si la compatibilité est cassée dans de telles proportions, donc ils essayent de coder des wrappings dans tous les sens pour permettre une certaine compatibilité. Mais vu la vitesse des changements des API et l'état de la doc c'est pas gagné.
- FreeBSD a déjà pris les devant et commence lentement (mais surement) à foutre dehors le GNU. Je pense que FreeBSD 11 ou 12 fonctionnera très bien sans GCC et les outils GNU.
Maintenant le problème c'est pas les *BSD, qui ont clairement l'habitude que la communauté Linux leur crache à la gueule (clause de publicité, accelerateurs TCP, scheduler, Pilotes wifi etc. ) c'est Linux tout seul. Je pense être relativement balèze en Linux/Unix Like et je n'arrive plus sous les dernières versions de Linux
- A créer des devices ou des pseudo devices persistant
- A configurer X11 comme je veux
- A faire des config réseau conditionelles
- A capter des events systèmes et à leurs associer des règles qui seront systématiquement respectés (mention spéciale au branchement de périph de stockage type clef USB)
Aujourd'hui c'est plus facile de faire des switchs de route entre différents alias de cartes réseaux sous Windows 7 que sous Linux avec network manager. Si ça ne vous inquiète pas, tant mieux.
[^] # Re: Ça sent le réchauffé...
Posté par Kaane . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 8.
Puis aujourd'hui je doute que PulseAudio, systemd et autres soient si gênants sauf cas assez particuliers…
Pareil que IE 6. Ça ne gênait absolument pas les utilisateurs, sauf cas assez particulier d'un ou deux sites(par ailleurs totalement oubliable pour les dits utilisateurs)
Prenons le cas du démarrage, c'est une étape qui dépend énormément du noyau et de ce qu'il fait en interne
Pas trop non. Enfin dans la mesure ou le noyau respecte les normes POSIX, le démarrage peut être accompli de moult façons différentes. La plupart des scripts écrits en SystemV fonctionnent sur plusieurs Unix différents, avec parfois un renommage de périph ici ou là.
il est donc je pense logique de faire une application propre pour chaque noyau pour bénéficier au mieux de ses capacités
C'est tellement logique que personne ne le fait. La plupart des scripts de démarrage fonctionnent très bien même si tu changes ton noyau. Encore qu'avec DBus/hald et autres network manager on se rapproche dangereusement du moment ou mise à jour du noyau = mise à jour de l'init. Ce qui serait une vraie catastrophe.
Par contre les commandes shell comme rm, mv et autres sont indépendants du noyau en soit, ce qui rend la compatibilité pour ces commandes utiles.
Le problème est justement des commandes shell, comme route, ifconfig, dhcpcd qui ont un comportement bizarre quand il y a network manager derrière.
À quoi sert un noyau avec des différences de *BSD (donnant des avantages au premier sur le dernier et inversement), si on ne peut pas les exploiter par peur de brusquer la communauté ?
Personne ne t'interdit de les utiliser. C'est juste qu'il y a des personnes qui veulent ne pas les utiliser. Pour des raisons diverses. La compatibilité est une des raisons, la stabilité du système (au niveau API), la prédictibilité, la flexibilité, la maintenance en sont d'autres. Honnêtement avec des API qui changent en permanence (DBus, HAL, Alsa) des daemons qui viennent casser des comportements séculaire d'UNIX sans rien apporter de fondamental, juste un peu de confort pour l'utilisateur et une absence récurrente de doc, on a clairement pas envie de sortir des clous et d'adapter l'OS à son besoin. Or c'est supposé être ça la force de Linux.
Et je trouve pour l'instant que cette linuxification touche les couches concernés par le noyau de manière assez forte (donnant un intérêt à faire dans son coin, la compatibilité étant utile pour les couches plus hautes et indépendantes du noyau). Typiquement PulseAudio et systemd entrent dans ce cadre.
Pour info PulseAudio est userland et SystemD va chatouiller le hardware. Donc dire qu'ils sont tous les deux dans le même cas c'est un poil contradictoire.
Je ne suis donc pas d'accord avec la compatibilité à tout prix que semblent vouloir les *BSD
Les *BSD ne veulent pas la compatibilité à tout prix,
- OpenBSD en a rien à battre
- NetBSD pleure un peu parcequ'ils n'ont pas la dev team assez fournie pour patcher l'ensemble de leurs ports assez vite pour mettre à jour si la compatibilité est cassée dans de telles proportions, donc ils essayent de coder des wrappings dans tous les sens pour permettre une certaine compatibilité. Mais vu la vitesse des changements des API et l'état de la doc c'est pas gagné.
- FreeBSD a déjà pris les devant et commence lentement (mais surement) à foutre dehors le GNU. Je pense que FreeBSD 11 ou 12 fonctionnera très bien sans GCC et les outils GNU.
Maintenant le problème c'est pas les *BSD, qui ont clairement l'habitude que la communauté Linux leur crache à la gueule (clause de publicité, accelerateurs TCP, scheduler, Pilotes wifi etc. ) c'est Linux tout seul. Je pense être relativement balèze en Linux/Unix Like et je n'arrive plus sous les dernières versions de Linux
- A créer des devices ou des pseudo devices persistant
- A configurer X11 comme je veux
- A faire des config réseau conditionelles
- A capter des events systèmes et à leurs associer des règles qui seront systématiquement respectés (mention spéciale au branchement de périph de stockage type clef USB)
Aujourd'hui c'est plus facile de faire des switchs de route entre différents alias de cartes réseaux sous Windows 7 que sous Linux avec network manager. Si ça ne vous inquiète pas, tant mieux.