et parfois des milliers de caractères distincts (CJK). Ça marche dans la vie réelle.
Ca marche tellement bien que dans la vie réelle le gouvernement chinois a été obligé d'adjoindre à unicode des metas supplémentaires et de créer son propre système d'encoding qui incorpore ces métas.
Et là on parle de 120 000 signes d'une vraie langue d'un vrai pays, pas des émoticones rigolotes qu'on pourrait rajouter en plus.
Et on parle du chinois moderne aussi, pas du chinois classique ni des différents patois (parlés par plusieurs millions de personnes à chaque fois) et de leurs accentuations spécifique.
Mais bon c'est surement que les Chinois s'y sont mal pris, et qu'il n'y aura aucun problème quand on aura des documents qui peuvent potentiellement recouvrir 20 ou 30 millions de signes.
Sur ce je vous laisse, restez bien sur vos position de "ca marche parceque ca marche parceque ca marchera" et ne vous confrontez pas au monde du dehors.
Rappel : On parle de points unicode qui codent des emoticones rigolotes comme "woman with bunny ears". Je te jure que je n'ai jamais installé de polices de caractères qui contiennent cette glyphe.
Pour les documents du monde réel (càd tous sauf les .po), il suffit d'un nombre très limité de signes pour représenter le document.
Rappel : On parle de points unicode qui codent des emoticones rigolotes comme "woman with bunny ears", et de la pertinence qu'il y a à mettre ce type de caractères dans unicode au risque de faire exploser le nombre de caractères utilisés dans les documents du monde réel.
Si tu t'appelles Keith Packard tu résous le problème de façon élégante en écrivant Fontconfig.
Font config ne résout pas le problème, il permet juste une classification hiérarchique des fontes. Pour que ce soit utile il faut que le logiciel sache utiliser cette classification (ca va c'est pas trop dur) et que le document possède des métas qui vont lui indiquer dans quelle hiérarchie aller taper si il n'a pas la police exacte. Sans ses deux éléments le logiciel est obligé de recourir à la force brute pour associer le glyphe U+XXXXXXXX avec le caractère "woman with bunny ears".
Donc en gros, à la place d'UTF-8 il faut se farcir des gros hacks.
Si c'est prévu dans la norme/le format je ne vois pas en quoi c'est un hack.
Et c'est tant mieux! C'est au logiciel de se débrouiller, pas à toi! C'est de la bidouille.
Dans un cas c'est au logiciel de l'auteur et dans l'autre cas c'est au logiciel du lecteur. Le truc est que si l'auteur est supposé savoir ce qu'il a voulu dire - le lecteur n'a pas forcément cette connaissance.
Bref, tu mélanges le codage d'un signe avec l'affichage d'un signe, tu mélanges le "savoir ce que c'est" avec le "comment on l'affiche", à partir de la il est impossible de discuter.
Non je ne mélange pas. L'utilisateur lambda il va être vachement content de savoir que le rectangle bordée de noir qu'il voit est en fait le caractère U+2868FFAE.
Non. Il peuvent dans un cas exceptionnel : que tous les caractères du message soient dans la même locale
C'est marrant j'ai une pile de documments ISO qui précisent les changement de locales et qui sont lisibles par toutes les personnes qui en ont besoin - Des docs SGML par exemple.
(on s'en fou de la police de caractère, tu mélanges, la police de caractère c'est pour la présentation, si tu n'as pas la même c'est pas grave)
On est en train de parler de la lisibilité pour des utilisateurs dans un monde ou tout est en dans un standard qui comporte 42 gazillions de signes. Donc aucune police ne représentera tous les signes. Donc on force l'installation de polices spécifiques pour pouvoir lire un texte. Donc la police, si tu n'as pas la même tu ne peux pas comprendre le document est c'est grave.
En ISO je sais comment faire pour dire "cette parte de texte utilise telle locale, si tu n'as pas la police "machin" prend au moins une police compatible". Et ce même si le type décide d'écrire en Klingon et en Quenya.
En UTF-X je ne sais pas faire. C'est au logiciel de se démerder pour trouver dans toutes les polices installées lesquelles peuvent convenir.
Si il y a trente polices installées ca va, si il y en a 300 c'est le bazar.
Exactement comme avant. Si tu veux lire des documents en coréen, vaut mieux que tu aies une police qui affiche le coréen... La différence, c'est qu'avant, le logiciel ne pouvait pas deviner quelle langue était utilisée.
On disposait quand même d'un système qui permettait de savoir quelle type de police pouvait répondre au problème. Par exemple en ISO 8859-15 défini un nombre finalement assez limité de caractères, de fait deux personnes en ISO peuvent échanger de smessages assez simplement.
As-tu tapé des formules de math dans les années 90, quand la seule solution était la police Symbol ?.
Oui. C'était d'ailleurs à l'époque ce qui m'a fait passer à Latex. Ceci étant la frappe de formules entières n'est pas frnachement résolu par Unicode non plus. Les caractères unicodes sont des entités indépendante, et à ma connaissance les interdépendances de caractères doivent être gérées séparément (par exemple la barre de la racine carré ou la hauteur du symbole d'intégration)
Aujourd'hui, tu peux mélanger toutes les écritures sans changer de police, et c'est le logiciel qui trouve quelle police sait afficher quel caractère.
Généralement le logiciel choisi parmis les quelques polices Universelle/unicode/multiglyphes qu'il possède celle qui pourrait convenir. Maintenant je rapelle que le sujet du débat ici présent est :
42 gazillions de caractères rigolos est-ce que ca sert à quelque chose ?
Je sais bien que ce n'est pas très difficile d'afficher du sanskrit, du japonais et du tibétain dans la même page, mais si on commence à mettre les émoticones, les glyphes égyptiennes, les symboles graphset, les repérages sécurité/incendie etc. comment fait-on.
Je ne vois pas une seule police contenir tous ces glyphes, je ne vois pas non plus les applis se farcir le scan de 300 polices spécialisées pour trouver le caractère qui va bien.
Grosso-modo plus on rajoute de caractères qui n'ont rien à voir avec des caractères alphabétiques, plus on prend le risque de se retrouver avec des problèmes de lisibilité des documents.
Quand un correspondant coréen m'écrit, je peux m'attendre à devoir installer une police qui prend en charge les caractères coréens si je n'en ai pas déjà une.
Quand un architecte m'écrit je ne veux pas chercher dans toutes les polices existante laquelle me permet de voir le caractères en position 6 de la ligne 22.
Pour éviter que l'on se retrouve coincés il vaut mieux laisser unicode tel qu'il est en minimisant les caratères admis le plus possible.
Donc non, tes polices de caractères ne pèseront pas plus lourd à mesure qu'unicode grandira.
Sans vouloir être méchant, Le but d'unicode est quand même de fournir un minimum d'interoperabilité et de lisibilité pour le lecteur final.
Aucune police saine d'esprit ne va s'amuser à implémenter des 42 gazillions de signes actuellement inclus dans unicode. On se retrouve donc à devoir installer sur son ordi une floppée de police pour couvrir les caractères qui nous interressent. Avec 42 gazillions de signe disponibles, on risque d'avoir des polices différentes pour chaque pays/corps de métier.
Si demain je reçois un document écrit avec (entre autres) trois polices que je ne possède pas, qui sont utilisés pour afficher des caractères rigolos, comment va faire mon ordi pour m'afficher des caractères au moins pseudo-corrects ?
a) Il va scanner toutes les polices installées à la recherche d'une d'entre elle qui possèderait les caractères voulus.
b) Il va afficher des gros rectangles baveux et laisser l'utilisateur rechercher parmis les 850 polices qu'il possède laquelle affiche ce #@!* de caractère.
c) On s'arrange pour que le poste du créateur du doc ajoute des infos sur les caractères de la police de façon à accélerer la recherche (par exemple indication : ISO8859-15 pour le caractère € - Solution qui ferait bien rire tout le monde)
d) Il demande votre numéro de carte de crédit pour acheter les polices qui vous manquent directement chez les fabriquants.
J'ai de plus en plus l'impression qu'unicode est en train de renforcer les problèmes qu'il est supposé résoudre....
Et à partir d'un certain niveau de déformation / transformation, ça doit pouvoir être considéré comme une œuvre originale (je crois qu'on parle d’œuvre dérivée ou qq chose comme ça).
Déjà c'est pas parceque ca devient une oeuvre originale que tu n'es pas tenu de t'aquitter des droits d'auteur sur l'oeuvre qui sert de base. Demande à Moby, Daft Punk et autres remixeurs/dj ce qu'ils en pensent.
Ensuite si on ajoute du bruit ou de la rotation chromatique ou qu'on modifie les bits de poids faible dans le but de boulverser complètement la transformée de Fourrier et fiche en l'air les logiciels d'analyse de masse, je doute fort que l'on puisse considérer celà comme une oeuvre...
<i>Même si tu as un buffer overflow, il faut passer par dessus la protection nx, par dessus la randomisation d'adresse, voir les protections par canary. C'est déjà une autre pair de manche.</i>
Si on se place dans le cas d'un auteur/contributeur malveillant, c'est un jeu d'enfant de faire du code dont on sait d'avance ou l'erreur va tomber, comment le buffer overflow va déborder etc. Et c'est particulièrement pernicieux à trouver. Passé deux out trois niveaux d'indirections et quelques changement de format plus tard (its a long long way to tipperary) qui va aller vérifier que ton tableau fait bien N éléments et pas N-1.
Tu peux même pousser le vice jusqu'à coder un canary à la fin du tableau ... de N éléments.
Si quelqu'un te choppe (très très peu probable, mais pourquoi pas) tu peux toujours plaider non coupable, la faute d'inattention qui t'a fait sauter un élément, dans un tableau alloué quatre pages de code plus haut (voire dans un include, d'include).
Après il suffit que le débordement aille gentiment écraser l'élément suivant dans une structure (tu sais ou ça tombe) et plaf un pointeur de fonction/une addresse de retour qui part aux fraises.
Pour finir tu envois un packet/fichier/flux avec un élément de trop au bon endroit et le malware s'active sans que personne ne puisse le voir à moins d'une analyse poussée du code.
NX ne verra rien, pointeur de fonction ou pointeur tout court, si on retourne bien dans la zone d’exécution (si tant est qu'on l'ai quittée) on aura son feu vert.
La randomisation d'adresse tombe à plat puis que je corromps des données allouées au sein de la même structure.
Et le canary posé posé en fin de structure ne sera même pas chatouillé par une corruption qui se produit trop en aval.
Et là c'est un exemple de méthode parmi des centaines qui passent largement au dessus des protections génériques et qui sont quasiment insensibles au fuzzing.
Un mec qui décide de créer une faille exprès dans son code, il a largement les moyens de la planquer tranquillement et de l'activer à la demande. Les techniques mentionnées marchent principalement contre les méchants qui essayent d'abuser un code écrit honnêtement.
Et voilà encore un journal de PAAAATRICK qui tombe à plat. Ça quand il s'agit de faire du copier/coller de vingt pages pour de la dépêche d'avant plan et rafler un abonnement d'un an à "Libre et Gratuit magazine" il est toujours là, mais pour faire du troll de qualité il n'y a plus personne.
Déjà pour faire court, les moules qui trollent le vendredi sont encore sous le choc du changement de bouchot. C'est fragile ces bêtes là, quand on leur change leurs habitudes ça doit se ré-acclimater. Là je suis en train de poster mon commentaire dans une interface kikoolol avec une pub à peine déguisée sur la gauche de la zone de texte, un léger dégradé et des icônes trop kawai dans la barre d'outil façon Windows. Je te prie de croire que c'est dur à supporter.
Ensuite tu as choisi ton camps. T'es modérateur, et ca veut dire que tu peux pas troller. Du moins pas exprès : on est jamais à l'abri de la faute de bon gout qui pousse à repeindre le site en vert à ma moindre sortie d'une distrib écolo-germanique, ni d'un manque de jugeote fondamentale qui fait penser que la meilleure chose qui soit arrivé au libre c'est quand Mark Méritefusée a revendu sa boite aux spoofeurs de DNS pour faire de l'élevage d'animaux adjectivés. Mais un modérateur qui trolle sciemment, depuis son vrai compte, et sur le site qu'il modère, ca porte un nom : KADREG. Tu connais Kadreg ? Tu veux devenir comme lui ? Si vraiment tu dois troller, ais au moins la décence de le faire depuis un compte multi (qui sont interdits, mais les trolls aussi alors bon...). Prends exemple sur Amaury : lui quand il doit cracher son venin sur les dérives, pourtant rare, de notre très saint père le Pape, il le fait depuis un compte dédié. Ça préserve le crédibilité du site lors de l'audit annuel par Famille de France.
Ensuite parlons du troll à proprement dit, nous avons une boite qui vend du GPL depuis des lustres, qui a fait croire à une génération entière de linuxien que ses pré-bétas castrées étaient en fait une distrib à part entière gérée par une communauté indépendante, et dont le soucis principal est d'être certifié par Oracle chaque année, une boite donc qui décide de faire du patchage imbitable pour pas qu'on arrive à comprendre trop vite comment les copier.
Honnêtement à part les jeunots qui vivent encore à bisounours land, ça surprend quelqu'un ?
Comme tu le disais toi même, Red Hat il sont au top of the top quand il s'agit de savoir comment faire de l'argent tout en jouant franc-jeu avec la GPL. Donc ils sont les mieux placés pour savoir que ce n'est pas possible. Pendant des années ils ont pris l'option ou ils ne gagnaient pas d'argent mais suçaient celui des investisseurs. En période de crise, quand l'investisseur se fait aussi rare que le Beluga dans le fleuve jaune ça devient dur de jouer à ce jeu très longtemps. Donc plan B : on arrête de jouer franc-jeu. Ah ben oui à force de passer des heures dans les locaux d'Oracle pour faire certifier leur biniou, il fallait bien s'attendre à ce qu'ils s'inspirent d'un business model successfull un jour ou l'autre.
Parce que voyons les choses de façon factuelle, quand ton plan de croissance est basé sur un produit dont le secret de fabrication est distribué publiquement d'une part, et sur 3000 employés qu'on peut débaucher le lendemain matin en leur promettant de leur donner un boulot encore plus autistisant sur le kernel linux d'autre part, ben t'es mal.
Donc RHEL sapusaipalibre, enfin pas tout à fait et pas comme il faudrait, on s'en moque un peu. Au final les applis Oracles ne tourneront peut-être plus aussi bien sous CentOS... On va pas pleurer non plus.
Donc non Red Hat est pas en train de devenir Evil, juste lucide. Mais c'est vrai que la lucidité a jamais vraiment aidé GNU/Linux au final.
C'est 75% de la reversion que fait Amazon quand on achète chez eux via cette méthode. Donc ni 75% du CA, ni 75% du bénéfice amazon.
Je ne connais pas les accords passés, mais ca doit être un truc genre Amazon reverse 10 à 30% de son bénéfice sur les produits vendus par l'interface Banshee. Donc c'est 75% des 10 à 30 % des X% de bénéfice par rapport au prix de vente. En vrai ca doit faire entre 1 et 3% du prix de vente.
Grande salle bien vide, les grosses huiles de nokia (6 ou 7 au maximum) regardent la mine dépitée les graphs des ventes de téléphone mobile dans le monde.
- "On s'est encore fait bouffer deux points par Apple, ca commence à aller mal"
- "Qu'est-ce que tu veux, les gens veulent du smartphone maintenant"
- "Ben on pourrait faire du smartphone alors..."
- "Ca fait dix ans qu'on essaye, il y a tout le budget R&D qui y passe et ca rapporte que dalle"
- "On pourrait faire des portables android, ca couperait la R&D"
- "Ouais bien sur, avec 70% des smartphone vendus sous android dans le monde, on va être en super position pour négocier avec Google si ils décident de péter un plomb..."
Long silence géné...
- "On en est ou sur les brevets GSM avec Apple"
- "Dans l'os, il va falloir attendre le procès, l'appel etc."
- "A la vitesse à laquelle on brule notre trésorerie, on va pas tenir longtemps si on arrive pas à sortir un produit révolutionnaire, ou si on trouve pas un partenaire pour nous aider"
- "Ben voyons, un partenaire qui va nous aider à lutter contre Apple tout en contrant Google et qui va financer notre trésorerie. Tu veux pas qu'il nous file un OS pour mobile tout fait aussi pendant que tu y es ?"
Ca serait tellement vrai si seulement le script ne se contentait que de faire des commandes shell en succession... C'est loin d'être le cas. On sort pas l'artillerie uniquement pour executer de la commande shell à la pelle.
Oui mais généralement il appellent quand même des fonctions shell au final, comme tu le faisais remarquer. Et pour peu qu'on sache un peu lire du code, même si on ne comprend pas les fonctions shell appelées, on arrive généralement à recomposer le script avec un minimum d'effort.
Avec une forte intégration POSIX au millieu, ca devient beaucoup plus complexe. Déjà il faut passer par l'étape programmation pour immiter le comportement, et ensuite il faut comprendre véritablement ce qui se passe sous peine de se ramasser à l'execution.
Ca n'a rien d'une propriété du langage ou de l'outil, mais de la programmation. Je peux sortir des scripts Perl imbitables que ca n'y changerait rien. De même pour Python.
Sur un script perl imbitable, ou sur un script python imbitable on arrive toujours à savoir ce qui se passe en remplaçant une execution shell par un echo vers fichier. C'est long et casse pied, mais pas à pas on finit par avoir la liste des commandes que le script veut passer.
Tu discutes d'une implémentation qui n'existe pas, en raisonnant sur des hypothèses qui sont tiennes, après avoir relu un article sur linuxfr. Je t'invite donc dans ce cas à poser tes questions sur tech-userlevel@NetBSD.org et tech-toolchain@NetBSD.org.
STOP. Le projet consiste à mettre dans le système de base NetBSD un iterpreteur LUA avec une forte intégration au système POSIX sous jacent. C'est pas une hypothèse que je fais sur un coup de tête, c'est le but du projet.
Les exemples donnés par le créateur du projet sont la refonte du système d'install, la modification des scripts d'init et le changement d'option du client DHCP. J'invente rien, c'est écrit noir sur blanc dans les deux liens donnés dans le journal.
Pourrais-tu montrer les scripts d'install en question? Et les scripts de conf? Si non, encore une fois, pures spéculations. C'est de la critique gratuite pour satisfaire un besoin de critiquer...
Si le système d'install et les scripts d'init passent en LUA, ce qui une fois de plus est le but annoncé du projet, je ne vois pas comment je pourrais me passer d'apprendre LUA pour pouvoir mettre les mains dans le camboui. Or il se trouve que mettre les mains dans le camboui c'est mon métier.
Quels points forts?
Le monde Unix effectue traditionellement la séparation des droits au niveau fichier, le monde windows le fait au niveau interface.
Dans les deux cas il y a des avantages et des défauts.
Sous Unix le défaut est que pour faire fonctionner un système complexe il faut donner des droits dans tous les sens, avec des serveurs qui se lancent en root puis abandonnent progressivement leurs privilèges.
Sous windows le défaut est que pour faire fonctionner un système complexe il faut installer et lier whatdouzemille framework même si au final on se sert de 10% des possibilités des frameworks concernés.
Sous Unix l'avantage est que les configs, scripts et autre conneries sont déplaceables et maléables à volonté. Une fois qu'on a une config qui marche, on a la quasi certitude qu'elle va marcher sous tout un tas de système raisonnablement posix. Et on peut le déplacer de droite à gauche sans trop de soucis.
Sous windows l'avantage est l'intégration. Vu qu'on ramasse tout un bloc de fonctions d'un coup on a au moins la certitude qu'on ne va pas avoir à se retourner le crane si un jour on a besoin d'ajouter ou d'enlever une fonctionnalité.Et au moins on a pas à se prendre la tête pour savoir comment tout çà va dialoguer ensemble.
"Le monde Unix" dont tu parles est mort il y a quelques années maintenant, ou alors au stade de coma dépassé.
Oui. Enfin bon faut pas dire çà aux banques, assurances, instituts de recherche et autres systèmes experts.
C'est amusant, tout ce que tu cites comme des défauts sont pour moi des qualités et réciproquement.
Par exemple le script Python qui ne fait "que" glue. Ca veut dire que si je ne veux pas de python sur ma machine, il suffit dans 90% des cas de faire du copier coller les éléments shell pour passer le script à la main.
Par contre avec LUA je vais être obligé de me plonger dans le truc pour faire du debug de script si je veux le faire fonctionner à la main. Ca peut aussi virer au jeu de piste avec des fonctions qui apellent d'autres fonctions LUA qui vont chercher des infos à droite, à gauche (base de données, device etc.)
Bref tout çà à analyser pour pouvoir passer sereinement quatre lignes de scripts...
J'ai connu le temps ou pour exploiter des comptes avec un contexte Kerberos, il fallait jouer avec des variables d'environnement et des fichiers temporaires pour que ca marche, parce que la GSSAPI n'était pas exploitable dans Python... et quand on voit la gueule de l'API, on comprend pourquoi.
Je vais peut être dire une connerie, mais c'était pas un contexte Kerberos SAMBA avec des certificats auto-signés dans le LDAP ? Parce qu'en utilisation authentification sur un réseau pur Unix Kerberos V4 et V5 ca a toujours plutôt bien tourné. Pour les bindings python, j'en ai jamais eu besoin donc ca ne m'a jamais manqué.
Autre exemple: éditer un fichier. Tu souhaites modifier /etc/motd en fonction de la journée. Aujourd'hui: tâche cron obligatoire, qui va appeler un script Perl (parce que le gars préférait Perl), qui va jouer au cat/grep/sed/ ~= <> FILE dedans.
Alors ca tu vois c'est EXACTEMENT ce qui fait que je ne veux pas de Lua dans mon BSD. Si Aujourd'hui j'ai un truc qui tombe tous les jours à 19h dans mon système et qui me fait chier (et bien oui, dans la vraie vie on a pas toujours installé les serveurs qu'on maintient), ben je vais dans le cron, je le tue et fin de l'histoire. Si demain ce truc peut être n'importe ou dans mon système, éventuellement régénéré par tel ou tel serveur si je le détruis, je vais devenir dingue.
Si tu veux te convaincre de l'utilité de la chose: je t'invite à lire le code source de net-snmp.
Code source != fichier de config. Si le mec veut faire un programme, une interface graphique, un concentrateur de données etc. en Lua, qu'il y aille. Aucun soucis avec moi.
Là il s'agit de fichiers de conf, des trucs qui peuvent déjà avoir pas mal d'incidence en aval (genre une erreur dans php.ini qui va joyeusement vautrer MySQL et Apache). A ceci on vient rajouter une possibilité d'incidence en amont (genre le script qui remplace mon php.ini va aller faire mumuse avec mes locales, mes params mémoire ou que sais-je encore). Là c'est non. Tout de suite. En plus on rajoute un interpreteur LUA dans mes serveurs, lequel interpreteur va avoir besoin de droits spécifiques pour exécuter tel ou tel partie du script de conf, dans le kernel parce que c'est plus fun.
Personne n'obligera à les utiliser.
Si les scripts d'install par défaut et les scripts de conf font du LUA, je ne vois pas comment je pourrais ne pas les utiliser à part en changeant de métier.
Il faut bien admettre que la tendance va vers cela
Oui, tout le monde veut copier le système windows/mac avec du call-back reporting dans tous les sens SAUF QUE traditionellement Unix/BSD/Linux sont monolithiques avec une logique de séparation et que NT/OS X sont des micro-kernel avec une logique de bloc.
Rien ne m'empêche sous Linux de prendre 300 API différentes au sein du même programme et de donner mes droits aux utilisateurs device par device, par contre sous windows, avec les objets COM par exemple, j'ai soit accès au bloc API ou pas, et si il y a des limitations elles sont gérés par le bloc, fonction par fonction, et pas par le système lui même. Par contre je peux me brosser pour faire tourner en même temps IIS 6.0 avec .net 2.0 et IIS 7.0 avec .net 3.5
(N.B : je sais que l'on peut faire du bloc en unix et faire tourner 14 IIs en même temps sous windows, mais c'est pas vraiment la philosophie du truc)
Bref c'est une tendance que je n'aime pas. On aurait tout à gagner à ce focaliser sur les points forts du monde Unix plutôt que de chercher à copier des systèmes dont les choix de départ sont très différents des nôtres.
C'est une vision de Linuxien ça. Le basesys d'un BSD forme un tout cohérent. Quand tu utilises le MDA du basesys, il n'est pas question de mettre à jour mysql-client-lib-2.6.7-1294.debian54.libc6.2 pour que ca marche/marche pas. Quand on met à jour, on met à jour l'ensemble du basesys, pas le MDA d'un coté et les "modules" d'un autre, avec une surprise au prochain redémarrage du service.
Je suis BSDiste. J'utilise principalement FreeBSD et OpenBSD (donc je connais moins bien NetBSD), mais je peux te dire que le basesys ne prend pas en charge les configuration avancées de type :
- Changement de MDA/MTA
- Authentification LDAP pour tout le monde (virtuel, réel etc. sauf root/wheel)
- Modification profonde de la config de base des Bases de données (genre load balancing, changement des réglages de moteurs de base de données, outils d'instrumentations intégrés etc.)
- PHP (oui PHP c'est juste l'horreur à suivre au niveau packages, avec des dépendances à tous les étages etc.)
Bref tout çà pour dire que même si j'ai une grosse confiance en les devs BSD, je ne vois pas comment leur projet de script peut ne pas partir en vrille au bout d'un moment.
Sous Linux ça a pris environ cinq ans (2004-2009 à peu près) pour que des éléments simple de config (genre les modes supportés par le serveur X) deviennent inéditables/inmodifiables parceque des scripts qui génèrent des scripts qui génèrent des scripts viennent t'écraser ta config à chaque mise à jour, voire à chaque reboot/fermeture violente de l'appli.
Donc oui, chat échaudé craint l'eau froide, le script qui configure automagiquement mes serveurs/params kernel j'en veux pas.
On va bientôt avoir des macro M4 qui via autoconf génèrent des fichiers XML avec du script LUA qui connecte des bases de données...
J'ai vraiment du mal à voir l'interet qu'il peut y avoir à foutre un parseur XML et un interpreteur LUA (même si ils sont tout petits) dans un serveur qui n'a au final rien à foutre de l'un ou de l'autre (au hasard un MDA).
J'attends avec impatience le moment ou je devrait mettre à jour MySQL-Client pour pouvoir recevoir mes mails...
N.B : j'aimerais bien savoir comment la sql query est secured aussi. Relation de confiance sur l'utilisateur/machhine ou bien il y a un autre fichier avec un mot de passe quelque part ?
Theora est tout sauf au niveau de h264 hein, cette comparaison elle dit que theora, sur un fichier donné, avec des options choisies aux petits oigons par le dév, et une keyframe toutes les 10 secondes, arrive à rivaliser avec h264 Baseline, avec les paramètres d'encodage de youtube ie pas adaptés à cette vidéo en particulier, et une keyframe toutes les secondes.
Il n'y a pas eu d'options choisies aux petits oignons, il s'agit d'un bête ffmpeg2theora brut de fonderie avec une image clef forcée minimum toutes les 170 images (contre toutes les 61 à l'époque pour Youtube)
Donc oui il y a un avantage donné à Theora mais il n'est pas aussi délirant que ce qu'on peut penser.
Ceci étant Theora reste à la traine sur le très bas bitrate. Mais passé 250kb/s ca n'est plus aussi évident.
Fais le test avec une version récente de ffmpeg2theora tu risques d'être surpris.
Ceci étant les benchmarks sont un véritable problème à mettre en place, surtout sur de la vidéo, surtout sur des codecs qui utilisent de la compression psycho-visuelle.
Généralement on ne s'en sort bien qu'avec une comparaison en double aveugle. Mais c'est compliqué à mettre en place.
Faut juste accepter de cracher les royalties demandées par le MPEG pour pouvoir l'utiliser, exit les logiciels libres, les petites structures etc ...
Pas de facturation en dessous de 100 000 unités (quelque soit le façon de compter les unités : matériel physique, abonné, paiement au titre, cible pour un broadcast)
Après c'est maximum 0.20$ par unité/abonné/titre supplémentaire.
Pour les logiciels libre distribués gratuitement, c'est gratuit coté AVC (pas coté diffusion par contre, ie si vous diffusez du contenu avec des logiciels libres vous êtes quand même tenu à la redevance).
Donc on va dire que les logiciels libre sont bloqués (pour certains) par leur licence, mais pas par des questions d'argent.
En ce qui concerne les petites structures (même les toutes toutes petites) elles peuvent souvent générer 0.20$ de marge par vente. Surtout quand les 100 000 premières unités par an sont gratuites. Donc au final on est très loin des brevets associés à des sommes pharaoniques, voire bloqués vissés en exploitation que l'on trouve sous tous les autres formats ou presque.
Pour l'instant la seule alternative à H264 est Theora. Les deux codecs progressent de concert, et même si la qualité de Theora (implémentation ffmpeg) est desormais au niveau de H264 http://people.xiph.org/~greg/video/ytcompare/comparison.htmlhttp://people.xiph.org/~maikmerten/youtube/ il a encore du mal sur les images les plus complexes à encoder (pluie violente, pan scan avec un ciel étoilé, ressac des vagues sur la plage etc.)
Maintenant il semblerait (je ne suis pas en position pour juger) que Theora soit plus complexe à encoder/decoder que H264. Donc, même pour une petite boite, il faut que cette puissance de calcul supplémentaire nécessaire lui coute moins de 0,20cts par client pour que Theora devienne plus interressant que H264.
Pas facile du tout...
Bref H264 le libre n'en veut pas pour des raisons compréhensibles (avec lesquelles on peut être en désaccord) - mais pas pour un problème d'argent.
Tu fais exprès ou t'es juste malcomprenant ?
ouvert dans le sens "tout le monde est libre d'utiliser le standard comme bon lui semble et sans aucune restriction".
Loin de moi l'idée de vouloir défendre Zenitram, mais j'ai la (légère) sensation que tu confonds un certain nombre de choses :
- Le standard
- L'implémentation
- La licence de l'implémentation
Le standard c'est soit un standard de fait (ie un truc que tout le monde utilise même si il n'a jamais été normé proprement), soit un standard connu, soit un standard normé. Dans tous les cas c'est une suite de mots qui traduisent un comportement attendu face à un évènement, ou un format de donnée.
Cette suite de mot tu peux en faire ce que tu veux. La publier en affiche 4 par 3 dans le métro, l'imprimer en vert, faire des collages pour une oeuvre d'art ou encore la tagguer sur les murs de ta chambre. Je ne pense pas que qui que ce soit y verra le moindre problème.
Généralement on parle de standard ouvert quand
a - le standard est normé, c'est à dire déposé sous forme de RFC
b - le standard est complet, c'est à dire que l'ensemble des possibilité de la technologie lié directement au standard est disponible dans les doccuments de la norme (par exemple pour le H264 on possède les algorithmes de décodage ET d'encodage)
c - le standard est non encombré, c'est à dire que le standard ne repose pas sur une autre techno qui elle n'est pas normée/connue/publiée. Un standard qui reposerait (par exemple) sur la gestion d'objet OLE par les bibliothèques MS Office ne pourrait pas être considéré comme ouvert.
L'implémentation est un problème technique que doit résoudre le programmeur pour respecter le standard. Cette implémentation n'est que très rarement sans restriction. Déjà elle se doit de fonctionner, de préférence sur des machines qui existent déjà et de façon reproductible. On peut dire que si le standard est bien fait le programmeur a le choix du langage (dans une certaine limite - pas la peine de faire du H264 en MS basic 2.0) et de la plateforme cible (dans une certaine limite aussi - il faut que la plateforme puisse mathématiquement traiter les algos et éventuellement afficher les résultats). Pour le reste il est extrêmement restreint et ne peut pas faire comme bon lui semble, sinon il va sortir du standard. Ses choix principaux vont se limiter à implémenter ou non les fonctionnalités potentielles du standard (quand il s'agit d'un standard publié).
La licence de l'implémentation dépend pour une part de la volonté du programmeur et pour une autre part des brevets et accords qui planent sur les algorithmes et technologies du standard. A titre d'information si le programmeur décide de prendre la GPL comme licence sur un standard sans aucun brevet, ben il y aura là aussi des restrictions et tu ne pourras pas faire comme bon te semble, ni avec le code source, ni avec le compilé...
Après on a tous sa définition du mot ouvert (et on va pas parler du mot libre hein...) Personnellement la seule chose qui me dérange dans le MPEG-Standardisation Group est le somme à payer pour pouvoir rentrer dans le groupe et donc participer aux discussions sur la création et les choix techniques des nouveaux codecs.
C'est marrant les player mplayer,vlc, xine, totem, aviplay ne consomme pas 100% de CPU
Tu confonds deux choses
a) Être bourrin ou gentil lors de l'execution de ton appli (combien de locks tu mets, combien d'interrupts tu goinfres, si tu es compatible avec te petits camarades, combien d'allocation tu fais etc.)
b) Être consomateur de ressources disponibles.
En multimédia si tu veux limiter b) tu as intéret à forcer a le plus possible.
De plus généralement les gens ne regardent pas plusieurs vidéos en même temps. Fais le test un jour de lancer deux vidéos simultanément. La première devrait être fluide et le rester, la seconde va être à l'agonie.
C'est pour ça que quelque soit la puissance du CPU flash est toujours à 100%?
Non ca c'est juste que Flash est mal compilé sur ta machine, chez moi flash prend 20% de CPU sur un E3500 avec une CG nvidia 8700 (pilotes proprios) lors de la lecture d'une video HD 1080p. Tu a sun problème avec ton mode de rendu, c'est tout.
Elle va surtout faire du son, ce qui est mieux que pas de son du tout, ou juste le son de flash.
Non, la SDL ne fait pas de son, elle envoit un flux vers un device. Si c'est un device audio ALSA, le pilote Alsa le transformera en son, si c'est un fichier tu auras un fichier wav à la fin.
S'il tient absolument à avoir une sychro temps réel alors il se coltine jack plutôt que SDL
Jack ne fais pas de son non plus, il sert juste à mettre à la queue leu leu des devices. Si un des devices de la chaine est un device son Alsa, Alsa fera du bruit. Sinon cf plus haut.
mais j'ai jamais entendu quelqu'un qui voulait avoir une synchro supérieur à ce que font tous les player vidéos.
En video tu as généralement deux secondes de buffer (parfois plus). C'est une des choses les plus simple à synchroniser (même si c'est déjà bien lourd merci les bit rates variables). Si tu as un problème de décodage/remplissage de buffer/défaut de ressouce tu as deux secondes pour y remedier et recommencer à remplir le buffer. C'est très très confortable.
Dans un jeu tu as généralement un vingtième de seconde pour comprendre un évènement, charger le rendu graphique, charger le rendu son, les synchroniser et les jouer.
Certes le rendu son dans les vidéos est souvent très bien synchronisé à l'image, mais c'est le cas "simple". faire la même chose en interactif ca peut être une vraie tannée.
Vu que la lib SDL est un appli assez bas niveau pour faire du son (basiquement on donne un wav à lire, et on fait le ping-pong avec 2 buffer audio, l'un se rempli, l'autre se lit)
Oui, c'est du très haut niveau çà en appli son.
Le haut niveau en fichier son c'est echo "fichier.wav" > /dev/macarte.
Pour te donner une idée voilà comment fonctionne la SDL avec le support Alsa dans Linux quand elle est en mode exclusif (ie aucune autre appli ne joue de sons) sur une carte en prise direct (ie pas de surcouche d'émulation dans alsa driver):
Appli -> SDL -> Alsalib -> Alsa -> Alsa driver
En vrai ca donne souvent çà :
Appli -> SDL -> Alsalib -> Alsa -> Alsa driver HDA PCM interface -> Alsa driver
Être bas niveau ca revient à discuter directement avec le matériel, voire à discuter avec les HControl/PCM/AC97 et autre interface à la con du driver Alsa (à la con parcequ'instables et non/mal documentés)
Tout ce que tu décris se fait en SDL
La SDL va permettre de mixer du son avec un autre appli qui parle avec GStreamer ? La SDL va empêcher pulseaudio de chopper une carte son ne mode exclusif ? La SDL va permettre à mon appli de partager un device avec trois autres applis qui ont des fréquences de rendu différentes ?
La SDL est une bibliothèque destiné au userland, pas un module noyau. Tout ce que peut faire la SDL c'est de cracher du son dans une interface. Après que ce son soit super bien foutu, soit le résultat du mixage de son de pleins de sons etc. on s'en fout. SDL c'est une instance par appli et par user.
Pour OpenAl, je pourrai pas donner plus de précision, mais vu comment râlent les joueurs lorsque les sons ne sont pas synchronisés je serai surpris que ça ne le permettes pas
Bine sur que dans la bibliothèque OpenAL il y a des fonctions qui permettent de synchroniser le son et l'image au sein de l'appli. Mais une fois d eplus on est mono appli, mono user. Y-a-t-il dans OpenAL une fonction qui permette de dialoguer avec le scheduler pour s'assurer que les sons seront effectivement synchronisés lors du rendu : non. OpenAL est userland aussi, il crache du son dans un device et c'est tout.
Je sais pas moi le premier truc que je ferai avant de tenter de coller l'image au son, c'est réduire la consommation démesuré de CPU; généralement la synchro pose moins de problème après :)
Perdu faut faire le contraire, il faut consommer un maximum de CPU, charger la mule le plus possible pour s'assurer que
a) les buffers sont pleins le plus longtemps possible
b) le scheduler se rende compte que tu es très consommateur de ressources et te passe dans un mode ou il t'alloue de grande tranche de temps de loin en loin plutôt que pleins de petites tranches de son. C'est ce qui garanti la cohésion image/son (entre autres).
De toute façon quand tes buffers sont pleins, tu rend la main - ta consommation de CPU au final reste la même.
et il aurait utilisé un truc du style openAl ou SDL (un machin plutôt stable dans ce bordel ambiant), il aurait eu qu'un seul dev à faire et tout (ou presque) de géré.
Le problème n'est pas de jouer du son, ca heureusement tout le monde peut le faire, mais de jouer du son de façon controllée :
Jouer du son en même temps qu'une autre application
Jouer du son venant de plusieurs sources, éventuellement à des fréquences différentes
Synchroniser du son et de l'image en direct
Synchroniser du son et de l'image alors qu'il faut gérer un buffer/un entrelacement/un multiformat
Donner la priorité à un son sur un autre entre deux applis différentes
etc.
SDL/OpenAL et consors ne savent pas faire ce genre de choses. C'est pourtant relativement demandé (Les gens aiment bien avoir le son et l'image synchronisé par exemple)
De façon générale les gens qui se plaignent de l'API son sous Linux sont des gens qui ont besoin d'un peu plus que d'un frontend pour "mad toto.mp3 - > /dev/dsp".
Le mec de chez Adobe il se plaint juste de devoir étudier 8 000 000 de possibilité différentes d'API et d'applis qui peuvent lui couper la priorité alors qu'il est en train d'essayer d'avoir une image qui colle avec le son.
t. T’as autant de systèmes parfaits que d’utilisateurs… J’apprécie que Linux me permette de réellement adapter le système pour qu’il soit parfait pour moi.
Pour qu'un système soit parfait il faut un minimum de "trucs"
En ce qui concerne le son sous Linux, tu vas te marrer :
On va diviser les utilisateurs en plusieurs grosses catégories :
- L'utilisateur pur, 0 technique, il prend une distrib l'installe et basta
- L'utilisateur avancé
- Le Pro du son
- Le dev
L'utilisateur pur va installer sa distrib, et là soit ca marche "out of the box", soit il essaye la distrib d'à coté. Au bout de trois distribs essayés il repasse sous windows. Ce mec ne cherche pas la distrib parfaite, il veut que "ca juste marche" quand il installe un truc. Et des fois ca juste marche (sur des PC relativement standards on va dire que ca fait 80% des cas de nos jours, ce qui est une belle performance). Cependant il va avoir tout un tas de petits soucis pour le faire chier : Des blancs entre les morceaux de sa musique (GStreamer est le prédateur naturel du gapless), un volume erratique (Ben oui le son il se règle dans Alsa, dans pulse audio, dans l'émulation OSS, dans GStreamer et parfois dans les applis ... super) Et puis parfois quand il va mettre à jour sa distrib, son plugin flash(proprio ou pas) va déconner grave au niveau du son jusqu'à la prochaine mise à jour. Si ca lui casse trop les pieds, il change.
L'utilisateur avancé il veut un comportement précis. Par exemple il veut du gapless (pas de blancs entre deux morceaux) parcequ'il écoute du classique/des concerts/des albums correctement assemblés. Lui déjà il souffre. Premièrement il doit foutre dehors GStreamer et s'arranger pour qu'il ne revienne pas à la charge quand il va mettre à jour sa distrib (ce qui demande déjà un bon niveau), ensuite il doit trouver des packages/repository compatibles avec sa distrib dans lesquels la dépendance à GStreamer a été enlevée. Sinon il doit tout compiler à la main, et tout recompiler à chaque mise à jour du kernel (en priant pour que ca marche encore - voire plus loin pour le dev).
Si il veut harmoniser les volumes, pour avoir un seul point à régler pour toutes les applis il va souffrir encore. Castrer Pulse Audio pour ne pas qu'il se mêle de régler le volume est pas évident du tout.Là aussi à chaque mise à jour du kernel ou presque il est bon pour revisiter ses réglages (d'une mise à jour sur l'autre, les éléments "secondaires" de la carte son, comme les sorties 5.1, les commuts micro/sortie, les entrées mic etc. changent de volume de base, voire de nom, voire de fonction - spécial dédicace au possesseurs de chipset son i810)
L'utilisateur pro, il devient juste fou. De façon générale il a besoin de jack en mode temps réel, lequel est particulièrement incompatible avec pulse audio. Pulse audio c'est un serveur en user space qui dialogue plusieurs centaine de fois par seconde avec le kernel space. C'est la fête du context switch. Même sur une très grosse machine si vous avez plusieurs logiciels, certains directement sous Jack et d'autres via pulse audio vous allez vous prendre du clock skew dans la gueule. Et genre pas qu'un peu. Un conseil éviter les mix 32khz/44,1khz/48khz ca n'arrange pas le problème, bien au contraire.
Après il va devoir lui aussi se taper la tête contre les murs avec les réglages de volume et les mises à jour. Si il a vraiment du temps à perdre il va essayer de gicler complètement pulse audio et GStreamer de sa distrib (de toute façon c'est un pro, sa/ses cartes audio font surement du mixage hard). Mais bon GStreamer est utilisé par un grand nombre d'applis son sous Linux (normalement ce ne sont pas celles qui l'interressent, mais bon) et gicler pulse-audio est devenu une tannée sur les distribs classiques. Reste la solution LFS, mais là il faut compiler ffado, ffmepg et jack dans des versions compatibles les unes avec les autres... Bonne chance gars.
Le dev, neuf fois sur dix, il a déjà laissé tombé. Il s'est arraché les cheveux sur l'absence de doc d'Alsa 0.8, il a failli se tirer une balle sur Alsa 0.9. Il a fait trois mois de dépression lors du passage en V4L2, a été interné pour la sortie d'Alsa 1.0 et ses magnifiques cartes virtuelles pour le mixage. On est en Alsa 1.0.22, les cartes virtuelles ne servent plus, 80% du code qu'il a pu écrire est inutilisable, il n'y a toujours pas de doc, les pilotes HDA sont à pleurer (on a encore changé les volumes par défaut et les noms de la moitié des entrées, mute permet dans certains cas de passer du mode capture au mode sortie). Il a pris sont parti, il écrit pour du high level. Gstreamer principalement, parceque phonon est pas complètement sec et qu'il a failli se pendre quand on a annoncé la mort d'Arts (encore du code qui part à la poubelle). Il sait que son appli traverse X couches d'émulation pour jouer le plus simple des sons. Il a décidé de s'en foutre, mais il lui a fallu deux ans de thérapie pour en arriver là.
Maxime attend de la concurrence de faire du temps réel. Elle le fait la concurrence ?
Oui définitvement. La plupart des plateformes de montages sont à la concurrence. Et ca marche. Par contre sous Linux il faut sérieusement s'accrocher. CF plus haut.
Ah! puis moi j’aime bien mon mpd, la concurrence a un lecteur de musique (juste un lecteur de musique) avec un protocole documenté pour pouvoir coder un petit client tout bien comme je veux (fade in/out+aléatoire pas trop con+console+arrêt uniquement à la fin du morceau)
MPD marche très bien en tant que serveur. Ceci étant il ne passe pas par GStreamer et il fonctionne encore mieux sans Pulse audio. Le serveur MPD est l'exmple typique du truc qui fait se demander à quoi servent toutes les couches là haut si ce n'est à faire moins bien pour plus d'overhead.
Les clients MPD java/windows fonctionnent très bien pour tout ce qui est fade-in/fade-out, aléatoire pas trop con etc.
et puis qui me fasse de la reconversion à la volée de flac vers ogg pour du streaming sur http ou n’importe quoi d’autre via ADSL. Toujours là la concurrence ?
Oui, oui FFMPeg et consors existent aussi chez la concurrence. Ils fonctionnent aussi très bien.
Et c’est juste faux :
make menuconfig
devices …
sound …
— ALSA
— OSS (DEPRECATED) (depuis pfiou… 4 ans? au moins)
Alsa, alsa driver, oss emulation, oss direct, V4L (deprecated aussi), V4L2
Sans compter les réglage à la con de type HPET ou Firewire on a 6 API dans le kernel qui fon mumuse avec le son. Tout va bien.
Et OSS est deprecated depuis près de 7 ans. Mais toujours dans le kernel (parceque bon, c'est quand même le truc qui marche partout et à chaque fois)
Et j’ai un scoop pour toi : si pulse expose l’API alsa aux applis ne parlant qu’alsa, ben ça veux pas dire que ton son est géré deux fois
En l'occurence si. Pulse se présente comme un pseudo device alsa, alors qu'il est en user land. Donc double contexte switch (user vers user puis user vers kernel) pour jouer le moindre son. Rajoute Une émulation OSS et gstreamer par dessus et c'est la fête du slip dans tes interrupts.
Bien sur le dev qui a fait son programme a pas à reprendre le code (encore que pulse-audio de part son caractère user land supporte assez mal les gruikeries Alsa et qu'un crash est vite arrivé). Mais si tu veux une synchro son/image tu te marres bien.
Et c’est ce que j’ai sur mon ordi. Enfin, j’ai PulseAudio suivant l’humeur du moment.
Je te parie que sur ton PC tu as pulseaudio, Alsa, Alsa drivers, l'émulation OSS, une voire deux émulation ESD, Gstreamer et peut-être même Phonon ou Arts. Moins certain mais probable : un alsa driver HDA et un autre en virtual midi.
Il y a peut être trois applis (dont le plugin flash Adobe d'ailleurs) capable de parler directement au HControl Alsa driver pour faire du mixage hard sans passer par les surcouches de surcouche de surcouche.
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.
On a mis 5 ans à avoir un truc qui marchouille à peu près
Ben j'ai pas idée que ca ait jamais marché sous Linux HAL.
On a d'abord eu la grande blague du passage devfs vers udev qui était en train de presque ressembler à un truc vaguement utilisable quand il a été décidé de passer à HAL.
Il y a une prise de pieds dans L'APIC quelquechose de violent, après DBus est arrivé et c'est là qu'on a commencé à vraiment se marrer. Parceque à partir de là chaque connexion/deconnexion de périph entrainnait une bataille de context switch quelquechose de lourd. Avec des résultats variables.Le moindre disque dur avait au moins 14 devices associé, par connexion physique, par connexion logique, par ID udev, par Numero de série, par ID "classique" à la linux etc. Au début automount devenait fou (le pauvre comment pouvait-il savoir que /dev/disk/13258AE, /dev/usb/disk/74548FF, /dev/sdd, /dev/id/3456-8903M684299 etc.) étaient un seul et même disque.
La configuration de udev est devenue assez amusante à faire, entre les listes mises à jour, les blacklists kernel, les blacklist locales et les sous-sous-sous répertoires de config udev. Chaque distrib prenant un peu au hasard parmis les 92 possibilités pour choisir son espace de nommage de référence.
Mais bon maintenant on a enfin tué HAL dans Debian et tout va mieux. Par exemple j'ai un graveur USB Samsung. La première fois que je le branche il est monté en tant que /dev/sdd, si je le débranche et que je le rebranche il ne se monte plus, si je recommence (3eme essai) il se monte en /dev/sr1. C'est très ludique...
[^] # Re: Utilité
Posté par Jerome Herman . En réponse au journal Unicode. Évalué à 3.
et parfois des milliers de caractères distincts (CJK). Ça marche dans la vie réelle.
Ca marche tellement bien que dans la vie réelle le gouvernement chinois a été obligé d'adjoindre à unicode des metas supplémentaires et de créer son propre système d'encoding qui incorpore ces métas.
Et là on parle de 120 000 signes d'une vraie langue d'un vrai pays, pas des émoticones rigolotes qu'on pourrait rajouter en plus.
Et on parle du chinois moderne aussi, pas du chinois classique ni des différents patois (parlés par plusieurs millions de personnes à chaque fois) et de leurs accentuations spécifique.
Mais bon c'est surement que les Chinois s'y sont mal pris, et qu'il n'y aura aucun problème quand on aura des documents qui peuvent potentiellement recouvrir 20 ou 30 millions de signes.
Sur ce je vous laisse, restez bien sur vos position de "ca marche parceque ca marche parceque ca marchera" et ne vous confrontez pas au monde du dehors.
[^] # Re: Utilité
Posté par Jerome Herman . En réponse au journal Unicode. Évalué à 0.
Non. Tu installes les mêmes polices qu'avant
Rappel : On parle de points unicode qui codent des emoticones rigolotes comme "woman with bunny ears". Je te jure que je n'ai jamais installé de polices de caractères qui contiennent cette glyphe.
Pour les documents du monde réel (càd tous sauf les .po), il suffit d'un nombre très limité de signes pour représenter le document.
Rappel : On parle de points unicode qui codent des emoticones rigolotes comme "woman with bunny ears", et de la pertinence qu'il y a à mettre ce type de caractères dans unicode au risque de faire exploser le nombre de caractères utilisés dans les documents du monde réel.
Si tu t'appelles Keith Packard tu résous le problème de façon élégante en écrivant Fontconfig.
Font config ne résout pas le problème, il permet juste une classification hiérarchique des fontes. Pour que ce soit utile il faut que le logiciel sache utiliser cette classification (ca va c'est pas trop dur) et que le document possède des métas qui vont lui indiquer dans quelle hiérarchie aller taper si il n'a pas la police exacte. Sans ses deux éléments le logiciel est obligé de recourir à la force brute pour associer le glyphe U+XXXXXXXX avec le caractère "woman with bunny ears".
[^] # Re: Utilité
Posté par Jerome Herman . En réponse au journal Unicode. Évalué à -2.
Donc en gros, à la place d'UTF-8 il faut se farcir des gros hacks.
Si c'est prévu dans la norme/le format je ne vois pas en quoi c'est un hack.
Et c'est tant mieux! C'est au logiciel de se débrouiller, pas à toi! C'est de la bidouille.
Dans un cas c'est au logiciel de l'auteur et dans l'autre cas c'est au logiciel du lecteur. Le truc est que si l'auteur est supposé savoir ce qu'il a voulu dire - le lecteur n'a pas forcément cette connaissance.
Bref, tu mélanges le codage d'un signe avec l'affichage d'un signe, tu mélanges le "savoir ce que c'est" avec le "comment on l'affiche", à partir de la il est impossible de discuter.
Non je ne mélange pas. L'utilisateur lambda il va être vachement content de savoir que le rectangle bordée de noir qu'il voit est en fait le caractère U+2868FFAE.
[^] # Re: Utilité
Posté par Jerome Herman . En réponse au journal Unicode. Évalué à 0.
Non. Il peuvent dans un cas exceptionnel : que tous les caractères du message soient dans la même locale
C'est marrant j'ai une pile de documments ISO qui précisent les changement de locales et qui sont lisibles par toutes les personnes qui en ont besoin - Des docs SGML par exemple.
(on s'en fou de la police de caractère, tu mélanges, la police de caractère c'est pour la présentation, si tu n'as pas la même c'est pas grave)
On est en train de parler de la lisibilité pour des utilisateurs dans un monde ou tout est en dans un standard qui comporte 42 gazillions de signes. Donc aucune police ne représentera tous les signes. Donc on force l'installation de polices spécifiques pour pouvoir lire un texte. Donc la police, si tu n'as pas la même tu ne peux pas comprendre le document est c'est grave.
En ISO je sais comment faire pour dire "cette parte de texte utilise telle locale, si tu n'as pas la police "machin" prend au moins une police compatible". Et ce même si le type décide d'écrire en Klingon et en Quenya.
En UTF-X je ne sais pas faire. C'est au logiciel de se démerder pour trouver dans toutes les polices installées lesquelles peuvent convenir.
Si il y a trente polices installées ca va, si il y en a 300 c'est le bazar.
[^] # Re: Utilité
Posté par Jerome Herman . En réponse au journal Unicode. Évalué à 3.
Exactement comme avant. Si tu veux lire des documents en coréen, vaut mieux que tu aies une police qui affiche le coréen... La différence, c'est qu'avant, le logiciel ne pouvait pas deviner quelle langue était utilisée.
On disposait quand même d'un système qui permettait de savoir quelle type de police pouvait répondre au problème. Par exemple en ISO 8859-15 défini un nombre finalement assez limité de caractères, de fait deux personnes en ISO peuvent échanger de smessages assez simplement.
As-tu tapé des formules de math dans les années 90, quand la seule solution était la police Symbol ?.
Oui. C'était d'ailleurs à l'époque ce qui m'a fait passer à Latex. Ceci étant la frappe de formules entières n'est pas frnachement résolu par Unicode non plus. Les caractères unicodes sont des entités indépendante, et à ma connaissance les interdépendances de caractères doivent être gérées séparément (par exemple la barre de la racine carré ou la hauteur du symbole d'intégration)
Aujourd'hui, tu peux mélanger toutes les écritures sans changer de police, et c'est le logiciel qui trouve quelle police sait afficher quel caractère.
Généralement le logiciel choisi parmis les quelques polices Universelle/unicode/multiglyphes qu'il possède celle qui pourrait convenir. Maintenant je rapelle que le sujet du débat ici présent est :
42 gazillions de caractères rigolos est-ce que ca sert à quelque chose ?
Je sais bien que ce n'est pas très difficile d'afficher du sanskrit, du japonais et du tibétain dans la même page, mais si on commence à mettre les émoticones, les glyphes égyptiennes, les symboles graphset, les repérages sécurité/incendie etc. comment fait-on. Je ne vois pas une seule police contenir tous ces glyphes, je ne vois pas non plus les applis se farcir le scan de 300 polices spécialisées pour trouver le caractère qui va bien.
Grosso-modo plus on rajoute de caractères qui n'ont rien à voir avec des caractères alphabétiques, plus on prend le risque de se retrouver avec des problèmes de lisibilité des documents.
Quand un correspondant coréen m'écrit, je peux m'attendre à devoir installer une police qui prend en charge les caractères coréens si je n'en ai pas déjà une.
Quand un architecte m'écrit je ne veux pas chercher dans toutes les polices existante laquelle me permet de voir le caractères en position 6 de la ligne 22.
Pour éviter que l'on se retrouve coincés il vaut mieux laisser unicode tel qu'il est en minimisant les caratères admis le plus possible.
[^] # Re: Utilité
Posté par Jerome Herman . En réponse au journal Unicode. Évalué à 5.
Donc non, tes polices de caractères ne pèseront pas plus lourd à mesure qu'unicode grandira.
Sans vouloir être méchant, Le but d'unicode est quand même de fournir un minimum d'interoperabilité et de lisibilité pour le lecteur final.
Aucune police saine d'esprit ne va s'amuser à implémenter des 42 gazillions de signes actuellement inclus dans unicode. On se retrouve donc à devoir installer sur son ordi une floppée de police pour couvrir les caractères qui nous interressent. Avec 42 gazillions de signe disponibles, on risque d'avoir des polices différentes pour chaque pays/corps de métier.
Si demain je reçois un document écrit avec (entre autres) trois polices que je ne possède pas, qui sont utilisés pour afficher des caractères rigolos, comment va faire mon ordi pour m'afficher des caractères au moins pseudo-corrects ?
a) Il va scanner toutes les polices installées à la recherche d'une d'entre elle qui possèderait les caractères voulus.
b) Il va afficher des gros rectangles baveux et laisser l'utilisateur rechercher parmis les 850 polices qu'il possède laquelle affiche ce #@!* de caractère.
c) On s'arrange pour que le poste du créateur du doc ajoute des infos sur les caractères de la police de façon à accélerer la recherche (par exemple indication : ISO8859-15 pour le caractère € - Solution qui ferait bien rire tout le monde) d) Il demande votre numéro de carte de crédit pour acheter les polices qui vous manquent directement chez les fabriquants.
J'ai de plus en plus l'impression qu'unicode est en train de renforcer les problèmes qu'il est supposé résoudre....
[^] # Re: et sinon...
Posté par Jerome Herman . En réponse au journal IE9. Évalué à 4.
<i>Faut reconnaître qu'il serait assez mal vu que des gens de Microsoft disent que leur produit est pourri le jour de sa sortie…</i>
Ben ca c'est déjà produit. Demande à l'équipe qui a bossé sur IE 6... Enfin ceux qui sont encore en vie bien sur...
[^] # Re: Goggles
Posté par Jerome Herman . En réponse au journal Des juges croient à la magie. Évalué à 4.
Et à partir d'un certain niveau de déformation / transformation, ça doit pouvoir être considéré comme une œuvre originale (je crois qu'on parle d’œuvre dérivée ou qq chose comme ça).
Déjà c'est pas parceque ca devient une oeuvre originale que tu n'es pas tenu de t'aquitter des droits d'auteur sur l'oeuvre qui sert de base. Demande à Moby, Daft Punk et autres remixeurs/dj ce qu'ils en pensent.
Ensuite si on ajoute du bruit ou de la rotation chromatique ou qu'on modifie les bits de poids faible dans le but de boulverser complètement la transformée de Fourrier et fiche en l'air les logiciels d'analyse de masse, je doute fort que l'on puisse considérer celà comme une oeuvre...
Ceci n'est pas une signature.
[^] # Re: Solution libre
Posté par Jerome Herman . En réponse au journal Avec Android, vous en avez plus pour votre argent. Évalué à 7.
<i>Même si tu as un buffer overflow, il faut passer par dessus la protection nx, par dessus la randomisation d'adresse, voir les protections par canary. C'est déjà une autre pair de manche.</i>
Si on se place dans le cas d'un auteur/contributeur malveillant, c'est un jeu d'enfant de faire du code dont on sait d'avance ou l'erreur va tomber, comment le buffer overflow va déborder etc. Et c'est particulièrement pernicieux à trouver. Passé deux out trois niveaux d'indirections et quelques changement de format plus tard (its a long long way to tipperary) qui va aller vérifier que ton tableau fait bien N éléments et pas N-1. Tu peux même pousser le vice jusqu'à coder un canary à la fin du tableau ... de N éléments.
Si quelqu'un te choppe (très très peu probable, mais pourquoi pas) tu peux toujours plaider non coupable, la faute d'inattention qui t'a fait sauter un élément, dans un tableau alloué quatre pages de code plus haut (voire dans un include, d'include). Après il suffit que le débordement aille gentiment écraser l'élément suivant dans une structure (tu sais ou ça tombe) et plaf un pointeur de fonction/une addresse de retour qui part aux fraises.
Pour finir tu envois un packet/fichier/flux avec un élément de trop au bon endroit et le malware s'active sans que personne ne puisse le voir à moins d'une analyse poussée du code.
NX ne verra rien, pointeur de fonction ou pointeur tout court, si on retourne bien dans la zone d’exécution (si tant est qu'on l'ai quittée) on aura son feu vert. La randomisation d'adresse tombe à plat puis que je corromps des données allouées au sein de la même structure. Et le canary posé posé en fin de structure ne sera même pas chatouillé par une corruption qui se produit trop en aval.
Et là c'est un exemple de méthode parmi des centaines qui passent largement au dessus des protections génériques et qui sont quasiment insensibles au fuzzing.
Un mec qui décide de créer une faille exprès dans son code, il a largement les moyens de la planquer tranquillement et de l'activer à la demande. Les techniques mentionnées marchent principalement contre les méchants qui essayent d'abuser un code écrit honnêtement.
[^] # Re: Et la largeur du texte ?
Posté par Jerome Herman . En réponse au journal Une nouvelle feuille de style orientée lecture. Évalué à 8.
Ben tu sais, dans les boulangeries toussa....
# N'importe quoi.
Posté par Jerome Herman . En réponse au journal Red Hat et les patchs: Un journal du vendredi publié samedi. Évalué à 10.
Et voilà encore un journal de PAAAATRICK qui tombe à plat. Ça quand il s'agit de faire du copier/coller de vingt pages pour de la dépêche d'avant plan et rafler un abonnement d'un an à "Libre et Gratuit magazine" il est toujours là, mais pour faire du troll de qualité il n'y a plus personne.
Déjà pour faire court, les moules qui trollent le vendredi sont encore sous le choc du changement de bouchot. C'est fragile ces bêtes là, quand on leur change leurs habitudes ça doit se ré-acclimater. Là je suis en train de poster mon commentaire dans une interface kikoolol avec une pub à peine déguisée sur la gauche de la zone de texte, un léger dégradé et des icônes trop kawai dans la barre d'outil façon Windows. Je te prie de croire que c'est dur à supporter.
Ensuite tu as choisi ton camps. T'es modérateur, et ca veut dire que tu peux pas troller. Du moins pas exprès : on est jamais à l'abri de la faute de bon gout qui pousse à repeindre le site en vert à ma moindre sortie d'une distrib écolo-germanique, ni d'un manque de jugeote fondamentale qui fait penser que la meilleure chose qui soit arrivé au libre c'est quand Mark Méritefusée a revendu sa boite aux spoofeurs de DNS pour faire de l'élevage d'animaux adjectivés. Mais un modérateur qui trolle sciemment, depuis son vrai compte, et sur le site qu'il modère, ca porte un nom : KADREG. Tu connais Kadreg ? Tu veux devenir comme lui ? Si vraiment tu dois troller, ais au moins la décence de le faire depuis un compte multi (qui sont interdits, mais les trolls aussi alors bon...). Prends exemple sur Amaury : lui quand il doit cracher son venin sur les dérives, pourtant rare, de notre très saint père le Pape, il le fait depuis un compte dédié. Ça préserve le crédibilité du site lors de l'audit annuel par Famille de France.
Ensuite parlons du troll à proprement dit, nous avons une boite qui vend du GPL depuis des lustres, qui a fait croire à une génération entière de linuxien que ses pré-bétas castrées étaient en fait une distrib à part entière gérée par une communauté indépendante, et dont le soucis principal est d'être certifié par Oracle chaque année, une boite donc qui décide de faire du patchage imbitable pour pas qu'on arrive à comprendre trop vite comment les copier. Honnêtement à part les jeunots qui vivent encore à bisounours land, ça surprend quelqu'un ?
Comme tu le disais toi même, Red Hat il sont au top of the top quand il s'agit de savoir comment faire de l'argent tout en jouant franc-jeu avec la GPL. Donc ils sont les mieux placés pour savoir que ce n'est pas possible. Pendant des années ils ont pris l'option ou ils ne gagnaient pas d'argent mais suçaient celui des investisseurs. En période de crise, quand l'investisseur se fait aussi rare que le Beluga dans le fleuve jaune ça devient dur de jouer à ce jeu très longtemps. Donc plan B : on arrête de jouer franc-jeu. Ah ben oui à force de passer des heures dans les locaux d'Oracle pour faire certifier leur biniou, il fallait bien s'attendre à ce qu'ils s'inspirent d'un business model successfull un jour ou l'autre.
Parce que voyons les choses de façon factuelle, quand ton plan de croissance est basé sur un produit dont le secret de fabrication est distribué publiquement d'une part, et sur 3000 employés qu'on peut débaucher le lendemain matin en leur promettant de leur donner un boulot encore plus autistisant sur le kernel linux d'autre part, ben t'es mal.
Donc RHEL sapusaipalibre, enfin pas tout à fait et pas comme il faudrait, on s'en moque un peu. Au final les applis Oracles ne tourneront peut-être plus aussi bien sous CentOS... On va pas pleurer non plus.
Donc non Red Hat est pas en train de devenir Evil, juste lucide. Mais c'est vrai que la lucidité a jamais vraiment aidé GNU/Linux au final.
[^] # Re: On ne le répétera jamais assez
Posté par Jerome Herman . En réponse au journal L'Amazon store inclus dans Banshee désactivé par Canonical. Évalué à 5.
Je ne connais pas les accords passés, mais ca doit être un truc genre Amazon reverse 10 à 30% de son bénéfice sur les produits vendus par l'interface Banshee. Donc c'est 75% des 10 à 30 % des X% de bénéfice par rapport au prix de vente. En vrai ca doit faire entre 1 et 3% du prix de vente.
# Contre analyse.
Posté par Jerome Herman . En réponse au journal Analyse perso du deal Nokia/Microsoft. Évalué à 10.
Grande salle bien vide, les grosses huiles de nokia (6 ou 7 au maximum) regardent la mine dépitée les graphs des ventes de téléphone mobile dans le monde.
- "On s'est encore fait bouffer deux points par Apple, ca commence à aller mal"
- "Qu'est-ce que tu veux, les gens veulent du smartphone maintenant"
- "Ben on pourrait faire du smartphone alors..."
- "Ca fait dix ans qu'on essaye, il y a tout le budget R&D qui y passe et ca rapporte que dalle"
- "On pourrait faire des portables android, ca couperait la R&D"
- "Ouais bien sur, avec 70% des smartphone vendus sous android dans le monde, on va être en super position pour négocier avec Google si ils décident de péter un plomb..."
Long silence géné...
- "On en est ou sur les brevets GSM avec Apple"
- "Dans l'os, il va falloir attendre le procès, l'appel etc."
- "A la vitesse à laquelle on brule notre trésorerie, on va pas tenir longtemps si on arrive pas à sortir un produit révolutionnaire, ou si on trouve pas un partenaire pour nous aider"
- "Ben voyons, un partenaire qui va nous aider à lutter contre Apple tout en contrant Google et qui va financer notre trésorerie. Tu veux pas qu'il nous file un OS pour mobile tout fait aussi pendant que tu y es ?"
[^] # Re: Génial !
Posté par Jerome Herman . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 3.
Oui mais généralement il appellent quand même des fonctions shell au final, comme tu le faisais remarquer. Et pour peu qu'on sache un peu lire du code, même si on ne comprend pas les fonctions shell appelées, on arrive généralement à recomposer le script avec un minimum d'effort.
Avec une forte intégration POSIX au millieu, ca devient beaucoup plus complexe. Déjà il faut passer par l'étape programmation pour immiter le comportement, et ensuite il faut comprendre véritablement ce qui se passe sous peine de se ramasser à l'execution.
Ca n'a rien d'une propriété du langage ou de l'outil, mais de la programmation. Je peux sortir des scripts Perl imbitables que ca n'y changerait rien. De même pour Python.
Sur un script perl imbitable, ou sur un script python imbitable on arrive toujours à savoir ce qui se passe en remplaçant une execution shell par un echo vers fichier. C'est long et casse pied, mais pas à pas on finit par avoir la liste des commandes que le script veut passer.
Tu discutes d'une implémentation qui n'existe pas, en raisonnant sur des hypothèses qui sont tiennes, après avoir relu un article sur linuxfr. Je t'invite donc dans ce cas à poser tes questions sur tech-userlevel@NetBSD.org et tech-toolchain@NetBSD.org.
STOP. Le projet consiste à mettre dans le système de base NetBSD un iterpreteur LUA avec une forte intégration au système POSIX sous jacent. C'est pas une hypothèse que je fais sur un coup de tête, c'est le but du projet.
Les exemples donnés par le créateur du projet sont la refonte du système d'install, la modification des scripts d'init et le changement d'option du client DHCP. J'invente rien, c'est écrit noir sur blanc dans les deux liens donnés dans le journal.
Pourrais-tu montrer les scripts d'install en question? Et les scripts de conf? Si non, encore une fois, pures spéculations. C'est de la critique gratuite pour satisfaire un besoin de critiquer...
Si le système d'install et les scripts d'init passent en LUA, ce qui une fois de plus est le but annoncé du projet, je ne vois pas comment je pourrais me passer d'apprendre LUA pour pouvoir mettre les mains dans le camboui. Or il se trouve que mettre les mains dans le camboui c'est mon métier.
Quels points forts?
Le monde Unix effectue traditionellement la séparation des droits au niveau fichier, le monde windows le fait au niveau interface.
Dans les deux cas il y a des avantages et des défauts.
Sous Unix le défaut est que pour faire fonctionner un système complexe il faut donner des droits dans tous les sens, avec des serveurs qui se lancent en root puis abandonnent progressivement leurs privilèges.
Sous windows le défaut est que pour faire fonctionner un système complexe il faut installer et lier whatdouzemille framework même si au final on se sert de 10% des possibilités des frameworks concernés.
Sous Unix l'avantage est que les configs, scripts et autre conneries sont déplaceables et maléables à volonté. Une fois qu'on a une config qui marche, on a la quasi certitude qu'elle va marcher sous tout un tas de système raisonnablement posix. Et on peut le déplacer de droite à gauche sans trop de soucis.
Sous windows l'avantage est l'intégration. Vu qu'on ramasse tout un bloc de fonctions d'un coup on a au moins la certitude qu'on ne va pas avoir à se retourner le crane si un jour on a besoin d'ajouter ou d'enlever une fonctionnalité.Et au moins on a pas à se prendre la tête pour savoir comment tout çà va dialoguer ensemble.
"Le monde Unix" dont tu parles est mort il y a quelques années maintenant, ou alors au stade de coma dépassé.
Oui. Enfin bon faut pas dire çà aux banques, assurances, instituts de recherche et autres systèmes experts.
[^] # Re: Génial !
Posté par Jerome Herman . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 6.
Par exemple le script Python qui ne fait "que" glue. Ca veut dire que si je ne veux pas de python sur ma machine, il suffit dans 90% des cas de faire du copier coller les éléments shell pour passer le script à la main.
Par contre avec LUA je vais être obligé de me plonger dans le truc pour faire du debug de script si je veux le faire fonctionner à la main. Ca peut aussi virer au jeu de piste avec des fonctions qui apellent d'autres fonctions LUA qui vont chercher des infos à droite, à gauche (base de données, device etc.)
Bref tout çà à analyser pour pouvoir passer sereinement quatre lignes de scripts...
J'ai connu le temps ou pour exploiter des comptes avec un contexte Kerberos, il fallait jouer avec des variables d'environnement et des fichiers temporaires pour que ca marche, parce que la GSSAPI n'était pas exploitable dans Python... et quand on voit la gueule de l'API, on comprend pourquoi.
Je vais peut être dire une connerie, mais c'était pas un contexte Kerberos SAMBA avec des certificats auto-signés dans le LDAP ? Parce qu'en utilisation authentification sur un réseau pur Unix Kerberos V4 et V5 ca a toujours plutôt bien tourné. Pour les bindings python, j'en ai jamais eu besoin donc ca ne m'a jamais manqué.
Autre exemple: éditer un fichier. Tu souhaites modifier /etc/motd en fonction de la journée. Aujourd'hui: tâche cron obligatoire, qui va appeler un script Perl (parce que le gars préférait Perl), qui va jouer au cat/grep/sed/ ~= <> FILE dedans.
Alors ca tu vois c'est EXACTEMENT ce qui fait que je ne veux pas de Lua dans mon BSD. Si Aujourd'hui j'ai un truc qui tombe tous les jours à 19h dans mon système et qui me fait chier (et bien oui, dans la vraie vie on a pas toujours installé les serveurs qu'on maintient), ben je vais dans le cron, je le tue et fin de l'histoire. Si demain ce truc peut être n'importe ou dans mon système, éventuellement régénéré par tel ou tel serveur si je le détruis, je vais devenir dingue.
Si tu veux te convaincre de l'utilité de la chose: je t'invite à lire le code source de net-snmp.
Code source != fichier de config. Si le mec veut faire un programme, une interface graphique, un concentrateur de données etc. en Lua, qu'il y aille. Aucun soucis avec moi.
Là il s'agit de fichiers de conf, des trucs qui peuvent déjà avoir pas mal d'incidence en aval (genre une erreur dans php.ini qui va joyeusement vautrer MySQL et Apache). A ceci on vient rajouter une possibilité d'incidence en amont (genre le script qui remplace mon php.ini va aller faire mumuse avec mes locales, mes params mémoire ou que sais-je encore). Là c'est non. Tout de suite. En plus on rajoute un interpreteur LUA dans mes serveurs, lequel interpreteur va avoir besoin de droits spécifiques pour exécuter tel ou tel partie du script de conf, dans le kernel parce que c'est plus fun.
Personne n'obligera à les utiliser.
Si les scripts d'install par défaut et les scripts de conf font du LUA, je ne vois pas comment je pourrais ne pas les utiliser à part en changeant de métier.
Il faut bien admettre que la tendance va vers cela
Oui, tout le monde veut copier le système windows/mac avec du call-back reporting dans tous les sens SAUF QUE traditionellement Unix/BSD/Linux sont monolithiques avec une logique de séparation et que NT/OS X sont des micro-kernel avec une logique de bloc.
Rien ne m'empêche sous Linux de prendre 300 API différentes au sein du même programme et de donner mes droits aux utilisateurs device par device, par contre sous windows, avec les objets COM par exemple, j'ai soit accès au bloc API ou pas, et si il y a des limitations elles sont gérés par le bloc, fonction par fonction, et pas par le système lui même. Par contre je peux me brosser pour faire tourner en même temps IIS 6.0 avec .net 2.0 et IIS 7.0 avec .net 3.5
(N.B : je sais que l'on peut faire du bloc en unix et faire tourner 14 IIs en même temps sous windows, mais c'est pas vraiment la philosophie du truc)
Bref c'est une tendance que je n'aime pas. On aurait tout à gagner à ce focaliser sur les points forts du monde Unix plutôt que de chercher à copier des systèmes dont les choix de départ sont très différents des nôtres.
[^] # Re: Génial !
Posté par Jerome Herman . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 3.
Je suis BSDiste. J'utilise principalement FreeBSD et OpenBSD (donc je connais moins bien NetBSD), mais je peux te dire que le basesys ne prend pas en charge les configuration avancées de type :
- Changement de MDA/MTA
- Authentification LDAP pour tout le monde (virtuel, réel etc. sauf root/wheel)
- Modification profonde de la config de base des Bases de données (genre load balancing, changement des réglages de moteurs de base de données, outils d'instrumentations intégrés etc.)
- PHP (oui PHP c'est juste l'horreur à suivre au niveau packages, avec des dépendances à tous les étages etc.)
Bref tout çà pour dire que même si j'ai une grosse confiance en les devs BSD, je ne vois pas comment leur projet de script peut ne pas partir en vrille au bout d'un moment.
Sous Linux ça a pris environ cinq ans (2004-2009 à peu près) pour que des éléments simple de config (genre les modes supportés par le serveur X) deviennent inéditables/inmodifiables parceque des scripts qui génèrent des scripts qui génèrent des scripts viennent t'écraser ta config à chaque mise à jour, voire à chaque reboot/fermeture violente de l'appli.
Donc oui, chat échaudé craint l'eau froide, le script qui configure automagiquement mes serveurs/params kernel j'en veux pas.
# Génial !
Posté par Jerome Herman . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 6.
J'ai vraiment du mal à voir l'interet qu'il peut y avoir à foutre un parseur XML et un interpreteur LUA (même si ils sont tout petits) dans un serveur qui n'a au final rien à foutre de l'un ou de l'autre (au hasard un MDA).
J'attends avec impatience le moment ou je devrait mettre à jour MySQL-Client pour pouvoir recevoir mes mails...
N.B : j'aimerais bien savoir comment la sql query est secured aussi. Relation de confiance sur l'utilisateur/machhine ou bien il y a un autre fichier avec un mot de passe quelque part ?
[^] # Re: .264
Posté par Jerome Herman . En réponse au journal Firefox 7 avant la fin de l'année ?. Évalué à 3.
Theora est tout sauf au niveau de h264 hein, cette comparaison elle dit que theora, sur un fichier donné, avec des options choisies aux petits oigons par le dév, et une keyframe toutes les 10 secondes, arrive à rivaliser avec h264 Baseline, avec les paramètres d'encodage de youtube ie pas adaptés à cette vidéo en particulier, et une keyframe toutes les secondes.
Il n'y a pas eu d'options choisies aux petits oignons, il s'agit d'un bête ffmpeg2theora brut de fonderie avec une image clef forcée minimum toutes les 170 images (contre toutes les 61 à l'époque pour Youtube)
Donc oui il y a un avantage donné à Theora mais il n'est pas aussi délirant que ce qu'on peut penser.
Ceci étant Theora reste à la traine sur le très bas bitrate. Mais passé 250kb/s ca n'est plus aussi évident.
Fais le test avec une version récente de ffmpeg2theora tu risques d'être surpris.
Ceci étant les benchmarks sont un véritable problème à mettre en place, surtout sur de la vidéo, surtout sur des codecs qui utilisent de la compression psycho-visuelle.
Généralement on ne s'en sort bien qu'avec une comparaison en double aveugle. Mais c'est compliqué à mettre en place.
[^] # Re: .264
Posté par Jerome Herman . En réponse au journal Firefox 7 avant la fin de l'année ?. Évalué à 5.
Pas de facturation en dessous de 100 000 unités (quelque soit le façon de compter les unités : matériel physique, abonné, paiement au titre, cible pour un broadcast)
Après c'est maximum 0.20$ par unité/abonné/titre supplémentaire.
Pour les logiciels libre distribués gratuitement, c'est gratuit coté AVC (pas coté diffusion par contre, ie si vous diffusez du contenu avec des logiciels libres vous êtes quand même tenu à la redevance).
Donc on va dire que les logiciels libre sont bloqués (pour certains) par leur licence, mais pas par des questions d'argent.
En ce qui concerne les petites structures (même les toutes toutes petites) elles peuvent souvent générer 0.20$ de marge par vente. Surtout quand les 100 000 premières unités par an sont gratuites. Donc au final on est très loin des brevets associés à des sommes pharaoniques, voire bloqués vissés en exploitation que l'on trouve sous tous les autres formats ou presque.
Pour l'instant la seule alternative à H264 est Theora. Les deux codecs progressent de concert, et même si la qualité de Theora (implémentation ffmpeg) est desormais au niveau de H264 http://people.xiph.org/~greg/video/ytcompare/comparison.html http://people.xiph.org/~maikmerten/youtube/ il a encore du mal sur les images les plus complexes à encoder (pluie violente, pan scan avec un ciel étoilé, ressac des vagues sur la plage etc.)
Maintenant il semblerait (je ne suis pas en position pour juger) que Theora soit plus complexe à encoder/decoder que H264. Donc, même pour une petite boite, il faut que cette puissance de calcul supplémentaire nécessaire lui coute moins de 0,20cts par client pour que Theora devienne plus interressant que H264.
Pas facile du tout...
Bref H264 le libre n'en veut pas pour des raisons compréhensibles (avec lesquelles on peut être en désaccord) - mais pas pour un problème d'argent.
[^] # Re: pour linux
Posté par Jerome Herman . En réponse au journal Firefox 7 avant la fin de l'année ?. Évalué à 7.
ouvert dans le sens "tout le monde est libre d'utiliser le standard comme bon lui semble et sans aucune restriction".
Loin de moi l'idée de vouloir défendre Zenitram, mais j'ai la (légère) sensation que tu confonds un certain nombre de choses :
- Le standard
- L'implémentation
- La licence de l'implémentation
Le standard c'est soit un standard de fait (ie un truc que tout le monde utilise même si il n'a jamais été normé proprement), soit un standard connu, soit un standard normé. Dans tous les cas c'est une suite de mots qui traduisent un comportement attendu face à un évènement, ou un format de donnée.
Cette suite de mot tu peux en faire ce que tu veux. La publier en affiche 4 par 3 dans le métro, l'imprimer en vert, faire des collages pour une oeuvre d'art ou encore la tagguer sur les murs de ta chambre. Je ne pense pas que qui que ce soit y verra le moindre problème.
Généralement on parle de standard ouvert quand
a - le standard est normé, c'est à dire déposé sous forme de RFC
b - le standard est complet, c'est à dire que l'ensemble des possibilité de la technologie lié directement au standard est disponible dans les doccuments de la norme (par exemple pour le H264 on possède les algorithmes de décodage ET d'encodage)
c - le standard est non encombré, c'est à dire que le standard ne repose pas sur une autre techno qui elle n'est pas normée/connue/publiée. Un standard qui reposerait (par exemple) sur la gestion d'objet OLE par les bibliothèques MS Office ne pourrait pas être considéré comme ouvert.
L'implémentation est un problème technique que doit résoudre le programmeur pour respecter le standard. Cette implémentation n'est que très rarement sans restriction. Déjà elle se doit de fonctionner, de préférence sur des machines qui existent déjà et de façon reproductible. On peut dire que si le standard est bien fait le programmeur a le choix du langage (dans une certaine limite - pas la peine de faire du H264 en MS basic 2.0) et de la plateforme cible (dans une certaine limite aussi - il faut que la plateforme puisse mathématiquement traiter les algos et éventuellement afficher les résultats). Pour le reste il est extrêmement restreint et ne peut pas faire comme bon lui semble, sinon il va sortir du standard. Ses choix principaux vont se limiter à implémenter ou non les fonctionnalités potentielles du standard (quand il s'agit d'un standard publié).
La licence de l'implémentation dépend pour une part de la volonté du programmeur et pour une autre part des brevets et accords qui planent sur les algorithmes et technologies du standard. A titre d'information si le programmeur décide de prendre la GPL comme licence sur un standard sans aucun brevet, ben il y aura là aussi des restrictions et tu ne pourras pas faire comme bon te semble, ni avec le code source, ni avec le compilé...
Après on a tous sa définition du mot ouvert (et on va pas parler du mot libre hein...) Personnellement la seule chose qui me dérange dans le MPEG-Standardisation Group est le somme à payer pour pouvoir rentrer dans le groupe et donc participer aux discussions sur la création et les choix techniques des nouveaux codecs.
[^] # Re: Cela dépend des cas…
Posté par Jerome Herman . En réponse au journal Linux ou POSIX ?. É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 Jerome Herman . En réponse au journal Linux ou POSIX ?. É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 Jerome Herman . En réponse au journal Linux ou POSIX ?. É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 Jerome Herman . En réponse au journal Linux ou POSIX ?. É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 Jerome Herman . En réponse au journal Linux ou POSIX ?. É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...