ookaze a écrit 271 commentaires

bin moi je vous conseille de ne pas installer ces headers:
sh NVIDIA-Linux-x86-1.0-7664-pkg1.run --no-opengl-headers

car j'ai des erreurs en compilant des softs suite à l'install de ces headers avec le nouveau driver. Par exemple avec mplayer (current) :
[...]
et on m'a dit sur IRC que ca fait la même chose pour wine, evas.

Ce qui m'échappe à moi, c'est que j'installe ces headers depuis toujours.
Or, je n'ai eu des problèmes que pour de rares jeux, et c'était dû au fait que les drivers NVidia utilisaient des headers d'une version OpenGL plus avancée que Mesa.

Je n'ai eu AUCUN problème à compiler Wine ou MPlayer avec les headers NVidia (et avec gcc4 en plus). Je n'ai pas essayé avec le dernier driver en date cependant.

Faudra attendre un moment avant que wine et mplayer et d'autre change eur code pour que ca compile avec les headers nvidia ...

C'est normalement inutile, si j'y arrive avec gcc4 sans souci.
Pour info, les anciens headers sont remis en place si on désinstalle le driver NVidia (à condition qu'il n'y ait pas eu plusieurs installs successives écrasant les anciennes).

C'est quoi les "principaux sites français" ?

Parce que sit c'est TF1, Virgin, la FNAC, je pense que c'est un peu normal : les plus futés (linuxiens) ne vont pas sur ces sites lamentables quand ils vont sur le net.

Merci pour toutes ces réponse enrichissantes :)

Au fait, kimono c'est plutôt "chose qui se porte", il n'y a pas la notion d'action dans le verbe "kiru", il faut l'ajouter par des particules.
Et merci pour la correction d'éthymologie ;)

Quelqu'un peut m'expliquer pourquoi on utilise un mot japonais dans le monde de l'impression, pour désigner une banderolle ?
Ou bien est-ce seulement ponctuel, parce que l'initiateur du concours nippophile (sinophile ? ...) ?

Non, gstreamer ne concurrence pas JACK, au contraire.
GStreamer possède un plugin pour JACK. GStreamer est une couche qui se trouve au-dessus de JACK.
Elle permet d'uniformiser, par exemple, les sorties de son vers JACK, ALSA, OSS. Ainsi, que tu veuille sortir du son vers JACK ou ESD ou ARTS ou ALSA directement, tu es sensé utiliser la même interface avec GStreamer.

KDE n'a aucun problème avec la Glib, qui est somme toute assez générique. D'autres produits d'infrastructure (hal ? dbus ?) l'utilisent, et sont eux-mêmes utilisés par KDE (je sais qu'il y a au moins une dépendance sur la glib dans kdelibs). GStreamer est du même acabit que la glib de ce point de vue.

GStreamer est une infrastructure multimedia permettant de faire abstraction des opérations de bas niveau (comme DirectX de MS je pense, mais limité à la vidéo et à l'audio je crois).
Pour essayer de vulgariser, en gros, c'est une bibliothèque de fonctions te permettant de faire des choses comme :
- extraire des données d'une source
- lire une entrée, lui appliquer une transformation, et mettre le résultat dans une ou plusieurs sorties
- insérer des données dans une ou plusieurs destinations

Les sources, destinations et transformations sont disponibles sous la forme de plugins.
Ainsi, si tu veux lire un fichier son dans ton programme, tu utilises toujours les mêmes méthodes, quelque soit le fichier son. Il te suffit d'avoir le plugin qui sait extraire les données de ton fichier son (ou d'une entrée de ta carte son, ou un logiciel qui génère des sons, ...). Puis si tu veux le jouer, il te suffit d'avoir le plugin pour, par exemple, ALSA, ou OSS, ou JACK, ... et il saura te sortir le son comme il faut, en utilisant toujours la même interface.
Ainsi, il est possible de lire tout format vidéo, audio, avec la même interface de programmation générique, du moment que tu as le plugin.

Dans le monde du fansub, SSA est LA référence, et son format aussi.
Le ASS, qui est en fait une extension du SSA, tend à devenir la référence, permettant tout un tas d'effets délirants, surtout utilisés dans les génériques.
SSA a disparu et étant freeware, tout est perdu, dommage. Mais le format est resté.

Je suis extrêmement reconnaissant à Pior pour l'info sur Sabbu. Je cherche un logiciel de ce genre depuis 2003. J'étais tombé sur Orange Slice, qui est abandonné et ne fonctionne pas correctement. J'en suis arrivé à laisser tomber mes fansubs tant que je n'ai pas une solution complète sous Linux, or il ne me manquait plus que l'équivalent SSA. Je comptais tenter régulièrement de le faire fonctionner sous Wine, et d'en créer un équivalent sous Linux.

Il est clair maintenant que je vais me mettre à Sabbu, et surement y contribuer, ou en tout cas faire des patchs pour moi. Je pensais faire un logiciel GTK+, mais utilisant GStreamer, plutôt que directement les bibliothèques ffmpeg ou libsndfile, ou ALSA.

Quelle bonne nouvelle aujourd'hui :) Bon, reste à voir si c'est utilisable, mais la base a l'air prometteuse.

As-tu essayé avec DVDRip ?
Il me semble qu'il y a un onglet dédié à cela.

J'ai tout compilé avec gcc 4.0.0, excepté glade 3, parce que j'installe pas de trucs en CVS sur ma machine.
Ca a compilé sans problème, excepté un -Werror dans un makefile de Anjuta je crois. Suffit de le virer.

Je ne suis pas d'accord.
J'utilise précisément ce genre de système, et il y a un tas de bonnes raisons.
La principale est que j'ai beaucoup plus de contrôle sur le packaging et l'installation des logiciels.
C'est parce que j'utilise ce système que je peux utiliser paco, que je suis en simpleinit-msb depuis des années (alors que certains trollent encore aujourd"hui sur un démarrage du système parallélisable, simple, ...), que je suis en LVM depuis des années, que j'ai pu installer gcc 4.0.0 à sa sortie, que j'ai pu compiler KDE avec (parce que ça va plus vite, même si c'est plus difficile à voir sur mon bi-pro), ...
Gentoo ne permet pas autant de contrôle, mais surtout, gentoo nécessite d'apprendre un système de paquetage pour bien le maîtriser, et de savoir interagir avec si on n'a pas d'ebuild pour un paquetage.
Par exemple, la dernière fois que j'ai regardé, on ne pouvait pas compiler grand chose avec gcc 4.0.0 sur Gentoo.

Je pense que quand on a "appris" avec LFS, une évolution intéressante est de capitaliser sur ce que l'on a appris. C'est ce que je fais depuis 2001 et je ne l'ai jamais regretté.

Mon système est basé sur une LFS, et tout ce petit monde est patché pour au moin gcc 3.4.3.
Il suffit de regarder sur BLFS (pour glib par exemple) ou chercher "ebuild package" sur Google (pour SDL par exemple), et d'aller dans le répertoire contenant les patches (files en général).

Les seuls packs que j'ai pas pu recompiler avec gcc 3.4.3, ce sont ceux de Gnomemm, surtout libglademm (le dernier 2.6.0). Je ne sais pas où est la régression, mais comme j'ai pas le temps pour ça ...

En revanche, avec GCC 4.0, c'est pire.
glib-1.2.10 compile sans souci, mais c'est pas le plus important.
Le pire, c'est que la glibc 2.3.5 vient de sortir, mais elle ne compile pas avec GCC 4.0. Les patches sont sortis (cf le site DIY Linux pour les hardcores comme moi pour qui LFS c'est un jeu pour enfants ;) ), mais je préfère attendre la sortie de glibc 2.3.6, qui va sortir, à ce que j'ai compris, rapidement, et exprès pour compiler avec gcc 4.0 !! Si c'est vrai, ça fera trois sorties de glibc très rapprochée, du jamais vu (surtout qu'avant, la 2.3.3 avait été sautée).

A mon avis, le -fvisibility ne sert que pour certaines biblio pour le desktop, pas besoin de tout recompiler !!
J'ai recompilé tout Gnome 2 avec. Pas trop difficile, le bug le plus courant est une déclaration en non statique, suivi d'une définition statique.
QT et KDE j'ai même pas essayé, car c'est vivement découragé partout (je vais essayer quand même tiens !).
Ce qui m'a fait le plus suer, c'est SDL, où il faut faire de sacrés modifs (parce que je ne maîtrise pas les alias de fonctions, celles-ci étant en assembleur ...).

J'ai fait tout ça car je voulais me préparer un bootcd pour mon Linux à moi, en gcc4, mais c'est pas pour demain, je vais rester en gcc 3.4.3 pour le bootcd pour l'instant.

Réponse de la part d'un utilisateur quotidien de Linux qui connaît le Libre.

A/ D'accord avec le début, pas avec la fin. L'apparence de logique binaire est bien plus simple à appréhender (oui ou non ?) que la logique humaine (oui, non, peut-être, quasiment, sans doute, ...). Je ne sais même pas si on peut appeler cela de la logique. Et avec des capacités logiques inférieures, on compense/intègre autant de défauts/spécificités de l'interface, on a juste plus de mal, et donc moins envie de recommencer.

D'où ça vient ça, que les ingénieurs font des mauvais utilisateurs ? Ce n'est tout simplement pas vrai. Le sophisme qui suit n'en est pas plus vrai. W32 n'est certainement pas un exemple de terrain avec de bonnes applications.

B/ Firefox est sans doute plus mauvais dans la version Linux que dans la version W32. Et effectivement, s'il y avait eu que des utilisateurs Linux, Firefox n'existerait pas. En effet, sous Linux, Galeon, Epiphany et Konqueror sont bien meilleurs (et bien mieux intégrés) que Firefox ou Mozilla, et cela depuis très longtemps.
Et cela grâce aux barbus ou pas, je sais pas. Enfin, c'est pas parce qu'on les insulte qu'ils n'ont pas fait du bon boulot, mais c'est un sophisme vieux comme le monde, certains n'hésitent pas à le ressortir dès que possible.

C/ Evidemment, c'est vite oublier toutes les autres applis libres qui ont démarrées ou existaient avant Linux. Je me retiendrais de donner mon avis sur le reste de ce point, mais je poserais une question.
En quoi la communauté elle-même a freiné les drivers sous Linux, le fait que Linux soit préinstallé en standard sur les PC, le fait que MS/Apple/Adobe/... ne développent pas leurs produits sous Linux ?
Y en a encore mais je vais m'arrêter là. Est-ce que ça veut dire que MS/Apple/Adobe/Dell/Compaq/... font partie de la communauté Libre ? J'étais pas au courant.

D/ On oublie trop vite que les FOSS sont libres. Rien que cela apporte tout un tas d'avantages.
En réalité, les gens en contact avec W32 ne peuvent pas le garder non plus sans une aide extérieure. Sinon, il rest à l'abandon, après qu'ils aient dépensé une fortune dessus et affirment tous que "l'informatique ça ne marche pas".
Porter ses logiciels sous W32, ça ne sert à rien pour le Libre si on ne fait pas la promo du libre en même temps. De toutes façons, l'infrastructure est complètement différente, donc, à part familiariser les utilisateurs, ça ne sert à rien. Les familiariser ne veut pas dire qu'ils vont switcher sous Linux.
Penser que KDE pourrait faire concurrence à l'API W32 sur son terrain c'est se fourrer le doigt dans l'oeil AMA, et c'est vite oublier l'histoire (pis devoir installer cygwin c'est déjà placer la barrière trop haut pour un utilisateur lambda).

E/ Il faudra m'expliquer quelle standardisation MS a imposé. Je vois que Linux qui ait imposé une quelconque standardisation. Et on n'y est pas encore. Un standard utilisable est forcément ouvert AMA.
MS n'a rendu aucun serveur plus accessible en terme de coût et de compétences, faut arrêter de raconter n'importe quoi. On doit pas vivre dans le même monde. Dans celui où je vis, je vois plein d'organisations annoncer qu'elles vont mettre Linux pour faire baisser les prix de la solution MS.
La vraie guerre est contre MS, ce sont eux qui l'ont lancée d'ailleurs. MS n'a rien contribué du tout à Linux ou à la standardisation que Linux apporte. MS n'a rien non plus de démocratique, comment peut-on sortir des anneries pareilles avec, par exemple, l'affaire VB6 ? Ou l'affaire de MS et de ses formats fermés dont ils refusent l'accès, alors qu'ils ont injonction de le faire par un tribunal ?
Non franchement, je m'arrête là, c'est plus une discussion intéressante, ça tourne au délire ...

Le grand public voit plus facilement des projets libres comme FireFox ou OpenOffice que linux, ne serait-ce que parce qu'il les utilise.

Tout à fait, le seul hic, c'est qu'ils ne savent même pas que ces projets sont libres. Ils voient qu'ils sont gratuits et c'est tout. La promotion n'est pas faite autour de la liberté de ces applis. En bref : ces applis ne servent à RIEN pour promouvoir le libre, et donc le choix. Elles amènent simplement un peu plus de contrôle sur l'infrastructure.
Linux n'est pas qu'un choix logiciel parmi d'autres, c'est un des seuls kernel libre utilisable, avancé et actif.
Et je préfère voir un Linux libre bardé de libre (ce qui est la majorité des cas) qu'un Windows bardé de propriétaire illégal (ce qui est la majorité des cas).

Pourtant il me semble que de plus en plus il devient difficile de trouver un Windows sans applis libres (ma constatation dans mon entourage qui n'est pas spécialement technophile) : un firefox par ci, un leechftp par là, (ho un R !) un OpenOffice ou un media player classic et parfois même un double boot.

Maintenant, il va falloir m'expliquer où est l'avantage pour le libre dans tout ça si les utilisateurs n'ont aucune notion du Libre (ce qui est le cas pour la plupart).

Je pense que si l'arrivée du dernier FireFox a fait plus de bruit que la sortie du dernier Konqueror c'est surement parce que FireFox tourne sous Windows et que ça concerne plus que les même pas 3% d'utilisateurs KDE

Moi je pense surtout que c'est grâce à la grosse promo qui a été faite autour. Parce que Mozilla tourne aussi sous Windows hein, et est là depuis bien plus longtemps, et pourtant, il n'est pas aussi connu !!!

Tout ça pour dire que je pense qu'il faut laisser les gens utiliser ce qu'ils trouvent bien ( = ça correspond à leurs critères et envies) et que les produits libres ont des atouts qui pèsent suffisement dans la balance pour être choisis de manière spontanée (la liberté est une feature :) ).

Et moi je ne pense pas. Pourquoi ? A cause de tous les exemples que j'ai dans la vraie vie, où les gens ne font aucun effort, où ils t'inventent des défauts inexistants dans une appli parfaitement fonctionnelle (OOo) pour retourner sous ce qu'ils connaissent, et t'avouent ensuite que c'est parce qu'ils ont la flegme de changer (les fonctionnalités ont pris 10 secondes à trouver pour un type comme moi qui n'y connaît rien à ces logiciels, et y a une grosse doc en français imprimée, avec deux pages sur les équivalences avec les logiciels sous Windows).

Aider les gens à utiliser du libre, c'est bien (par exemple, en developpant du libre sur des OS proprio, install party ou conseil). Les pousser à le faire je trouve ça très mal.

En suivant ce raisonnement, je pourrais dire : fournir l'école gratuitement aux gens, c'est bien, les forcer à y aller je trouve ça très mal. Heureusement, je ne pense pas comme cela du tout.
En effet, ce comportement est poussé uniquement par l'envie de ne pas fatiguer son cerveau.
Comment choisir entre libre et proprio si l'on ne connaît que le proprio ?
C'est impossible évidemment, mais ça n'arrête pas certaines personnes sur pas mal de forums.

Quel revirement quand même !
Autant que je me souvienne, MGE supporte Linux au moins depuis 1999, date à laquelle j'ai acheté mon onduleur (toujours là, mais la batterie doit être presque morte).
Mais à l'époque, le client Linux était : très intrusif, moins évolué que le client Windows, pas simple à installer, en ncurses, et aux sources fermés. Au moins ça fonctionnait à peu près bien.
Je me rappelle avoir demandé une version libre, mais rien n'y a fait. En montant de version de Linux et autres, psp était devenu inutilisable.
Il y a encore 6 mois, je cherchais une version libre et il n'y en avait pas (la version sur le site ne fonctionnait pas chez moi de toutes façons), c'est là que j'ai découvert NUT.
Maintenant que PSP est libre, a une interface graphique et tout, c'est la panacée qui arrive d'un coup :)

Au fait, il s'interface avec la partie client de NUT, ou bien est-ce que ça la remplace et discute directement avec le serveur ?

Toi tu peux traduire ce que tu veux, le problème, c'est que L. Mc Voy, lui, il dit clairement (dans l'article en plus) que développer un outil spécifique pour le kernel (donc sous Linux) n'est pas du tout une menace pour son produit, qui aurait maintenant la majorité des licences sous Windows.
Ce qui contredit la raison qu'il a évoqué pour arrêter le dév de la version gratuite, puisque je suis sûr que les personnes qui faisaient du reverse-engineering sur BK n'avaient pas l'intention d'implémenter une version Windows ou pour autre chose que le kernel.
En tout casn je suis sûr que c'était pas fait pour couler BK.

Pour moi, la position de BM reste logique, mais aussi incompréhensible si l'on met en jeu seulement les principes et la morale (comme c'est ce qui est mis en avant par L. Mc Voy).
Si je met les profits en jeu, tout de suite, ça devient plus compréhensible. En somme, je soupçonne une forte dose d'hypocrisie.

J'ose espérer que c'est une blague, en tout cas pour Gnumeric ?

Nan parce que ma femme, qui est comptable, n'utilise peut-être pas toutes les fonctionnalités d'Excel, mais ce qui est sûr, c'est qu'elle l'utilise toute la journée au boulot et intensément.

En bref : elle dit que Gnumeric est largement au-dessus de tout ce qu'elle a essayé sous Linux jusqu'à présent, dixit elle-même : "c'est mieux qu'Excel !!!", et elle utilise Excel de manière professionnelle. Alors bon, c'est qu'une anecdote, mais ça ne fait que corroborer tout ce que j'entends sur les fonctionnalités de Gnumeric, et va à l'encontre de ce que dit le post parent.

En plus long :
Ma femme utilise beaucoup les tableurs parce que ça doit être ce qu'elle connaît (et comprend) le mieux en informatique. Elle a utilisé le tableur d'OOo pour son boulot et pour elle. Elle m'a fait tout un tas de reproches sur le tableur d'OOo, bon OK, elle a connaissance de la doc (en français), et elle m'avait avoué qu'elle avait pas envie de changer tout ce qu'elle savait. Elle utilisait KSpread pour ses fichiers perso et disait que c'était suffisant, mais que tout marchait pas bien.
Récemment passé en KDE 3.4 et Gnome 2.10, les applis sont maintenant mélangées dans les menus des deux DE. Un matin de la semaine dernière, elle m'appelle tout excitée : "regarde ! J'ai trouvé un super tableur, ça fait tout comme Excel, c'est même mieux, y a pas tel bug !". Les yeux ébahis, je lui demande comment elle a trouvé ce programme. Elle me montre alors le menu Bureautique de KDE, avec Tableur Gnumeric (ou un truc comme ça) tout en bas du menu.
Au passage, vu qu'elle utilise aussi Galeon comme navigateur, ça finit de casser à mes yeux les deux arguments suivants anti-LL :
- Il est très difficile de trouver à quoi sert une appli dont on ne connaît pas le nom sous Linux (j'utilisais Gnumeric parce que je suis sous Gnome, mais je lui avais pas dit, maintenant, c'est terminé pour KSpread :( )
- Les applis Gnome s'intègrent très mal dans KDE et vice-versa. Moi je ne suis pas une référence quand je dis que je ne vois pas de différence en utilisant mp3Kult sous Gnome, mais ma femme qui a utilisé Gnumeric (et Galeon) sans souci, sans même se rendre compte qu'il y avait des choses différentes, ça en dit long. Ah si, elle a quand même bloqué sur l'enregistrement de fichier : elle cherchait comment enregistrer dans un sous-répertoire de son HOME (faut cliquer la petite flèche, le texte explicatif à côté est encore trop technique pour elle).
- Ma femme, utilisateur lambda typique qui n'y comprend rien à l'informatique, n'a jamais été aussi productive à la maison, que depuis Janvier 2001 où j'ai finit de basculer sous Linux, venant de Windows (moi aussi, mais on m'accuserait d'être fanatique).
- Gnumeric est très loin devant le tableur d'OOo et au moins égal à Excel pour la plupart des utilisateurs professionnels non programmeurs (ma femme fait des petites macros pas trop compliquées)

Faux, aucun OS ne fait ça très bien.
Lis un peu ce que disent les autres avant d'essayer de les casser.

Moi j'ai un CD multisession et je veux le lire. Avec ton système, l'environnement me mets en mode gravure sur mon multisession, mais ce n'est PAS ce que je veux : il faut tout défaire et trouver un moyen de lire son CD, ou alors toujours activer une boîte de dialogue demandant ce qu'on veut faire. En plus, l'analyse du media m'oblige à attendre pour rien. Tu ne peux pas tout avoir, c'est impossible à l'heure actuelle.
Je connais un OS où ils ont implémenté un truc comme tu décris. Résultat des courses, j'ai tout désactivé. Cette fonctionnalité m'a fait rater des gravures.Parfois, ça lockait tout pendant plusieurs minutes.

Dans le même ordre d'idée, les extensions Epiphany existent depuis longtemps, alors je n'ai pas compris où était la nouveauté dans la news.
C'est juste parce qu'il y en a de nouvelles ?

Ce que je veux dire, c'est que ce que tu veux faire impliquerait l'architecture qui se trouve sous ton gestionnaire de session.
Ce n'est pas au gestionnaire de session de servir de relais, surtout pas, il n'a pas assez d'infos pour valider qu'il a le droit de transférer un mot de passe à une appli.
Ce n'est pas non plus à PAM de lancer une appli (qui dépend de la session), l'archi de mon truc n'est pas bonne.

Il faudrait changer toute l'architecture, et je pense que ça ne vaut pas le coup pour un simple desktop. De plus, modifier l'infra du bureau pour une appli du type wallet ne me semble pas judicieux. Il faut administrer ce genre de choses, or un utilisateur lambda ne sait pas administrer sa machine.

Ce que ta boîte fait sous Windows est tout à fait possible à faire sous Linux. J'avais implémenté un LDAPv3 (en me basant sur le howto qui est largement dépassé) avec Kerberos et cie en 2002.
Il faudrait que le wallet intègre la notion de tickets Kerberos et puisse dialoguer avec.
Je suis personnellement revenu à un système plus light, sans kerberos. Parce que autant c'est très bien pour une entreprise le single sign-on, autant pour un desktop c'est une misère à gérer. Le moindre composant qui pète et c'est la misère à revenir à l'état normal. J'ai tout arrêté le jour où j'ai eu une longue coupure de courant, mon onduleur a claqué trop vite, résultat : base LDAP corrompue, openldap redémarre plus, plus rien ne marche, partition chiffrée irrécupérable. Une semaine pour réparer er revenir en l'état.

Sinon le coup des merdes style Windows ça me parait déplacé ici : la gestion des droits d'accès sous Windows n'a pas à rougir de celle sous Linux à mon avis (aïe aïe je suis en train de pourrir moi même ma discussion)

Je pense que tu fais erreur. Tu confonds "granularité plus fine des droits d'accès" avec "plus évolué". La gestion des droits d'accès est un calvaire à configurer et administrer sous Windows ou sous tout OS implémentant plus que le ugo Unix (acl et cie).
Un utilisateur sous Windows a les moyens de se bousiller irrémédiablement l'accès à ses propres fichiers s'il joue avec les droits. Par comparaison, c'est impossible à faire sous Unix.
Je pense que la gestion des droits a bien à rougir sous Windows, au contraire (passant le fait que la plupart des applis ne sont même pas compatibles avec cette gestion poussée des droits).

Si c'est le gestionnaire de session qui lance le wallet, alors pas besoin que les applications aient accès au mot de passe, et pas besoin de le laisser trainer en clair quelque part.

Non, on te l'as déjà dit : Il ne faut pas :P
Le gestionnaire de sessions est une application au même niveau que le wallet. Si tu lui permet de conserver ce genre d'infos, c'est déjà trop tard niveau sécurité.
Il faut implémenter à un niveau plus bas (PAM me semble être au bon niveau).
De plus, le gestionnaire de session gère l'accès à la session, pas les applis qu'elle contient. C'est au DE (KDE, GNOME, ...) de faire ce boulot. "Il ne faut pas" faire des rustines de ce genre dans un gestionnaire de session, on s'expose à tout et n'importe quoi sinon.

Les développeurs ne voulaient pas implémenter le wallet sans mot de passe pour la simple et bonne raison que du coup, tout chiffrement est facile à casser, car au pire il n'y en a pas, et au mieux, il est basé sur des infos connues de tous (nom de user par exemple).

La mémoire PAM ça n'existe pas. Je pensais à un procédé comme dans KDE. Dans le cas où les accès aux sessions passent par PAM (c'est pas le cas de toutes les distros ?), on peut implémenter un module de session qui garde en mémoire volatile (pas sur disque) un certain temps le mot de passe fourni par l'utilisateur, accessible aux applis de cet utilisateur uniquement (du genre, en utilisant le cookie X de session pour l'accès aux infos). Ou plus simplement, un nouveau module PAM exprès pour le wallet de KDE, auquel il suffit de passer les infos (en implémentant use_first_pass dans le module).

Et tu as tort de penser que la seule explication au problème que tu exposes est technique et pas théorique. Je pense que c'est le contraire.
Car la problématique est une problématique de sécurité et d'architecture. Si tu implémentes ton concept, il faut qu'il soit accessible et utilisé par tous les gestionnaires de session, et exprès pour le wallet de KDE, tout en étant raisonnablement sécurisé. Je ne vois que PAM pour faire cela, c'est même fait pour.
Il faut tout de même bien jouer son coup en plaçant le module partout où il faut, parce que sinon, dès que l'utilisateur change son mot de passe : boom, plus d'accès au wallet (mallette).
Du coup, il faut aussi prévoir un "rechiffrement" de la mallette au changement de mot de passe : pas simple tout ça, ça a tous les ingrédients pour échouer.

A part ça, GDM peut lancer des programmes à différents jalons de l'ouverture de session. KDM je sais pas, XDM je ne veux pas savoir ...

Je me demande ...

Parce que dans le monde Windows, parfois on fait payer en plus, pour avoir accès aux betas (des mauvaises langues diront que les versions finales sont aussi des betas).
M'enfin, c'est vrai que personne ne clame que "Windows est prêt pour le bureau", ce n'est donc pas comparable ...

C'est l'idée que tu exposais que je trouve bête, pas toi.

Les autres moyens ? Celui proposé par les utilisateurs KDE (sur la majeure partie des desktops Linux, ça sera équivalent) à savoir un wallet sans mot de passe, la "mémoire" dans PAM, ...

Mais le résultat est le même que si tu ne mets pas de mot de passe au wallet : tu entres dans ta session et tu as accès à tous les mots de passe que le wallet contient.
Ce qui ne me va pas dans ce que tu proposais, c'est que EN PLUS, on avait accès à ton mot de passe de session.

Ben non, ce n'est pas le seul moyen.
Mais de toutes façons, le wallet ouvert sans mot de passe à l'ouverture de session revient quasiment au même pour un utilisateur : pas de mot de passe en plus à taper, wallet ouvert ...

Oui, quelqu'un s'est penché dessus.
Il y a tout un groupe qui bosse dessus, mais j'ai oublié leur nom (cherche à BigLux et festival ou liaphon).

Ces groupes bossent sur leur propre outil liaphon, mais malheureusement, non reconnu par gnome-speech ou, je pense, le module ktts de KDE.

J'ai terminé cette semaine un XML pour nALFS permettant d'installer Festival 1.95-beta avec support du français (voix mbrola, donc solution pas complètement libre). J'ai mon propre patch car la dernière version de festival patchée pour supporter le français est la 1.4.3.

Malheureusement, je n'ai pas réussi à faire fonctionner mon Festival avec gnome-speech, j'espère que ça fonctionnera avec ktts. J'ai des options à passer à festival (festival --language french) pour avoir le français par défaut (à moins qu'on puisse changer la conf, si qqn est fort en Scheme et connais Festival). Si on peut configurer ktts pour passer les options à festival, c'est gagné je pense.
Festival est aussi très ancré dans OSS, et doit l'utiliser assez mal, des fois ça marche pas même avec aoss (j'ai un dmix bien configuré, mais je crois que l'ALSA du noyau 2.6.10 marche pas bien, je verrais en 2.6.11).
Mais KDE étant la session de ma femme, je vais devoir attendre la release pour tester ktts.