Journal Linux ou POSIX ?

Posté par  (site web personnel) .
59
26
jan.
2011
POSIX c'est le standard officiel qui définit les interfaces communes à tous les systèmes de type Unix. Quand vous voulez que votre programme fonctionne sur tous les Unix alors vous codez en respectant les interfaces POSIX et hop, magique, vous êtes compatible avec Linux, les BSD, Solaris, etc.
Bien entendu c'est une contrainte puisqu'on doit se limiter au plus petit dénominateur commun et on ne peut plus utiliser les spécificités techniques de chaque plateforme. Ou alors on fait des chemins spécifiques dans le code pour chacun des OS mais on le paye en temps de développement, facilité de relecture, nombre de bugs, etc.

Cette question de la portabilité du code entre les différents OS a été évoquée récemment à l'occasion de la sortie de l'environnement de bureau Xfce 4.8. Dans l'annonce officielle il était dit que les systèmes BSD allait perdre des fonctionnalités puisque Xfce utilisait des composants n'existant que sous Linux (comme udev, consolekit, policykit, etc). Un post plus détaillé a été publié pour bien expliquer le problème qui se pose. L'infrastructure qui entoure Linux est très mouvante puisque la philosophie des développeurs est de ne pas avoir peur de changer les choses si on peut améliorer un point.
Cette philosophie est mal vécue par les adeptes des systèmes BSD qui sont souvent plus conservateurs et qui manquent de main d'oeuvre pour suivre le rythme des changements.
Quand on lit les commentaires l'opposition se résume souvent à "Sous Linux c'est pourri car tout change d'une année sur l'autre" contre "Si les BSD veulent que ça fonctionne chez eux il faut qu'ils se réveillent et qu'il participent au lieu de chouiner dans leur coin".

Alors que faire ? Doit-on choisir de se limiter à POSIX ou bien ne coder que pour Linux en se disant que les autres suivront ?
Nous ne sommes pas vendredi et c'est bien dommage car l'interview qu'a donné Lennart Poettering à l'occasion du FOSDEM est un petit bijou de provocation sur ce sujet.
Lennart évoque systemd (le démon init qu'il écrit pour remplacer sysvinit) et il détaille toutes les fonctions du noyau Linux qu'il exploite dans son code. Que ce soit cgroups, udev, fanotify, timerfd, signalfd, etc, on voit que systemd s'appuie à fond sur du code spécifique à Linux et qu'il serait extrêmement difficile de le porter sur un autre système.

Selon lui le fait d'utiliser toutes ces interfaces modernes au lieu de se limiter aux interfaces classiques POSIX est un énorme avantage:

"Ne pas avoir à se préoccuper de la portabilité à deux gros avantages: Nous pouvons utiliser ce que nous offre un noyau Linux moderne sans nous prendre la tête - Linux est un des noyaux les plus complets qui existe mais beaucoup de ses fonctions ne sont pas exploitées par les autres solutions d'init. Et deuxièmement cela simplifie grandement notre code et le rend plus compact. Comme nous n'avons pas à construire des abstractions d'OS la quantité de code glue est minimale et nous avons moins de chance d'introduire des bugs, moins de chance de désorienter le lecteur du code (donc amélioration de la maintenabilité) et une empreinte réduite".

Jusque là tout va bien et, même si les utilisateurs des autres systèmes regrettent sans doute cet abandon de la portabilité, Lennart est dans son droit d'écrire son code comme il le veut.
Là ou c'est plus tangent c'est quand il recommande joyeusement aux autres de faire comme lui:

"En fait, de la façon dont je vois les choses, l'API Linux joue maintenant le rôle de l'API POSIX et Linux est devenu le point focal de tout le développement du logiciel libre. De ce fait je ne peux que recommander aux développeurs d'essayer de hacker avec seulement Linux en tête et de faire l'expérience de la liberté que cela apporte et des opportunités que cela vous ouvre. Procurez-vous une copie du livre "The Linux Programming Interface", ne vous préoccupez pas de tout ce qui est écrit dedans au sujet de la compatibilité POSIX et écrivez votre super logiciel Linux. Ça soulage !".

Je ne sais pas si ça soulage mais en tout cas ce n'est pas avec ce genre d'appel qu'il va se faire des amis chez les BSDphiles.
  • # Cela dépend des cas…

    Posté par  (site web personnel) . Évalué à 10.

    Pour moi cela dépend grandement des cas de ce qu'il faut faire.
    Systemd notamment s'occupe du démarrage de la machine, c'est un moment important et où la cohésion avec le noyau doit être la plus importante pour aller plus vite et faire les choses du mieux que possible à cette étape cruciale (quand on sait que certains tuent pour quelques secondes de gagner…). Je ne vois pas l'intérêt de porter un tel programme alors que justement son but est de profiter au maximum du noyau support pour être optimisé. Puis ce n'est pas comme si l'absence de systemd va gêner *BSD ensuite.

    Le cas Xfce est plus différent. Pour moi la question c'est : quelle est la proportion d'utilisation du Xfce parmi les différents OS l'utilisant ? Si *BSD est pratiquement absent, il ne faut pas s'étonner de la situation malheureusement, les développeurs ne vont pas si priver pour une poignée d'utilisateurs alors qu'ils pourront « changer la vie » de plusieurs fois d'autres personnes.

    De toute façon je pense que le concept de POSIX est à modérer. Son but était d'unifier les API Unix pour éviter la guerre d'incompatibilité entre les différentes solutions. Mais GNU/Linux et *BSD sont si différents et évoluent chacun de leur côté, ça serait ridicule d'empêcher l'un ou l'autre de s'envoler de ses propres ailes avec ses solutions, selon moi POSIX ne doit concerner que les parties génériques des Unix et ne pas aller trop loin (tout ce qui pourrait toucher de près ou de loin le noyau et le matériel, car on voit que souvent les problèmes sont liés à l'abstraction matériel qui divergent chez *BSD et GNU/Linux).

    Pour moi il ne faut pas s'étonner de la situation ni s'offenser. Par contre il ne faut pas aller trop loin non plus… Je suis assez mitigé sur la question c'est vrai.

    Et que personne ne s'offusque, j'ai peut être dit de grosses conneries, merci de me corriger dans ce cas. =)
    • [^] # Re: Cela dépend des cas…

      Posté par  . Évalué à 5.

      quand on voit les interfaces "linux only", de type Alsa, pulse audio, consolekit, policikit, on se dit que finalement le posix c'est beaucoup plus simple et fiable. Je n'ai personnellement jamais réussi à comprendre comment utiliser ces trucs...

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Cela dépend des cas…

        Posté par  (Mastodon) . Évalué à 7.

        quand on voit les interfaces "linux only", de type Alsa,

        Je bricole actuellement des trucs avec la partie MIDI d'ALSA, et j'aimerais retrouver la même chose avec OpenBSD, dans lequel la gestion du MIDI est très différente. Et sur ce domaine précis, je crois que Posix ne peut pas grand chose...
        • [^] # Re: Cela dépend des cas…

          Posté par  . Évalué à 5.

          Je pense que l'idee de posix c'est justement d'eviter des trucs de ce style http://blogs.adobe.com/penguin.swf/linuxaudio.png

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

          • [^] # Re: Cela dépend des cas…

            Posté par  . Évalué à 6.

            Ouaip, sauf que la dernière fois qu’on a sorti ce graphique sous Linuxfr je me suis fais un malin plaisir de faire un parallèle avec le système de mail (fetchmail+postfix+dovecot+procmail). Pourtant je ne crois pas avoir entendu grand monde se plaindre de la complexité d’un serveur de mail sous Linux ; à raison car tu peux juste avoir quelque chose de fonctionnel (ie. récupération, imap, filtre) et simple avec fetchmail et dovecot (tout troll sur le meilleur serveur imap est la bienvenue:).

            Pour l’audio c’est pareil, tu peux juste mettre pulse-audio et ensuite tes différentes libs qui ont besoin du son « attaquent » pulse. Testé et validé sous Debian : enlevé les paquets alsa-*, mettre pulse, vérifier que la lib. multimedia gère pulse (c’est le cas de gstreamer, sdl et mplayer au moins).
            • [^] # Re: Cela dépend des cas…

              Posté par  . Évalué à 1.

              La difference avec un systeme de mail, c'est que les applis qui doivent envoyer un mail en local ne vont pas peter du jour au lendemain parce qu'ubuntu est passee de postfix a sendmail.
              C'est pourtant plus ou moins ce qui est arrive avec le plugin flash (remplacer flash par n'importe quel autre appli faisant pouic pouic quand on clique) quand il sont passe a pulse audio.

              La question c'est pas de reduire la complexite de configuration de tel ou tel appli, c'est de definir des interfaces pour que les applis puissent marcher tout court.

              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

              • [^] # Re: Cela dépend des cas…

                Posté par  . Évalué à 6.

                « avec le plugin flash »

                Humpf… humpf… MOUAHAHAHAHAHA

                Non rien, je cherche même plus à argumenter… c’est comme les griefs fait contre Firefox ça, « — T’as Flash ? — oui — démerdes toi — … » bon en même temps le graphe vient de blogs.adobe.com… fallait pas s’attendre à autre chose.

                « La question c'est pas de reduire la complexite de configuration de tel ou tel appli, c'est de definir des interfaces pour que les applis puissent marcher tout court. »

                Tu remarqueras que c’est le but avoué d’un serveur de son… mais là le mec qui a fait ce graphe il a juste découvert que Linux est modulaire, en mélangeant allègrement au passage ce qui est du ressort du noyau (et techniquement n’importe quelle appli, pour n’importe quel usage peut « s’amuser » à attaquer l’interface exposée par le noyau), ou encore en y incluant les lib. multimédia qui n’ont pas pour rôle de gérer le son du système. C’est vrai pour l’ensemble du système, tu peux empiler les couches de façon tarabiscotée, ou alors faire en sorte, temporairement, que les applis ne connaissant pas pulseaudio parlent en alsa à un périphérique exposé par pulseaudio exprès (mais c’est terminé cette période il me semble, peut-être à part pour quelques applis obscures). Il n’y a guère que X et la couche graphique qui était simple (dans le sens où il n’y avait pas trop à se poser de questions sur ce qu’il fallait installer), mais ils sont en train de tout changer aussi de ce côté là.

                Contrairement à d’autres j’aime bien la direction que prend le développement ces dernières années, ça prouve une activité : on teste des solutions, on récupère ce qui marche bien, etc. Et oui les utilisateurs d’Ubuntu sont plus ou moins contraints de servir de testeurs vu l’orientation de la distribution… on va bien rigoler aussi s’ils veulent mettre wayland aussi vite qu’ils le disent. Personnellement je rigole bien : j’installe les choses, je les teste, j’avise, et ma distrib. m’emmerde pas si je ne les installe pas. :)

                Et la modularité et la multiplicité des solutions n’est pas négociable, c’est juste la conséquence intrinsèque de la liberté des utilisateurs et des développeurs.
                • [^] # Re: Cela dépend des cas…

                  Posté par  . Évalué à 1.

                  Ca veut pas dire grand chose ce que tu racontes la, tu sens fort le linuxien qui se rend compte que son systeme est pas parfait et fait donc diversion pour eviter la critique.

                  La situation de la stack sonore linux est un gros merdier ingerable, que ca te plaise ou non. Le simple fait d'avoir 3 API kernel est deja une aberration. Tout le monde sait tres bien pourquoi on en est arrive la, c'est pas trop le sujet en fait.
                  Surtout quand on compare a la concurrence qui a une api qui juste marche depuis 15 ans.

                  Ce qui me choque dans ce graphe, c'est pas les boites grises (frameworks haut niveau), c'est les boite de couleurs, et surtout le fait que chaque boite grise est connectee a chaque boite de couleur et a chaque autre boite grise.
                  Dans un monde ideal, t'aurais une box de couleur, autant de box grise que tu veux, les box grises connectee a la box de couleur et basta. Le fait d'etre oblige d'ecrire 25 couches de compatibilite avec le reste du monde denote d'un serieux probleme d'architectures, tu trouve pas? Et ca c'est pas de la modularite vu qu'il faut explicitement supporter tout le reste du monde sous peine d'avoir un truc qui pete qq part chez un utilisateur.
                  Et meme avec ca, ca a jamais vraiment marche a 100% non plus.
                  Les serveurs de sons n'ont pas entierement resolu le probleme vu que personne n'a jamais reussi a se mettre d'accord sur une api. Ce qu'ils ont surtout reussi a faire c'est transformer un probleme bas niveau en un probleme haut niveau de jungle d'API.
                  Surtout a la grande epoque ou tu te retrouve avec arts ET esd parce que telle appli supportait l'un et pas l'autre et inversement, oblige d'en tuer un pour relancer l'autre, et entre temps t'as machin qui a fait pouic pouic et qui squatte le canal OSS et du coup ton serveur de son se retrouve le bec dans l'eau a pas faire de son etc.

                  PulseAudio vient mettre de l'ordre la dedans, mais ca resoud surtout le probleme en tapant sur la table et en disant "bon les gars, on arrete les conneries et tout le monde utilise le meme serveur de son maintenant", vu que pulse audio doit toujours supporter alsa/oss et les 450 000 frameworks sonore.
                  Et ca a pris quoi, 10 ans pour en arriver la?
                  Certes, ya de l'activite, mais je suis pas sur que le resultat soit super brillant dans le domaine du son...

                  bon en même temps le graphe vient de blogs.adobe.com…
                  Ouais, ben en attendant je pense que la gars a une connaissance de la stack multimedia linux un peu plus approfondie que toi...

                  on teste des solutions, on récupère ce qui marche bien
                  C'est vrai pour pas mal d'aspect du development linux, mais en ce qui concerne le son, c'est surtout une grosse dose de NIH syndrom couple a une envie frenetique de tout peter pour un truc qui brille tous les 6 mois.

                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                  • [^] # Re: Cela dépend des cas…

                    Posté par  . Évalué à 1.

                    en fait la boite développant n'aurait pas merdé en voulant fermer leur code, on en serait pas là.

                    C'est con, mais c'est comme ça.

                    > La situation de la stack sonore linux est un gros merdier ingerable,
                    Jamais eu de problème, et j'ai même la capacité depuis pas mal d'année de jouer un son sur un autre PC (oui je l'ai fait, je ne me souviens plus pourquoi mais à l'époque c'était la solution la plus simple (une seule chaine hifi pour plusieurs machine)

                    Pour le reste si tu veux pas te faire chier en dev tu fais une sortie alsa, ou si tu veux du temps réel jack.
                    Oss aurait eu un intérêt (théoriquement plus portable), mais comme dit ci dessus y'en a qu'on merdé.

                    Enfin point de vu utilisateur, je préfère nettement ce que j'ai avec pulse ou jack que le truc que j'ai sous windows (réglage des niveaux sonores par application, sélection de la sortie...)

                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                    • [^] # Re: Cela dépend des cas…

                      Posté par  . Évalué à 1.

                      en fait la boite développant n'aurait pas merdé en voulant fermer leur code, on en serait pas là.
                      Ben voyons, ca va etre de leur faute bientot...
                      Pour autant que je sache, le but de ce genre d'API bas niveau c'est de fonctionner pour tout le monde non?

                      Pour le reste si tu veux pas te faire chier en dev tu fais une sortie alsa, ou si tu veux du temps réel jack.
                      Ouais, et tu penses aussi a supporter OSS au cas ou.
                      C'est bien le fond du probleme je crois... Dire "il suffit de supporter les 3 api majeures", c'est precisement ca le probleme. Bon, ca s'ameliore, doucement, mais ca s'ameliore.


                      Enfin point de vu utilisateur, je préfère nettement ce que j'ai avec pulse ou jack que le truc que j'ai sous windows (réglage des niveaux sonores par application, sélection de la sortie...)
                      C'est cool que ca te plaise, mais personnelement, a l'epoque ou j'utilsiais linux sur mon desktop, un seul volume pour le systeme qui marche 100% du temps sans avoir a explicitement choisir mon backend sonore, ca m'aurait deja rendu heureux.
                      Avant de savoir courir, il faut apprendre a marcher comme qui dirait.

                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                      • [^] # Re: Cela dépend des cas…

                        Posté par  . Évalué à 2.

                        Ben voyons, ca va etre de leur faute bientot...
                        Si demain une boite, disons... Sun, se fait racheter par, aller au hasard, Oracle, et que java se fait verrouiller de tout coté, et qu'il faut pour tous les pc récent une version fermée et payante, faudra pas longtemps pour qu'il y ait des alternatives.
                        Ha on me souffle qu'il existe déjà au moins 4 jvm, et qu'elles ne datent pas d'hier :) Ça aussi c'est le bazar (et que sur java).
                        Hé oui tu fermes ton codes, c'est un appeau à projets concurrent

                        Ouais, et tu penses aussi a supporter OSS au cas ou.
                        OSS = DEPRECIATED
                        Depuis fiouu la le noyau 2.4.des poussières?

                        Dire "il suffit de supporter les 3 api majeures"
                        Une SEULE bordel; alsa, et ce depuis pas mal d'années; si tu veux faire du temps réel, tu prends jack, et tu oublies alsa. (Et maintenant, je dirai pusle ou jack vu que les gens on l'air d'accord pour plulse)

                        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                        • [^] # Re: Cela dépend des cas…

                          Posté par  (site web personnel) . Évalué à 3.

                          Dire "il suffit de supporter les 3 api majeures"
                          Une SEULE bordel; alsa, et ce depuis pas mal d'années; si tu veux faire du temps réel, tu prends jack, et tu oublies alsa.


                          Et au revoir portabilité :)

                          Alsa n'est pas portable c'est quand même clair (en plus d'être super complexe par rapport a OSS qui est quand même le standard historique sur tous les unix)

                          bref.
                        • [^] # Re: Cela dépend des cas…

                          Posté par  . Évalué à 5.

                          OSS = DEPRECIATED
                          Depuis fiouu la le noyau 2.4.des poussières?


                          Chez moi c'est l'inverse, c'est ALSA qui disparaît 3 secondes après l'installation de la distribution.

                          Y a OSS, qui gère tout ce que doit gérer un pilote audio (multiplexage, etc.) et de l'autre coté y a ALSA, Linux-only et qui gère rien du tout.
                  • [^] # Re: Cela dépend des cas…

                    Posté par  . Évalué à 9.

                    Mouai… le mec qui me parle de système parfait, je rigole bien fort. T’as autant de systèmes parfaits que d’utilisateurs… J’apprécie que Linux me permette de réellement adapter le système pour qu’il soit parfait pour moi. Et comme je l’ai déjà dit ce n’est pas négociable. Ça a son lot d’inconvénient (je sais, c’est dur de choisir, c’est mieux quand papa Steve vous dit ce qui est bien et ce qui mal, plus sérieusement : les choix fait par les distrib. semblent assez risqués). Nom de dieu de pète mes couilles, quand est-ce que vous allez comprendre messieurs les trolleurs que Linux est un grand bazar c’est précisément le but.

                    « Surtout quand on compare a la concurrence qui a une api qui juste marche depuis 15 ans. »

                    Anne attend de la concurrence qu’elle permette de choisir de ne pas avoir de serveur de son. Jean-Paul attend de la concurrence de ne pas avoir de son du tout (moi dans une vie antérieure*). Maxime attend de la concurrence de faire du temps réel. Elle le fait la concurrence ? Ah! puis moi j’aime bien mon mpd, la concurrence a un lecteur de musique (juste un lecteur de musique) avec un protocole documenté pour pouvoir coder un petit client tout bien comme je veux (fade in/out+aléatoire pas trop con+console+arrêt uniquement à la fin du morceau), ah! et puis qui me fasse de la reconversion à la volée de flac vers ogg pour du streaming sur http ou n’importe quoi d’autre via ADSL. Toujours là la concurrence ?

                    « Le simple fait d'avoir 3 API kernel est deja une aberration. »

                    Et c’est juste faux :
                    make menuconfig
                    devices …
                    sound …
                    — ALSA
                    — OSS (DEPRECATED) (depuis pfiou… 4 ans? au moins)

                    Oui je sais j’y connais rien à la pile son sous Linux, donc je dois croire un obscur graphe trouvé sur un blog… make menuconfig c’est définitivement pas fiable comme méthode pour se renseigner sur le kernel.

                    « chaque boite grise est connectee a chaque boite de couleur et a chaque autre boite grise. »

                    Oui j’ai déjà répondu sur ce point, c’est juste faux. Y’a peut-être un malentendu : tu n’es pas obligé de connecter toutes les boîboites sur ton système (oui tu es libre de faire beaucoup plus simple, je sais c’est dur d’avoir la liberté de choix de sa pile son… quel drame, tu dois être perdu…). Et j’ai un scoop pour toi : si pulse expose l’API alsa aux applis ne parlant qu’alsa, ben ça veux pas dire que ton son est géré deux fois… c’est juste une API hein, le boulot n’est pas fait deux fois ! Mais là encore j’y connais rien, je dois croire un obscur graphe trouvé sur un blog plutôt que mon ordinateur qui me fait juste du son (merde mon ordinateur n’a pas 90 % des flèches du graphe… le mec d’Adobe a dû oublier de le mettre au courant).

                    « Dans un monde ideal, t'aurais une box de couleur, autant de box grise que tu veux, les box grises connectee a la box de couleur et basta. »

                    Et c’est ce que j’ai sur mon ordi. Enfin, j’ai PulseAudio suivant l’humeur du moment.

                    « Et ca c'est pas de la modularite vu qu'il faut explicitement supporter tout le reste du monde sous peine d'avoir un truc qui pete qq part chez un utilisateur. »

                    Oui ces cons d’utilisateurs de Linux, ils n’en font qu’à leur tête, on leur dit d’utiliser Windows, comme tout le monde histoire que les dév. n’aient qu’à dév. pour Win. (dédicace Zenitram), et paf! ils en veulent pas. Bon on tolère Mac alors, parce que Steve est sympa. et… paf! ils en veulent pas non plus. Merde alors. Bon ok laissons les gus dans leur garage… rhâ même pas foutu de faire tous la même chose, non faut que chacun utilise sa propre solution différente du voisin. Je t’ai déjà parlé d’un certain bazar, peut-être pas de la cathédrale alors ?

                    « Et ca a pris quoi, 10 ans pour en arriver la? »

                    Ben 8 ans que je suis exclusivement sous Linux, 8 ans que j’ai du son (ou pas! *j’ai eu un vieux coucou à une époque, le simple fait de décoder un mp3 était un calvaire). Par contre je me rappelle très bien qu’il fallait explicitement rajouter les utilisateurs dans le groupe audio sous Debian pour avoir accès au périphérique.

                    Merde, on n’est plus vendredi… j’ai pas fait gaffe à l’heure…
                    • [^] # Re: Cela dépend des cas…

                      Posté par  . Évalué à 2.

                      Nom de dieu de pète mes couilles, quand est-ce que vous allez comprendre messieurs les trolleurs que Linux est un grand bazar c’est précisément le but
                      Oui, et ce que je disais initialement, c'est que l'objectif de POSIX c'est precisement d'eviter ce bazar.
                      Je rappelle que l'assertion intiale etait "POSIX n'y peut pas grand chose", si, POSIX peut eviter ce merdier qui est tout sauf voulu.
                      T'as beau tourner le probleme dans tous les sens et utiliser toute la novlangue du monde, la situation du son sous linux c'est la merde profonde, ca n'a AUCUN avantage, c'est juste un gros merdier.
                      Un merdier qu'on a appris a gerer, mais un merdier quand meme. POINT!

                      Oui je sais j’y connais rien à la pile son sous Linux, donc je dois croire un obscur graphe trouvé sur un blog… make menuconfig c’est définitivement pas fiable comme méthode pour se renseigner sur le kernel.
                      C'est sur, tu preferes te rassurer en inventant des arguments debiles plutot que de faire confiance a un mec dont le boulot est d'ecrire la version linux du plugin multimedia le plus utilise sur la planete.
                      Honnetement, rendu a ce niveau, tes reponses ne m'etonnent plus.

                      Oui j’ai déjà répondu sur ce point, c’est juste faux.
                      Non, c'est pas faux. Ya des binding a la con de chaque framework vers chaque autre framework parce que c'est la seule facon de faire un truc potable.
                      Personne n'a force personne a le faire, mais generalement quand on se fait chier a ecrire des bindings redondants, c'est pour une bonne raison. En l'occurence, faire marcher le son chez tout le monde quelle que soit la methode d'output installee par l'utilsiateur.

                      (merde mon ordinateur n’a pas 90 % des flèches du graphe… le mec d’Adobe a dû oublier de le mettre au courant).
                      ....
                      La je sais plus quoi dire.
                      Ce que le graphe veut dire, c'est que chaque framework (les boites grises) ont des bindings pour sortir vers n'importe quelle autre boite grise. Pas qu'il faut tout avoir installe pour que ca marche...
                      PArce qu'on veut que gstreamer puisse parler a ESD ou arts selon ce que t'as sur ta machine.
                      Que si gstreamer ne peut parler qu'a esd, ben ca va pas le faire chez 50% des utilisateurs. Mais qu'il ya aussi des gens qui n'ont ni ESD ni arts et que donc faut aussi parler a ALSA. Et OSS, parce que certains n'ont pas alsa.
                      Mais certains sont sur jack qui parle a FFADO et donc faut aussi pouvoir parler a Jack directement si pulse audio n'est pas la et ... Serieux, faut que je continue longtemps?

                      Pour reprendre ton parallele des emails, si la meme situation s'appliquait aux mail, faudrait que thunderbird integre des bindings vers le moindre serveur de mail existant pour etre sur de pouvoir envoyer un mail parce que personne ne s'est mit d'accord sur le protocole a utiliser...

                      Et j’ai un scoop pour toi : si pulse expose l’API alsa aux applis ne parlant qu’alsa, ben ça veux pas dire que ton son est géré deux fois…
                      Ah bon?
                      Et comment fait Pulse pour exposer l'api alsa?
                      Il dit juste "alsa!"?
                      Non, il se tape un boulot de wrapping alsa.
                      et il doit faire la meme chose pour oss.
                      Et pour FFADO.
                      Et quand ca change, il doive le maintenir, faire gaffe a pas peter la compatibilite backwards etc.

                      Oui ces cons d’utilisateurs de Linux, ils n’en font qu’à leur tête, on leur dit d’utiliser Windows
                      Personne n'a dit d'utiliser windows, tout ce que je dit ici, c'est que c'est un merdier sans nom, c'est tout.
                      Si ca te plait, ben qu'est ce que tu veux que je te dise?
                      T'utilises pas le meilleur os de la planete, big fucking deal, qu'est ce qu'on s'en cogne? Tant que t'en es content de ton linux et que tu viens pas pretendre que la stack son sous linux est super, tout va pour le mieux...

                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                      • [^] # Re: Cela dépend des cas…

                        Posté par  . Évalué à 3.

                        Heu mon gars, t’as rien compris à ce que je raconte.
                        — Tu me dis que c’est un merdier parce que le nombre de possibilités explose. Je te dis que c’est pas un problème, car tu peux avoir à un instant t sur un ordinateur c une solution simple et efficace. Tu me dis que c’est le merdier parce que les possibilités explosent. Je te dis que t’es pas obligé sur un ordinateur donné de reproduire ce merdier. Tu me dis… on risque pas d’avancer beaucoup.
                        — Tu me dis que le son sous Linux n’a aucun avantage, je te donne moi et un commentaire au-dessus quelques exemples d’utilisation et nous te demandons quel est l’état des autres systèmes ? Répondent-ils à tous les usages exposés ? On attend la réponse.
                        — Bon voilà t-il pas que tu dis mes arguments débiles. C’est plus facile que de contre-argumenter, c’est vrai qu’un pilote marqué comme DEPRECATED par les développeurs du noyau est un argument débile… heu… d’accord… et sinon ? En quoi est-il débile ? N’hésite surtout pas à argumenter… Perso. je fais assez confiance aux dév. du noyau pour dire que quand ils marquent DEPRECATED, c’est qu’il ne faut plus utiliser le pilote en question.
                        — Tu me demandes surtout de faire confiance à un mec qui a développé un plugin multimedia que prend 100 % du cpu sous Linux quelle que soit la situation. Alors oui, je crois que j’ai le droit de remettre en doute ses compétences sous Linux, et il fait moins autorité en matière de pilote son sous Linux que les dév. noyau. Mais je sais c’est débile de considérer les dév. noyau comme plus fiables en la matière qu’un dev. adobe.
                        — Tu ne peux pas empêcher un utilisateur ou un développeur de Linux monter sa propre solution, unique. C’est le point, et tout le fonctionnement intrinsèque du libre. Ton problème, et le problème du mec, c’est que vous découvrez Linux, vous vous rendez compte que c’est le bazar, et vous critiquez Linux pour ça. Vous vous ridiculisez en montrant ainsi votre méconnaissance de l’écosystème libre, à croire qu’il est possible d’imposer une solution unique pour tout le monde ; c’est juste impossible, c’est la conséquence de la liberté de modifier un programme.
                        — J’ai pas dit que c’était le système parfait. Jamais. C’est toi qui délire mon vieux avec ta notion de système parfait ; je t’ai déjà dit qu’elle n’avait pas de sens car tu ne peux avoir une solution unique à des problèmes différents. Ça a des inconvénients, mais les avantages sont non négociables.
                        — La différence fondamentale avec les mails, c’est que le problème est bien plus complexe que de transporter du texte. Qu’il n’y a pas de normalisation. Que personne n’en a fait et que tu te contentes de dire, y’a qu’à faire. Ben fais le si c’est aussi simple. Le truc c’est qu’il faudra que ton interface contente absolument tous les usagers, il faut juste, au moins, démontrer que c’est faisable. Je te dis que la manière d’y parvenir est précisément de tester plein de solution : en remettant en cause ce principe c’est un pan entier du libre que tu remets en cause, et j’ai déjà dit… c’est pas négociable.
                        — Les wrappers représentent un boulot supplémentaire pour les dév. et des problèmes pour les utilisateurs. Oui. Je suis d’accord. Si le dév. d’adobe ne veut pas faire se boulot il n’a qu’à utiliser une lib. multimédia qui l’aura fait… et qu’ils se rassurent : leur consommation CPU n’ira pas à plus de 100 %.

                        PS : utiliser le mot bazar a la place de merdier n’est pas innocent… et sûrement pas du novlangue, je sais pas si t’as bien pigé le truc…

                        PPS: sais-tu qu’en deux-trois mouvement, et pas moins de 2 minutes on peux être non-POSIX ? Qu’on casse ainsi potentiellement le serveur de mail. Et il y a sûrement des milliers de façons différentes de le faire… Ce qui fait la norme c’est aussi les utilisateurs qui décident de la suivre… Il ne suffit pas de la décreter.
                        • [^] # Re: Cela dépend des cas…

                          Posté par  . Évalué à 2.

                          simpe et efficace ... et buggée. Le son merdoie encore sur ma machine avec quelques applis, pour des raisons que je maitrise pas du tout, que ce soit le driver alsa qui soie buggé, je ne sais quel frameworks de plus haut niveau ou n'importe quelle autre raison. gstreamer a du mal, minecraft (appli java utilisant openAL) aussi, par exemple.
                        • [^] # Re: Cela dépend des cas…

                          Posté par  . Évalué à -4.

                          C'effectivement une discussion de sourd, je te dit que la stack sonore est un enfer pour les developpeurs d'appli ou de framework, tu me repond que c'est pas vrai parce que t'arrives a jouer des mp3 et donc ca marche.

                          Insulter le mec d'adobe, soit. Toujours est il que le mec a ecrit plus de code multimedia que tu n'en ecriras jamais dans ta vie, et qu'entre un branleur qui sait visiblement pas de quoi il parle et lui, c'est lui que les gens serieux vont ecouter.
                          La forte conso du cpu de flash, elle est la pour des raisons precises, je t'invite a rechercher. C'est clairement pas un probleme de competence des auteurs, la vm s'en sort tres bien sur nombre de points. Le blog cite plus haut explique d'ailleurs le pourquoi du comment.

                          Pour ta partie sur le deprecated, la principale raison pour laquelle c'est deprecated et pas juste retire, c'est parce que des applis l'utilisent encore. Cf le schema plus haut que tu refuse de regarder.
                          On a un bel exemple dans ce fil ou en trois message, on se rend compte qu'il faut supporter mini pulse, alsa, oss et ffdao.

                          Ma meconnaissance de l'eco systeme libre t'emmerde, pti con. Tu n'es pas le seul a avoir des annees de bouteilles dans le libre, l'eco systeme je l'ai bien compris et c'est pour ca que je n'utilise plus linux en desktop.
                          T'as beau dire autant que tu veux que le bazar c'est bien, la stack sonore c'est pas le bazar, c'est juste le merdier.

                          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                          • [^] # Re: Cela dépend des cas…

                            Posté par  . Évalué à 3.

                            moi je dirais plus que le dev de chez adobe est une grosse feignasse qui n'a pas envie de se casser le cul à développer autre chose puisque ça juste marche chez la grande majorité des linuxiens, et le fait de flash ouvrait le /dev/dsp en exclusif n'emmerdait que la minorité qui aurait voulu bénéficier d'autre applis faisant de son.

                            Si alsa n'avait pas fourni un /dev/dsp pour assurer la compatibilité ascendante, le dev d'adobe aurait trouvé rapidement le temps de gérer alsa.

                            Le coup du schéma compliqué pour ne rien avoir à faire, je connais; mais là on ne lui demandait pas de faire un truc intégré à toute les libs, juste une attaque d'alsa; pas pulse, arts, esd ou jack, juste asla ou utiliser une seule des multiple bibliothèque audio (SDLSound, OpenAl... ) qui auraient géré le reste à sa place.

                            Jamais on a réclamé qu'il gère l'intégralité des serveurs de son.

                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                            • [^] # Re: Cela dépend des cas…

                              Posté par  . Évalué à 3.

                              Jamais on a réclamé qu'il gère l'intégralité des serveurs de son.

                              Non, toi tu veux juste Alsa. Mais d'autres veulent jack, ou bien oss (ils aiment pas alsa ou pulse), pulse, etc. Et bien sur, ils veulent que ca soit gerer et integre dans leur systeme et le font savoir de facon sonore.

                              Et c'est sans parler de V4L2 (et 1 a l'epoque) et de tous les trolls qui spammaient les commentaires a chaque fois pour reclamer une version 64bits.

                              Le dev flash il a surtout le cuir bien epais pour resister aux emmerdeurs en tout genre qui reclament tout et son contraire (un petit tour dans les commentaires du blog devrait te convaincre rapidement).
                              • [^] # Re: Cela dépend des cas…

                                Posté par  . Évalué à 2.

                                et il aurait utilisé un truc du style openAl ou SDL (un machin plutôt stable dans ce bordel ambiant), il aurait eu qu'un seul dev à faire et tout (ou presque) de géré.

                                Sortir un graph pour dire que c'est le bordel et qu'il veux pas s'y coller, c'est son droit, mais je trouve que c'est une excuse de feignasse, sans être péjoratif hein, je suis moi même une grosse feignasse qui aime trouver des excuses pour en faire le moins possible sur des boulots qui ne m'intéressent pas, ce qui ne m'empêche pas de coder des trucs qui m'intéressent le Week end.

                                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                • [^] # Re: Cela dépend des cas…

                                  Posté par  . Évalué à 2.

                                  Mon petit doigt me dit que quand on est lead dev d'un truc aussi visible que flash dans une boite aussi grosse qu'adobe, son boulot, on le trouve interessant.
                                  Tout le monde n'a pas la mentalite d'un ssdeuxien.

                                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                • [^] # Re: Cela dépend des cas…

                                  Posté par  . Évalué à 3.

                                  et il aurait utilisé un truc du style openAl ou SDL (un machin plutôt stable dans ce bordel ambiant), il aurait eu qu'un seul dev à faire et tout (ou presque) de géré.

                                  Le problème n'est pas de jouer du son, ca heureusement tout le monde peut le faire, mais de jouer du son de façon controllée :

                                  Jouer du son en même temps qu'une autre application
                                  Jouer du son venant de plusieurs sources, éventuellement à des fréquences différentes
                                  Synchroniser du son et de l'image en direct
                                  Synchroniser du son et de l'image alors qu'il faut gérer un buffer/un entrelacement/un multiformat
                                  Donner la priorité à un son sur un autre entre deux applis différentes
                                  etc.

                                  SDL/OpenAL et consors ne savent pas faire ce genre de choses. C'est pourtant relativement demandé (Les gens aiment bien avoir le son et l'image synchronisé par exemple)

                                  De façon générale les gens qui se plaignent de l'API son sous Linux sont des gens qui ont besoin d'un peu plus que d'un frontend pour "mad toto.mp3 - > /dev/dsp".

                                  Le mec de chez Adobe il se plaint juste de devoir étudier 8 000 000 de possibilité différentes d'API et d'applis qui peuvent lui couper la priorité alors qu'il est en train d'essayer d'avoir une image qui colle avec le son.
                                  • [^] # Re: Cela dépend des cas…

                                    Posté par  . Évalué à 2.

                                    > SDL/OpenAL et consors ne savent pas faire ce genre de choses. C'est pourtant relativement demandé (Les gens aiment bien avoir le son et l'image synchronisé par exemple)

                                    Vu que la lib SDL est un appli assez bas niveau pour faire du son (basiquement on donne un wav à lire, et on fait le ping-pong avec 2 buffer audio, l'un se rempli, l'autre se lit) ce que tu fais est assez libre en fait. Tout ce que tu décris se fait en SDL, et oui tu peux avoir du multiformat et du mixage soft avec SDL.

                                    Pour OpenAl, je pourrai pas donner plus de précision, mais vu comment râlent les joueurs lorsque les sons ne sont pas synchronisés je serai surpris que ça ne le permettes pas

                                    > Le mec de chez Adobe il se plaint juste de devoir étudier 8 000 000 de possibilité différentes d'API et d'applis qui peuvent lui couper la priorité alors qu'il est en train d'essayer d'avoir une image qui colle avec le son.
                                    Je sais pas moi le premier truc que je ferai avant de tenter de coller l'image au son, c'est réduire la consommation démesuré de CPU; généralement la synchro pose moins de problème après :)

                                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                    • [^] # Re: Cela dépend des cas…

                                      Posté par  . Évalué à 3.

                                      Vu que la lib SDL est un appli assez bas niveau pour faire du son (basiquement on donne un wav à lire, et on fait le ping-pong avec 2 buffer audio, l'un se rempli, l'autre se lit)

                                      Oui, c'est du très haut niveau çà en appli son.
                                      Le haut niveau en fichier son c'est echo "fichier.wav" > /dev/macarte.

                                      Pour te donner une idée voilà comment fonctionne la SDL avec le support Alsa dans Linux quand elle est en mode exclusif (ie aucune autre appli ne joue de sons) sur une carte en prise direct (ie pas de surcouche d'émulation dans alsa driver):
                                      Appli -> SDL -> Alsalib -> Alsa -> Alsa driver

                                      En vrai ca donne souvent çà :
                                      Appli -> SDL -> Alsalib -> Alsa -> Alsa driver HDA PCM interface -> Alsa driver

                                      Être bas niveau ca revient à discuter directement avec le matériel, voire à discuter avec les HControl/PCM/AC97 et autre interface à la con du driver Alsa (à la con parcequ'instables et non/mal documentés)

                                      Tout ce que tu décris se fait en SDL
                                      La SDL va permettre de mixer du son avec un autre appli qui parle avec GStreamer ? La SDL va empêcher pulseaudio de chopper une carte son ne mode exclusif ? La SDL va permettre à mon appli de partager un device avec trois autres applis qui ont des fréquences de rendu différentes ?

                                      La SDL est une bibliothèque destiné au userland, pas un module noyau. Tout ce que peut faire la SDL c'est de cracher du son dans une interface. Après que ce son soit super bien foutu, soit le résultat du mixage de son de pleins de sons etc. on s'en fout. SDL c'est une instance par appli et par user.


                                      Pour OpenAl, je pourrai pas donner plus de précision, mais vu comment râlent les joueurs lorsque les sons ne sont pas synchronisés je serai surpris que ça ne le permettes pas

                                      Bine sur que dans la bibliothèque OpenAL il y a des fonctions qui permettent de synchroniser le son et l'image au sein de l'appli. Mais une fois d eplus on est mono appli, mono user. Y-a-t-il dans OpenAL une fonction qui permette de dialoguer avec le scheduler pour s'assurer que les sons seront effectivement synchronisés lors du rendu : non. OpenAL est userland aussi, il crache du son dans un device et c'est tout.

                                      Je sais pas moi le premier truc que je ferai avant de tenter de coller l'image au son, c'est réduire la consommation démesuré de CPU; généralement la synchro pose moins de problème après :)

                                      Perdu faut faire le contraire, il faut consommer un maximum de CPU, charger la mule le plus possible pour s'assurer que
                                      a) les buffers sont pleins le plus longtemps possible
                                      b) le scheduler se rende compte que tu es très consommateur de ressources et te passe dans un mode ou il t'alloue de grande tranche de temps de loin en loin plutôt que pleins de petites tranches de son. C'est ce qui garanti la cohésion image/son (entre autres).
                                      De toute façon quand tes buffers sont pleins, tu rend la main - ta consommation de CPU au final reste la même.
                                      • [^] # Re: Cela dépend des cas…

                                        Posté par  . Évalué à 2.

                                        > Perdu faut faire le contraire, il faut consommer un maximum de CPU, charger la mule le plus possible pour s'assurer que
                                        C'est marrant les player mplayer,vlc, xine, totem, aviplay ne consomme pas 100% de CPU. Y a 10 ans effectivement wmp6 consommait 100% sous win; la vidéo était saccadé et la synchro sur certaines devait régulièrement être refaite via un coup de déplacement dans la bare de défilement. À la même époque, aviplay consommait quasiment rien en CPU et l'image restait synchronisé (même machine dual boot).

                                        >De toute façon quand tes buffers sont pleins, tu rend la main - ta consommation de CPU au final reste la même.
                                        C'est pour ça que quelque soit la puissance du CPU flash est toujours à 100%?

                                        >La SDL va empêcher pulseaudio de chopper une carte son ne mode exclusif
                                        Elle va surtout faire du son, ce qui est mieux que pas de son du tout, ou juste le son de flash.

                                        S'il tient absolument à avoir une sychro temps réel alors il se coltine jack plutôt que SDL, mais j'ai jamais entendu quelqu'un qui voulait avoir une synchro supérieur à ce que font tous les player vidéos.

                                        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                        • [^] # Re: Cela dépend des cas…

                                          Posté par  . Évalué à 1.

                                          C'est marrant les player mplayer,vlc, xine, totem, aviplay ne consomme pas 100% de CPU

                                          Tu confonds deux choses
                                          a) Être bourrin ou gentil lors de l'execution de ton appli (combien de locks tu mets, combien d'interrupts tu goinfres, si tu es compatible avec te petits camarades, combien d'allocation tu fais etc.)
                                          b) Être consomateur de ressources disponibles.

                                          En multimédia si tu veux limiter b) tu as intéret à forcer a le plus possible.

                                          De plus généralement les gens ne regardent pas plusieurs vidéos en même temps. Fais le test un jour de lancer deux vidéos simultanément. La première devrait être fluide et le rester, la seconde va être à l'agonie.

                                          C'est pour ça que quelque soit la puissance du CPU flash est toujours à 100%?
                                          Non ca c'est juste que Flash est mal compilé sur ta machine, chez moi flash prend 20% de CPU sur un E3500 avec une CG nvidia 8700 (pilotes proprios) lors de la lecture d'une video HD 1080p. Tu a sun problème avec ton mode de rendu, c'est tout.

                                          Elle va surtout faire du son, ce qui est mieux que pas de son du tout, ou juste le son de flash.
                                          Non, la SDL ne fait pas de son, elle envoit un flux vers un device. Si c'est un device audio ALSA, le pilote Alsa le transformera en son, si c'est un fichier tu auras un fichier wav à la fin.

                                          S'il tient absolument à avoir une sychro temps réel alors il se coltine jack plutôt que SDL
                                          Jack ne fais pas de son non plus, il sert juste à mettre à la queue leu leu des devices. Si un des devices de la chaine est un device son Alsa, Alsa fera du bruit. Sinon cf plus haut.

                                          mais j'ai jamais entendu quelqu'un qui voulait avoir une synchro supérieur à ce que font tous les player vidéos.
                                          En video tu as généralement deux secondes de buffer (parfois plus). C'est une des choses les plus simple à synchroniser (même si c'est déjà bien lourd merci les bit rates variables). Si tu as un problème de décodage/remplissage de buffer/défaut de ressouce tu as deux secondes pour y remedier et recommencer à remplir le buffer. C'est très très confortable.
                                          Dans un jeu tu as généralement un vingtième de seconde pour comprendre un évènement, charger le rendu graphique, charger le rendu son, les synchroniser et les jouer.

                                          Certes le rendu son dans les vidéos est souvent très bien synchronisé à l'image, mais c'est le cas "simple". faire la même chose en interactif ca peut être une vraie tannée.
                                          • [^] # Re: Cela dépend des cas…

                                            Posté par  . Évalué à 2.

                                            > De plus généralement les gens ne regardent pas plusieurs vidéos en même temps. Fais le test un jour de lancer deux vidéos simultanément. La première devrait être fluide et le rester, la seconde va être à l'agonie.
                                            Il y a quelques années (à l'époque où aviplay était encore maintenu) j'en envoyais jusqu'à cinq ou six à l'écran (un iiyama 22" cathodique) avant que ça ne saccade (sur un monocoeur) , là je recommence avec une dizaine sans soucis non plus (vlc, affichage composite désactivé, faut pas déconner non plus, j'ai pas la place d'en mettre plus), j'ai pas une carte graphique de la mort qui tue; par contre 10 vidéo simultanée sous flash ça ramouille un poil pour être gentils

                                            > Non ca c'est juste que Flash est mal compilé sur ta machine, chez moi flash prend 20% de CPU
                                            C'est une évolution récente de flash, tout comme le fait que flash utilise désormais alsa pour le son (en tout cas chez moi c'est le cas)

                                            >Dans un jeu tu as généralement un vingtième de seconde pour comprendre un évènement, charger le rendu graphique, charger le rendu son, les synchroniser et les jouer.
                                            Et c'est marrant je peux regarder game one en même temps que fallout 3 / assassin creed sans faire ramer toute la machine (avec tout à fond), et y a quatre ans, je faisais de même avec un autre jeu, par contre si j'ouvrais une page avec flash à la place d'un vlc (sous windows hein) ça ramait à mort (depuis j'ai plus retesté).

                                            Je note quand même qu'il consomme encore entre 25% et 50% d'un coeur de mon phenom X4 pour une vidéo qui ne fait pas décoller 3% sous mplayer

                                            > Jack ne fais pas de son non plus, il sert juste à mettre à la queue leu leu des devices.
                                            jack c'est un poil plus que juste un truc qui sert à mettre à la queue leu leu les devices JACK is system for handling real-time, low latency audio (and MIDI). It runs on GNU/Linux, Solaris, FreeBSD, OS X and Windows (and can be ported to other POSIX-conformant platforms)

                                            Enfin la question n'est pas de pinailler sur quoi fait du son, mais que faire pour que du son sorte; ensuite on peut ajouter des détails comme a t'on besoin de consommer plus de ressource que crysis pour avoir une synchro son, mais premièrement flash à déjà évolué (consommation de ressource moindre, donc il ne consomme que comme assassin creed, et deuxièmement il s'est mis à alsa)

                                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                            • [^] # Re: Cela dépend des cas…

                                              Posté par  . Évalué à 1.

                                              par contre 10 vidéo simultanée sous flash ça ramouille un poil pour être gentils

                                              Ouvre 10 videos ogg dans une balise video sous Firefox et compare avec la meme chose en Flash. Ensuite demande toi pourquoi il y a pas beaucoup de difference en terme de conso CPU[1].

                                              Comparer les perfs de Flash dans le navigateur avec un player video separe, c'est completement debile.

                                              [1] sauf si t'es sur un systeme supporte pour l'acceleration hardware Flash, la version avec la balise video risque d'etre un peu a la ramasse...
                            • [^] # Re: Cela dépend des cas…

                              Posté par  . Évalué à 4.

                              Ah, et j'allais oublier: 10mins de recherche Google t'aurais permis de connaitre l'identite du dev flash linux d'Adobe.

                              Sachant que tu utilises surement son code libre dans ta distrib pour lire des videos en tout genre et que le code en question est plutot du genre difficile a ecrire (tout le monde ne fait pas de reverse-engineering de codec videos pour s'amuser le weekend), le traiter de grosse feignasse est tres rigolo...
                    • [^] # Re: Cela dépend des cas…

                      Posté par  . Évalué à 10.

                      t. T’as autant de systèmes parfaits que d’utilisateurs… J’apprécie que Linux me permette de réellement adapter le système pour qu’il soit parfait pour moi.

                      Pour qu'un système soit parfait il faut un minimum de "trucs"
                      En ce qui concerne le son sous Linux, tu vas te marrer :

                      On va diviser les utilisateurs en plusieurs grosses catégories :
                      - L'utilisateur pur, 0 technique, il prend une distrib l'installe et basta
                      - L'utilisateur avancé
                      - Le Pro du son
                      - Le dev

                      L'utilisateur pur va installer sa distrib, et là soit ca marche "out of the box", soit il essaye la distrib d'à coté. Au bout de trois distribs essayés il repasse sous windows. Ce mec ne cherche pas la distrib parfaite, il veut que "ca juste marche" quand il installe un truc. Et des fois ca juste marche (sur des PC relativement standards on va dire que ca fait 80% des cas de nos jours, ce qui est une belle performance). Cependant il va avoir tout un tas de petits soucis pour le faire chier : Des blancs entre les morceaux de sa musique (GStreamer est le prédateur naturel du gapless), un volume erratique (Ben oui le son il se règle dans Alsa, dans pulse audio, dans l'émulation OSS, dans GStreamer et parfois dans les applis ... super) Et puis parfois quand il va mettre à jour sa distrib, son plugin flash(proprio ou pas) va déconner grave au niveau du son jusqu'à la prochaine mise à jour. Si ca lui casse trop les pieds, il change.

                      L'utilisateur avancé il veut un comportement précis. Par exemple il veut du gapless (pas de blancs entre deux morceaux) parcequ'il écoute du classique/des concerts/des albums correctement assemblés. Lui déjà il souffre. Premièrement il doit foutre dehors GStreamer et s'arranger pour qu'il ne revienne pas à la charge quand il va mettre à jour sa distrib (ce qui demande déjà un bon niveau), ensuite il doit trouver des packages/repository compatibles avec sa distrib dans lesquels la dépendance à GStreamer a été enlevée. Sinon il doit tout compiler à la main, et tout recompiler à chaque mise à jour du kernel (en priant pour que ca marche encore - voire plus loin pour le dev).
                      Si il veut harmoniser les volumes, pour avoir un seul point à régler pour toutes les applis il va souffrir encore. Castrer Pulse Audio pour ne pas qu'il se mêle de régler le volume est pas évident du tout.Là aussi à chaque mise à jour du kernel ou presque il est bon pour revisiter ses réglages (d'une mise à jour sur l'autre, les éléments "secondaires" de la carte son, comme les sorties 5.1, les commuts micro/sortie, les entrées mic etc. changent de volume de base, voire de nom, voire de fonction - spécial dédicace au possesseurs de chipset son i810)

                      L'utilisateur pro, il devient juste fou. De façon générale il a besoin de jack en mode temps réel, lequel est particulièrement incompatible avec pulse audio. Pulse audio c'est un serveur en user space qui dialogue plusieurs centaine de fois par seconde avec le kernel space. C'est la fête du context switch. Même sur une très grosse machine si vous avez plusieurs logiciels, certains directement sous Jack et d'autres via pulse audio vous allez vous prendre du clock skew dans la gueule. Et genre pas qu'un peu. Un conseil éviter les mix 32khz/44,1khz/48khz ca n'arrange pas le problème, bien au contraire.
                      Après il va devoir lui aussi se taper la tête contre les murs avec les réglages de volume et les mises à jour. Si il a vraiment du temps à perdre il va essayer de gicler complètement pulse audio et GStreamer de sa distrib (de toute façon c'est un pro, sa/ses cartes audio font surement du mixage hard). Mais bon GStreamer est utilisé par un grand nombre d'applis son sous Linux (normalement ce ne sont pas celles qui l'interressent, mais bon) et gicler pulse-audio est devenu une tannée sur les distribs classiques. Reste la solution LFS, mais là il faut compiler ffado, ffmepg et jack dans des versions compatibles les unes avec les autres... Bonne chance gars.

                      Le dev, neuf fois sur dix, il a déjà laissé tombé. Il s'est arraché les cheveux sur l'absence de doc d'Alsa 0.8, il a failli se tirer une balle sur Alsa 0.9. Il a fait trois mois de dépression lors du passage en V4L2, a été interné pour la sortie d'Alsa 1.0 et ses magnifiques cartes virtuelles pour le mixage. On est en Alsa 1.0.22, les cartes virtuelles ne servent plus, 80% du code qu'il a pu écrire est inutilisable, il n'y a toujours pas de doc, les pilotes HDA sont à pleurer (on a encore changé les volumes par défaut et les noms de la moitié des entrées, mute permet dans certains cas de passer du mode capture au mode sortie). Il a pris sont parti, il écrit pour du high level. Gstreamer principalement, parceque phonon est pas complètement sec et qu'il a failli se pendre quand on a annoncé la mort d'Arts (encore du code qui part à la poubelle). Il sait que son appli traverse X couches d'émulation pour jouer le plus simple des sons. Il a décidé de s'en foutre, mais il lui a fallu deux ans de thérapie pour en arriver là.

                      Maxime attend de la concurrence de faire du temps réel. Elle le fait la concurrence ?

                      Oui définitvement. La plupart des plateformes de montages sont à la concurrence. Et ca marche. Par contre sous Linux il faut sérieusement s'accrocher. CF plus haut.

                      Ah! puis moi j’aime bien mon mpd, la concurrence a un lecteur de musique (juste un lecteur de musique) avec un protocole documenté pour pouvoir coder un petit client tout bien comme je veux (fade in/out+aléatoire pas trop con+console+arrêt uniquement à la fin du morceau)

                      MPD marche très bien en tant que serveur. Ceci étant il ne passe pas par GStreamer et il fonctionne encore mieux sans Pulse audio. Le serveur MPD est l'exmple typique du truc qui fait se demander à quoi servent toutes les couches là haut si ce n'est à faire moins bien pour plus d'overhead.
                      Les clients MPD java/windows fonctionnent très bien pour tout ce qui est fade-in/fade-out, aléatoire pas trop con etc.

                      et puis qui me fasse de la reconversion à la volée de flac vers ogg pour du streaming sur http ou n’importe quoi d’autre via ADSL. Toujours là la concurrence ?

                      Oui, oui FFMPeg et consors existent aussi chez la concurrence. Ils fonctionnent aussi très bien.

                      Et c’est juste faux :
                      make menuconfig
                      devices …
                      sound …
                      — ALSA
                      — OSS (DEPRECATED) (depuis pfiou… 4 ans? au moins)


                      Alsa, alsa driver, oss emulation, oss direct, V4L (deprecated aussi), V4L2
                      Sans compter les réglage à la con de type HPET ou Firewire on a 6 API dans le kernel qui fon mumuse avec le son. Tout va bien.
                      Et OSS est deprecated depuis près de 7 ans. Mais toujours dans le kernel (parceque bon, c'est quand même le truc qui marche partout et à chaque fois)

                      Et j’ai un scoop pour toi : si pulse expose l’API alsa aux applis ne parlant qu’alsa, ben ça veux pas dire que ton son est géré deux fois

                      En l'occurence si. Pulse se présente comme un pseudo device alsa, alors qu'il est en user land. Donc double contexte switch (user vers user puis user vers kernel) pour jouer le moindre son. Rajoute Une émulation OSS et gstreamer par dessus et c'est la fête du slip dans tes interrupts.
                      Bien sur le dev qui a fait son programme a pas à reprendre le code (encore que pulse-audio de part son caractère user land supporte assez mal les gruikeries Alsa et qu'un crash est vite arrivé). Mais si tu veux une synchro son/image tu te marres bien.

                      Et c’est ce que j’ai sur mon ordi. Enfin, j’ai PulseAudio suivant l’humeur du moment.

                      Je te parie que sur ton PC tu as pulseaudio, Alsa, Alsa drivers, l'émulation OSS, une voire deux émulation ESD, Gstreamer et peut-être même Phonon ou Arts. Moins certain mais probable : un alsa driver HDA et un autre en virtual midi.
                      Il y a peut être trois applis (dont le plugin flash Adobe d'ailleurs) capable de parler directement au HControl Alsa driver pour faire du mixage hard sans passer par les surcouches de surcouche de surcouche.

                      Pour info voici le lien vers la doc du HControl interface d'Alsa driver
                      http://www.alsa-project.org/alsa-doc/alsa-lib/hcontrol.html

                      Si tu préfères passer par l'API Alsa abstraite, voici un lien vers la doc pour utiliser le mixer audio virtuel :
                      http://www.alsa-project.org/alsa-doc/alsa-lib/mixer.html

                      Ben 8 ans que je suis exclusivement sous Linux, 8 ans que j’ai du son
                      Oui, tu as du son. Exactement de la même façon que les utilisateurs windows ont un navigateur internet Microsoft depuis 15 ans. Si ça te suffit tant mieux, mais ca rend pas le truc moins absurde ou plus utilisable.
                      • [^] # Re: Cela dépend des cas…

                        Posté par  . Évalué à 2.

                        Pour info voici le lien vers la doc du HControl interface d'Alsa driver
                        http://www.alsa-project.org/alsa-doc/alsa-lib/hcontrol.html

                        Si tu préfères passer par l'API Alsa abstraite, voici un lien vers la doc pour utiliser le mixer audio virtuel :
                        http://www.alsa-project.org/alsa-doc/alsa-lib/mixer.html


                        Ben quoi, c'est bien precise dans la licence, non? :P

                        This documentation is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
                      • [^] # Re: Cela dépend des cas…

                        Posté par  . Évalué à 0.

                        Premièrement il doit foutre dehors GStreamer et s'arranger pour qu'il ne revienne pas à la charge quand il va mettre à jour sa distrib (ce qui demande déjà un bon niveau), ensuite il doit trouver des packages/repository compatibles avec sa distrib dans lesquels la dépendance à GStreamer a été enlevée.
                        Un certain nombre de logiciels ne dépendent déjà pas de gstreamer. Par exemple cmus peut utiliser directement ALSA/OSS, et Kaffeine/VLC n'ont pas de dépendance en gstreamer dans Debian Lenny (je viens de faire un ldd).

                        Sinon il doit tout compiler à la main, et tout recompiler à chaque mise à jour du kernel (en priant pour que ca marche encore - voire plus loin pour le dev).
                        D'où l'intérêt d'utiliser Slackware où le noyau est très rarement mis à jour.

                        Si il veut harmoniser les volumes, pour avoir un seul point à régler pour toutes les applis il va souffrir encore. Castrer Pulse Audio pour ne pas qu'il se mêle de régler le volume est pas évident du tout.
                        D'où l'intérêt de Slackware car il n'inclut pas cette bouse de PulseAudio. De toute façon sous les autres distribution c'est facile aussi, yum remove pulseaudio; killall pulseaudio suffit pour Fedora (en tout cas la version KDE). D'ailleurs c'est ma première opération administrative que je fais après mes installations de Fedora.

                        Là aussi à chaque mise à jour du kernel ou presque il est bon pour revisiter ses réglages (d'une mise à jour sur l'autre, les éléments "secondaires" de la carte son, comme les sorties 5.1, les commuts micro/sortie, les entrées mic etc. changent de volume de base, voire de nom, voire de fonction - spécial dédicace au possesseurs de chipset son i810)
                        D'où l'intérêt de Slackware pour laquelle un SlackBuild de OSS4 qui est stable, a un DKMS qui permet de le laisser inchangé en fonctionnalité à chaque mise à jour du noyau et permet de faire un réglage de volume propre à chaque application.

                        Donc au final Slackware roulaize, et au passage Arch Linux aussi permet de ne pas installer PulseAudio et d'installer OSS4 (il y a même un paquet oss). Et de plus dans ces distributions si tu veux recompiler un logiciel pour virer la dépendance en GStreamer, tu bénéficie de ne pas avoir à installer de -dev et d'avoir des scripts de compilation lisibles (pas des usine à gaz comme pour les deb et rpm).
      • [^] # Re: Cela dépend des cas…

        Posté par  . Évalué à 10.

        Tu confonds beaucoup de chose quand même là.

        POSIX définit une API à un niveau "plus bas" que consolekit, polycitkit et compagnie. En ce qui concerne ALSA et PulseAudio il n'y a rien qui concerne le son dans POSIX qui est plutôt orienté sur les API comme la création de threads, la synchronisation, les entrée/sortie etc...

        (Je pars du principe que tu parles de la partie en espace utilisateur d'Alsa)
      • [^] # Re: Cela dépend des cas…

        Posté par  . Évalué à 4.

        C'est peut-être plus simple, mais est-ce que tu peux faire du son en réseau en restant purement POSIX ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Cela dépend des cas…

          Posté par  . Évalué à 1.

          Est ce que tu peut faire des jeux vidéo avec HTML pur ?
          Les normes ça sert à rien faut utiliser les spécificités du navigateur du développeur !

          Oups ! Trompé de journal ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Cela dépend des cas…

            Posté par  (Mastodon) . Évalué à 7.

            Est ce que tu peut faire des jeux vidéo avec HTML pur ?

            HTML pur, je ne sais pas, mais HTML+CSS, oui, tu peux : en reprenant la structure des "Livres dont vous êtes le héros", il y a moyen de faire quelque chose, je pense.
            • [^] # Re: Cela dépend des cas…

              Posté par  . Évalué à 2.

              Si c'est pour faire ce genre de jeux, tu peux très bien le faire en HTML (même en HTML4 ou XHTML1.0), ce qui permet d'être compatible avec 100% des navigateurs (y compris ceux en console).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Cela dépend des cas…

            Posté par  . Évalué à 3.

            • [^] # Re: Cela dépend des cas…

              Posté par  . Évalué à 2.

              Merci pour le lien mais le standard a du évoluer pendant des années c'est ce genre de réflexion qui a permis l'émergence de flash et ça a continue a être le cas. Parce que de la même manière avec HTMl 5 je perds la compatibilité avec pleins de navigateurs (pour le moment en tout cas).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Cela dépend des cas…

        Posté par  . Évalué à 6.

        PulseAudio is a sound system for POSIX OSes, meaning that it is a proxy for your sound applications. It allows you to do advanced operations on your sound data as it passes between your application and your hardware. Things like transferring the audio to a different machine, changing the sample format or channel count and mixing several sounds into one are easily achieved using a sound server.

        PulseAudio is designed for Linux systems. It has also been ported to and tested on Solaris, FreeBSD, NetBSD, MacOS X, Windows 2000 and Windows XP.

        http://www.pulseaudio.org/
        • [^] # Re: Cela dépend des cas…

          Posté par  . Évalué à 4.

          D'ailleurs...

          "Dependencies :

          * Linux / Solaris 11+ / FreeBSD"

          http://www.freedesktop.org/wiki/Software/ConsoleKit

          Et apparemment, c'est dans les ports :
          http://www.freshports.org/sysutils/consolekit/

          Après, que ça ait été architecturé pour Linux puis porté sur FreeBSD, j'en sais rien, mais en tout cas, c'est disponible pour ce dernier.
          • [^] # Re: Cela dépend des cas…

            Posté par  (site web personnel) . Évalué à 3.


            Après, que ça ait été architecturé pour Linux puis porté sur FreeBSD, j'en sais rien, mais en tout cas, c'est disponible pour ce dernier.


            HAL aussi est présent sous FreeBSD. On a mis 5 ans à avoir un truc qui marchouille à peu près. Et voilà-t-y pas que sous Linux ils se rendent compte que c'est de la merde et virent carrément la couche d'abstraction.

            Bon...

            les pixels au peuple !

            • [^] # Re: Cela dépend des cas…

              Posté par  . Évalué à 7.

              Disons qu'à l'époque où HAL est sorti, il n'y avait rien d'autre, alors on était bien content d'avoir un truc qui marche.

              Maintenant qu'on est arrivé à ses limites, il a fallu le remplacer, c'est normal.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Cela dépend des cas…

              Posté par  . Évalué à 10.

              On a mis 5 ans à avoir un truc qui marchouille à peu près

              Ben j'ai pas idée que ca ait jamais marché sous Linux HAL.
              On a d'abord eu la grande blague du passage devfs vers udev qui était en train de presque ressembler à un truc vaguement utilisable quand il a été décidé de passer à HAL.
              Il y a une prise de pieds dans L'APIC quelquechose de violent, après DBus est arrivé et c'est là qu'on a commencé à vraiment se marrer. Parceque à partir de là chaque connexion/deconnexion de périph entrainnait une bataille de context switch quelquechose de lourd. Avec des résultats variables.Le moindre disque dur avait au moins 14 devices associé, par connexion physique, par connexion logique, par ID udev, par Numero de série, par ID "classique" à la linux etc. Au début automount devenait fou (le pauvre comment pouvait-il savoir que /dev/disk/13258AE, /dev/usb/disk/74548FF, /dev/sdd, /dev/id/3456-8903M684299 etc.) étaient un seul et même disque.

              La configuration de udev est devenue assez amusante à faire, entre les listes mises à jour, les blacklists kernel, les blacklist locales et les sous-sous-sous répertoires de config udev. Chaque distrib prenant un peu au hasard parmis les 92 possibilités pour choisir son espace de nommage de référence.

              Mais bon maintenant on a enfin tué HAL dans Debian et tout va mieux. Par exemple j'ai un graveur USB Samsung. La première fois que je le branche il est monté en tant que /dev/sdd, si je le débranche et que je le rebranche il ne se monte plus, si je recommence (3eme essai) il se monte en /dev/sr1. C'est très ludique...
              • [^] # Re: Cela dépend des cas…

                Posté par  . Évalué à 1.

                Ouf, je me sens moins seul d'un coup. J'ai hésité à troller donner mon avis sur le sujet : je suis déjà catalogué comme anti-python anti-XML-dans-les-fichioers-de-conf, et comme raleur, j'avais peur d'en rajouter. Mais je suis vraiment content de lire des commentaires pareils. Ca prouve bien ce que je pense de Linux, des LL et et de leur développement depuis quelques années.
                • [^] # Re: Cela dépend des cas…

                  Posté par  (site web personnel) . Évalué à 6.

                  techniquement, ça prouve juste que tu as une autre personne qui partage ton opinion. C'est différent de prouver ce que tu penses.
                  • [^] # Re: Cela dépend des cas…

                    Posté par  . Évalué à 1.

                    Il ne s'agit pas d'opinion, pmais de témoignage. Ce n'est pas la même chose. Le message donne des faits, et ces faits ne font que confirmer ce que je pense.
              • [^] # Re: Cela dépend des cas…

                Posté par  . Évalué à 1.

                Tiens à ce sujet : j'aimerais bien avoir quelques chiffres sur l'aspect "détection automatique du matériel" dans le noyau Linux :
                - la quantité de code
                - le temps passé à développer/débugger/recommencer à développer
                - la quantité de bugs trouvés
                - le temps CPU utilisé en fonctionnement
                - le réel intéret d'une telle fonctionnalité.

                Parce que je reste convaincu que la détection et le nommage dynamique des périphérique est un réel problème, que ça apporte plus de problèmes que ça n'en résout, et qu'un bête bouton ou une bête commande pour détecter le matériel lorsqu'on le branche serait bien plus efficace.
    • [^] # Re: Cela dépend des cas…

      Posté par  (site web personnel) . Évalué à 10.

      Comme tu dis sous les système de type BSD un init systemV sous licence GPL ultra optimisé linux on s'en tape surtout quand je vois qu'une OpenBSD, NetBSD ou FreeBSD out of box boot en une poigné de seconde car eux aussi utilise des systèmes qui leur sont propres et qui leur sont optimisés.

      On peut prendre l'exemple inverse avec PF sur OpenBSD qui est devenu tellement optimisé OpenBSD que NetBSD préfère développer son propre firewall plutôt que de l'adapter (plus de 4000 patch a adapter).

      Ce qui me dérange le plus pour moi sur un soft comme Xfce c'est que c'est un ensemble de logiciel graphique agissant sur la couche haute du système. Donc si leur logiciel descend trop bas dans les appels système c'est sur que ce ne sera pas portable. D'ailleurs en quoi Xfce doit faire des appels kernel directement ?

      Bref le problème se trouve plutôt sur les couches intermédiaire qui font l'abstraction entre les couches hautes et le kernel qui devraient elles être portable comme il faut.

      Après qu'on ne vienne pas me dire que c'est impossible quand on voit que X.org y arrive parfaitement ou qu'on trouve des serveur postfix sur des freebsd qui n'ont vraiment pas à rougir niveau performance face à leur équivalent sous linux.

      De ma petite expérience en portage de code C j'ai surtout vu que les dev codent souvent sans se demander s'il existe un monde à côté de linux. En simplifiant/nettoyant le code d'un logiciel libre on avait gagné en perf, en simplicité de maintenance, moins de bug et le code devenait portable comme par magie.

      Sinon si Xfce n'arrive pas à faire du code portable faut qu'ils demandent comment KDE. Perso j'utilise Xfce depuis 5 ans et avant j'étais sous gnome. Je l'utilise sous linux, OpenBSD et NetBSD sans problème. Ce que je ne veux pas c'est voir les gens qui s'occupent des portages pleurer parce qu'une fonctionnalité est à réécrire complètement. De plus les portages une fois effectué donnent souvent un code compatible sur tout les unix pour un effort très faible de developpement.
      • [^] # Re: Cela dépend des cas…

        Posté par  . Évalué à 3.

        Tu n'a pas compris je crois. Xfce utilise des couches intermédiaires qui sont spécifiques à linux (notamment udev à la place de hal), c'est à cause de ça qu'ils perdent en portabilité.

        KDE utilise Qt en grande partie et fait énormément d'abstraction. C'est un gros projets ils en sont capable. Ils ont pleins de sous-systèmes qui utilise une sorte de patern proxy. Les appli utilisent une interface et derrière c'est le système spécifique qui est utiliser. C'est vraiment bien (si les performances sont au rendez-vous), mais c'est très consommateur en temps de développement (il faut que l'interface permette d'utiliser le plus grand sous ensemble commun de fonctionnalités).

        Ça reste tout de même un technique buldozer qui est censée être inutile grâce à POSIX.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Cela dépend des cas…

          Posté par  . Évalué à 2.

          "Xfce utilise des couches intermédiaires qui sont spécifiques à linux (notamment udev à la place de hal)"
          Il me semble que KDE envisage (est en cours ?) de faire la même chose...
          • [^] # Re: Cela dépend des cas…

            Posté par  . Évalué à 4.

            C'est même déjà fait, depuis KDE 4.5. D'ailleurs, KDE utilise aussi PolicyKit et PulseAudio.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Cela dépend des cas…

            Posté par  . Évalué à 7.

            Pas tout à fait puisque KDE a ses propres couches d'abstraction (Phonon, etc) dans le but de pouvoir rester portable justement..
            Donc oui, ils ont changé les couches d'abstractions pour utiliser udev à la place de HAL pour Linux, j'ignore ce qui a été fait pour la partie *BSD..
            • [^] # Re: Cela dépend des cas…

              Posté par  . Évalué à 2.

              "Thanks to Solid's new UPower, UDev and UDisks backends, the deprecated HAL is no longer needed to manage hardware on Linux. Applications do not need to be updated to make use of these new backends. The HAL backend is still available for systems that do not support UPower."
              (cité de http://www.kde.org/announcements/4.6/platform.php )
              Ils ont tout simplement gardé le support de HAL dans Solid.
      • [^] # Re: Cela dépend des cas…

        Posté par  (site web personnel) . Évalué à 4.

        postfix sur des freebsd qui n'ont vraiment pas à rougir niveau performance face à leur équivalent sous linux.

        Bah l'auteur utilise FreeBSD (je ne retrouve pas l'interview (2004))

        > - What distribution do you use? Why did you choose it?
        >
        > I have been using UNIX systems since 1985, and FreeBSD since
        > 1993. This is UNIX software that was ported to the PC environment
        > late in its life cycle. It is relatively mature compared to the
        > software that was written for PCs and that looks like UNIX.

        les pixels au peuple !

    • [^] # Re: Cela dépend des cas…

      Posté par  (site web personnel) . Évalué à 10.

      les développeurs ne vont pas si priver pour une poignée d'utilisateurs alors qu'ils pourront « changer la vie » de plusieurs fois d'autres personnes.

      Tiens, cette phrase marche aussi pour les développeurs Windows à qui on demande la portabilité Linux.
      Comme quoi, Windowsien ou Linuxien, finalement c'est une peu pareil : il y en a des deux côtés pour dire chacun pour sa pomme, tout ce qui compte c'est que ça marche sur mon OS et tant pis pour la minorité qui a l'idée d'avoir un autre OS...

      Je retiens le commentaire, surtout la partie "quelle est la proportion d'utilisation du Xfce parmi les différents OS l'utilisant ? " auquel je remplacerait Xfce par un logiciel fonctionnant bien sous Windows et pas bien sous Linux, vous devriez donc accepter de faire partie de la minorité à qui on ne s’intéresse pas car minorité et dire "ah oui, c'est normal, donc pas d'amélioration pour le linuxiens minoritaires" ;-).

      j'ai peut être dit de grosses conneries, merci de me corriger dans ce cas. =)

      Pas de grosse connerie, mais il faut rester cohérent vis à vis des "minorités", car on peut aussi être la minorité, et dire "ils sont minoritaires donc on va pas développer pour eux", ça peut nous revenir dans la gueule rapidement. Ce n'est pas un argument.
      • [^] # Re: Cela dépend des cas…

        Posté par  (site web personnel) . Évalué à 5.

        > Comme quoi, Windowsien ou Linuxien, finalement c'est une peu pareil : il y en a des deux côtés pour dire chacun pour sa pomme
        Faut savoir, déjà que ça parle de linux et bsd, il rajoute du windows dans l'histoire, et insidieusement il voudrait faire basculer le débat vers mac, qui comme tout le monde le sait, a une couche bsd. La boucle est bouclée ?
      • [^] # Re: Cela dépend des cas…

        Posté par  (site web personnel) . Évalué à 2.

        "ils sont minoritaires donc on va pas développer pour eux", ça peut nous revenir dans la gueule rapidement. Ce n'est pas un argument.

        Bien sur que si.

        Une différence fondamentale ici est que l'on parle de logiciels libres. Donc si un dev a envie de faire le portage (ou de porter la brique spécifique qui n'existe pas sur son système), il a tout ce qu'il faut pour le faire, voire, si c'est bien fait, le contribuer upstream.
        • [^] # Re: Cela dépend des cas…

          Posté par  (site web personnel) . Évalué à 7.

          sauf que l'on parle de briques importantes, pas de la 250 000 version de pong. Ils serait bon de les penser multiplateforme dès le début que celui qui va faire le boulot de portage n'est que ça a faire au lieu de deviner que a tel ou tel endroit du code il y a des linuxeries.

          Le problème c'est que ce n'est jamais ou presque fait comme ça.
          • [^] # Re: Cela dépend des cas…

            Posté par  (site web personnel) . Évalué à 8.

            >>> Le problème c'est que ce n'est jamais ou presque fait comme ça.

            Est-ce que ce n'est jamais fait comme ça car les devs Linux se fichent explicitement de tout ce qui n'est pas Linux (hypothèse 1) ou bien est-ce parce que les devs BSD ne se manifestent pas, ne participent pas et sortent juste de leur trou à la fin du processus (hypothèse 2).
            Je n'en sais rien mais ce serait intéressant de lire les échanges sur les mailing lists de ces projets "briques" ou d'aller voir sur freedesktop si des devs BSD participent ou pas.

            La question est controversée (et propice aux trolls) et les réponses aux post http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors sont vraiment tranchées.
            Est-ce que tu as lu le second message (celui de Simon) ? Comment savoir si c'est vrai ?
            • [^] # Re: Cela dépend des cas…

              Posté par  (site web personnel) . Évalué à 5.

              La réponse est assez simple, prend le cas de hal, regarde quand est ce que ce truc a été annoncé comme le messie que tout le monde devait l'utiliser, regarde ensuite à quel moment a commencé le travail pour le rendre portable - travail effectuer par des devs BSD et non les devs hal - (réponse dès que l'on a su que l'on allait nous imposer ça c'est à dire assez rapidement).

              Regarde enfin, combien de temps il a fallu pour obtenir un truc propre qui fonctionne et soit un minimum portable. Et c'est à ce moment là que tout le monde le vire "ah bah non les gars en fait on a fait de la merde... désolé, mais on recommence avec le nouveau truc qui déchire et vous pouvez encore vous faire voir pour avoir du portable".

              La dedans il y a deux problèmes :
              - les devs linux-centriques qui ne cherchent pas a isoler les code OS spécifique mais qui malgré tout cherche a imposer leur soluce comme la base d'applis auparavant portable (ie hal par exemple devenu souche pour beaucoup de gros projets)
              - les "putains les gars j'ai mon nouveau truc qui déchire" et hop avant de comprendre il est partout, mais comme il n'est pas suffisamment réfléchi en amont bah il gicle peu de temps après (cf toujours HAL par exemple). Le plus drôle c'est quand la même connerie est recommencée plus tard : cf esound vs pulseaudio (que c'est pas la même chose on te dit mais que ça y ressemble drôlement avec un résultat aussi moisi)

              /me qui en a ras le cul de faire grep \/proc pour trouver les linuxeries cachées
              • [^] # Re: Cela dépend des cas…

                Posté par  (site web personnel) . Évalué à 7.

                Euh, hal ca fait un moment que ca existe quand même, au moins 7 ans qu'il est dans les distribs donc il a pas giclé direct... (2004 si ma mémoire est bonne).
                • [^] # Re: Cela dépend des cas…

                  Posté par  . Évalué à 0.

                  2004, enfin ça dépend de la distribution.
                  Dans la Slackware, HAL a été introduit dans la 12.0 en juillet 2007.
        • [^] # Re: Cela dépend des cas…

          Posté par  . Évalué à 2.

          Logiciel libre, logiciel libre,... quand je vois qu'on parle de faire de l'ingénieure inverse sur le protocole de udev, je suis désolé mais ça pue. Et c'est pas de voir le code qui va beaucoup t'aider.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Cela dépend des cas…

        Posté par  (site web personnel) . Évalué à 4.

        >tiens, cette phrase marche aussi pour les développeurs Windows à qui
        >on demande la portabilité Linux.

        Parfaitement, et alors ? Y'a a pas des masses des logiciels libre qui ne tourne que sous Windows (VirtualDub de tête) et si les devs ont fait ce choix, c'est surement que ce dernier repose que sur les API Win32...

        Mais un logiciel libre en Qt/Gtk, il n'y aucune raison qu'il tourne sous Windows et pas sous un Unix libre... (ou pas libre).

        Par contre, que les linuxiens qui se plaignent que tel logiciel proprio ne soit pas dispo sous Linux n'ont qu'a retourner sous Windows si ils veulent utiliser des softs proprios... (mode aigri).
      • [^] # Re: Cela dépend des cas…

        Posté par  (site web personnel) . Évalué à 5.

        Le code étant libre, les amateurs de Xfce sous *BSD sont libres de bosser pour que le portage soit fait, cette liberté n'est pas retirée.

        Puis il y a logiciel portable et logiciel portable. Avoir un logiciel qui exploite au mieux les possibilités sous GNU/Linux, si son portage n'est qu'une piètre adaptation ce n'est pas la peine de le porter, qu'il reste sous Windows et les optimisations pour.
        Je rajouterais à ce sujet que Xfce est un gros projet d'environnement bureautique et qu'il y a la partie sensible de l'abstraction matérielle. Xfce a besoin de ces outils qui sont rarement génériques entre les OS (et c'est logique et tant mieux sinon on est bridé un max). Cette situation est donc bien plus pardonnable qu'un logiciel tel un navigateur web qui n'a besoin que d'un langage portable (et d'être bien codé) pour être porté correctement, il n'y a besoin de trop de code spécifiques.

        La situation est donc totalement différente qu'avec certains logiciels sous Windows pas portables (car en général on se fou bien du gestionnaire de fenêtre de Windows par exemple) et quand bien même ils seraient portables, beaucoup sont mal faits ou tellement optimisés pour Windows que sous GNU/Linux on récolte un logiciel un peu décevant.

        Et pour l'histoire de la cohérence, je ne me suis jamais plains de la portabilité des logiciels sous Windows vu que je n'utilise que des Logiciels Libres (souvent portables), donc je suis très cohérent avec moi même.
        • [^] # Re: Cela dépend des cas…

          Posté par  . Évalué à 3.

          Le code étant libre, les amateurs de Xfce sous *BSD sont libres de bosser pour que le portage soit fait, cette liberté n'est pas retirée.

          T'as déjà essayé de porter un logiciel plein de linbuxeries sous un autre OS ?


          Puis il y a logiciel portable et logiciel portable. Avoir un logiciel qui exploite au mieux les possibilités sous GNU/Linux, si son portage n'est qu'une piètre adaptation ce n'est pas la peine de le porter, qu'il reste sous Windows et les optimisations pour.


          La structuration du code est importante dans ce cas. Il n'est pas forcément utile de faire un soft tous OS compatible, mais il est surement utile dès la conception du logiciel de bien séparer les parties OS Spécific du reste, tout comme en général on sépare les couches présentation/traitement/stockage (exemple MVC).

          Le but n'est pas d'empêcher d'utiliser les spéccificités de l'OS, si elles existent et permettent de gagner en perfs sous Linux, autant le faire. Il faut juste bien le faire (attention, je ne parle pas des couches basses de l'OS, qui elles doivent être spécifiques, mais des couches un peu plus hautes telles qu'un gestionnaire de bureau, ou un navigateur www).
        • [^] # Re: Cela dépend des cas…

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Le code étant libre, les amateurs de Xfce sous *BSD sont libres de bosser pour que le portage soit fait

          C'est exactement ce qui se fait : [http://comments.gmane.org/gmane.os.freebsd.devel.ports/92313]

          C'est juste beaucoup plus laborieux.
  • # POSIX ≠ UNIX

    Posté par  . Évalué à 4.

    OpenVMS est compatible POSIX, Windows NT avec son « C: » et ses contre-obliques à-la-con™ aussi, paraît-il...
    • [^] # Re: POSIX ≠ UNIX

      Posté par  . Évalué à 5.

      Il me semble que dans l'émulation POSIX sur windows NT y'a pas de C: ni de \.
      POSIX n'est qu'un sous système du noyau NT.
      • [^] # Re: POSIX ≠ UNIX

        Posté par  . Évalué à 9.

        POSIX est ce qu'on appelle une personality au dessus du noyau NT, au meme titre que Win32. Il n'y a aucune emulation.
    • [^] # Re: POSIX ≠ UNIX

      Posté par  . Évalué à 1.

      Sais-tu pourquoi on a les "contre-obliques à-la-con™"?

      A cause des brevets logiciels.. :-(
      • [^] # Re: POSIX ≠ UNIX

        Posté par  . Évalué à 3.

        Tu veux dire que le '/' est breveté!?
        • [^] # Re: POSIX ≠ UNIX

          Posté par  . Évalué à 2.

          J'avais lu que c'était par peur d'un procès pour contrefaçon de l'interface Unix, mais le lien de pBpG (merci à lui) montre que ce n'était pas le cas..
      • [^] # Re: POSIX ≠ UNIX

        Posté par  . Évalué à 7.

        • [^] # Re: POSIX ≠ UNIX

          Posté par  . Évalué à 8.

          c'est marrant, parce que de migrer doucement un truc moche et pénible qui date de plus de 25 ans, ça ne leur semble pas envisageable "pour rester rétro compatible" ou je ne sais quoi.

          En revanche, casser la rétrocompatibilité des formats de fichiers de ms office, .doc ou .xls, datant de quelques années seulement, ça ne les dérange absolument pas.

          Je ne comprendrais jamais la politique et la vision sur le long terme de cette entreprise...

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: POSIX ≠ UNIX

            Posté par  (site web personnel) . Évalué à 9.

            Bah ça me semble cohérent : en cassant la compatibilité des outils bureautique tu vends des licences, en cassant la compatibilité des scripts des admins tu fais fuir les clients vers d'autres solutions. C'est une question de public cible.
          • [^] # Re: POSIX ≠ UNIX

            Posté par  . Évalué à 2.

            Mmmmh, sur un clavier qwerty, je vois pas trop en quoi \ est plus pénible que /.
            • [^] # Re: POSIX ≠ UNIX

              Posté par  . Évalué à 2.

              ne serait-ce que parce que les gens sont habitués aux / des URL

              Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: POSIX ≠ UNIX

              Posté par  . Évalué à 4.

              parce qu'il faut presque toujours les doubler tripler quadrupler quintupler, ou même plus selon les scripts et que dès qu'on change un poil la façon dont la chaîne est utilisés, on sais plus si faut en rajouter 2,3, 4 ou en retirer.

              le \ est aussi un caractère d'échappement et c'est chiant en C, script, ou même java d'avoir a faire gaffe a un chemin rentré ainsi c:\plop\new. Alors oui les le c:/plop/new passe aussi, mais faut toujours faire gaffe. (bon un replace("\\","/") corrige bien le tir, mais c'est chiant.

              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: POSIX ≠ UNIX

          Posté par  . Évalué à 1.

          « So they coded the OS to accept either "/" or "\" character as the path character (this continues today [...] ) »

          C'était peut être vrai en 2005 (date du billet), mais malheureusement ça n'est plus le cas... en tout cas pour Explorer.
          • [^] # Re: POSIX ≠ UNIX

            Posté par  (site web personnel) . Évalué à 2.

            heu... t'es sur ?

            je viens de tester : j'ouvre explorer (win + e)
            barre de titre
            je tappe "z:/dev/exp", entrée
            et hop, je me retrouve dans (en détail) :
            Ordinateur - Z: - Dev - Exp (oué c'est de triangles à la con dans cette barre) et si je clique pour afficher le vrai chemin j'ai Z:\Dev\Exp

            Donc vu comme ça :
            * ça marchait en 2005
            * ça marche toujours aujourd'hui sur un seven

            Donc si ça marche pas ça serait cool que tu colles un exemple car là...
            Idem dans cmd, je peux faire mon cd avec des /
            • [^] # Re: POSIX ≠ UNIX

              Posté par  . Évalué à 5.

              On va dire que ca marche de temps en temps (XP SP2):

              C:\> cd /winnt
              C:\WINNT>


              Et maintenant, je recommence :
              C:\WINNT> cd /winnt
              Le chemin d'accès spécifié est introuvable


              Mais avec une contre oblique, ca marche :
              C:\WINNT> cd \winnt
              C:\WINNT>


              Bref, c'est pas vraiment au point...
              • [^] # Re: POSIX ≠ UNIX

                Posté par  . Évalué à 3.

                Pareil sur mon XP... dans la barre d'adresse d'Explorer, je peux utiliser :
                dir1\dir2\dir3
                dir1/dir2/dir3
                dir1\dir2\..
                mais pas:
                dir1/dir2/..
              • [^] # Re: POSIX ≠ UNIX

                Posté par  (site web personnel) . Évalué à 2.

                si si, c'est au point, si tu utilises une version récente de windows ;) (j'ai plus de xp depuis un moment pour vérifier) :
                C:\> cd /Users
                C:\Users> cd /Users
                C:\Users> cd \Users
                C:\Users> cd /Users/Default
                C:\Users\Default> cd \Users\Default
                C:\Users\Default> cd \Users\Default\..
                C:\Users> cd /Users/Default/..
                C:\Users>


                Vu comme ça, tout fonctionne normalement.
                Et idem dans l'explorer

                Donc en tout cas sous 7 c'est ok.

                Maintenant, sous bash on a aussi des bizarreries plutôt louches genre :
                [...@... /]$ cd /
                [...@... /]$ cd //
                [...@... //]$ cd ///
                [...@... /]$


                ha oui mais non, paraît que dans ce cas c'est une feature...
                • [^] # Re: POSIX ≠ UNIX

                  Posté par  . Évalué à 2.

                  Donc en tout cas sous 7 c'est ok.

                  D'apres le blog ci-dessus, la fonctionnalité est là depuis MS-DOS. Sous XP, je vois que ça fonctionne pas tout à fait, mais je suis rassuré s'apprendre que sous Se7en ça fonctionne enfin correctement.

                  Quelle réussite, après tant d'années d'effort...
                  • [^] # Re: POSIX ≠ UNIX

                    Posté par  (site web personnel) . Évalué à 6.

                    oué mais non les gars, vous confondez deux problèmes :
                    * l'usage de / ou \ en tant que séparateur de répertoire / fichier
                    ** cela fonctionne bien depuis très longtemps
                    * l'usage de / pour décrire la racine du système
                    ** sous un win 2003 cd / ne fait rien...
                    *** donc un cd /Users dans le répertoire /Users ne fonctionnera pas (/ n'est pas la racine)
                    ** sous 7 / est la racine
                    *** cd / retourne à la racine du lecteur
                    *** donc cd /Users dans le répertoire /Users fonctionne

                    Je veux bien que les problèmes sont un peu ridicule, mais / fonctionne bien en délimiteur de fichier
                    • [^] # Re: POSIX ≠ UNIX

                      Posté par  . Évalué à 0.

                      T'as pas bien lu les commentaires dessus... et je rajoute que depuis un sélecteur de fichier, ça ne marche pas du tout.
                • [^] # Re: POSIX≠UNIX

                  Posté par  . Évalué à 5.

                  Il suffit d'utiliser un vrai shell comme zsh (il parait qu'on est vendredi aujourd'hui…)
                • [^] # Re: POSIX ≠ UNIX

                  Posté par  . Évalué à 1.

                  Euh... Mais c'est quoi cette feature ? Quelqu'un pour m'éclairer ?
                  • [^] # Re: POSIX≠UNIX

                    Posté par  . Évalué à 2.

                    It's not a feature it's a bug (ou l'inverse ça dépend des cas et de la température de la choucroute)
                  • [^] # Re: POSIX ≠ UNIX

                    Posté par  (site web personnel) . Évalué à 2.

                    ben la feature c'est que cd // nous amène à // alors que toutes les autres combinaisons ramènent à /
                    Je crois que j'avais lu un message disant que la personne (je vais ptetre dire une connerie, mais je crois que ça venait de pterjan...) avait essayé de remonter le bug et qu'on lui avait répondu que c'était normal

                    Une explication parmi d'autres :
                    POSIX.2, in its description of 'cd', says that three or more leading slashes may be replaced with a single slash when canonicalizing the current working directory.

                    This is, I presume, for historical compatibility. Certain versions of Unix, and early network file systems, used paths of the form //hostname/path to access 'path' on server 'hostname'.
      • [^] # Re: POSIX ≠ UNIX

        Posté par  (Mastodon) . Évalué à 8.

        Sais-tu pourquoi on a les "contre-obliques à-la-con™"?

        Dans mes souvenirs brumeux de vieux dino, c'est juste que pour le premier ms-dos, qui ne connaissait PAS les répertoires, une entitée pensante a estimé que le caractère / pourrait servir à préfixer les options. Et quand les répertoires sont arrivés, quelques mois plus tard, paf le chien.
        • [^] # Re: POSIX ≠ UNIX

          Posté par  . Évalué à 2.

          Paf, le chemin !
        • [^] # Re: POSIX ≠ UNIX

          Posté par  . Évalué à 1.

          Le même gars a dû se dire : « Et pis, on dirait que pour les variables on mettrait '%' devant au lieu de '$' ! »

          Et pourtant c'est bien un certain William Henry Porte III, créateur de Fenêtres et fondateur de MicroMou™ (l'ironie c'est que les fenêtres molles, c'est nous qu'on les a dans Compiz), qui a popularisé le langage symbolique généraliste pour débutant (i.e. B.A.S.I.C.) utilisant ledit caractère pognon '$' devant les variables.
          • [^] # Re: POSIX ≠ UNIX

            Posté par  (site web personnel) . Évalué à 2.

            > les fenêtres molles, c'est nous qu'on les a dans Compiz
            oué ben c'est pas le truc le plus intelligent qu'on ait inventé... a oui, pour faire le kéké devant son écran (et devant les autres geek boutonneux) je comprend, mais dans le genre pas utilisable ça se pose là.
            Heureusement qu'on peut les virer rapidement.

            (mais sinon les autres features sont pas trop mal, mais pas ça non...)

            /avisperso
    • [^] # Re: POSIX ≠ UNIX

      Posté par  . Évalué à 2.

      On peut aussi aussi préciser que Unix n'est pas « conforme POSIX ».
      De la première à la dixième et dernière édition, aucune n'est conforme à aucun des standards POSIX de IEEE 1003.1-1988 à 2008.
  • # En tant que BSDiste je me permets de participer au troll

    Posté par  . Évalué à 10.

    Le reproche fait à Linux n'est pas
    Sous Linux c'est pourri car tout change d'une année sur l'autre

    Mais

    Sous Linux c'est pourri car tout change tous les six mois niveau API, tous les deux mois niveau ABI; te casse pas les pieds à chercher la doc y en a pas ou elle est fausse (spécial dédicace Alsa); de toute façon le kernel Linux c'est 6 sociétés qui tirent la couverture vers eux, 15 000 mômes qui s'amusent et Alan Cox qui fait le ménage sous les insultes.

    Les BSDistes quand ils critiquent sont toujours complets, même si parfois acerbes.
    • [^] # Re: En tant que BSDiste je me permets de participer au troll

      Posté par  (Mastodon) . Évalué à 8.

      la doc y en a pas ou elle est fausse (spécial dédicace Alsa);

      Pertinenté.
    • [^] # Re: En tant que BSDiste je me permets de participer au troll

      Posté par  (Mastodon) . Évalué à 10.

      [...] le kernel Linux c'est 6 sociétés qui tirent la couverture vers eux, 15 000 mômes qui s'amusent et Alan Cox qui fait le ménage sous les insultes.

      Très très bon :D

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: En tant que BSDiste je me permets de participer au troll

      Posté par  . Évalué à 3.

      Exacte la documentation du noyau est pourri simplement parce qu'il est impossible à l'heure actuel de produire une doc tout les 8 ou 10 semaines pour qu'elle soit à jour.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: En tant que BSDiste je me permets de participer au troll

        Posté par  . Évalué à 4.

        Et tu trouves ça normal ?
        • [^] # Re: En tant que BSDiste je me permets de participer au troll

          Posté par  . Évalué à 2.

          Ben vas-y, si tu as du temps, c'est ouvert à tous.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: En tant que BSDiste je me permets de participer au troll

            Posté par  . Évalué à 4.

            C'est bien connu, il est bien plus pratique d'avoir de la doc écrite par un mec qui n'est pas à l'origine du bout de code qui a été rajouté.
            • [^] # Re: En tant que BSDiste je me permets de participer au troll

              Posté par  . Évalué à 1.

              C'est bien connu, si on vous écrit un logiciel avec les sources que vous pouvez utiliser gratuitement, il est inadmissible de ne pas avoir la doc avec.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: En tant que BSDiste je me permets de participer au troll

              Posté par  . Évalué à 9.

              C'est bien connu, il est bien plus pratique d'avoir de la doc écrite par un mec qui n'est pas à l'origine du bout de code qui a été rajouté.

              Oui, complètement.

              Et ça ne vaut pas que pour le code.

              Un mec qui code bien n'est toujours quelqu'un doué pour écrire de la doc. (Si on était vrendredi, j'aurais même rajouté que c'est même plutôt rare).

              D'autant plus que quelqu'un qui est à l'origine du truc considère beaucoup de trucs comme acquis, ou évident, ou simplement oublie de parler d'un truc.

              Alors que quand un mec s'est fait chier pour comprendre quelque chose, il a déjà fait le parcourt intellectuel pour essayer de comprendre le truc. Donc il sait ce qu'il faut documenter, les choses à prendre en compte, là où il faut insister, les trucs qu'il faut éviter ou ce dont il faut se méfier, les éventuels prérequis qu'il n'avait pas avant etc.


              Alors certes, ça demande plus d'effort, mais ça fait une documentation bien plus accessible par la suite.
              • [^] # Re: En tant que BSDiste je me permets de participer au troll

                Posté par  . Évalué à 3.

                Je ne parle pas de doc « complète » du soft; juste de doc en début de fonction et dans les parties critiques d'un code. Et comme les gens (surtout dans le libre) ont tendance à changer des trucs, ben si je change quelque chose dans le code, je dois prendre la peine de modifier les commentaires existants pour qu'ils reflètent le nouveau comportement.

                Maintenant, ça n'empêche pas d'avoir quelqu'un d'autre proposant une doc de plus haut niveau, mais avoir le minimum vital à portée de clavier, ça aide quand même vachement beaucoup.
    • [^] # Re: En tant que BSDiste je me permets de participer au troll

      Posté par  (site web personnel) . Évalué à 3.

      Il faudrait juste une vrai norme comme freedesktop (même si elle est pourris) histoire de se mettre par dessus l'OS. En gros, refaire un POSIX "moderne" de niveau d'abstraction supérieur qui pourrait partir des interfaces Linux stable.

      "La première sécurité est la liberté"

  • # Patrick_G a inventé le saut spacio-temporel !

    Posté par  . Évalué à 3.

    On est vendredi !!!
  • # Vous devez entrer un sujet et un commentaire

    Posté par  . Évalué à 10.

    Xfce utilisait des composants n'existant que sous Linux (comme udev, consolekit, policikit, etc).

    http://www.openbsd.org/cgi-bin/cvsweb/ports/sysutils/polkit/
    http://www.openbsd.org/cgi-bin/cvsweb/ports/sysutils/console(...)
    http://www.freshports.org/sysutils/policykit/
    http://www.freshports.org/sysutils/consolekit/
    http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/security/policyki(...)
    http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/consolek(...)

    Ca serait bien de se renseigner un minimum avant de parler. Certes, le portage n'a pas été simple (pas de PAM sous OpenBSD par exemple), mais ces couches marchent.

    Les 2 composants qui manquent 'vraiment' sont udev et upower. Upower est relativement bien codé, mais il n'a pour l'instant qu'un backend linux et un backend freebsd.

    Udev/Gudev sont bien évidemment linux-only, et il n'y a pas vraiment de doc claire pour faire un équivalent compatible qui marche sur les autres OS.

    Après tout, udevd se contente d'envoyer des évenements DBUS lors de l'ajout/suppression de périphériques, il reste "juste" a reverse-engineerer le protocole.

    Ah, et Xfce marche très bien sous OpenBSD, il n'y a juste pas d'automontage des périphériques (thunar-volman) ni xfce4-power-manager, mais le plugin xfce4-battery marche très bien.
    • [^] # Re: Vous devez entrer un sujet et un commentaire

      Posté par  (site web personnel) . Évalué à 3.

      >>> Ca serait bien de se renseigner un minimum avant de parler.

      Il me semble que j'ai justement donné les liens vers les deux posts concernant Xfce pour que les gens puissent aller les lire et se faire une idée.
      Par exemple dans le second lien il y a ça :

      "At least udev is strongly linked to Linux and as far as I know is not available on any of the BSD flavors. Unfortunately it is now the only good way to detect storage devices, cameras, printers, scanners and other devices using a single framework (...) I don’t know what the porting status of the other frameworks is. But I am pretty sure not all of them have been ported to other platforms yet which is why I felt the need to express our disappointment in the announcement".

      Maintenant si tu dis que seul udev et upower sont concernés alors c'est une excellente nouvelle. Les BSD vont donc pouvoir plus facilement profiter de toutes les fonctions d'Xfce.

      >>> Après tout, udevd se contente d'envoyer des évenements DBUS lors de l'ajout/suppression de périphériques, il reste "juste" a reverse-engineerer le protocole.

      Est-ce que tu sais si cette doc est à jour ?
      http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev(...)
      • [^] # Re: Vous devez entrer un sujet et un commentaire

        Posté par  . Évalué à 7.


        Est-ce que tu sais si cette doc est à jour ?
        http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev(...)


        Si tu lis cette doc (plutot que de googler et balancer direct le lien), ce n'est que pour le code 'utilisateur' d'udev, elle ne parle pas du tout des évenements DBUS ni du fonctionnement interne, il manque quelque chose comme http://upower.freedesktop.org/docs/ref-dbus.html. Un truc qui montre ce qui se passe lors de l'insertion/suppression de perifs (matching de pci/usb ids pour trouver la classe/type, etc..). Quand je parle de reverse-engineerer, ca va etre faire tourner une ubuntu sur une clef usb, et regarder ce qui passe sur DBUS avec dbus-monitor.

        et quand je vois

        const char * udev_get_sys_path (struct udev *udev);
        Retrieve the sysfs mount point. The default is "/sys".

        Qu'on vienne pas me dire que c'est portable.

        C'est beaucoup plus simple pour moi de faire un faux udev en shell qui balance des événements DBUS lors de l'insertion de périphériques (chose qui peut se scripter avec hotplugd sous OpenBSD, avec devd sous FreeBSD, etc..) que de faire un udevd en code C qui se pluggue sur le code kernel correspondant. L'udevd existant utilise énormement de linuxeries (les sockets netlink + sock_filter, des flags d'open() ....)
    • [^] # Re: Vous devez entrer un sujet et un commentaire

      Posté par  . Évalué à -1.

      Après tout, udevd se contente d'envoyer des évenements DBUS lors de l'ajout/suppression de périphériques, il reste "juste" a reverse-engineerer le protocole.

      Ça, c'est concept : faire du reverse ingeneering sur du logiciel libre. Et les sources, ça ne suffit pas ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Vous devez entrer un sujet et un commentaire

      Posté par  (Mastodon) . Évalué à 2.

      il n'y a juste pas d'automontage des périphériques

      Si il ne manque que ça, je ne vois pas l'intérèt du troll. Si les fonctions de base (wm, taskbar, menu et machin à applet) fonctionnent, je peux tranquillement retourner boire une bière.
  • # GNU ou POSIX ?

    Posté par  . Évalué à 3.

    Le projet GNU a une position ambiguë sur le sujet.

    http://www.gnu.org/prep/standards/standards.html#Using-Exten(...) dit que "ça dépend"

    http://www.gnu.org/prep/standards/standards.html#Non_002dGNU(...) dit que seuls les "standards" GNU comptent quitte à ne pas respecter les standards.

    BeOS le faisait il y a 20 ans !

    • [^] # Re: GNU ou POSIX ?

      Posté par  . Évalué à 5.

      Linux n'est pas un projet GNU.
      • [^] # Re: GNU ou POSIX ?

        Posté par  . Évalué à 4.

        N'est-ce pas ?

        Ce qui est intéressant c'est :
        - que les gens derrière GNU se sont posé la même question que les gens derrière "Linux"
        - qu'on voit un "éco-système d'exploitation" "Linux" émerger autour et pardessus le système GNU et le noyau Linux.

        BeOS le faisait il y a 20 ans !

  • # Au bûcher !

    Posté par  (Mastodon) . Évalué à 10.

    Lennart Poettering, c'est le gars qui a commis :
    - Avahi
    - PulseAudio
    - systemd

    Je crois qu'il faut vraiment qu'il arrête d'avoir des idées...

    </humour>
    • [^] # Re: Au bûcher !

      Posté par  . Évalué à 6.

      Au contraire.

      J'utilise tous les jours Avahi et PulseAudio, ça marche et ça fait des trucs que je ne sais pas faire autrement de manière aussi simple. Et quand on voit qu'Avahi est devenu l'implémentation de référence pour Zeroconf d'après les gars d'Apple…

      Pour systemd, j'y passe dès que j'aurais pris un peu de temps pour comprendre.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Au bûcher !

        Posté par  . Évalué à 6.

        Pour systemd, j'y passe dès que j'aurais pris un peu de temps pour comprendre.

        Oh, d'ici la ca aura été remplacé par upstart^Wrunit^Winitng^Winitflavorofthemonth...
        • [^] # Re: Au bûcher !

          Posté par  . Évalué à 3.

          Oh, je suis sous Debian, j'ai le temps de voir venir.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Au bûcher !

      Posté par  (Mastodon) . Évalué à 5.

      Comme je vois que je suis pertinenté, j'enlève ma balise humour et je vais chercher des bûches...
  • # Mauvais conseil

    Posté par  (site web personnel) . Évalué à 9.

    En fait, de la façon dont je vois les choses, l'API Linux joue maintenant le rôle de l'API POSIX et Linux est devenu le point focal de tout le développement du logiciel libre. De ce fait je ne peux que recommander aux développeurs d'essayer de hacker avec seulement Linux en tête et de faire l'expérience de la liberté que cela apporte

    Je trouve ce conseil choquant.

    Je pense qu'un logiciel devrait être portable, si possible. On peut faire du logiciel non portable, si c'est fait en *connaissance de cause*. Mais pour cela, il faut déjà avoir un minimum de connaissance sur la portatibilité pour pouvoir faire le choix. Savoir qu'il y a des différences, ça fait partie de la culture générale d'un développeur (ama).
    Ce n'est pas en se focalisant sur Linux qu'on va apprendre ça.

    Et est-ce que la *liberté* n'est pas, justement, de ne pas être pieds et poings liés à un système, quel qu'il soit ?

    Perso j'ai beaucoup appris (et trouver quelques bugs...) en faisant tourner du code sous différents Unix, et si possible des architectures différentes (genre sparc). On a parfois des drôles de surprises...

    Avec ce genre de conseil, on va finir par se retrouver avec du code incapable de tourner sur autre chose que du x86 et ce même sous Linux (c'est peut-être déjà fait ceci dit).

    les pixels au peuple !

  • # posix + linux

    Posté par  . Évalué à 6.

    Alors que faire ? Doit-on choisir de se limiter à POSIX ou bien ne coder que pour Linux en se disant que les autres suivront ?
    Ben le mieux c'est de faire le maximun en POSIX et puis utilisé des API linux pour les trucs qui n'existe pas dans POSIX (udev, ...).

    Mais faire un soft POSIX portable n'est pas simple si on a pas plusieurs plateformes pour tester. Les specs sont parfois ambiguë, et chaque OS prendre quelque fois des libertés (et même sur un même OS ca peut varier entre les libc : glibc, uclibc, bionic, ...). Mais ca restera plus simple à porter que un truc coder uniquement pour Linux.

    Après ça dépend quel est la porté de ton projet. C'est sur que si tu code un truc spécifique linux, autant se faire plaisir.

    Lennart est dans son droit d'écrire son code comme il le veut.
    Là ou c'est plus tangent c'est quand il recommande joyeusement aux autres de faire comme lui:

    Mouais, c'est son choix. Le mien c'est de faire profiter mon soft au maximun de gens quelque soit la plateforme qu'ils utilisent.
    • [^] # Re: posix + linux

      Posté par  . Évalué à 3.

      Je suis assez d'accord avec toi, et j'ajouterais que l'organisation du code est primodiale pour faciliter la portabilité. Alors c'est sur, ça oblige à se poser plus de questions que si on développe "à la volée" comme sous Linux, mais au final le soft s'en trouve plus maintenable.
      • [^] # Re: posix + linux

        Posté par  (site web personnel) . Évalué à 7.

        Il me semble que, au moins pour systemd, Lennart ne s'est pas embarqué dans un développement "à la volée"sans se poser de questions. Au contraire il a soigneusement analysé les solutions existantes, il a discuté des possibilités avec Kay Sievert et ils ont finalement opté pour une architecture pensée dès l'origine pour profiter des fonctions spécifiques de Linux.
        Le fait d'utiliser cgroups avec sa hiérarchisation des process et sa capacité à appliquer des règles ou des limitations. Le fait de lancer les process dans leur espace de nommage spécifique et de leur appliquer des capabilities spéciales. Le fait d'utiliser des API spécifiques Linux comme timerfd ou signalfd, etc.
        Tout ceci est délibéré et, comme le dit Lennart dans l'interview, cela permet d'avoir un code beaucoup plus simple, plus court et plus maintenable.
        Dire qu'ils se sont lancés là dedans comme des boeufs sans se poser de questions c'est faire une grave erreur il me semble.

        Là ou je te rejoins c'est pour les applications plus "hautes" et plus proches de l'espace utilisateur que ne l'est systemd. Des environnements de bureau tels qu'Xfce, KDE ou GNOME devraient être pensés pour faciliter la portabilité.
        • [^] # Re: posix + linux

          Posté par  . Évalué à 2.

          Tout ceci est délibéré et, comme le dit Lennart dans l'interview, cela permet d'avoir un code beaucoup plus simple, plus court et plus maintenable.
          Dire qu'ils se sont lancés là dedans comme des boeufs sans se poser de questions c'est faire une grave erreur il me semble.


          Je ne parlais pas de ce projet spécifiquement mais d'autres projets qui laissent un sentiment de "codé à la volée sans trop se poser de questions".
        • [^] # Re: posix + linux

          Posté par  . Évalué à 2.

          Tout ceci est délibéré et, comme le dit Lennart dans l'interview, cela permet d'avoir un code beaucoup plus simple, plus court et plus maintenable.

          C'est dans le même genre qu'OpenSSH qui a deux version: une portable et une spécifique à OpenBSD qui est décrite comme plus sécurisée car le code est plus clair et donc potentiellement avec moins de bugs.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: posix + linux

            Posté par  . Évalué à 2.

            Euh... faut arrêter les conneries la.

            Le code d'OpenSSH-portable est le même que celui d'OpenSSH, avec un script configure en plus et des #ifdef/#have en fonction des features additionnelles / os cible.
            Les 2 ont bien évidemment le même niveau de sécurité.
            • [^] # Re: posix + linux

              Posté par  . Évalué à 6.

              Il est pourtant écrit sur la page d'accueil d'OpenSSH:

              OpenSSH is developed by two teams. One team does strictly OpenBSD-based development, aiming to produce code that is as clean, simple, and secure as possible. We believe that simplicity without the portability "goop" allows for better code quality control and easier review. The other team then takes the clean version and makes it portable (adding the "goop") to make it run on many operating systems -- the so-called -p releases, ie "OpenSSH 5.7p1".

              Qui dit clairement que le code de la version p est moins sécurisé puisque le code de la version de base est plus sécurisé

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: posix + linux

          Posté par  . Évalué à 3.

          Des environnements de bureau tels qu'Xfce, KDE ou GNOME devraient être pensés pour faciliter la portabilité.
          Ce qui est le cas de KDE, surtout pour KDE4 (Solid, Phonon, etc.)
  • # Mouhouhouahahaha

    Posté par  . Évalué à -4.

    T'inquiètes, ça marchera toujours sous FreeBSD avec le Linuxulator.

    Maintenant, toi, tu décris le problème un peu comme étant une prise de partie de XFCE vis à vis des BSD, je pense que c'est plutot une explication sur l'absence d'une fonctionnalité.
    Cette absence ne pose de problèmes que si une distribution basée sur un BSD s'en trouve gênée, ce qui n'est pas encore totalement le cas.

    Pour l'avenir, le problème va être l'absence de KMS+GEM , et Wayland . l'absence de systemd ne devrait pas être trop gênante.

    Ah oui, et pour la deuxième partie de ton rnal ... Les donneurs de leçon lixiuniens là, quand est-ce qu'ils font un noyau modulaire chez Linux ?
    Tu sais un truc où tu peux faire :

    kldunload radeon
    kldload snd_hda
    ...
    kldload linux

    à chaud, avec des logiciels tournant ...

    parce que bon, hein ... voila quoi...

    Sedullus dux et princeps Lemovicum occiditur

    • [^] # Re: Mouhouhouahahaha

      Posté par  . Évalué à 3.

      Franchement, décharger le pilote de la carte graphique et espérer que le serveur X ne dise rien, ça ne me paraît pas vraiment possible.

      Sous Linux aussi tu peux décharger des modules sans stopper les logiciels avec rmmod -f, mais bon, tu vas te retrouver avec un truc très instable.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Mouhouhouahahaha

        Posté par  . Évalué à 1.

        juste une petite réponse parce que maintenant on est vendredi .
        radeon.ko n'est pas le pilote de la carte graphique. Comme sous Linux, ce dernier s'appelle /usr/ports/x11/xf86-video-ati .
        radeon.ko c'est le module permettant entre autres d'avoir X11 en espace utilisateur, d'avoir un beau direct rendering=YES , et tutti quanti .

        Pour la stabilité des modules chargeables à chaud, ben ouais, c'est ce que je vois. Ya un fossé, un cañon entre le kernel Linux et celui de FreeBSD en matière de gestion des modules . :)

        Mais je reconnais que j'ai un peu dévié du sujet. En même temps, j'ai le droit de me moquer des problèmes " d'automount " par l'absence d'udev, problème dont se plaint le dev de XFCE-4.8 . J'ai le droit, et je pense que ça ne devrait pas concerner les gens qui prennent le temps et les moyens de lire le handbook. " Commment faire ça ? C'est dans le handbook !'
        Si XFCE sort une version FreeBSD dans laquelle il n'existe plus d'automount , à cause de l'absence de HAL , ce sera documenté, et la façon _traditionnelle_ de monter et démonter des périphériques est connue et documentée aussi. L'autre façon, c'est blingbling. ça ne me concerne moyennement . ( pour ces façons de faire, j'ai mes partoches Linux ).

        La seule chose qui me concerne, ce serait d'enfin pouvoir jouer à des jeux directX9 sous ma FreeBSD. mais bon, wine en chroot 32 bits, j'aime po :)

        Sedullus dux et princeps Lemovicum occiditur

        • [^] # Re: Mouhouhouahahaha

          Posté par  . Évalué à 2.

          Je repose quand même la question, parce que j'ai du mal à y croire : est-ce que décharger le module radeon.ko du noyau se fait sans que X.org ne sourcille ?

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Mouhouhouahahaha

            Posté par  . Évalué à 3.

            en fait non : s'il peut pas décharger le module parce que le périphérique est occupé, il répond de façon tout à fait POSIX par un message d'erreur.

            kldunload radeon
            kldunload: can't unload radeon: device busy.

            Sedullus dux et princeps Lemovicum occiditur

            • [^] # Re: Mouhouhouahahaha

              Posté par  (Mastodon) . Évalué à 3.

              s'il peut pas décharger le module parce que le périphérique est occupé,

              Ah ah ah, ça me rappelle un vieux troll fmbl sur le déchargement du module son.
            • [^] # Re: Mouhouhouahahaha

              Posté par  . Évalué à 4.

              Je m'en doutais un peu.

              Du coup, je ne vois pas en quoi la gestion des modules sous BSD serait meilleure que sous Linux, tout au moins je ne vois pas ce que voulait dire le premier message.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Mouhouhouahahaha

                Posté par  . Évalué à -4.

                ben suffit de fermer les logiciels qui utilisent les modules.

                En gros, l'avantage, c'est que tu peux conserver un noyau générique et charger au boot les modules qui ne sont pas dans le noyau générique. Ce qui te permet de passer par l'utilitaire freebsd-update pour mettre à jour ton OS. C'est un peu la voie " normale" actuelle proposée.
                Tu mets les modules dans le /boot/loader.conf, et ils sont chargés juste après le noyau au démarrage de la machine. ( et on peut facilement booter sans les modules , merci Grub2 ) .
                L'autre utilisation du noyau modulaire est de minimiser la taille du noyau au maximum, et de ne charger les modules que lorsqu'on en a besoin. ( chose que je fais couramment avec le son par exemple mais qui peut/pourrait être fait avec n'importe quel périphérique , comme une webcam, une imprimante ou un scanner ). C'est un plus en matière de paranoïa sécuritaire, de savoir que la webcam n'a pas son driver installé.
                Sans parler de tout ce qui peut être fait par des fabriquants de matériels tiers. ( un kldload permet d'activer/vérifier le bon fonctionnement d'un matériel sans avoir besoin forcément de rebooter ).

                Sedullus dux et princeps Lemovicum occiditur

  • # Post mal fichu ou troll?

    Posté par  . Évalué à 3.

    Si ton post est sincère alors il est mal fichu car tu mets ensembles deux choses totalement séparées:
    a- les API dans les domaines non-couvert par POSIX donc forcément non-POSIX (cas de XFce 4.8)

    b- les API couvertes aussi par POSIX mais ou coder en "spécifique Linux" apporte des avantages (performances, facilités d'utilisation car spec POSIX mal fichu, etc).

    Si c'est un troll, bah fallait attendre Vendredi..
  • # Lennart en live

    Posté par  (site web personnel) . Évalué à 3.

    À 27C3, il y a eu une présentation sur l'état des APIs desktop sous Linux. Lennart était dans le public...
    vidéo : http://mirror.fem-net.de/CCC/27C3/mp4-h264-HQ/27c3-4017-en-d(...)
    audio : http://mirror.fem-net.de/CCC/27C3/ogg-audio-only/27c3-4017-e(...)
    abstract+slides : http://events.ccc.de/congress/2010/Fahrplan/events/4017.en.h(...)

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Lennart en live

      Posté par  . Évalué à 4.

      Lennart était dans le public...

      Pour ceux qui ont la flemme de regarder la video, Lennart c'est le douchebag qui interrompt tout le temps pour balancer des trucs du genre "Do you hate handicapped people?".

      Entre le presentateur qui raconte beaucoup de betises (ignorance ou mauvaise foi, difficile a dire) et Lennart qui prend toute critique, meme minime, comme une attaque en regle contre son illustre personne, ca donne une presentation assez penible a regarder.
  • # Debian GNU/kFreeBSD et XFCE

    Posté par  . Évalué à 1.

    Je me demande si la nouvelle version de XFCE peut être installée à 100% sur Debian avec le noyau de FreeBSD.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.