Je ne sait pas si c'est systèmatiquement le cas, mais les serveurs rackables que j'ai eu entre les mains ont toujours une carte vidéo intégrée dans la carte mère. Pas facile à enlever ! ;)
Je ne me suis pas senti assez à l'aise pour faire une dépêche (le sujet est ardu et m'échappe largement).
Mais bon, histoire de détourner les débats du journal vers ici ;), je vais essayer de faire une mini synthèse sur un point qui a été discuté dans le journal, et qui semblait pas naturel pour certains: sur les Unix modernes, le super utilisateur root n'est pas toujours censé avoir tout les droits.
En particulier, il est généralement admis qu'il est préférable que les utilisateurs (dont root) n'accèdent pas directement au matériel: on préfère qu'ils s'adressent au noyau (qui peut ensuite décider de dialoguer avec le matériel) via une interface bien définie (un appel système). Mais pour des raisons de commodité et de portabilité notamment, x.org et XFree86 dérogent à ce principe et accèdent directement au matériel. Le noyau doit donc ménager une ouverture pour permettre ce genre d'opérations.
Par ailleurs les Unix libres intègrent parfois des protections permettant de limiter les dégâts que peut causer (volontairement ou pas) les programmes ayant des droits root (acquis et utilisés légitimement ou pas). Par exemple les systèmes BSD incluent généralement un mécanisme appelé securelevel(7) qui peut permettre -entre autres- d'empêcher totalement (même pour root) la modification des fichiers ayant le drapeau "immuable", ou d'écrire sur /dev/mem, ou de modifier le paramétrage du pare feu, etc. En théorie, seul l'administrateur système (la personne physique, à ne pas confondre avec le concept informatique de "root") peut désactiver ces mécanismes lorsqu'il a accès à la console physique de la machine, et avant que le système d'exploitation ne passe en mode multi utilisateur. Le noyau Linux possède lui aussi des mécanisme de confinement (comme SELinux, GRSecurity ou encore RSBAC).
Mais là où les choses deviennent manifestement ennuyeuses, c'est que l'ouverture noyau donnant accès au matériel permet aussi de manipuler certaines fonctionnalités dangereuses des processeurs i386, lesquelles permettent un accès total à l'espace mémoire (en fait aux 4 premiers Go) à l'insu du noyau. C'est suffisant pour permettre à un logiciel ayant les droits root de détourner toutes les protections noyau évoquées ci-dessus.
Appréciation personnelle (et sans rapport direct avec la dépêche): x.org est un logiciel énorme (plusieurs million de lignes de code) qui tourne presque totalement avec les droits root. En partie du fait de ce problème de conception, et en partie parce que les développeurs n'ont pas choisi d'intégrer certains mécanismes pour réduire la proportion de code tournant en root (d'où ma remarque amère sur la non intégration des patches d'OpenBSD. Bref, on est assis sur une bombe). Et les récentes failles d'x.org (CVE-2006-1526 et CVE-2006-0745) témoignent des problèmes qu'engendre un si gros programme suid root...
Quelques corrections apportées par les commentaires dans le journal:
- Le titre de la news (repris du journal) etait involontairement trollistique, car x.org n'est pas le seul ni le principal responsable.
Un titre plus précis mais trop long : « Des déficiences combinées dans l'architecture des processeurs i386 et le design des serveurs XWindows obligent les noyaux de nombreux Unix libres à ouvrir une brèche pouvant être exploitée pour contourner les mécanismes et politiques de sécurité ».
- La « moralité » que j'avais ajoutée est trompeuse : en réalité il ne suffit pas de ne pas lancer de serveur X11: qu'il tourne ou pas, la brêche est ouverte (accessoirement, sous OpenBSD, on peut dans ce cas précis la refermer avec la commande "sysctl machdep.allowaperture=0").
En fait l'objectif des protections comme les securelevels n'est pas de déporter les droits sur un super-super utilisateur.
L'idée est plutôt de restreindre l'éxecution de certains privilèges à chaud (au runtime, ou plus précisément, lorsque le kernel tourne en mode multiutilisateur ).
Autrement dit, on considère qu'on a confiance dans le gars qui est derrière la console physique. Celui qui, par exemple, passe les paramètres activant les sécurisations en question au noyau lors du boot.
Exemple concret: l'admin boote son OpenBSD en init 1 (donc non multiuser, non réseau), active le niveau fort de restrictions (en écrivant "securelevel=2" dans le fichier /etc/rc.securelevel). Il met aussi un machdep.allowaperture=0 dans /etc/sysctl.conf vu que TdR vient de le lui recommander ;). Puis il pose le flag "immutable" sur certains fichiers cruciaux (au hasard: /etc/rc.securelevel, le kernel /bsd, /sbin/init, et le firewall /etc/pf.conf et /sbin/pfctl). Ensuite il passe le système en mode multiutilisateur. Et bien dès ce moment, root ne peut plus désactiver les protections du securelevel, ni rien modifier qui permette que ça soit désactiver au prochain reboot, etc. Sauf s'il a accès physique à la console, ou si on peut bypasser le noyau comme dans le cas qui nous intéresse.
Ce n'est donc pas une "remise en cause" de root. En une phrase: le noyau/arch idéal ne devrait pas permettre à un root "distant", lorsque le système est en mode mutlisateur/en prod, de se tirer une balle dans la tête, de griller son hardware, ou de voler des données les plus confidentielles de ses utilisateurs.
Pas faux. J'aurais du dire un truc comme: « La conception de l'architecture i386 nécéssite l'ouverture de failles pour permettre le fonctionnement des serveurs x » (enfin dans le genre mais en plus court ! ;)
Mea culpa, c'était involontaire, l'effervecence journalistique, toussa...
La faille est présente pour toutes les applis ayant les droits "raw i/o" et Xorg en fait partie mais est loin d'etre la seule.
Hmm, il y a bien sûr XFree86 aussi. A qui pense-tu (qui ne soit pas spécifique à Linux) ?
D'ailleurs quand on lit le Papier de Loïc Duflot, dans les possibles correctifs, il ne mentionne jamais de corriger le serveur X.
Enfin si un peu quand même ! :
« The best solution by far would thus be for the operating system to prevent ring 3 code from being able to access PIO registers. This can only be done if no standard application requires such privileges. This would require the designers of the X server, for instance, to decide to move their display server to a saner security model. ».
Mais c'est vrai qu'il pointe surtout du doigt l'archi pécé.
C'est moi ou le patch proposé par TdR ne sert à rien ? X accède à la carte graphique en tapant directement dans ses registres pour déclencher des actions et sa "solution" consiste à permettre à l'administrateur de brider voire bloquer l'accès à ces mêmes registres. Sauf que si on active cette option c'est l'explosion en vol du serveur X.
Non, la solution déjà intégrée dans OpenBSD consiste à pouvoir fermer totalement le fameux accès problématique direct aux registres des cartes graphiques (TdR indique seulement que ça va être vérouillé par défaut dorénavant).
Il va donc de soi que cette solution est faite pour les gens qui ne veulent pas faire tourner X.
"Pourquoi ?" me direz vous. Et bien vous n'avez pas suivi ;)
(je doit reconnaitre que j'ai un peu lancé ça dans le journal même).
Contrairement à ce qui a été dit ici, faire ou ne pas faire tourner X ne change rien à la présence du problème, du moins tant qu'on n'utilise pas une solution comme celle indiquée par TdR (sysctl machdep.allowaperture=0).
Et oui, car la place est désormais ouverte dans le kernel pour qu'un processus root puisse taper dans les registres de la carte graphique. Cette "ouverture" est bien sûr prévue pour les serveurs X, mais n'importe quel processus root peut y accéder !
Le machdep.allowaperture=0 dont parle TdR permet à OpenBSD de reboucher ce trou (ne pas autoriser les accès directs aux registres hw pour x.org et pour les autres).
Moralité, si vous utilisez des serveurs i386, n'installez pas X11 ... et utilisez OpenBSD ;)
En réalité, et contrairement à ce qu'on pourrai croire, root de devrait pas avoir *tout les droits* sur les Unix modernes. En particulier, il n'est pas censé pouvoir lire/modifier arbitrairement toutes les structures de données du noyau.
Voilà quelques exemples simples qui montrent que root (ou disons, un root illégitime, autre que la personne qui a choisi les options au boot) ne devrait pas pouvoir faire, sans quoi le problème excède largement le fait d'avoir une machine compromise:
- Accéder à la clef, au mot de passe de la clef ou au message déchiffré d'un utilisateur qui utilise GPG sur le système.
- Idem pour les transaction SSL en cours (root ne devrait pas avoir accès à mon numéro de carte bleu lorsque je consulte le site de ma banque).
- S'évader d'une cage chroot() dans lequel ce processus root est confiné (eg. daemon chrooté qui s'est fait pwned) ou autre protection de ce type (systrace, jail, ...).
- Accéder au hardware, lui injecter cochonneries et le griller (ou accéder aux fonctionnalités de mise à jour du bios depuis l'OS etc).
- Avoir la possibilité de modifier la visibilité de certains infos sur l'état de la machine (eg. cas d'une rootkit qui masque certains processus sur une machine compromise). Si on est pwned, pouvoir s'en apercevoir (ou pas), ça fait une grosse différence.
- S'évader d'une pseudo "machine virtuelle" (penser à l'hébergement mutualisé virtuel) telle que jail sous FreeBSD ou uml sous Linux ou qemu/vmware ...
etc.
Étant donné la sophistication des Unix modernes, pour pouvoir s'assurer de ça, on a besoin de polices qui empêchent certaines actions (comme le chargement de modules noyau, sous linux). Donc ça rajoute une série de protections contre ce type de droits roots -eg.empêcher le chargement de modules du noyau si telle option a été passée au boot- (SELinux, securelevel, Capabilities etc.), qui elles mêmes ne doivent pas être modifiables/désactivables par root.
Je suppose que ça signifie que logiciel artsplay doit savoir convertir les mp3 en raw pcm et les envoyer à aRts (?) (c'est juste une hypothèse, hein).
En plus amarok supporte arts comme moteur ca veut dire qu'il peut faire ca
Je n'ai pas d'amaroK sous les yeux pour tester, mais soit il le fait en spécifiant explicitement au framework multimedia en cours d'utilisation d'utiliser aRts (je ne sait pas pour xinelibs, mais GStreamer permet de bybasser sa décision et de choisir soi-meme la sortie audio qu'il utilisera), soit c'est du code qui date d'avant l'inclusion des backends comme GStreamer dans amaroK.
À côté de ca tu cite NMM comme framework mais il me semblait que c'etait un démon (d'ailleur pour pouvoir gérer le réseau faut un serveur et à part les démons je vois pas)
Un petit texte sur NMM avec des jolis dessins ;) http://www.linuxdevices.com/news/NS5209121793.html
Ça dit: « NMM works by moving multimedia applications away from their traditional client-server architecture, toward a more distributed middleware approach. ».
Heu j'ai compris différement cette remarque de TdR (me semble pas qu'il parle spécifiquement de /dev, si ?).
Il me semble qu'il dit que sous Unix les programes userland utilisent read() et write() pour écrire ou lire sur le disque.
Donc que les progs userland utilisent des interfaces bien définies du noyau (des appels systèmes POSIX) plutôt que d'aller taper directement dans les registres du chipset SATA (ou SCSI etc.) pour écrire ou lire sur un disque dur ou une carte réseau.
Et c'est le noyau qui se charge de causer au hardware pour faire la jonction (et au passage, nettoyer les requetes malsaines, optimiser, utiliser des caches, gérer les droits, les accès concurents etc.). Heureusement !
Sous entendu: les developpeurs x.org devraient faire pareil et définir un jeu d'appels systèmes aux interfaces définies (comme l'a fait POSIX pour l'accès à d'autres matériels) plutôt que de requierir des droits root et de taper en direct dans le hardware. Ce qui, au delà des questions de sécurité, est aussi intéressant pour des raisons de bon sens (qui n'a pas subit un gel complet de son système à cause d'un déconnage de X11 ?).
En fait, cela permet de contourner toutes les protections noyaux contre les possibles abus de root (l en existe plein: par exemple les securelevels, SELinux, GRsecurity, les protection contre les rootkits, ou par exemple un processus root peut alors sortir d'une cage chroot() ...).
De plus, Duflot fait remarquer que cette faille permet d'écrire dans des zones non volatiles sur certains matériels (comprendre: de véroler la machine, au sens matériel, de façon résistante aux reboots et réisntallations d'OS).
Aussi convient-il de noter qu'x.org s'éxecute en très grande partie avec les droits root (surtout sur les autres plateformes qu'OpenBSD).
Désolé, mais glib et son modèle GObject est totalement gnome-centriques, c'est le coeur même du modèle objet de Gnome (et pas du tout celui de KDE), développée et maintenue uniquement par des developpeurs gnome etc. Et non, je ne confond pas avec GTK+.
C'est un peu comme si tu me disait « ah les devs gnome ne veulent pas devenir totalement dépendant de QtCore (la partie non-gui de Qt4), comme c'est bizzare, pourtant c'est une lib généraliste ». Un peu de sérieux.
ensuite, si gstreamer dépend de la glib, c'est surtout parce que plus personne ne code les bindings pour qt.
Absolument pas. Regarde les docs de l'API: le modèle objet GObject est au coeur de GStreamer.
C'est pas un simple wrapper objet autour des fonctionalités offertes par ce framework (et donc: même si un binding C++ ou Qt est écrit, ce sera simplement un enrobage, la dépendance à glib ne pourra pas être enlevée).
N'y vois pas une position religieuse de ma part: je deteste le C++ autant que le modèle objet de gnome.
- Oxygen est juste un thème d'icône (pas encore fini) qui est un candidat pour devenir le thème d'icône par défaut de KDE4.
Il n'y a là aucun objectif d'unification entre les différent desktop, mais le but est au contraire d'arriver à une charte graphique spécifique à KDE
Oui je ne voulais pas dire qu'il y avait l'intention d'unification interdesktop du coté KDE. D'ailleur je trouve que les devs KDE n'ont pas ce defaut d'"unilateraliation".
D'ailleur le projet Tango a tellement capoté qu'il n'est même pas adopté comme jeux d'icônes par défaut dans gnome.
Merci pour la précision sur Telepathy (je crois que j'était resté avec des infos assez vieilles, au temps pour moi !).
Moi à la place des devels GStreamer je serais fier d'être utilisé par KDE alors que gstreamer était prévu pour GNOME!
Arf, mon explication devrait être très floue parcequ'en fait c'est l'inverse: les developpeurs de GStreamer pensaient que ce framework était prévu pour tout les DE (et ne se sont pas apperçu de certains aspects trop gnome-centrique puisqu'ils étaient tous devs gnome) ; ils sont plutot surpris d'apprendre que KDE ne l'adopte pas comme seul framework possible (à priori Phonon laissera le choix à l'utilisateur/distributeur du fw mm sous-jacent, gstreamer ou autre), et sont surpris de découvrir soudainement que les developpeurs de juk, amaroK etc. ont tu mal à maintenir leur backend GStreamer.
alors que jack qui est dans le même genre que gstreamer
En fait non. Jack est un serveur de son multipiste orienté temps réel (il fait du multiplexage, ce genre de choses). Il est plutôt de la famille de ESD ou aRts que de Gst en fait. Jack ne fait pas d'encodage/desencodage ogg/mp3 par ex.
Et GStreamer n'est pas un serveur de son. C'est un framework multimedia: il fournis une API unfiée pour parler aux serveurs de son comme aRts ou ESD (ou aux pilotes de la carte son directement), une API unifiée sur les différents codecs (audio, vidéo, sous-titres: ça évite d'avoir des structures totalement différentes dans son code selon qu'on accède à un fichier ogg ou a un mp3, par ex.), de synchronisation etc. Par contre il ne gère pas le multiplexage entre les accès audio concurents de diverses applis (rôle d'un serveur de son).
Btw il existe d'ailleur une tentative de plugin GStreamer offrant un backend sur jack (très experimental !).
Un exemple, pour situer tout ça. Imagine un lecteur audio :
- Il peut se charger lui même de lire les fichiers audio ogg, mp3, flac, wav, cd audios etc. et envoyer le résultat à Jack (ou à alsa, ou arts ...) pour le rendu sonore. Mais dans ce cas, il doit faire toutes les conversions (codecs -> pcm raw) lui meme (en s'adaptant à chaque fois aux API des différentes libs), et gérer lui même les accès au serveur de son (avec là encore leurs diférentes API: jack, esd, ...) ou à la carte son directement (API/interface différentes à chaque fois: alsa, win32, oss, mac os x, *bsd, solaris ...)
- Il peut utiliser un "framework multimedia" (comme GStreamer, xinelibs ou NMM) qui se chargera à sa place de deviner le codec utilisé (ogg, mp3, wav etc) de fournir à l'appli le son dans une structure de donnée "unifiée" (quel que soit le codec d'origine) de façon transparente. Le framework fournira éventuellement la possibilité d'appliquer des effets à ce son, encore une fois avec une API unifiée quelque soit la provenance des "effets" (native, LADSPA, ...). Enfin, le framework se chargera aussi d'envoyer le son au serveur de son / à la carte son / sur le réseau / ... pour le rendu, là encore, via une API unique malgrè la différence de chaque type de sortie possible.
- Il peut enfin utiliser un wrapper (type Phonon, quand il sera fait) qui permet d'écrire les besoins simples (lis tel fichier, enregistre telle source, envoi le son sur telle sortie ...) en peu de lignes dans l'application multimedia, et qui se charge de transformer ça en appels à un framework multimedia sous-jacent (GStreamern ou NMM etc). Celà permet notament de remplacer le framework multimedia s'il ne convient pas, sans rien modifier dans l'application.
Bref, pour situer shématiquement leurs positions relatives: Phonon fournis une couche d'abstraction/simplification au-dessus de GStreamer qui fournis une couche d'abstraction au-dessus de Jack.
Les frameworks comme GStreamer permettent d'éviter à chaque appli multimedia de ré-écrire le même code chacune de leur coté. Les wrappers comme phonon leur permettent d'être indépendants du choix du framework comme GStreamer ou xlinelibs (et de mutualiser ce code d'abstraction: qui est actuellement implémenté en double dans juk et amarok par ex.).
Concernant les « couches » qui ces derniers années ont alourdi/ralenti le rendu des polices, il faut préciser qu'il s'agit surtout de l' "unicodisation" globle des DE (ex. de conséquence : l'espace occupé par une chaine doit être calculée lettre par lettre) et l'ajout de la possiblité d'écrire en "bidirectionel" (eg. de droite à gauche).
Bref, c'est le prix à payer pour que les utilisateurs non occidentaux puissent utiliser Linux dans leur langue (si ça peut aider à faire passer la pillule ;).
(ps: et pour l'ex1: fuse n'a été intégré dans le noyau linux - et, au fait, seulement linux - que très récement, donc l'os ne pouvait pas founir ce service à l'époque de l'intégration systèmatique de gnome-vfs et kioslave).
Ah oui aussi, je voudrais insister sur l'échec répété (mais quand progresseront-ils ?!) des décisions d' « unification globale des environements de bureau » prises unilatéralement par les devs gnome (sans consulter les devs KDE, qui seraient alors censés suivre la voie, subjugués):
- Tango (le projet d'unification des jeux de graphismes) : le but était d'avoir un look uni et cohérent, meme lorsqu'on lance des applis kde sous gnome et réciproquement. Des devs gnome ont lancé ça dans leur coin en croyant que les gens de KDE suivraient nécéssairement. Ce qu'ils n'ont pas fait, et pire, KDE a mis en place un projet équivalent (Oxygen) mais incompatible (la palette de couleurs n'est pas le même).
- Cairo : tout le monde etait censé definitivement adorer, et convertir tout les accès xlib sur cette lib vectorielle. Pas de bol, Qt4 est sorti avec sa propre lib vectorielle.
- GStreamer : dans l'esprit des auteurs, censé être la solution multimedia unifiée que les gros desktop environement devraient adopter définitivement. Mais en fait développé et maintenu par des devs gnome, totalement dépendant de libs gnomes (glib, liboil), et ne répondant pas aux besoins élémentaires des devs KDE (qu'ils auraient pu connaitre s'ils leurs avaient adréssé un petit mail, btw ...). D'où Phonon. Raté, donc.
- Telepathy: qui est sur le même chemin (deviendra une norme pure gnome, non supportée par kde, alors qu'elle se vend comme "cross-desktop voip/im framework").
- Orbit : idem, mais bon, on s'en sort bien avec D-Bus.
- je doit en oublier d'autres encore ...
L'attitude des developpeurs Gnome à cet égard me fait vraiment penser à l'attitude politique actuelle des USA vis à vis des instance internationales comme l'ONU: supposer que la démocratie, c'est leurs décisions unilatérales, que la discussion/négociation préliminaire est inutile, et que les autres approuveront leur idées puisqu'elles sont brillantes.
À cet égard j'aimerai aussi ajouter que freedesktop.org est une pure organisation de foutage de gueule (ou pire, un wiki pour que les devs gnome annoncent leurs directives aux devs kde), ou en tout cas, pas du tout une véritable instance de normalisation (aucune norme formelle n'est écrite, donc pas de votes, n'importe quel dev peut poser "sa norme universlle-cross-desktop-définitive" tout seul sur un coin de wiki etc.
Précision important à savoir, parcequ'on lis souvent sur linuxfr des commentaires qui ventent les qualités d'un DE par son taux de conformité "aux standards fd.o".
- Comme Uraeus le fait remarquer à un moment dans les commentaires d'un des blogs, bien que les devs de Phonon aient au départ des ambitions modestes (le simple wrapper sur gst/nmm/xinelibs/...) et visait les cas d'utilisation les plus simples (qui sont aussi les plus courants: simple lecteur audio/vidéo, ou simple enregistreur), les utilisateurs potentiels de Phonon ont déjà commencé à faire le forcing pour le plomber de fonctionalités (VoIP etc). Or les devs de Phonon, qui avaient pourtant bien précisé au départ qu'ils voulaient couvrir les cas simples (et que les devs aux besoins avancés devaient se rabattre sur les fw mm directement), ils commencent peut à peut à céder à cette préssion et ont une wishlist qui devient énorme !
Du coup, le projet est (de l'avis d'Uraeus) un poil dévoyé: il va devenir gros (donc plus difficile à maintenir), il va implémenter des choses qui ne seront malheureusement pas mutualisables par les nombreuses aplis non kde. Et Uraeus souhaite que les devs travaillent plus pour mutualiser leurs efforts lorsqu'ils visent les mêmes objectifs (ce qui n'est en rien incompatible avec l'idée de Phonon comme wrapper, mais plutot avec Phonon comme réimplem des codecs voip/gsm, et tôt ou tard, s'ils ne posent pas de délimitations, de toutes les fonctions mm).
- L'intention fédératrice de GStreamer est tout de même louable: la dispertion à conduit les developpeurs à écrire une foultitude de frameworks multimedias (ou simples reimplems: vlc, xinelibs, mplayer, nmm, gstreamer, ...) qu'ils n'ont pas le temps de maintenir correctement (corriger les bugs etc), ou de mettre à jour pour suivre l'évolution sur rapide des codecs, ou de faire avec du code clean (sous tests unitaires, avec une API bien documenté etc), ou dont le modele "tout en un" (vs dlopen() des libs contenant les codecs à chaud) empeche l'intégration facile des codecs propriétaires ou brevetés dans les distros libres (gst, à ce niveau, propose un modèle assez intelligent) etc.
D'où leur investissement personnels très fort (vraiment) dans la qualité logicielle: gstreamer compile avec "-Wall -Werror", est sans cesse testé sous valgrind, est couvert par un énorme jeu de tests unitaires, testé en boucle sur plein de machines diverses, un coding style précis est imposé, un pipleine "efence" existe pour découvrir les moindres fuites mémoires, les devs ont une énorme collection de medias "vicieux" avec lesquels ils testent le svn-trunk quotidiennement ... et ils font de très gros efforts pour fermer les bugs au plus vite (je le sait, j'ai fait plusieurs bugs repports, ils ont été corrigés dans les un ou deux jours qui suivent !) et donc éviter que leur bugzilla ne grossise de façon incontrolable (cf. les devs de vlc: ils ont du fermer l'acces public à leur bugtracker tellement ils ont perdu pied ! ou mplayer, qui n'a même pas de bugtracker !).
Malheureusement ils manquent parfois de recul sur leur framework (je crois que leurs efforts pour la qualité du code, la position mentale que celà exige, y est pour qq chose: il faut être fier de son code et exigeant pour pouvoir refuser de le laisser partir à la dérive): comment peuvent-ils pester apres Phonon alors qu'ils n'ont pas encore écrit de binding C++ (condition minima pour être utilisable par les diverses applis mm de KDE) ? comment peuvent ils se dire "desktop agnostiques" alors qu'ils utilisent la glib de façon hardcore ? comment peuvent-ils dire qu'ils couvrent tout les besoins alors qu'en l'état, gst ne permet même pas de naviguer sur des DVD (entre autres grosses limitations) ? Comment peuvent-ils prétendre que leur API sera très stable pendant longtemps alors que la transition de 0.8 a 0.10 s'est faite dans le sang, les larmes et la douleur ? ...
- Certains commentaires l'ont clairement fait sentir: les developpeurs de gstreamer sont souvent trop enthousiastes au sujet de leur framework - et par contrecoup, n'ont pas l'oreille assez ouverte aux retours sur les problemes -: problèmes de portabilité (ils répètent a tout va que gst est ultra portable), manque d'API plus haut niveau pour les besoins simples de façon aisée et rapide (cf. les problèmes d'amaroK pour maintenir son portage sur gst, ou les débutants qui se plaignent de ne pas réussir à "renterer" dans le framework ou ne pas trouver de tutos clairs).
Il est évident que pour un dev de la lib gst, son utilisation est claire et simple, du coup cest dommage qu'ils n'entendent pas les appels à l'aide des developpeurs - moins familiers qu'eux avec les détails du fonctionnement de GStreamer - qui jugent l'API difficile d'accès, la doc pas pratique, même pour les besoins élémentaires (sachant que c'est un des principaux problème qu'entend adresser Phonon).
- 50 langues pour la correction orthographique ? Pourquoi pas 150 ? Et quel interet si on code seulement ?
Comme j'ai dit plus haut, vim utilise les dictionnaires de langues d'OpenOffice.org. Il supporte donc autant de langues qu'OOo (soit: autant qu'il y a eu des volontaires pour écrire des dictionnaires).
Concernant l'intéret du correcteur , il est surtout flagrant pour les utilisations généralistes de vim (par exemple pour l'édition d'emails en backend de mutt). Mais même lorsqu'on l'utilise pour coder, c'est parfois utile de pouvoir vérifier l'orthographe des textes des messages dans le code (ou dans les fichiers gettext etc).
- quel est le langage des script vim ? et que fait-on avec ?
Le language de script natif, toujours inclus, est le viml (un ml sur mesure).
Les languages Python, Perl, Ruby ou TCL sont aussi supportés (mais peuvent être activés ou pas, selon les options de compilation de vim).
Ce qu'on fait avec ? c'est très varié, jette un oeil ici : http://www.vim.org/scripts/
- quel interet de chercher dans les fichiers compressés ?
Vim permet de travailler de façon transparente avec les fichiers compréssés (.gz, .zip, .bz2), et même les archives (.tar, .tar.gz, .tgz, .tar.bz2).
On peut les éditer directement, sans avoir à la décomprésser (vim foo.tar.gz).
Dans le cas des archives, on les parcoure comme s'il s'agissait de simples répertoires, et on peut ouvrir, éditer les fichiers qu'elles contiennent ...
C'est pourquoi la possibilité de chercher / grepper dans les fichiers compréssés est pertinente ici.
Heu, oui, mais je doit préciser : c'était surtout une blague (les contrastes, toussa ...) !!
Évidement je ne donnerais jamais mon baril de vim contre deux barils de kate, nedit et eclipse ! ;)
La présentation des données n'est pas du tout la même dans Eclipse [...]
En fait, pour la plupart, des choses qui sont disponibles dans vim (nativement, comme la gestion des erreurs/warnings, ou par plugins, comme pour la navigation dans les classes et fonctions ou les templates et la génération des accesseurs). Par contre, c'est vrai que les fonctions de refactoring Java sont absentes de vim.
L'intégration avec les gestion de source n'est, a mon avis, pas aussi poussée dans Vim (je ne connais pas trop, merci de confirmer|infirmer)
Je ne suis pas sûr que tu parle des logiciel de gestion de révisions (type rcs, cvs, svn etc.) mais si c'est ça, la situation de vim et eclipse sont en tout point comparables: c'est totalement géré, via des plugins.
Pour des projets de développement de grosse taille, je pense qu'Eclipse serait un meilleur choix, tandis que pour les modifications plus ponctuelles je choisirais davantage vim
Et bien voilà le sens des plugins cités plus haut: désormais, tu n'es plus obligé de choisir ;)
Sinon, blague à part, je dirais plutôt: pour travailler sur du Java, Eclipse est excellent, pour le reste vim est une valeur sûre (pour avoir essayé les plugins pour php, python et C sous Eclipse, je peut t'assurer que c'est pas aussi bien géré que java, de loin ...).
D'autant qu'on peut maintenant utiliser vim en remplacement de l'éditeur d'Eclipse (et de celui de VisualStudio, et de NetBeans, ... universel je vous dit! !) ;)
Vim7 utilise les fichiers de vocabulaire d'OpenOffice.org, donc toute la roue n'est pas réinventée ;)
Je risque de te décevoir mais malheureusement ce nouvel outil de vérification d'ortographe est très ... hum, sommaire (pas vraiment contextuelle, pas de prise en compte de la sytaxe, conjugaison parfois approx., et chiant avec lorsqu'on utilise des mots informatiques, souvent anglais, dans du texte français, se vautre souvent lors de la vérification de texte dans du code html/c/python ...) :(
Ce n'est pas ce que j'ai voulu dire: je pensait plutôt que ça en fait un éditeur qu'il est utile de savoir utiliser, surtout en cas d'urgences (en l'occurence, pour un unixien, plus utile que de savoir utiliser windows ;).
Bon, c'est pas un logiciel libre avec un bout de gratuit, mais un logiciel gratuit pas libre, mais pour un intégriste du libre c'est kif kif non ? :)
Bin non parcequ'on n'est pas obligé d'utiliser kqemu (la partie propriétaire) pour faire tourner une machine qemu.
Kqemu ne fait qu'accélerer l'émulation (et encore, seulement dans le cas d'une emulation x86 sur un hote x86, et sur Linux et FreeBSD uniquement), mais n'est pas du tout nécéssaire (donc on peut utiliser qemu de façon 100% intègre ;).
Celà dit, ce qui fait que qemu emporte mon choix est ailleurs:
- il ne met pas le ouaille sur mon système (alors que vmware, avec sa pléthore de modules noyau et de scripts d'inits dans rc.d, bofff).
- à la différence de vmware, il sait émuler autre choses que du x86 (du sparc, ppc, arm, mips...), très utile pour tester la portabilité de mon code.
D'autre part, si j'ai bien compris, le vmware player (gratuit) ne permet pas de créer sa propre machine virtuelle ? si oui, c'est un sacré handicap.
Bon, disclaimer, je n'ai pas utilisé vmware depuis belle lurette, peut-être que le premier point s'est arrangé ?
Pour éviter ce problème, placer "set showmode" dans son ~/.vimrc.
Dès lors vim affichera le mode courant ("-- INSERT --" ou "-- VISUAL --") en dessous de la statusline.
[^] # Re: Théo : one point - X.Org : (void *)NULL
Posté par herodiade . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 2.
[^] # Re: petites corrections par rapport au journal
Posté par herodiade . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 10.
Mais bon, histoire de détourner les débats du journal vers ici ;), je vais essayer de faire une mini synthèse sur un point qui a été discuté dans le journal, et qui semblait pas naturel pour certains: sur les Unix modernes, le super utilisateur root n'est pas toujours censé avoir tout les droits.
En particulier, il est généralement admis qu'il est préférable que les utilisateurs (dont root) n'accèdent pas directement au matériel: on préfère qu'ils s'adressent au noyau (qui peut ensuite décider de dialoguer avec le matériel) via une interface bien définie (un appel système). Mais pour des raisons de commodité et de portabilité notamment, x.org et XFree86 dérogent à ce principe et accèdent directement au matériel. Le noyau doit donc ménager une ouverture pour permettre ce genre d'opérations.
Par ailleurs les Unix libres intègrent parfois des protections permettant de limiter les dégâts que peut causer (volontairement ou pas) les programmes ayant des droits root (acquis et utilisés légitimement ou pas). Par exemple les systèmes BSD incluent généralement un mécanisme appelé securelevel(7) qui peut permettre -entre autres- d'empêcher totalement (même pour root) la modification des fichiers ayant le drapeau "immuable", ou d'écrire sur /dev/mem, ou de modifier le paramétrage du pare feu, etc. En théorie, seul l'administrateur système (la personne physique, à ne pas confondre avec le concept informatique de "root") peut désactiver ces mécanismes lorsqu'il a accès à la console physique de la machine, et avant que le système d'exploitation ne passe en mode multi utilisateur. Le noyau Linux possède lui aussi des mécanisme de confinement (comme SELinux, GRSecurity ou encore RSBAC).
Mais là où les choses deviennent manifestement ennuyeuses, c'est que l'ouverture noyau donnant accès au matériel permet aussi de manipuler certaines fonctionnalités dangereuses des processeurs i386, lesquelles permettent un accès total à l'espace mémoire (en fait aux 4 premiers Go) à l'insu du noyau. C'est suffisant pour permettre à un logiciel ayant les droits root de détourner toutes les protections noyau évoquées ci-dessus.
Appréciation personnelle (et sans rapport direct avec la dépêche): x.org est un logiciel énorme (plusieurs million de lignes de code) qui tourne presque totalement avec les droits root. En partie du fait de ce problème de conception, et en partie parce que les développeurs n'ont pas choisi d'intégrer certains mécanismes pour réduire la proportion de code tournant en root (d'où ma remarque amère sur la non intégration des patches d'OpenBSD. Bref, on est assis sur une bombe). Et les récentes failles d'x.org (CVE-2006-1526 et CVE-2006-0745) témoignent des problèmes qu'engendre un si gros programme suid root...
Voilou.
Un peu de doc complémentaire:
Les récentes failles sécu d'x.org:
http://wiki.x.org/wiki/SecurityPage
L'implémentation des securelevel(7) sous OpenBSD:
http://www.openbsd.org/cgi-bin/man.cgi?query=securelevel
SELinux:
http://en.wikipedia.org/wiki/Security-Enhanced_Linux
# petites corrections par rapport au journal
Posté par herodiade . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 10.
- Le titre de la news (repris du journal) etait involontairement trollistique, car x.org n'est pas le seul ni le principal responsable.
Un titre plus précis mais trop long : « Des déficiences combinées dans l'architecture des processeurs i386 et le design des serveurs XWindows obligent les noyaux de nombreux Unix libres à ouvrir une brèche pouvant être exploitée pour contourner les mécanismes et politiques de sécurité ».
- La « moralité » que j'avais ajoutée est trompeuse : en réalité il ne suffit pas de ne pas lancer de serveur X11: qu'il tourne ou pas, la brêche est ouverte (accessoirement, sous OpenBSD, on peut dans ce cas précis la refermer avec la commande "sysctl machdep.allowaperture=0").
Voilà, désolé pour ces imprécisions initiales.
[^] # Re: Théo : one point - X.Org : (void *)NULL
Posté par herodiade . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 4.
[^] # Re: Euh ...
Posté par herodiade . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 4.
L'idée est plutôt de restreindre l'éxecution de certains privilèges à chaud (au runtime, ou plus précisément, lorsque le kernel tourne en mode multiutilisateur ).
Autrement dit, on considère qu'on a confiance dans le gars qui est derrière la console physique. Celui qui, par exemple, passe les paramètres activant les sécurisations en question au noyau lors du boot.
Exemple concret: l'admin boote son OpenBSD en init 1 (donc non multiuser, non réseau), active le niveau fort de restrictions (en écrivant "securelevel=2" dans le fichier /etc/rc.securelevel). Il met aussi un machdep.allowaperture=0 dans /etc/sysctl.conf vu que TdR vient de le lui recommander ;). Puis il pose le flag "immutable" sur certains fichiers cruciaux (au hasard: /etc/rc.securelevel, le kernel /bsd, /sbin/init, et le firewall /etc/pf.conf et /sbin/pfctl). Ensuite il passe le système en mode multiutilisateur. Et bien dès ce moment, root ne peut plus désactiver les protections du securelevel, ni rien modifier qui permette que ça soit désactiver au prochain reboot, etc. Sauf s'il a accès physique à la console, ou si on peut bypasser le noyau comme dans le cas qui nous intéresse.
Ce n'est donc pas une "remise en cause" de root. En une phrase: le noyau/arch idéal ne devrait pas permettre à un root "distant", lorsque le système est en mode mutlisateur/en prod, de se tirer une balle dans la tête, de griller son hardware, ou de voler des données les plus confidentielles de ses utilisateurs.
[^] # Re: troll
Posté par herodiade . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 5.
Pas faux. J'aurais du dire un truc comme: « La conception de l'architecture i386 nécéssite l'ouverture de failles pour permettre le fonctionnement des serveurs x » (enfin dans le genre mais en plus court ! ;)
Mea culpa, c'était involontaire, l'effervecence journalistique, toussa...
La faille est présente pour toutes les applis ayant les droits "raw i/o" et Xorg en fait partie mais est loin d'etre la seule.
Hmm, il y a bien sûr XFree86 aussi. A qui pense-tu (qui ne soit pas spécifique à Linux) ?
D'ailleurs quand on lit le Papier de Loïc Duflot, dans les possibles correctifs, il ne mentionne jamais de corriger le serveur X.
Enfin si un peu quand même ! :
« The best solution by far would thus be for the operating system to prevent ring 3 code from being able to access PIO registers. This can only be done if no standard application requires such privileges. This would require the designers of the X server, for instance, to decide to move their display server to a saner security model. ».
Mais c'est vrai qu'il pointe surtout du doigt l'archi pécé.
[^] # Re: Théo : one point - X.Org : (void *)NULL
Posté par herodiade . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 10.
Non, la solution déjà intégrée dans OpenBSD consiste à pouvoir fermer totalement le fameux accès problématique direct aux registres des cartes graphiques (TdR indique seulement que ça va être vérouillé par défaut dorénavant).
Il va donc de soi que cette solution est faite pour les gens qui ne veulent pas faire tourner X.
"Pourquoi ?" me direz vous. Et bien vous n'avez pas suivi ;)
(je doit reconnaitre que j'ai un peu lancé ça dans le journal même).
Contrairement à ce qui a été dit ici, faire ou ne pas faire tourner X ne change rien à la présence du problème, du moins tant qu'on n'utilise pas une solution comme celle indiquée par TdR (sysctl machdep.allowaperture=0).
Et oui, car la place est désormais ouverte dans le kernel pour qu'un processus root puisse taper dans les registres de la carte graphique.
Cette "ouverture" est bien sûr prévue pour les serveurs X, mais n'importe quel processus root peut y accéder !
Le machdep.allowaperture=0 dont parle TdR permet à OpenBSD de reboucher ce trou (ne pas autoriser les accès directs aux registres hw pour x.org et pour les autres).
Moralité, si vous utilisez des serveurs i386, n'installez pas X11 ... et utilisez OpenBSD ;)
[^] # Re: Risque réel?
Posté par herodiade . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 0.
Voilà quelques exemples simples qui montrent que root (ou disons, un root illégitime, autre que la personne qui a choisi les options au boot) ne devrait pas pouvoir faire, sans quoi le problème excède largement le fait d'avoir une machine compromise:
- Accéder à la clef, au mot de passe de la clef ou au message déchiffré d'un utilisateur qui utilise GPG sur le système.
- Idem pour les transaction SSL en cours (root ne devrait pas avoir accès à mon numéro de carte bleu lorsque je consulte le site de ma banque).
- S'évader d'une cage chroot() dans lequel ce processus root est confiné (eg. daemon chrooté qui s'est fait pwned) ou autre protection de ce type (systrace, jail, ...).
- Accéder au hardware, lui injecter cochonneries et le griller (ou accéder aux fonctionnalités de mise à jour du bios depuis l'OS etc).
- Avoir la possibilité de modifier la visibilité de certains infos sur l'état de la machine (eg. cas d'une rootkit qui masque certains processus sur une machine compromise). Si on est pwned, pouvoir s'en apercevoir (ou pas), ça fait une grosse différence.
- S'évader d'une pseudo "machine virtuelle" (penser à l'hébergement mutualisé virtuel) telle que jail sous FreeBSD ou uml sous Linux ou qemu/vmware ...
etc.
Étant donné la sophistication des Unix modernes, pour pouvoir s'assurer de ça, on a besoin de polices qui empêchent certaines actions (comme le chargement de modules noyau, sous linux). Donc ça rajoute une série de protections contre ce type de droits roots -eg.empêcher le chargement de modules du noyau si telle option a été passée au boot- (SELinux, securelevel, Capabilities etc.), qui elles mêmes ne doivent pas être modifiables/désactivables par root.
# rohhhh le vilain troll !
Posté par herodiade . En réponse à la dépêche Sortie de FreeBSD 6.1. Évalué à 10.
Trop gros, passera pas.
Dire qu'en ce moment les devs d'OpenBSD s'arrachent pour porter OpenOffice.org !
[^] # Re: précisions
Posté par herodiade . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 3.
Je suppose que ça signifie que logiciel artsplay doit savoir convertir les mp3 en raw pcm et les envoyer à aRts (?) (c'est juste une hypothèse, hein).
En plus amarok supporte arts comme moteur ca veut dire qu'il peut faire ca
Je n'ai pas d'amaroK sous les yeux pour tester, mais soit il le fait en spécifiant explicitement au framework multimedia en cours d'utilisation d'utiliser aRts (je ne sait pas pour xinelibs, mais GStreamer permet de bybasser sa décision et de choisir soi-meme la sortie audio qu'il utilisera), soit c'est du code qui date d'avant l'inclusion des backends comme GStreamer dans amaroK.
À côté de ca tu cite NMM comme framework mais il me semblait que c'etait un démon (d'ailleur pour pouvoir gérer le réseau faut un serveur et à part les démons je vois pas)
Un petit texte sur NMM avec des jolis dessins ;)
http://www.linuxdevices.com/news/NS5209121793.html
Ça dit: « NMM works by moving multimedia applications away from their traditional client-server architecture, toward a more distributed middleware approach. ».
[^] # Re: Théo : one point - X.Org : (void *)NULL
Posté par herodiade . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 8.
Il me semble qu'il dit que sous Unix les programes userland utilisent read() et write() pour écrire ou lire sur le disque.
Donc que les progs userland utilisent des interfaces bien définies du noyau (des appels systèmes POSIX) plutôt que d'aller taper directement dans les registres du chipset SATA (ou SCSI etc.) pour écrire ou lire sur un disque dur ou une carte réseau.
Et c'est le noyau qui se charge de causer au hardware pour faire la jonction (et au passage, nettoyer les requetes malsaines, optimiser, utiliser des caches, gérer les droits, les accès concurents etc.). Heureusement !
Sous entendu: les developpeurs x.org devraient faire pareil et définir un jeu d'appels systèmes aux interfaces définies (comme l'a fait POSIX pour l'accès à d'autres matériels) plutôt que de requierir des droits root et de taper en direct dans le hardware. Ce qui, au delà des questions de sécurité, est aussi intéressant pour des raisons de bon sens (qui n'a pas subit un gel complet de son système à cause d'un déconnage de X11 ?).
[^] # Re: Risque réel?
Posté par herodiade . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 7.
De plus, Duflot fait remarquer que cette faille permet d'écrire dans des zones non volatiles sur certains matériels (comprendre: de véroler la machine, au sens matériel, de façon résistante aux reboots et réisntallations d'OS).
Aussi convient-il de noter qu'x.org s'éxecute en très grande partie avec les droits root (surtout sur les autres plateformes qu'OpenBSD).
[^] # Re: précisions
Posté par herodiade . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 6.
C'est un peu comme si tu me disait « ah les devs gnome ne veulent pas devenir totalement dépendant de QtCore (la partie non-gui de Qt4), comme c'est bizzare, pourtant c'est une lib généraliste ». Un peu de sérieux.
ensuite, si gstreamer dépend de la glib, c'est surtout parce que plus personne ne code les bindings pour qt.
Absolument pas. Regarde les docs de l'API: le modèle objet GObject est au coeur de GStreamer.
C'est pas un simple wrapper objet autour des fonctionalités offertes par ce framework (et donc: même si un binding C++ ou Qt est écrit, ce sera simplement un enrobage, la dépendance à glib ne pourra pas être enlevée).
N'y vois pas une position religieuse de ma part: je deteste le C++ autant que le modèle objet de gnome.
[^] # Re: précisions
Posté par herodiade . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 2.
Il n'y a là aucun objectif d'unification entre les différent desktop, mais le but est au contraire d'arriver à une charte graphique spécifique à KDE
Oui je ne voulais pas dire qu'il y avait l'intention d'unification interdesktop du coté KDE. D'ailleur je trouve que les devs KDE n'ont pas ce defaut d'"unilateraliation".
D'ailleur le projet Tango a tellement capoté qu'il n'est même pas adopté comme jeux d'icônes par défaut dans gnome.
Merci pour la précision sur Telepathy (je crois que j'était resté avec des infos assez vieilles, au temps pour moi !).
[^] # Re: précisions
Posté par herodiade . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 3.
Arf, mon explication devrait être très floue parcequ'en fait c'est l'inverse: les developpeurs de GStreamer pensaient que ce framework était prévu pour tout les DE (et ne se sont pas apperçu de certains aspects trop gnome-centrique puisqu'ils étaient tous devs gnome) ; ils sont plutot surpris d'apprendre que KDE ne l'adopte pas comme seul framework possible (à priori Phonon laissera le choix à l'utilisateur/distributeur du fw mm sous-jacent, gstreamer ou autre), et sont surpris de découvrir soudainement que les developpeurs de juk, amaroK etc. ont tu mal à maintenir leur backend GStreamer.
alors que jack qui est dans le même genre que gstreamer
En fait non. Jack est un serveur de son multipiste orienté temps réel (il fait du multiplexage, ce genre de choses). Il est plutôt de la famille de ESD ou aRts que de Gst en fait. Jack ne fait pas d'encodage/desencodage ogg/mp3 par ex.
Et GStreamer n'est pas un serveur de son. C'est un framework multimedia: il fournis une API unfiée pour parler aux serveurs de son comme aRts ou ESD (ou aux pilotes de la carte son directement), une API unifiée sur les différents codecs (audio, vidéo, sous-titres: ça évite d'avoir des structures totalement différentes dans son code selon qu'on accède à un fichier ogg ou a un mp3, par ex.), de synchronisation etc. Par contre il ne gère pas le multiplexage entre les accès audio concurents de diverses applis (rôle d'un serveur de son).
Btw il existe d'ailleur une tentative de plugin GStreamer offrant un backend sur jack (très experimental !).
Un exemple, pour situer tout ça. Imagine un lecteur audio :
- Il peut se charger lui même de lire les fichiers audio ogg, mp3, flac, wav, cd audios etc. et envoyer le résultat à Jack (ou à alsa, ou arts ...) pour le rendu sonore. Mais dans ce cas, il doit faire toutes les conversions (codecs -> pcm raw) lui meme (en s'adaptant à chaque fois aux API des différentes libs), et gérer lui même les accès au serveur de son (avec là encore leurs diférentes API: jack, esd, ...) ou à la carte son directement (API/interface différentes à chaque fois: alsa, win32, oss, mac os x, *bsd, solaris ...)
- Il peut utiliser un "framework multimedia" (comme GStreamer, xinelibs ou NMM) qui se chargera à sa place de deviner le codec utilisé (ogg, mp3, wav etc) de fournir à l'appli le son dans une structure de donnée "unifiée" (quel que soit le codec d'origine) de façon transparente. Le framework fournira éventuellement la possibilité d'appliquer des effets à ce son, encore une fois avec une API unifiée quelque soit la provenance des "effets" (native, LADSPA, ...). Enfin, le framework se chargera aussi d'envoyer le son au serveur de son / à la carte son / sur le réseau / ... pour le rendu, là encore, via une API unique malgrè la différence de chaque type de sortie possible.
- Il peut enfin utiliser un wrapper (type Phonon, quand il sera fait) qui permet d'écrire les besoins simples (lis tel fichier, enregistre telle source, envoi le son sur telle sortie ...) en peu de lignes dans l'application multimedia, et qui se charge de transformer ça en appels à un framework multimedia sous-jacent (GStreamern ou NMM etc). Celà permet notament de remplacer le framework multimedia s'il ne convient pas, sans rien modifier dans l'application.
Bref, pour situer shématiquement leurs positions relatives: Phonon fournis une couche d'abstraction/simplification au-dessus de GStreamer qui fournis une couche d'abstraction au-dessus de Jack.
Les frameworks comme GStreamer permettent d'éviter à chaque appli multimedia de ré-écrire le même code chacune de leur coté. Les wrappers comme phonon leur permettent d'être indépendants du choix du framework comme GStreamer ou xlinelibs (et de mutualiser ce code d'abstraction: qui est actuellement implémenté en double dans juk et amarok par ex.).
[^] # Re: Ce qui est dommage
Posté par herodiade . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 4.
Bref, c'est le prix à payer pour que les utilisateurs non occidentaux puissent utiliser Linux dans leur langue (si ça peut aider à faire passer la pillule ;).
(ps: et pour l'ex1: fuse n'a été intégré dans le noyau linux - et, au fait, seulement linux - que très récement, donc l'os ne pouvait pas founir ce service à l'époque de l'intégration systèmatique de gnome-vfs et kioslave).
[^] # Re: précisions
Posté par herodiade . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 9.
- Tango (le projet d'unification des jeux de graphismes) : le but était d'avoir un look uni et cohérent, meme lorsqu'on lance des applis kde sous gnome et réciproquement. Des devs gnome ont lancé ça dans leur coin en croyant que les gens de KDE suivraient nécéssairement. Ce qu'ils n'ont pas fait, et pire, KDE a mis en place un projet équivalent (Oxygen) mais incompatible (la palette de couleurs n'est pas le même).
- Cairo : tout le monde etait censé definitivement adorer, et convertir tout les accès xlib sur cette lib vectorielle. Pas de bol, Qt4 est sorti avec sa propre lib vectorielle.
- GStreamer : dans l'esprit des auteurs, censé être la solution multimedia unifiée que les gros desktop environement devraient adopter définitivement. Mais en fait développé et maintenu par des devs gnome, totalement dépendant de libs gnomes (glib, liboil), et ne répondant pas aux besoins élémentaires des devs KDE (qu'ils auraient pu connaitre s'ils leurs avaient adréssé un petit mail, btw ...). D'où Phonon. Raté, donc.
- Telepathy: qui est sur le même chemin (deviendra une norme pure gnome, non supportée par kde, alors qu'elle se vend comme "cross-desktop voip/im framework").
- Orbit : idem, mais bon, on s'en sort bien avec D-Bus.
- je doit en oublier d'autres encore ...
L'attitude des developpeurs Gnome à cet égard me fait vraiment penser à l'attitude politique actuelle des USA vis à vis des instance internationales comme l'ONU: supposer que la démocratie, c'est leurs décisions unilatérales, que la discussion/négociation préliminaire est inutile, et que les autres approuveront leur idées puisqu'elles sont brillantes.
À cet égard j'aimerai aussi ajouter que freedesktop.org est une pure organisation de foutage de gueule (ou pire, un wiki pour que les devs gnome annoncent leurs directives aux devs kde), ou en tout cas, pas du tout une véritable instance de normalisation (aucune norme formelle n'est écrite, donc pas de votes, n'importe quel dev peut poser "sa norme universlle-cross-desktop-définitive" tout seul sur un coin de wiki etc.
Précision important à savoir, parcequ'on lis souvent sur linuxfr des commentaires qui ventent les qualités d'un DE par son taux de conformité "aux standards fd.o".
# précisions
Posté par herodiade . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 10.
- Comme Uraeus le fait remarquer à un moment dans les commentaires d'un des blogs, bien que les devs de Phonon aient au départ des ambitions modestes (le simple wrapper sur gst/nmm/xinelibs/...) et visait les cas d'utilisation les plus simples (qui sont aussi les plus courants: simple lecteur audio/vidéo, ou simple enregistreur), les utilisateurs potentiels de Phonon ont déjà commencé à faire le forcing pour le plomber de fonctionalités (VoIP etc). Or les devs de Phonon, qui avaient pourtant bien précisé au départ qu'ils voulaient couvrir les cas simples (et que les devs aux besoins avancés devaient se rabattre sur les fw mm directement), ils commencent peut à peut à céder à cette préssion et ont une wishlist qui devient énorme !
Du coup, le projet est (de l'avis d'Uraeus) un poil dévoyé: il va devenir gros (donc plus difficile à maintenir), il va implémenter des choses qui ne seront malheureusement pas mutualisables par les nombreuses aplis non kde. Et Uraeus souhaite que les devs travaillent plus pour mutualiser leurs efforts lorsqu'ils visent les mêmes objectifs (ce qui n'est en rien incompatible avec l'idée de Phonon comme wrapper, mais plutot avec Phonon comme réimplem des codecs voip/gsm, et tôt ou tard, s'ils ne posent pas de délimitations, de toutes les fonctions mm).
- L'intention fédératrice de GStreamer est tout de même louable: la dispertion à conduit les developpeurs à écrire une foultitude de frameworks multimedias (ou simples reimplems: vlc, xinelibs, mplayer, nmm, gstreamer, ...) qu'ils n'ont pas le temps de maintenir correctement (corriger les bugs etc), ou de mettre à jour pour suivre l'évolution sur rapide des codecs, ou de faire avec du code clean (sous tests unitaires, avec une API bien documenté etc), ou dont le modele "tout en un" (vs dlopen() des libs contenant les codecs à chaud) empeche l'intégration facile des codecs propriétaires ou brevetés dans les distros libres (gst, à ce niveau, propose un modèle assez intelligent) etc.
D'où leur investissement personnels très fort (vraiment) dans la qualité logicielle: gstreamer compile avec "-Wall -Werror", est sans cesse testé sous valgrind, est couvert par un énorme jeu de tests unitaires, testé en boucle sur plein de machines diverses, un coding style précis est imposé, un pipleine "efence" existe pour découvrir les moindres fuites mémoires, les devs ont une énorme collection de medias "vicieux" avec lesquels ils testent le svn-trunk quotidiennement ... et ils font de très gros efforts pour fermer les bugs au plus vite (je le sait, j'ai fait plusieurs bugs repports, ils ont été corrigés dans les un ou deux jours qui suivent !) et donc éviter que leur bugzilla ne grossise de façon incontrolable (cf. les devs de vlc: ils ont du fermer l'acces public à leur bugtracker tellement ils ont perdu pied ! ou mplayer, qui n'a même pas de bugtracker !).
Malheureusement ils manquent parfois de recul sur leur framework (je crois que leurs efforts pour la qualité du code, la position mentale que celà exige, y est pour qq chose: il faut être fier de son code et exigeant pour pouvoir refuser de le laisser partir à la dérive): comment peuvent-ils pester apres Phonon alors qu'ils n'ont pas encore écrit de binding C++ (condition minima pour être utilisable par les diverses applis mm de KDE) ? comment peuvent ils se dire "desktop agnostiques" alors qu'ils utilisent la glib de façon hardcore ? comment peuvent-ils dire qu'ils couvrent tout les besoins alors qu'en l'état, gst ne permet même pas de naviguer sur des DVD (entre autres grosses limitations) ? Comment peuvent-ils prétendre que leur API sera très stable pendant longtemps alors que la transition de 0.8 a 0.10 s'est faite dans le sang, les larmes et la douleur ? ...
- Certains commentaires l'ont clairement fait sentir: les developpeurs de gstreamer sont souvent trop enthousiastes au sujet de leur framework - et par contrecoup, n'ont pas l'oreille assez ouverte aux retours sur les problemes -: problèmes de portabilité (ils répètent a tout va que gst est ultra portable), manque d'API plus haut niveau pour les besoins simples de façon aisée et rapide (cf. les problèmes d'amaroK pour maintenir son portage sur gst, ou les débutants qui se plaignent de ne pas réussir à "renterer" dans le framework ou ne pas trouver de tutos clairs).
Il est évident que pour un dev de la lib gst, son utilisation est claire et simple, du coup cest dommage qu'ils n'entendent pas les appels à l'aide des developpeurs - moins familiers qu'eux avec les détails du fonctionnement de GStreamer - qui jugent l'API difficile d'accès, la doc pas pratique, même pour les besoins élémentaires (sachant que c'est un des principaux problème qu'entend adresser Phonon).
[^] # Re: des questions
Posté par herodiade . En réponse à la dépêche Sortie de Vim 7. Évalué à 3.
Comme j'ai dit plus haut, vim utilise les dictionnaires de langues d'OpenOffice.org. Il supporte donc autant de langues qu'OOo (soit: autant qu'il y a eu des volontaires pour écrire des dictionnaires).
Concernant l'intéret du correcteur , il est surtout flagrant pour les utilisations généralistes de vim (par exemple pour l'édition d'emails en backend de mutt). Mais même lorsqu'on l'utilise pour coder, c'est parfois utile de pouvoir vérifier l'orthographe des textes des messages dans le code (ou dans les fichiers gettext etc).
- quel est le langage des script vim ? et que fait-on avec ?
Le language de script natif, toujours inclus, est le viml (un ml sur mesure).
Les languages Python, Perl, Ruby ou TCL sont aussi supportés (mais peuvent être activés ou pas, selon les options de compilation de vim).
Ce qu'on fait avec ? c'est très varié, jette un oeil ici : http://www.vim.org/scripts/
- quel interet de chercher dans les fichiers compressés ?
Vim permet de travailler de façon transparente avec les fichiers compréssés (.gz, .zip, .bz2), et même les archives (.tar, .tar.gz, .tgz, .tar.bz2).
On peut les éditer directement, sans avoir à la décomprésser (vim foo.tar.gz).
Dans le cas des archives, on les parcoure comme s'il s'agissait de simples répertoires, et on peut ouvrir, éditer les fichiers qu'elles contiennent ...
C'est pourquoi la possibilité de chercher / grepper dans les fichiers compréssés est pertinente ici.
[^] # Re: Nedit ?
Posté par herodiade . En réponse à la dépêche Sortie de Vim 7. Évalué à 2.
Heu, oui, mais je doit préciser : c'était surtout une blague (les contrastes, toussa ...) !!
Évidement je ne donnerais jamais mon baril de vim contre deux barils de kate, nedit et eclipse ! ;)
La présentation des données n'est pas du tout la même dans Eclipse [...]
En fait, pour la plupart, des choses qui sont disponibles dans vim (nativement, comme la gestion des erreurs/warnings, ou par plugins, comme pour la navigation dans les classes et fonctions ou les templates et la génération des accesseurs). Par contre, c'est vrai que les fonctions de refactoring Java sont absentes de vim.
L'intégration avec les gestion de source n'est, a mon avis, pas aussi poussée dans Vim (je ne connais pas trop, merci de confirmer|infirmer)
Je ne suis pas sûr que tu parle des logiciel de gestion de révisions (type rcs, cvs, svn etc.) mais si c'est ça, la situation de vim et eclipse sont en tout point comparables: c'est totalement géré, via des plugins.
Pour des projets de développement de grosse taille, je pense qu'Eclipse serait un meilleur choix, tandis que pour les modifications plus ponctuelles je choisirais davantage vim
Et bien voilà le sens des plugins cités plus haut: désormais, tu n'es plus obligé de choisir ;)
Sinon, blague à part, je dirais plutôt: pour travailler sur du Java, Eclipse est excellent, pour le reste vim est une valeur sûre (pour avoir essayé les plugins pour php, python et C sous Eclipse, je peut t'assurer que c'est pas aussi bien géré que java, de loin ...).
[^] # Re: Nedit ?
Posté par herodiade . En réponse à la dépêche Sortie de Vim 7. Évalué à 1.
D'autant qu'on peut maintenant utiliser vim en remplacement de l'éditeur d'Eclipse (et de celui de VisualStudio, et de NetBeans, ... universel je vous dit! !) ;)
http://vimplugin.sourceforge.net/
ou
http://eclim.sourceforge.net/
[^] # Re: Gvim (vim-x11)
Posté par herodiade . En réponse à la dépêche Sortie de Vim 7. Évalué à 2.
Je risque de te décevoir mais malheureusement ce nouvel outil de vérification d'ortographe est très ... hum, sommaire (pas vraiment contextuelle, pas de prise en compte de la sytaxe, conjugaison parfois approx., et chiant avec lorsqu'on utilise des mots informatiques, souvent anglais, dans du texte français, se vautre souvent lors de la vérification de texte dans du code html/c/python ...) :(
[^] # Re: ceci n'est pas un troll ...
Posté par herodiade . En réponse à la dépêche Sortie de Vim 7. Évalué à 3.
[^] # Re: Et la fameuse rétribution ?
Posté par herodiade . En réponse à la dépêche Sortie de QEMU 0.8.1. Évalué à 3.
Bin non parcequ'on n'est pas obligé d'utiliser kqemu (la partie propriétaire) pour faire tourner une machine qemu.
Kqemu ne fait qu'accélerer l'émulation (et encore, seulement dans le cas d'une emulation x86 sur un hote x86, et sur Linux et FreeBSD uniquement), mais n'est pas du tout nécéssaire (donc on peut utiliser qemu de façon 100% intègre ;).
Celà dit, ce qui fait que qemu emporte mon choix est ailleurs:
- il ne met pas le ouaille sur mon système (alors que vmware, avec sa pléthore de modules noyau et de scripts d'inits dans rc.d, bofff).
- à la différence de vmware, il sait émuler autre choses que du x86 (du sparc, ppc, arm, mips...), très utile pour tester la portabilité de mon code.
D'autre part, si j'ai bien compris, le vmware player (gratuit) ne permet pas de créer sa propre machine virtuelle ? si oui, c'est un sacré handicap.
Bon, disclaimer, je n'ai pas utilisé vmware depuis belle lurette, peut-être que le premier point s'est arrangé ?
[^] # Re: ceci n'est pas un troll ...
Posté par herodiade . En réponse à la dépêche Sortie de Vim 7. Évalué à 3.
Dès lors vim affichera le mode courant ("-- INSERT --" ou "-- VISUAL --") en dessous de la statusline.