Sauf que PulseAudio peut être remplacée par Alsa à ta guise, certains le font d'ailleurs. Puis PulseAudio est libre et non obsolète, donc si défaut il y a rien, rien à voir avec le cas de IE6.
Déjà des programmes commencent à réclamer absolument Pulse Audio, ensuite il y a des incompatibilité et des différences entre l'API Alsa pure et l'API Alsa exposée par Pulseaudio. Donc non pour la première partie de ta phrase
Puis PulseAudio est libre et non obsolète, donc si défaut il y a rien, rien à voir avec le cas de IE6
Pulse Audio est (mal) documenté, ne gère pas les rendus de la même façon d'une machine à l'autre et casse pas mal de fonctionnalités de son avancés pour simplifier les fonctionnalités de base. Effectivement on n'avait pas accès au code d'IE 6 mais au moins les spécificités et les "quirks" d'IE 6 étaient connu et documentés (même si présentés comme des features... Un grand classique). Donc non pas tant de différence entre Pulse Audio aujourd'hui et IE 6 il y a 5 ans.
Oui, mais tu perds ici nettement les avantages que le noyau peut te procurer derrière au profit de la portabilité
Non. L'init n'a rien à voir avec le comportement du noyau. La compatibilité ne fait perdre qu'une seule chose : de la vitesse de boot, donc du pur confort. Rien n'empêchera ton appli après d'utiliser les spécificité du noyau, rien n'empêchera tes pseudo-devices de se créer ou tes droits de descendre. SystemD nef ait que deux choses :
a) accélérer le boot (éventuellement)
b) foutre un boxon de tous les diables dans la hiérarchie des devices et des dossiers systèmes.
De plus systemd garde cette compatibilité pour ceux qui le souhaitent, la vie n'est-elle pas merveilleuse ?
Sauf que c'est juste pour amorcer la pompe, avec derrière l'intention avouée de forcer la normalisation des hierarchies devices/folders pour éviter les scripts à rallonge. Donc à terme des Linux qui ne peuvent booter qu'avec SystemD ou des init qui émulent le comportement des SystemD.
Donc il n'existe aucun composant qui est uniquement afit pour *BSD ou Linux
Bien sur que si, mais ca ne sert à rien pendant l'init. Les noyaux sont très différents, avec des fonctionnalités spécifiques dans les deux cas, mais les API nécessaires à l'init sont les mêmes (et ces API sont très réduites). SystemD et consors ne changeront rien à cela (enfin j'espère, sinon c'est encore pire que ce que je pense).
En quoi cela serait une catastrophe ? Tu aimes avoir des noyaux et autres composants basses sous-exploiter pour une compatibilité parfaite comme actuellement ?
Ok tu ne sais pas de quoi tu parles. On parle des scripts qui attribuent une IP à ta carte réseau et qui lancent le démon apache là. Rien à voir avec les fonctionnalités des couches basses/moyennes/haute du noyau. Il s'agit juste des interfaces qui permettent de lancer un processus, de le daemoniser et de le rattacher à un user ou à un autre processus. Eventuellement de créer un device ou un container de sécurité (et encore c'est vraiment mieux quand c'est fait par le processus lui même plutôt que par le mécanisme d'init).
Cela permet aussi une remise en uqestion de l'organisation précédente.
Quelle remise en question ? Quand on arrive aux limites d'une API et qu'on la casse pour passer à autre chose c'est bien sur profitable, mais quand on a 28 fonctions d'une API pour le même résultat (Bonjour Alsa, bonjour ACPI, bonjour HAL) et qu'au final 3 finissent par être utilisée avec les 25 autres qui pourrissent sur pied sans être ni documentés ni mise à jour ni même marquée "deprecated". Ou est la remise en question ?
_ l'interaction avec le noyau de ces programmes est plus important que pour Firefox par exemple, normal ce sont des composantes basses du système._
Je veux bien que tu m'explique lentement en quoi PulseAudio interagit plus avec le noyau que Firefox, et en quoi il fait partie des composantes basse du système. PulseAudio est un programme userland pur qui choppe Alsa en mode exclusif et qui propose des interfaces pour le piloter. C'est aussi bas niveau que xmms.
Et SystemD c'est pas franchement le top non plus du point de vue "bas niveau", à terme il n'a pas d'autres but que de dialoguer avec DBus. Il est en espace kernel parfois certes, mais c'est juste une API d'abstraction.
Pourquoi alors les utilisateurs de *BSD pleurent de la linuxification de certaines parties du système ?
Principalement parce que ca va leur faire du boulot idiot en plus. Et aussi parce que la rupture du userland va être préjudiciable aux deux parties. Il y a aussi pas mal de BSDistes qui ont apportés de gros bout de codes et d'audits à des projets phares sous GPL (Déjà juste SSH) donc se voir claquer la porte au nez ca les ennerve.
J'ai de gros odutes uqe cela soit à sens unique tu vois… Je ne négligerais les torts d'aucun des deux partis.
Ben écoute quand tu auras trouvé des torts des *BSD (ie des projets sur lesquels les BSD ont profité du code Linux avant de le rendre incompatible avec Linux) fait moi signe, je te promet de ne pas les négliger non plus.
Pour avoir tester, non.
Ben écoute je veux bien ta solution sous Linux avec Network Manager actif pour faire du basculement de route conditionnel. pour l'instant je suis obligé de laisser tourner un watchdog en tache de fond et de simuler des trames DHCP le tout avec des règles IPTables longues comme le bras. Sous windows ca prend 3 ligne de WSH et la config résiste au reboot si le pont est toujours présent.
ne serait-ce pour la détection du mode connecté/déconnecté
Qui permet de crasher pas mal d'autres applications qui auraient parfaitement survécu grace à leur TTL si Network Manager était pas venu foutre le bronx dans les routes et les gateway. C'est toujours bon de perdre son tunnel SSH, sa connexion SIP et son VPN tout çà parceque le système a mis 5 secondes à contourner un équipement défectueux.
[^] # Re: Ça sent le réchauffé...
Posté par Kaane . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 9.
Sauf que PulseAudio peut être remplacée par Alsa à ta guise, certains le font d'ailleurs. Puis PulseAudio est libre et non obsolète, donc si défaut il y a rien, rien à voir avec le cas de IE6.
Déjà des programmes commencent à réclamer absolument Pulse Audio, ensuite il y a des incompatibilité et des différences entre l'API Alsa pure et l'API Alsa exposée par Pulseaudio. Donc non pour la première partie de ta phrase
Puis PulseAudio est libre et non obsolète, donc si défaut il y a rien, rien à voir avec le cas de IE6
Pulse Audio est (mal) documenté, ne gère pas les rendus de la même façon d'une machine à l'autre et casse pas mal de fonctionnalités de son avancés pour simplifier les fonctionnalités de base. Effectivement on n'avait pas accès au code d'IE 6 mais au moins les spécificités et les "quirks" d'IE 6 étaient connu et documentés (même si présentés comme des features... Un grand classique). Donc non pas tant de différence entre Pulse Audio aujourd'hui et IE 6 il y a 5 ans.
Oui, mais tu perds ici nettement les avantages que le noyau peut te procurer derrière au profit de la portabilité
Non. L'init n'a rien à voir avec le comportement du noyau. La compatibilité ne fait perdre qu'une seule chose : de la vitesse de boot, donc du pur confort. Rien n'empêchera ton appli après d'utiliser les spécificité du noyau, rien n'empêchera tes pseudo-devices de se créer ou tes droits de descendre. SystemD nef ait que deux choses :
a) accélérer le boot (éventuellement)
b) foutre un boxon de tous les diables dans la hiérarchie des devices et des dossiers systèmes.
De plus systemd garde cette compatibilité pour ceux qui le souhaitent, la vie n'est-elle pas merveilleuse ?
Sauf que c'est juste pour amorcer la pompe, avec derrière l'intention avouée de forcer la normalisation des hierarchies devices/folders pour éviter les scripts à rallonge. Donc à terme des Linux qui ne peuvent booter qu'avec SystemD ou des init qui émulent le comportement des SystemD.
Donc il n'existe aucun composant qui est uniquement afit pour *BSD ou Linux
Bien sur que si, mais ca ne sert à rien pendant l'init. Les noyaux sont très différents, avec des fonctionnalités spécifiques dans les deux cas, mais les API nécessaires à l'init sont les mêmes (et ces API sont très réduites). SystemD et consors ne changeront rien à cela (enfin j'espère, sinon c'est encore pire que ce que je pense).
En quoi cela serait une catastrophe ? Tu aimes avoir des noyaux et autres composants basses sous-exploiter pour une compatibilité parfaite comme actuellement ?
Ok tu ne sais pas de quoi tu parles. On parle des scripts qui attribuent une IP à ta carte réseau et qui lancent le démon apache là. Rien à voir avec les fonctionnalités des couches basses/moyennes/haute du noyau. Il s'agit juste des interfaces qui permettent de lancer un processus, de le daemoniser et de le rattacher à un user ou à un autre processus. Eventuellement de créer un device ou un container de sécurité (et encore c'est vraiment mieux quand c'est fait par le processus lui même plutôt que par le mécanisme d'init).
Cela permet aussi une remise en uqestion de l'organisation précédente.
Quelle remise en question ? Quand on arrive aux limites d'une API et qu'on la casse pour passer à autre chose c'est bien sur profitable, mais quand on a 28 fonctions d'une API pour le même résultat (Bonjour Alsa, bonjour ACPI, bonjour HAL) et qu'au final 3 finissent par être utilisée avec les 25 autres qui pourrissent sur pied sans être ni documentés ni mise à jour ni même marquée "deprecated". Ou est la remise en question ?
_ l'interaction avec le noyau de ces programmes est plus important que pour Firefox par exemple, normal ce sont des composantes basses du système._
Je veux bien que tu m'explique lentement en quoi PulseAudio interagit plus avec le noyau que Firefox, et en quoi il fait partie des composantes basse du système. PulseAudio est un programme userland pur qui choppe Alsa en mode exclusif et qui propose des interfaces pour le piloter. C'est aussi bas niveau que xmms.
Et SystemD c'est pas franchement le top non plus du point de vue "bas niveau", à terme il n'a pas d'autres but que de dialoguer avec DBus. Il est en espace kernel parfois certes, mais c'est juste une API d'abstraction.
Pourquoi alors les utilisateurs de *BSD pleurent de la linuxification de certaines parties du système ?
Principalement parce que ca va leur faire du boulot idiot en plus. Et aussi parce que la rupture du userland va être préjudiciable aux deux parties. Il y a aussi pas mal de BSDistes qui ont apportés de gros bout de codes et d'audits à des projets phares sous GPL (Déjà juste SSH) donc se voir claquer la porte au nez ca les ennerve.
J'ai de gros odutes uqe cela soit à sens unique tu vois… Je ne négligerais les torts d'aucun des deux partis.
Ben écoute quand tu auras trouvé des torts des *BSD (ie des projets sur lesquels les BSD ont profité du code Linux avant de le rendre incompatible avec Linux) fait moi signe, je te promet de ne pas les négliger non plus.
Pour avoir tester, non.
Ben écoute je veux bien ta solution sous Linux avec Network Manager actif pour faire du basculement de route conditionnel. pour l'instant je suis obligé de laisser tourner un watchdog en tache de fond et de simuler des trames DHCP le tout avec des règles IPTables longues comme le bras. Sous windows ca prend 3 ligne de WSH et la config résiste au reboot si le pont est toujours présent.
ne serait-ce pour la détection du mode connecté/déconnecté
Qui permet de crasher pas mal d'autres applications qui auraient parfaitement survécu grace à leur TTL si Network Manager était pas venu foutre le bronx dans les routes et les gateway. C'est toujours bon de perdre son tunnel SSH, sa connexion SIP et son VPN tout çà parceque le système a mis 5 secondes à contourner un équipement défectueux.