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.
Journal Linux ou POSIX ?
26
jan.
2011
# Cela dépend des cas…
Posté par Renault (site web personnel) . Évalué à 10.
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 B16F4RV4RD1N . Évalué à 5.
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 Tonton Th (Mastodon) . Évalué à 7.
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 pasScott pasForstall . Évalué à 5.
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 nicolas . Évalué à 6.
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 pasScott pasForstall . Évalué à 1.
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 nicolas . Évalué à 6.
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 pasScott pasForstall . Évalué à 1.
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 fearan . Évalué à 1.
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 pasScott pasForstall . Évalué à 1.
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 fearan . Évalué à 2.
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 Bapt (site web personnel) . Évalué à 3.
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 Anonyme . Évalué à 5.
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 nicolas . Évalué à 9.
« 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 pasScott pasForstall . Évalué à 2.
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 nicolas . Évalué à 3.
— 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 Thomas Douillard . Évalué à 2.
[^] # Re: Cela dépend des cas…
Posté par pasScott pasForstall . Évalué à -4.
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 fearan . Évalué à 3.
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 Littleboy . Évalué à 3.
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 fearan . Évalué à 2.
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 pasScott pasForstall . Évalué à 2.
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 Jerome Herman . Évalué à 3.
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 fearan . Évalué à 2.
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 Jerome Herman . Évalué à 3.
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 fearan . Évalué à 2.
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 Jerome Herman . Évalué à 1.
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 fearan . Évalué à 2.
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 Littleboy . Évalué à 1.
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 Littleboy . Évalué à 4.
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 Jerome Herman . Évalué à 10.
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 Littleboy . Évalué à 2.
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 FreeB5D . Évalué à 0.
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 monde_de_merde . Évalué à 10.
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 zebra3 . Évalué à 4.
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 barmic . Évalué à 1.
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 Tonton Th (Mastodon) . Évalué à 7.
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 barmic . Évalué à 2.
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 Moonz . Évalué à 3.
[^] # Re: Cela dépend des cas…
Posté par barmic . Évalué à 2.
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 Maxime Buffa . Évalué à 6.
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 Maxime Buffa . Évalué à 4.
"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 Patrick Lamaizière (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 zebra3 . Évalué à 7.
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 Jerome Herman . Évalué à 10.
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 totof2000 . Évalué à 1.
[^] # Re: Cela dépend des cas…
Posté par Misc (site web personnel) . Évalué à 6.
[^] # Re: Cela dépend des cas…
Posté par totof2000 . Évalué à 1.
[^] # Re: Cela dépend des cas…
Posté par totof2000 . Évalué à 1.
- 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 Mr Kapouik (site web personnel) . Évalué à 10.
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 barmic . Évalué à 3.
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 windu.2b . Évalué à 2.
Il me semble que KDE envisage (est en cours ?) de faire la même chose...
[^] # Re: Cela dépend des cas…
Posté par zebra3 . Évalué à 4.
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 reno . Évalué à 7.
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 FreeB5D . Évalué à 2.
(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 Patrick Lamaizière (site web personnel) . Évalué à 4.
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 Zenitram (site web personnel) . Évalué à 10.
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 CrEv (site web personnel) . Évalué à 5.
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 vieuxshell (site web personnel) . Évalué à 2.
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 Bapt (site web personnel) . Évalué à 7.
Le problème c'est que ce n'est jamais ou presque fait comme ça.
[^] # Re: Cela dépend des cas…
Posté par patrick_g (site web personnel) . Évalué à 8.
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 Bapt (site web personnel) . Évalué à 5.
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 gnumdk (site web personnel) . Évalué à 7.
[^] # Re: Cela dépend des cas…
Posté par FreeB5D . Évalué à 0.
Dans la Slackware, HAL a été introduit dans la 12.0 en juillet 2007.
[^] # Re: Cela dépend des cas…
Posté par barmic . Évalué à 2.
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 gnumdk (site web personnel) . Évalué à 4.
>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 Renault (site web personnel) . Évalué à 5.
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 totof2000 . Évalué à 3.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
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 Davy Defaud . Évalué à 4.
[^] # Re: POSIX ≠ UNIX
Posté par Pinaraf . Évalué à 5.
POSIX n'est qu'un sous système du noyau NT.
[^] # Re: POSIX ≠ UNIX
Posté par pasBill pasGates . Évalué à 9.
[^] # Re: POSIX ≠ UNIX
Posté par reno . Évalué à 1.
A cause des brevets logiciels.. :-(
[^] # Re: POSIX ≠ UNIX
Posté par calandoa . Évalué à 3.
[^] # Re: POSIX ≠ UNIX
Posté par reno . Évalué à 2.
[^] # Re: POSIX ≠ UNIX
Posté par pasBill pasGates . Évalué à 7.
[^] # Re: POSIX ≠ UNIX
Posté par B16F4RV4RD1N . Évalué à 8.
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 psychoslave__ (site web personnel) . Évalué à 9.
[^] # Re: POSIX ≠ UNIX
Posté par lasher . Évalué à 2.
[^] # Re: POSIX ≠ UNIX
Posté par B16F4RV4RD1N . Évalué à 2.
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 fearan . Évalué à 4.
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 calandoa . Évalué à 1.
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 CrEv (site web personnel) . Évalué à 2.
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 shbrol . Évalué à 5.
C:\> cd /winntC:\WINNT>
Et maintenant, je recommence :
C:\WINNT> cd /winntLe chemin d'accès spécifié est introuvable
Mais avec une contre oblique, ca marche :
C:\WINNT> cd \winntC:\WINNT>
Bref, c'est pas vraiment au point...
[^] # Re: POSIX ≠ UNIX
Posté par calandoa . Évalué à 3.
dir1\dir2\dir3mais pas:dir1/dir2/dir3
dir1\dir2\..
dir1/dir2/..[^] # Re: POSIX ≠ UNIX
Posté par CrEv (site web personnel) . Évalué à 2.
C:\> cd /UsersC:\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 shbrol . Évalué à 2.
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 CrEv (site web personnel) . Évalué à 6.
* 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 calandoa . Évalué à 0.
[^] # Re: POSIX≠UNIX
Posté par daimrod . Évalué à 5.
[^] # Re: POSIX≠UNIX
Posté par CrEv (site web personnel) . Évalué à 2.
... at ... in ~○ bash
[...@... ~]$
Ca fait bien longtemps que bash n'est plus mon shell par défaut tellement zsh rox des maman ours !!
bonux : https://github.com/robbyrussell/oh-my-zsh
[^] # Re: POSIX ≠ UNIX
Posté par Nucleos . Évalué à 1.
[^] # Re: POSIX≠UNIX
Posté par daimrod . Évalué à 2.
[^] # Re: POSIX ≠ UNIX
Posté par CrEv (site web personnel) . Évalué à 2.
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 Tonton Th (Mastodon) . Évalué à 8.
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 Davy Defaud . Évalué à 2.
[^] # Re: POSIX ≠ UNIX
Posté par flagos . Évalué à 9.
[^] # Re: POSIX ≠ UNIX
Posté par Geo Vah . Évalué à 3.
http://nojhan.free.fr/article.php3?id_article=81
[^] # Re: POSIX ≠ UNIX
Posté par flagos . Évalué à 2.
[^] # Re: POSIX ≠ UNIX
Posté par Davy Defaud . Évalué à 1.
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 CrEv (site web personnel) . Évalué à 2.
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 Physche . Évalué à 2.
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 Jerome Herman . Évalué à 10.
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 Tonton Th (Mastodon) . Évalué à 8.
Pertinenté.
[^] # Re: En tant que BSDiste je me permets de participer au troll
Posté par gUI (Mastodon) . Évalué à 10.
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 barmic . Évalué à 3.
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 Romeo . Évalué à 4.
[^] # Re: En tant que BSDiste je me permets de participer au troll
Posté par zebra3 . Évalué à 2.
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 lasher . Évalué à 4.
[^] # Re: En tant que BSDiste je me permets de participer au troll
Posté par zebra3 . Évalué à 1.
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 lasher . Évalué à 7.
Blague à part: devoir passer autant de temps à documenter une partie de code obscure (car inconnue du lecteur) qu'à écrire le code alors que rajouter quelques commentaires bien placés (genre en début de fonction et sur les portions de code critiques) aurait pris 10x moins de temps, oui je trouve ça un peu idiot.
[^] # Re: En tant que BSDiste je me permets de participer au troll
Posté par gaaaaaAab . Évalué à 1.
http://thedailywtf.com/Comments/Documentation-Done-Right.asp(...)
[^] # Re: En tant que BSDiste je me permets de participer au troll
Posté par j_kerviel . É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 lasher . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: En tant que BSDiste je me permets de participer au troll
Posté par Tonton Th (Mastodon) . Évalué à 3.
Mais est-ce que ça existe, ça ?
# Patrick_G a inventé le saut spacio-temporel !
Posté par GoNoGo . Évalué à 3.
[^] # Re: Patrick_G a inventé le saut spacio-temporel !
Posté par Julien Gilbert . Évalué à 3.
Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
[^] # Re: Patrick_G a inventé le saut spacio-temporel !
Posté par windu.2b . Évalué à 10.
[^] # Re: Patrick_G a inventé le saut spacio-temporel !
Posté par Julien Gilbert . Évalué à 2.
Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
[^] # Re: Patrick_G a inventé le saut spacio-temporel !
Posté par fearan . Évalué à 2.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Patrick_G a inventé le saut spacio-temporel !
Posté par Erus_Iluvatar . Évalué à 4.
[^] # Re: Patrick_G a inventé le saut spacio-temporel !
Posté par Seb . Évalué à 2.
[^] # Re: Patrick_G a inventé le saut spatio-temporel !
Posté par insert_coincoin . Évalué à 1.
# Vous devez entrer un sujet et un commentaire
Posté par gaston . Évalué à 10.
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 patrick_g (site web personnel) . Évalué à 3.
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 gaston . É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 zebra3 . Évalué à -1.
Ç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 Sylvain Sauvage . Évalué à 8.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par zebra3 . Évalué à -2.
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 Guillaume Knispel . Évalué à 7.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par zebra3 . Évalué à 2.
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 Tonton Th (Mastodon) . Évalué à 2.
C'est quand même un peu ce qu'il faut faire pour porter aseqnet dans OpenBSD, mais tcpdump aide bien aussi, il faut avouer.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par barmic . Évalué à 5.
De la doc c'est pas compliqué comme principe. C'est un peu comme si pour les normes on se contentait de faire une preuve de concept ou une implémentation de référence.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Ph Husson (site web personnel) . Évalué à 5.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Tonton Th (Mastodon) . Évalué à 2.
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 dinomasque . Évalué à 3.
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 Albert_ . Évalué à 5.
[^] # Re: GNU ou POSIX ?
Posté par dinomasque . Évalué à 4.
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 rewind (Mastodon) . Évalué à 10.
- 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 zebra3 . Évalué à 6.
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 gaston . Évalué à 6.
Oh, d'ici la ca aura été remplacé par upstart^Wrunit^Winitng^Winitflavorofthemonth...
[^] # Re: Au bûcher !
Posté par zebra3 . Évalué à 3.
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 rewind (Mastodon) . Évalué à 5.
# Mauvais conseil
Posté par Patrick Lamaizière (site web personnel) . Évalué à 9.
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 M . Évalué à 6.
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 totof2000 . Évalué à 3.
[^] # Re: posix + linux
Posté par patrick_g (site web personnel) . Évalué à 7.
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 totof2000 . Évalué à 2.
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 claudex . Évalué à 2.
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 gaston . Évalué à 2.
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 claudex . Évalué à 6.
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 FreeB5D . Évalué à 3.
Ce qui est le cas de KDE, surtout pour KDE4 (Solid, Phonon, etc.)
# Mouhouhouahahaha
Posté par houra . Évalué à -4.
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 zebra3 . Évalué à 3.
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 houra . Évalué à 1.
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 zebra3 . Évalué à 2.
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 houra . Évalué à 3.
kldunload radeon
kldunload: can't unload radeon: device busy.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Mouhouhouahahaha
Posté par Tonton Th (Mastodon) . Évalué à 3.
Ah ah ah, ça me rappelle un vieux troll fmbl sur le déchargement du module son.
[^] # Re: Mouhouhouahahaha
Posté par zebra3 . Évalué à 4.
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 houra . Évalué à -4.
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
[^] # Re: Mouhouhouahahaha
Posté par Moonz . Évalué à 8.
[^] # Re: Mouhouhouahahaha
Posté par houra . Évalué à 0.
Et je sais pas, j'ai jamais vu une seule distribution Linux en faire de " la pub "
une recherche google "Linux kmod" me donne des résultats qui sont tout sauf explicatifs .
si tu veux savoir un peu plus ce qu'est le KLD de FreeBSD ça commence ici: ( 1er et 3eme lien sur une recherche Google FreeBSD KLD )
http://www.freebsd.org/doc/fr/books/developers-handbook/x172(...)
Et si t'en veux plus, tu fais une recherche FreeBSD kldload et en premier lien t'as :
http://www.freebsd.org/cgi/man.cgi?query=kldload&sektion(...)
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Mouhouhouahahaha
Posté par daimrod . Évalué à 7.
[^] # Re: Mouhouhouahahaha
Posté par Moonz . Évalué à 4.
http://linux.die.net/man/8/modprobe
http://linux.die.net/man/8/rmmod
De rien.
[^] # Re: Mouhouhouahahaha
Posté par houra . Évalué à 1.
mais si mais si.
par contre du coup je viens de faire un lsmod ( ubuntu 32 )...
Je comprends pourquoi on dit " le bazaar ". :)
Sedullus dux et princeps Lemovicum occiditur
# Post mal fichu ou troll?
Posté par reno . Évalué à 3.
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 Krunch (site web personnel) . Évalué à 3.
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 Littleboy . Évalué à 4.
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 Sébastien Wilmet . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.