dimanche 21 mars

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

[54] Sortie de la version 1.0.0 de Kerrighed
[60] Firefox 1.0.1 et autres nouvelles Mozilliennes
[18] ETF, UT 2004, America's Army, etc.
[34] Sortie de Templeet 3.0
[12] KQEMU : un module d'accélération pour QEMU
[6] Livret de compétences : Appel au développeurs et Coding Party
[7] Ultimate Boot CD v3.2
[20] Calendar 0.8.3+ en français
[32] amaroK 1.2 est là !
[0] Erlang REPOS 1.1 est prêt

Liens connexes

Annonce (288 clics)
KDE (688 clics)
Features (518 clics)
"Klax" KDE 3.4 RC 1 Live-CD (641 clics)

Dépêche modérée par

Ragnagna

Dépêche éditée par

Logiciel : KDE 3.4 RC1

Posté par David Douard (). Modéré le 01 mars 2005.

Conformément au calendrier, KDE 3.4 Release Candidate 1 vient de sortir.

Disponible via les sources (et konstruct en particulier), l'équipe de KDE propose aussi un LiveCD (traduction ?) pour pouvoir tester immédiatement sans avoir à "casser" sa configuration.

Rappel : KDE est un environnement de bureau très complet pour GNU/Linux et autres BSDs (et Unix).

NdM : Klax, le LiveCD de KDE 3.4RC1, se base sur le liveCD Slax, basé sur Slackware 10.1. Il pèse 375 Mo, est en anglais, et aRts est désactivé par défaut.

Annonce (288 clics)
KDE (688 clics)
Features (518 clics)
"Klax" KDE 3.4 RC 1 Live-CD (641 clics)

> Lire la suite (63 commentaires, moyenne: 2,2). [dépêche : 1763 caractères]

La liste des améliorations est (très) longue, on notera par exemple :
- un visualiseur PDF (kpdf, moteur basé sur Xpdf) très puissant,
- un début d'intégration Zéroconf (aka Rendezvous chez Apple),
- intégration d'un énonceur de messages (synthèse vocale),
- KHTML s'améliore toujours davantage, avec un support CSS2 de plus en plus complet,
- support d'un mot de passe "maître" pour kwallet, voire d'une utilisation sans mot de passe (cette fonctionnalité ayant été ajoutée à la demande des utilisateurs, et contre l'avis des développeurs),
- kcontrol propose de plus en plus de réglages, il permet par exemple de configurer les "touchpad" synaptic et les souris Logitech (niveau de batterie, résolution, etc.),
- support de la transparence (avec les extensions X qui vont bien),
- nouveaux kioslaves, l'un des "features" de KDE qui "roxe" des ours un maximum,
- possibilité de naviguer dans les répertoires d'images en mode "album photo" avec Konqueror,
- kontact s'améliore, avec en particulier l'intégration du module de synchronisation (Palm, etc.),
- etc. etc.

Et bien sûr un nombre impressionnant de bugs corrigés (et encore bien d'autres une fois que vous aurez rapporté ceux que vous aurez découvert).

La version finale est prévue pour le 16 mars, alors à vos compilos/liveCD !

PS : pour les grincheux qui trouvent anormal de publier cette info (ce n'est qu'une RC) sur LinuxFR, il me semble que l'objet d'une RC est d'être très largement diffusée, si on veut une version finale de bonne facture. D'où publicité. Et puis il s'agit tout de même d'une version importante de KDE.

NdM : Nous ne publierons pas forcément toutes les RC à venir, préparez une bonne dépêche pour la finale !

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Le lien du LiveCD

Posté par nakan (page perso, ) le 01/03/2005 à 08:27. (lien). Évalué à 6.

Et hop, le lien pour télécharger le live CD qui manquait cruellement à la news:

http://ktown.kde.org/~binner/klax/(...)

Bons downloads :-)

--
Au pays des pingouins, les manchots sont empereurs.

LiveCD mais pourquoi faire ?

Posté par Mickaël Sibelle (Jabber id, page perso, ) le 01/03/2005 à 08:29. (lien). Évalué à 1.

D'après ce que j'ai compris, ce live CD permet surtout aux développeurs de travailler et aux curieux de tester la dernière version.

Il contient KDE en VO (les i18n prenant trop de place).

[^]Re: LiveCD mais pourquoi faire ?

Posté par Rastaman (page perso, ) le 01/03/2005 à 10:18. (lien). Évalué à 1.
A propos de LiveCD, j'entends souvent une traduction qui est : "CD vif"

--
In tchio tour din ch'Nord ?
betizfest.info
- [^]Re: LiveCD mais pourquoi faire ?
  
  Posté par Jeanuel (Jabber id, page perso, ) le 01/03/2005 à 10:54. (lien). Évalué à 1.
  Moi j'aime bien "auto-CD" ou "CD-porteur" ou encore "CD auto-porteur" mais c'est plus long.
  - [^]Re: LiveCD mais pourquoi faire ?
    
    Posté par yoho (page perso, ) le 03/03/2005 à 11:43. (lien). Évalué à 3.
    Moi j'aime bien LiveCD.
- [^]Re: LiveCD mais pourquoi faire ?
  
  Posté par Me Nut (page perso, ) le 04/03/2005 à 08:34. (lien). Évalué à 5.
  La seule fois où j'ai vu cette expression "CD vif" (dans un journal de l'auteur de GCompris je crois) j'ai du mentalement la traduire en anglais pour comprendre de quoi le monsieur parlait... La francisation c'est bien, en abuser ça craint©
  
  --
  "On the internet, nobody can hear you being subtle" -- /usr/src/linux/Documentation/ManagementStyle

Vivent les RC

Posté par Zorro (page perso, ) le 01/03/2005 à 08:40. (lien). Évalué à 6.

Je trouve ça très bien, de publier les RC.
Si on ne trouve pas d'infos sur l'évolution des logiciels libres, je me demande où on les trouvera ? Quand même pas sur VNUnet...
À moins bien sûr qu'il n'y ait de la place que pour les RC Mandrake !
Il faudrait faire un sondage "Pour ou contre les actus sur les RC".

--
Aide instantanée sur Mandriva : retrouvez-nous sur http://chat.jabberfr.org/muckl_int/?room=mandriva

[^]Re: Vivent les RC

Posté par Mickaël Sibelle (Jabber id, page perso, ) le 01/03/2005 à 08:56. (lien). Évalué à 4.
Je ne sais pas combien les news sur les RC sont "censurées",
mais de mon point de vue de lecteur/commentateur ça va,
il n'y a pas trop de news sur les RC...
Surtout, il n'y a pas 42 news sur les RC d'une appli, et c'est mieux !

Je pense que publier des news sur les RC c'est bien,
mais pas concernant toutes les appli
(c'est là que les modérateurs interviennent pour orienter le site),
et pas à chaque RC (comme le dit la note du modérateur).

Conclusion : équilibre.

[+] [^]Vivent les RC, mais au bon endroit.

Posté par Florimond Simonklein (page perso, ) le 01/03/2005 à 13:02. (lien). Évalué à -2.
D'un autre côté, pour promouvoir les logiciels libre, il faudrait communiquer avec autre chose que "on a besoin de vous pour tester !"

On ne peut pas d'un côté clamer "GNU/Linux est prêt pour le bureau !" et de l'autre "Pour ne pas qu'il y ait de bugs plus tard dans votre bureau il faut les essuyer maintenant !" sur la première page d'un même site, une tribune plutôt reconnue par ailleurs je crois (votes de linuxjournal ?). La cohérence pour les non-initiés en prend un coup.

En ce qui me concerne, je préfère que les annonces de RC restent dans le domaine des journaux privés.
- [^]Re: Vivent les RC, mais au bon endroit.
  
  Posté par ookaze () le 01/03/2005 à 13:08. (lien). Évalué à 1.
  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 ...
  - [^]Re: Vivent les RC, mais au bon endroit.
    
    Posté par Florimond Simonklein (page perso, ) le 01/03/2005 à 13:36. (lien). Évalué à 2.
    Arrêtez moi si je me trompe, mais une RC est très différente d'une beta. Donc effectivement, ça n'est pas comparable.
    
    Quant à faire payer pour avoir des betas, pourquoi se priver si ça marche ? Ce qui me chagrine, c'est une généralisation hâtive. Pour la plupart des betas dont j'ai entendu parlé pour des trucs Windows, il fallait faire une candidature, et la beta n'était distribuée qu'à des testeurs "privilégiés", mais gratuitement. Ca a été le cas pour InstallShield DevStudio 9 à l'été 2003, tout comme pour World of Warcraft de manière plus récente. Deux produits au publics très différents (professionnels, particuliers), mais très larges.
    - [+] [^]Re: Vivent les RC, mais au bon endroit.
      
      Posté par Croconux () le 01/03/2005 à 19:27. (lien). Évalué à -2.
      Pour la plupart des betas dont j'ai entendu parlé pour des trucs Windows, il fallait faire une candidature
      
      Si seulement c'était le cas. Au boulot j'ai fait un Windows Update aujourd'hui et il me conseillait parmis les mises à jour urgentes l'anti spyware Microsoft. Le fameux truc en version beta qui propose de virer Firefox pour "des raisons de sécurité", le truc pour lequel MS offre un dédommagement (de 5$) s'il abime votre système. Et quand on le déselectionne il balance un gros warning : "Attention votre ordinateur ne sera plus sécurisé si vous n'installez pas cette mise à jour". C'est clair. Si je n'installe pas un machin en version beta pas testé je vais être la proie des vilains pirates. Nul doute que tous les utilisateurs lambda vont cliquer sur OK sans réfléchir. Et grace au système qui propose d'envoyer des rapports de plantage automatiquement, une bonne partie de la planète se retrouve d'office beta testeuse du MS anti spyware.
      - [^]Re: Vivent les RC, mais au bon endroit.
        
        Posté par Matthieu Moy (page perso, ) le 01/03/2005 à 21:37. (lien). Évalué à 6.
        > Le fameux truc en version beta qui propose de virer Firefox pour
        > "des raisons de sécurité"
        
        Sauf que ça, c'est un fake ...
      - [^]Re: Vivent les RC, mais au bon endroit.
        
        Posté par zero heure (Jabber id, page perso, ) le 01/03/2005 à 22:57. (lien). Évalué à 2.
        un machin en version beta pas testé
        Faut pas déconner, Microsoft a des bécanes de tests. Ils doivent au minimum s'éviter les foudres des clients "grosse entreprise".
        Après, l'exotisme et l'inattendu étant la règle dans le monde du PC pour particulier, ça ne peut pas être 100% testé.
        D'accord, c'est vrai, on a souvent l'impression que c'est plus proche du 1 ou 2% testé, mais ... après tout c'est peut-être à cause des procédures de test? ou des testeurs qui baclent? ou des poissons rouges?
        
        --
        J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
        
        [^]Re: Vivent les RC, mais au bon endroit.
        
        Posté par Sébastien Bonnefoy (Jabber id, page perso, ) le 02/03/2005 à 16:25. (lien). Évalué à 2.
        Je ne sais pas, je m'en fous
        Ils feraient mieux d'aller tous boire un coup
        Et si la nuit les chats sont gris
        Est-ce que les petits pois sont rouges ?
        
        Mickey 3D
        
        Je poste car c'est pas completement hors sujet : voir le reste (et le titre) de la chanson... Et puis aussi l'écouter; moi j'aime bien.
        
        [^]Re: Vivent les RC, mais au bon endroit.
        
        Posté par François Becker (page perso, ) le 18/03/2005 à 11:24. (lien). Évalué à 1.
        >D'accord, c'est vrai, on a souvent l'impression que c'est plus proche du 1 ou 2%
        >testé, mais ... après tout c'est peut-être à cause des procédures de test? ou des
        >testeurs qui baclent? ou des poissons rouges?
        
        perso de tous les trucs qui m'ont choqué chez eux le plus marquant c'est la localisation... on a l'impression qu'elle a été faite par des stagiaires, et jamais relue... on arrive à des non-sens totaux... (ou alors c'est passé par le traducteur gougueule)
        
        --
        elle est libre ma musique : http://moala.online.fr/audiosite/
- [^]Re: Vivent les RC, mais au bon endroit.
  
  Posté par fabb () le 01/03/2005 à 13:41. (lien). Évalué à 4.
  > On ne peut pas d'un côté clamer "GNU/Linux est prêt pour le bureau !"
  
  Qui dit ça ?
  Presque personne. Le desktop commence tout doucement pour Linux et il n'est pas encore prêt. Il n'y a que depuis peu que le desktop est pris en compte par LSB et OSDN. Il n'y a que depuis peu que Red Hat ou Novell ou IBM parle de desktop pour Linux. Avant c'était les serveurs et les stations de travail.
  
  > et de l'autre "Pour ne pas qu'il y ait de bugs plus tard dans votre bureau il faut les essuyer maintenant !"
  
  Car tu crois que le "on est au top et on a besoin de rien" est responsable ?
  
  Cette attitude est du n'importe quoi.
  Même si GNU/Linux à 99,99 % du marché, c'est du n'importe quoi. Le logiciel doit toujours s'améliorer pour le confort, la productivité des utilisateurs finaux. On ne demande pas aux utilisateurs de développers ou tester. On incite ceux qui le veulent.
  
  > sur la première page
  
  C'est en seconde page et personne n'a réclamé la première page.
  
  > La cohérence pour les non-initiés en prend un coup.
  
  La cohérence c'est d'"éduquer" les non-initiés (par définition). Leur expliquer que le libre, le développement du libre, est public et qu'il n'y a rien à cacher. Que chaqu'un peut intervenir dans le développement/test mais qu'il n'est pas demandé d'être un développeur du libre pour utiliser les logiciels libres (par définition, c'est libre).
  
  Les logiciels en phase beta/test/rc ne sont pas pour les utilisateurs qui ne veulent pas tester/développer. Je crois que ce n'est pas compliqué à comprendre. Non ?
  - [^]Ok, j'ai bouletté.
    
    Posté par Florimond Simonklein (page perso, ) le 01/03/2005 à 14:10. (lien). Évalué à 0.
    
    Car tu crois que le "on est au top et on a besoin de rien" est responsable ?
    
    Je te renvoie le compliment : "Qui dit ça ?" Certainement pas moi en tout cas.
    
    C'est en seconde page et personne n'a réclamé la première page.
    
    Mea culpa, je voulais dire passer en dépêche plutôt qu'en journal. (Comme je les reçois via rss je ne fais pas de différence entre première et seconde page.)
  - [^]Re: Vivent les RC, mais au bon endroit.
    
    Posté par anonimulo () le 01/03/2005 à 22:33. (lien). Évalué à 7.
    > On ne peut pas d'un côté clamer "GNU/Linux est prêt pour le bureau !"
    
    Qui dit ça ?
    Presque personne. Le desktop commence tout doucement pour Linux et il n'est pas encore prêt. Il n'y a que depuis peu que le desktop est pris en compte par LSB et OSDN. Il n'y a que depuis peu que Red Hat ou Novell ou IBM parle de desktop pour Linux.
    
    Moi je dis ca.
    
    Je fais partie de "presque personne".
    
    Effectivement, c'est pas le point de focus de Redhat ou d'IBM, et c'est bien dommage que les leaders ne s'impliquent pas plus, mais on les comprend car dans ce secteur sinistré par le succès de Microsoft, il serait dur d'être rentable. RedHat ou IBM visent plutôt donc le marché des techos pour empiéter sur Sun ou HP/UX, mais Linux peut sans problèmes venir chercher des noises aussi Apple et Microsoft sur leur terrain.
    
    Jour après jour, je découvre une nouvelle pincée d'intelligence dans mon bureau Linux, j'adore. Est-ce juste un succès d'estime, Linux est-il inutilisable en dehors de mon petit nombril ? Non, j'habite en Allemagne, et je vois des gens de tout horizon l'utiiliser avec bonheur, des multitudes de SuSE, des Mandrakes dans les cyber-cafés ou autres call-center à destination du Otto-normaler-deutsch, des manuels pour apprendre à galoper sur le pinguin en pagaille dans la librairie de base et j'en passe. Si les mots ont encore un sens, la situation n'est pas celle que tu décris. Linux est dans l'état Mozilla 1.0, il y a des petits grincements de dents ici et là et le succès populaire ne vient pas, mais le talent et la technologie sont là, quand bien même personne ne le sait encore.
    
    Pas de fausse modestie, la réalisation collective qui a été accomplie jusqu'à aujourd'hui est magnifique.
    
    Beaucoup ont tendance à perdre cela de vue à cause de la mentalité "Open Source" qui fait qu'on focalise toute son énergie sur les problèmes ou sur les points qu'il est possible d'améliorer. Bien sûr c'est ce qui permet d'avancer, mais ca aveugle aussi : la tête dans le guidon, on rougit de honte devant le trou peu glorieux dans la chaussette gauche, et on discute des heures là dessus, et on ne voit pas qu'on est habillé dans un magnifique costar à 5 000 euros.

KDE 3.4

Posté par fabb () le 01/03/2005 à 09:00. (lien). Évalué à 5.

Ça sera dans FC4 test 1 (le 14 mars):
http://cvs.fedora.redhat.com/viewcvs/devel/kdelibs/kdelibs.spec?rev(...)
Comme ce n'est pas très claire, j'indique que c'est kde 3.4.0-rc1 et compilé avec gcc-4 (édition de lien plus rapide). Ça n'a pas encore atteind Rawhide.

> - support d'un mot de passe "maître" pour kwallet, voire d'une utilisation sans mot de passe (cette fonctionnalité ayant été ajoutée à la demande des utilisateurs, et contre l'avis des développeurs),

Plus d'info ? Je ne comprends pas bien le problème, l'avis des développeurs.

> PS : pour les grincheux qui trouvent anormal de publier cette info (ce n'est qu'une RC) sur LinuxFR, il me semble que l'objet d'une RC est d'être très largement diffusée, si on veut une version finale de bonne facture.

J'applaudis la démarche. La seconde page est nickel pour ça.

> NdM : Nous ne publierons pas forcément toutes les RC à venir, préparez une bonne dépêche pour la finale !

Il me semble que la première rc c'est suffisant voire parfait. Puis il faut le faire que pour les gros projets qui demandent beaucoup de test (Gnome, Mozilla, gcc, KDE, OOo, etc).

Il me semble aussi qu'il serait bon de passer les news sur la première beta des distributions qui intégre souvent des logiciels en rc ou beta et est un lieu idéal pour faire des tests. Ça évite de s'arracher les cheveux pour compiler et il y a le support du distributeur qui va filtrer les bugs qu'il faut remonter en upstream.

NB : Linux n'a maintenant *que* des rc. Linus (notre dictateur favoris) a décidé de nommer "rc" toutes les versions entre les versions finales. Il en avait marre des discussions sur "pre vs rc".

[^]Re: KDE 3.4

Posté par lezardbreton (Jabber id, page perso, ) le 01/03/2005 à 09:27. (lien). Évalué à 3.
Franchement, KDE sur FC3 ne me donnait pas envie. Aucune appli KDE ou presque n'était pris en compte par défaut. Exemples :
- client mail -> evolution
- navigateur web -> firefox

Après, c'est facilement modifiable, bien sûr, mais les paramètres de base de FC3/KDE me paraissaient vraiment surprenant.

Sais-tu quelles sont les évolutions prévues pour FC4 ?

Par ailleurs, il y a du neuf du côté de Mandrake : kaffeine remplace enfin totem comme lecteur vidéo par défaut sur la 10.2 !
- [^]Re: KDE 3.4
  
  Posté par fabb () le 01/03/2005 à 10:25. (lien). Évalué à 1.
  > - client mail -> evolution
  > - navigateur web -> firefox
  
  C'est comme ça depuis RH8.0...
  J'ai fait des stats il y a longtemps sur les mailing Fedora (user/devel/test) et evolution est de très très très loin le plus utilisé (autour de 85 %). En seconde position ce n'est pas kmail mais mutt...
  Par contre, KDE (le bureau) même s'il est moins utilisé que Gnome (Normal, Fedora est plus concentré sur Gnome que sur KDE) reste beaucoup utilisé (30 à 35 % au pif), il semble bien qu'une majorité d'utilisateur utilise evolution sous KDE.
  Notons que sur mailing devel il y a assez peu d'utilisateur KDE (10 % au pif)
  
  Donc le chois de Red Hat/Fedora est "normal".
  
  Enfin notons qu'il y a plein de distribution qui ne propose pas autant de choix que Fedora. Slack abandonne Gnome petit à petit, certaines version de Mandrake ou SuSE ne propose que KDE, Ubuntu ne propose que Gnome, etc.
  
  > Sais-tu quelles sont les évolutions prévues pour FC4 ?
  
  http://lwn.net/Articles/119500/(...)
  
  L'utilisation de gcc-4 est confirmé (planning reculé de 3 semaines) :
  http://lwn.net/Articles/124798/(...)
  
  Pour avoir eclipse, et autres "broutilles", FC4 suis un régime :
  http://lwn.net/Articles/124800/(...)
  
  C'est assez contre versé. Pour FC5, il n'y aura pas de problème. FC(n)+FE(n) vers FC(n+1)+FE(n+1) sera supporté par anaconda.
  Ce n'est pas vraiment un régime. FC3 = 4 CDs. FC4 = 4 CDs.
- [^]Re: KDE 3.4
  
  Posté par rb14 () le 01/03/2005 à 14:30. (lien). Évalué à 2.
  > Franchement, KDE sur FC3 ne me donnait pas envie.
  
  Utilise les paquets kde-redhat ( http://kde-redhat.sourceforge.net/(...) ), qui sont en fait les paquets sources KDE "authentiques" compilés pour une distribution redhat/fedora (de rh8 à fc3!, et même RHE). C'est disponible via un repositery yum (et apt).
  Historiquement, c'était pour contourner les modifs qu'apportait redhat à KDE, mais maintenant ça devient plus "fournisseur de paquets à jour".
  Y'a en ce moment KDE-3.3.92 dans unstable (rc1 sera disponible cette semaine), ça qui permet de tester tout ça.
  Cela permet d'avoir en plus l'ensemble des applis KDE (amarok, kile, digikam, ... ) ou des bibliothèques (baghira, gtk-qt-engine, ...), avec en bonus openoffice.org "KDEisé"!
  
  Bref, KDE clean sur une distribution très à jour et, quoi qu'on en dise, très stable (oui FC1 c'était pas trop ça).
  
  Le forum pour voir les news et l'activité: http://sourceforge.net/mailarchive/forum.php?thread_id=6710748&(...)
  - [^]Re: KDE 3.4
    
    Posté par fabb () le 01/03/2005 à 15:29. (lien). Évalué à 1.
    > avec en bonus openoffice.org "KDEisé"!
    
    Déjà dans la FC3 "standard".
    
    > Historiquement, c'était pour contourner les modifs qu'apportait redhat à KDE
    
    Red Hat apporte si peu de modif... Red Hat en fait plus pour Gnome. C'est surtout ceux qui n'utilise pas Fedora qui gueule...
    M'enfin, les gouts et les couleurs.
    
    > mais maintenant ça devient plus "fournisseur de paquets à jour".
    
    C'est surtout en ça que http://kde-redhat.sourceforge.net/(...) est appréciable.
    
    J'ai remarqué un "truc". Les bureaux Gnome et KDE ne sont plus aussi "unifiés" qu'avant. Certains vont dire "youpi" mais ça peut dire que Red Hat ne veut plus se faire chier à unifier les deux car selon leur retour ils doivent surtout avoir des utilisateurs de Gnome (puisqu'ils bossent sur Gnome et c'est le bureau par défaut).
    C'est que mon interprétation.

[^]Re: KDE 3.4

Posté par Nap () le 01/03/2005 à 09:40. (lien). Évalué à 2.

Plus d'info ? Je ne comprends pas bien le problème, l'avis des développeurs.

sans bien connaître kwallet, pour moi si il n'y a pas de mot de passe maitre alors les comptes ne sont pas chiffrés de manière sécurisée

ça me parait être un gros problème...

la question que je me pose : pourquoi n'utilisent-ils pas le mot de passe de la session ? Les gestionnaires de login ne permettent pas de le passer à l'environnement à l'ouverture de session ? Si c'est le cas, c'est une très grosse lacune des environnements libres !
- [^]Re: KDE 3.4
  
  Posté par Larry Cow () le 01/03/2005 à 10:15. (lien). Évalué à 5.
  Les gestionnaires de login ne permettent pas de le passer à l'environnement à l'ouverture de session ?
  
  J'espère que non. Moins il y a de gens (ou de logiciels) qui sont au courant du mot de passe non-chiffré, mieux c'est.
  
  Faute de quoi, on risque de se trouver une faille à la con dans l'un des logiciels "aware" ou d'avoir des versions "modifiées" qui trainent.
- [^]Re: KDE 3.4
  
  Posté par fabb () le 01/03/2005 à 10:27. (lien). Évalué à 2.
  > Si c'est le cas, c'est une très grosse lacune des environnements libres !
  
  Non, c'est très bien.
- [^]Re: KDE 3.4
  
  Posté par ookaze () le 01/03/2005 à 10:30. (lien). Évalué à 2.
  Sans vouloir être offensant, je trouve cette idée de passer le mot de passe dans l'environnement d'une bêtise sans nom.
  
  Je trouve en plus que le gestionnaire de login est à un niveau trop élevé pour faire passer ce type d'infos. Une "mémoire" dans PAM serait plus judicieux je pense (je trouve ça aussi stupide, juste un peu moins).
  - [^]Re: KDE 3.4
    
    Posté par Nap () le 01/03/2005 à 11:06. (lien). Évalué à 1.
    c'est parce que pour moi c'est le seul moyen de chiffrer des données de l'utilisateurs sans avoir à retaper un mot de passe
    
    contre ta volonté, je suis offensé... je pense qu'il y a des choses plus bêtes que mon raisonnement
    - [^]Re: KDE 3.4
      
      Posté par ookaze () le 01/03/2005 à 11:29. (lien). Évalué à 1.
      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 ...
      - [^]Re: KDE 3.4
        
        Posté par Nap () le 01/03/2005 à 12:24. (lien). Évalué à 2.
        
        Ben non, ce n'est pas le seul moyen.
        Et c'est quoi les autres ? Justement j'aimerais bien savoir, histoire que la discussion avance au lieu de m'attaquer sur ma bétise (bétise que je ne nie pas complètement, hein)
        
        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 ...
        
        bah oui, mais dans ce cas, par quoi sont protégés les comptes ? c'est quand même ça le problème... Je sais pas comment ça marche dans le détail, mais pour moi si on a pas techniquement besoin du mot de passe pour ouvrir le "wallet", je ne vois pas comment les comptes sont réellement protégés.
        
        [^]Re: KDE 3.4
        
        Posté par Nap () le 01/03/2005 à 12:25. (lien). Évalué à 2.
        désolé, j'ai merdé avec les balises blockquote (c'est tellement chiant à taper aussi ce truc, je me gourre une fois sur deux)
        
        [^]Re: KDE 3.4
        
        Posté par fabb () le 01/03/2005 à 12:50. (lien). Évalué à 1.
        Je vais essayé de clarifier les choses.
        Si t'as un compte, le compte est pour toi. D'accord, c'est évident mais ça doit être rappelé. La soeur ou ton pote n'ont pas à travailler sous ton compte donc il n'ont pas accès à tes mots de passe. Si l'OS est bien conçu (ce qui est le cas de Linux), faire attention à son compte est suffisant.
        
        Donc pourquoi les crypter ?
        Crypter a un avantage : se protéger de l'administrateur qui peut mettre son nez partout.
        Personnellement, je crypte mes données sensibles. N'étant pas parano je ne crypte pas grand chose. Je pense qu'un mot de passe "master" pour certaines données est un plus. Par exemple FireFox le fait pour les mots de passes des sites et j'apprécie ça. Sinon je devrais faire ça manuellement et c'est lourdingue.
        
        Ceci dit, l'administrateur peut toujours contourner les "master" mot de passe. Par exemple il lui suffit d'installer un firefox "bidouillé". Donc, ça a encore ses limites. M'enfin avec rpm (deb?) tu peux vérifier que les programmes installés ont la bonne signature. Si la signature n'est pas bonne, tu donnes un coup de boule à l'admin ou t'installes localement à ton compte un firefox dont tu auras vérifié la signature.
        
        [^]Re: KDE 3.4
        
        Posté par Nap () le 01/03/2005 à 13:43. (lien). Évalué à 2.
        
        Ceci dit, l'administrateur peut toujours contourner les "master" mot de passe. Par exemple il lui suffit d'installer un firefox "bidouillé".
        
        Alors là je comprends pas trop... si il s'installe un firefox bidouillé, ça lui permettra pas de déchiffrer les mots de passe des autres :)
        
        ou alors tu veux dire que le firefox installé dès le départ est bidouillé. Dans ce cas il est tordu ton admin, il ferait mieux d'installer un keylogger, ça lui éviterait de bidouiller du code.
        
        Bref le problème est toujours le même : il faut taper plusieurs fois un mot de passe : session, wallet, firefox...
        
        J'ose espérer qu'un jour firefox intégrera les wallet gnome et kde, mais il y aura toujours deux mots de passe à taper, ce qui ne peux s'expliquer que par des limitations techniques, et n'est donc pas satisfaisant.
        
        Pour l'instant la seule solution serait kerberos, mais c'est pas envisageable pour un poste de particulier par exemple.
        
        [^]Re: KDE 3.4
        
        Posté par fabb () le 01/03/2005 à 13:52. (lien). Évalué à 1.
        > Alors là je comprends pas trop... si il s'installe un firefox bidouillé, ça lui permettra pas de déchiffrer les mots de passe des autres :)
        
        Certe. Mais il peut par exemple connaitre le mot de passe "master" (installation d'un mouchard dans firefox qui maile les mots de passe tapé) que tu utilises.
        
        > il ferait mieux d'installer un keylogger
        
        C'est aussi une autre possibilité.
        
        > J'ose espérer qu'un jour firefox intégrera les wallet gnome et kde, mais il y aura toujours deux mots de passe à taper, ce qui ne peux s'expliquer que par des limitations techniques, et n'est donc pas satisfaisant.
        
        J'ai l'impression que tu fais exprès de ne pas comprendre. Si t'es "parano", tu utiliseras un mot de passe pour le "wallet". Si tu ne l'ai pas, alors n'en utilises pas. Dans ce dernier cas, ça sera comme sous Windows (ou presque).
        
        [^]Re: KDE 3.4
        
        Posté par Nap () le 01/03/2005 à 14:16. (lien). Évalué à 2.
        
        J'ai l'impression que tu fais exprès de ne pas comprendre.Si t'es "parano", tu utiliseras un mot de passe pour le "wallet". Si tu ne l'ai pas, alors n'en utilises pas.
        
        Détrompe-toi, j'ai parfaitement compris. Seulement je rêve d'un système où par défaut tout est chiffré (mode parano si tu préfères) et où aucune contrainte n'est ajoutée pour l'utilisateur. Et je pose des questions techniques sur la faisabilité de ce système. Désolé de t'avoir énervé...
        Pour ce qui est du stockage d'informations sensibles, on peut appeler ça de la parano, après c'est une question de vocabulaire :) En tout cas je veux bien être parano en ce qui concerne les mots de passe des applications d'entreprise par exemple.
        
        [^]Re: KDE 3.4
        
        Posté par fabb () le 01/03/2005 à 14:37. (lien). Évalué à 1.
        > Seulement je rêve d'un système où par défaut tout est chiffré
        
        Mais c'est impossible. Mets ta partition root en crypté (c'est possible), quoi qu'il en soit lorsque le système tourne les données sont en claire pour les applis.
        Une partition crypté, c'est bien si on te vole le disque dure.
        Même si ta partition est crypté, il faut toujours un bon OS !
        
        > et où aucune contrainte n'est ajoutée pour l'utilisateur.
        
        Il serait bien de n'avoir aucun mot de passe ni rien, mais on ne peut pas techniquement et théoriquement (peut-être en rève...).
        
        Je retente une explication. Si les applis n'utilise pas de mot de passe alors il ne faut pas de mot de passe (!) et donc tes données sont lisibles. Que de façon intermédiaire ça tripote un mot de passe dans un coin pour (dé)crypter des données sur le disque dure ne change rien. Le seule truc positif, c'est que c'est plus sûr si tu n'es pas loggué pour prévenir les indélicatesse de l'administrateur ou les voles de disque dure. Sinon, c'est 0 en gain de sécurité.
        
        [^]Re: KDE 3.4
        
        Posté par yoho (page perso, ) le 03/03/2005 à 12:07. (lien). Évalué à 1.
        Un jour tout le monde aura une carte d'identité qui comporte une signature numérique et qui te permettra de d'identifier pour te logger sur ton PC et de renseigner tous les credentials à ta place (sans compter t'authentifier auprès des administrations, etc...). Tu l'insère dans un lecteur de carte et zouuh.
        
        Du coup, plus un seul mot de passe à taper nulle part.
        
        On me fait signe que ça existe déjà dans un pays francophone pas si éloigné du nôtre...
        
        [^]Re: KDE 3.4
        
        Posté par ookaze () le 01/03/2005 à 13:05. (lien). Évalué à 1.
        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.
        
        [^]Re: KDE 3.4
        
        Posté par Nap () le 01/03/2005 à 13:28. (lien). Évalué à 2.
        bon je dois vraiment être bête car je ne comprends pas le coup du wallet sans mot de passe, ou alors tu as voulu dire "avec mot de passe"
        je résume une partie de la discussion :
        
        pour moi c'est le seul moyen de chiffrer des données de l'utilisateurs
        
        Ben non, ce n'est pas le seul moyen.
        
        Et c'est quoi les autres ?
        
        un wallet sans mot de passe
        
        comment le wallet sans mot de passe chiffre-t-il les comptes de l'utilisateur ?
        
        bon, sinon, c'est quoi la mémoire PAM ? ça m'intéresse. beaucoup ce truc
        c'est un espace mémoire réservé à l'utilisateur ?
        
        En tout cas, ce qui me gène dans tout ça, c'est de se baser uniquement sur les protections offertes par l'OS (à part le coup du chiffrement sans mot de passe du wallet où j'ai rien compris)
        Pour stocker des informations sensibles comme des mots de passe, il me semble impératif de chiffrer le tout avec un mot de passe maitre. Si on ne peut pas utiliser le mot de passe de la session, on est obligé d'en avoir deux ou de taper le même deux fois, ce que l'utilisateur aura du mal à comprendre, et moi aussi finalement car la seule explication qu'il peut y avoir est une explication technique (limitations des interactions entre le gestionnaire de session et la session elle même) et non pas théorique.
        
        En effet on pourrait parfaitement imaginer que le gesionnaire de session ouvre lui même la session du wallet avec le mot de passe de l'utilisateur. Or il ne peut techniquement qu'ouvrir la session.
        Il faudrait un mécanisme indiquant à la session de lancer le wallet avec le mot de passe.
        
        Enfin pour préciser les choses je n'ai bien sûr jamais voulu que toute application puisse accéder au mot de passe de la session :)
        je voyais les choses dans l'autre sens : la session, possédant le mot de passe au moment de l'ouverture, ouvre le wallet avec celui-ci.
        
        Autre idée : le gestionnaire de session peut-il lancer un programme dans la session une fois celle-ci ouverte ?
        
        [^]Re: KDE 3.4
        
        Posté par ookaze () le 01/03/2005 à 13:45. (lien). Évalué à 1.
        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 ...
        
        [^]Re: KDE 3.4
        
        Posté par Nap () le 01/03/2005 à 14:08. (lien). Évalué à 2.
        
        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).
        
        Très bien, dans ce cas, les développeurs, toi et moi sommes parfaitement d'accord sur ce point :)
        
        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).
        
        ça a l'air vachement bien, ça pourrait d'ailleurs être utiliser par le wallet de gnome aussi. Et dans ce cas c'est PAM qui lance le wallet ?
        
        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.
        
        Alors là, j'ai beau te relire dix fois, je ne vois que des explications techniques. Evidemment, si c'est mal fait, ça marche pas. Evidemment c'est compliqué et il y a des risques que ce soit mal fait et donc que ça ne marche pas. Mais je ne vois pas d'obstacle insurmontable théoriquement ni d'erreur architecturale. Il y en a peut etre, mais tu ne me les donnes pas ici.
        
        Pour terminer, si je fais toutes ces remarques et contre-remarques, c'est parce que ma boite développe ça sous windows, et que c'est parfaitement possible, puisque ça marche très bien (rechiffrements etc). Hélas, c'est proprio...
        
        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 ...
        
        Idem pour XDM :)
        Ici il manque donc juste une spec freedesktop.
        
        [^]Re: KDE 3.4
        
        Posté par fabb () le 01/03/2005 à 14:41. (lien). Évalué à 1.
        > ça a l'air vachement bien, ça pourrait d'ailleurs être utiliser par le wallet de gnome aussi. Et dans ce cas c'est PAM qui lance le wallet ?
        
        PAM c'est très bien mais ce n'est pas pour ça. PAM c'est pour l'authentification.
        
        [^]Re: KDE 3.4
        
        Posté par ookaze () le 01/03/2005 à 14:55. (lien). Évalué à 2.
        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.
        
        [^]Re: KDE 3.4
        
        Posté par Nap () le 01/03/2005 à 17:41. (lien). Évalué à 2.
        la différence est qu'on ne le fait pas avec kerberos... le module d'authentification de windows (la gina), qui gère l'authentification et le changement du mot de passe, lance le logiciel à l'ouverture de session en lui passant le mot de passe. La différence est que dans notre architecture, c'est le wallet qui décide si il donne ou pas les mots de passe, suivant l'appli. J'avais mal compris le principe de kwallet.
        
        Je vois de quel howto tu parles, il est complètement obsolète effectivement.
        
        [^]Re: KDE 3.4
        
        Posté par fabb () le 01/03/2005 à 13:47. (lien). Évalué à 1.
        > En tout cas, ce qui me gène dans tout ça, c'est de se baser uniquement sur les protections offertes par l'OS
        
        Car c'est ce qu'il faut faire !
        Sinon tu ponds des merdes styles windows.
        
        > Si on ne peut pas utiliser le mot de passe de la session, on est obligé d'en avoir deux ou de taper le même deux fois
        
        Si tu n'as pas à le taper deux fois alors il traine en claire quelque part. C'est un problème de sécurité évident.
        
        > Enfin pour préciser les choses je n'ai bien sûr jamais voulu que toute application puisse accéder au mot de passe de la session :)
        
        Mais comment tu garantis ça sans te baser sur l'OS ?
        
        [^]Re: KDE 3.4
        
        Posté par Nap () le 01/03/2005 à 13:57. (lien). Évalué à 2.
        
        > En tout cas, ce qui me gène dans tout ça, c'est de se baser uniquement sur les protections offertes par l'OS
        
        Car c'est ce qu'il faut faire !
        Sinon tu ponds des merdes styles windows.
        
        Ok, si C'Est Ce Qu'Il Faut Faire, alors je m'incline :)
        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)
        
        > Si on ne peut pas utiliser le mot de passe de la session, on est obligé d'en avoir deux ou de taper le même deux fois
        
        Si tu n'as pas à le taper deux fois alors il traine en claire quelque part. C'est un problème de sécurité évident.
        
        > Enfin pour préciser les choses je n'ai bien sûr jamais voulu que toute application puisse accéder au mot de passe de la session :)
        
        Mais comment tu garantis ça sans te baser sur l'OS ?
        
        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. Je ne dis pas que c'est la solution que je veux (je préfèrerais peut-être passer par l'intermédiaire de la session elle-même, ou toute autre solution du genre, je ne maitrise _pas du tout_ ces mécanismes), mais je pense qu'elle prouve le concept.
        
        [^]Re: KDE 3.4
        
        Posté par fabb () le 01/03/2005 à 14:26. (lien). Évalué à 1.
        > Sinon le coup des merdes style Windows
        
        Je pensais à Win 3.x 9x qui n'avait rien côté OS. Windows 2000 démontre clairement qu'il faut un OS solide côté sécurité et ne pas s'appuier uniquement sur les applis.
        
        > Si c'est le gestionnaire de session qui lance le wallet, alors pas besoin que les applications aient accès au mot de passe
        
        Si elle n'ont pas accès au mot de passe alors elle ne l'utilise pas. On est d'accord ?
        Ce qui veut dire que n'importe quel programme peut accéder au wallet sans utiliser de mot de passe (qu'il soit stocké de façon crypté ne change rien au problème).
        
        [^]Re: KDE 3.4
        
        Posté par Nap () le 01/03/2005 à 14:34. (lien). Évalué à 2.
        
        Ce qui veut dire que n'importe quel programme peut accéder au wallet sans utiliser de mot de passe (qu'il soit stocké de façon crypté ne change rien au problème).
        
        Ah ben ouais je suis con...
        
        J'avais complètement oublié que le wallet marche dans ce sens : l'appli lui demande le mot de passe.
        
        Je pensais que c'était le wallet lui-même qui identifiait l'appli et ne lui donnait que son mot de passe à elle.
        
        Désolé :(
        
        [^]Re: KDE 3.4
        
        Posté par ookaze () le 01/03/2005 à 14:38. (lien). Évalué à 2.
        
        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.
        
        [^]Re: KDE 3.4
        
        Posté par fabb () le 01/03/2005 à 15:35. (lien). Évalué à 2.
        > Il faut implémenter à un niveau plus bas (PAM me semble être au bon niveau).
        
        Perso, je ne comprend pas t'on insistance avec PAM.
        Tu vas mettre quoi comme condition d'authentification dans PAM ?
        Un truc du genre :
        - si uid=toto alors il peut accéder aux mots de passe toto.
        
        Pour faire ça, c'est très simple, tu fais un fichier uniquement accessible à toto. Inutile d'utiliser PAM.
        
        [^]Re: KDE 3.4
        
        Posté par pasBill pasGates () le 02/03/2005 à 16:31. (lien). Évalué à 3.
        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.
        
        Toi t'as jamais vraiment joue avec chown et chmod on dirait...
        
        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).
        
        Moi j'en doutes enormement, Windows a le merite d'avoir une techno standard dans tout l'OS, contrairement a d'autres systemes ou les ACLs ont ete "hackees" dedans et que les applications ne supportent pas correctement car ecrites pour la plupart pour ugo.
        
        [^]Re: KDE 3.4
        
        Posté par gnumdk (page perso, ) le 03/03/2005 à 09:52. (lien). Évalué à 2.
        >les applications ne supportent pas correctement car ecrites pour la plupart
        >pour ugo
        
        Mwai, faire un script shell tar_acl qui sauvegarde les acl, spa la mort ;)
        
        C'est vrai que pour l'instant beaucoup d'outils ne supporte pas les ACLs. Et avec l'arrivée des ACLs NT dans Samba 4, ca risque d'être de moins en moins utilisé vu que les droits unix suffisent des qu'il ne s'agit pas d'un serveur de fichier.
        
        [^]Re: KDE 3.4
        
        Posté par fabb () le 03/03/2005 à 18:39. (lien). Évalué à 1.
        > Mwai, faire un script shell tar_acl qui sauvegarde les acl, spa la mort ;)
        
        Star supporte acl.
        
        Dar ( http://dar.linux.free.fr/(...) ) support les acl et les attributs étendus.

captures

Posté par moulux () le 01/03/2005 à 09:32. (lien). Évalué à 9.

Quelques captures dispo ici

http://teolus.free.fr/(...)

+

[^]Re: captures

Posté par Johann Ollivier-Lapeyre (page perso, ) le 01/03/2005 à 10:09. (lien). Évalué à 3.
Le meilleur ajout de cette version pour les pinailleurs du desgn comme moi, c'est qu'il ont refait les vieux écrans style années 80 qui était vraiment moche... ex:
- page d'accueil de konqueror
- page d'accueil de la config KDE
- ...

C'est beaucoup plus jolie aujourd'hui

Il ont refait aussi les infobulles du tableau de bord. très classe.

Pour la page d'accueil de konqueror, outre le design, les liens directs (dossiers utilisateur, reseaux, périphériques (...) sont vraiment une bonne idée.

--
----------------------------------------------------------------
"Be a man, run TRUNK !" - #kde-devel@freenode.org

LiveCD (traduction ?)

Posté par Clément varaldi () le 01/03/2005 à 09:46. (lien). Évalué à 3.

Dans la documentation Gentoo, on a choisi de le garder tel quel.
Un LiveCD, des LiveCD (sans s)
http://dev.gentoo.org/~neysx/trads-fr-conventions.html(...)#doc_chap4_sect14

Pour rester dans le sujet, KDE3.4 sera la première version qui sera proposée sous Gentoo sous forme de une application KDE = un ebuild/un paquet.
Ce qui fait que probablement un peu de "retard" dans la sortie de la chose sera à prévoir. Mais le travail est déjà commencé depuis quelques temps déjà. En espérant que ça aille comme prévu :)
Lire pour cela : http://www.gentoo.org/doc/en/kde-split-ebuilds.xml?style=printable(...) (en cours de relecture pour la version française d'ailleurs)

Enonceur de messages pour le français

Posté par Frédéric COIFFIER (Jabber id, ) le 01/03/2005 à 09:53. (lien). Évalué à 1.

D'après ce que j'ai vu dans la précédente bêta, cette application peut utiliser Festival (qui est libre mais ne gère pas le français) ou d'autres applis (qui ne sont pas libres mais doivent supporter le français [je n'ai pas testé]).

A votre connaissance, existe-t-il quelque part dans un recoin du net, encore méconnu, une appli de synthèse vocale supportant le français et libre ? Ou existe-t-il quelque chose en développement (dans des labos universitaires) ?
Je crois avoir vu que Festival supportait maintenant l'italien (qui est aussi une langue latine donc peut-être plus proche du français) : quelqu'un s'est-il penché sur la difficulté de supporter une nouvelle langue avec Festival ?

[^]Re: Enonceur de messages pour le français

Posté par ookaze () le 01/03/2005 à 10:56. (lien). Évalué à 2.
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.
- [^]Re: Enonceur de messages pour le français
  
  Posté par baud123 (Jabber id, page perso, ) le 01/03/2005 à 12:53. (lien). Évalué à 3.
  tu as la distribution OraLux qui travaille sur le sujet
  
  http://oralux.org/(...)
  http://oralux.org/faq.php#syntincluded(...) synthèse vocale incluse : EFM
  http://www.culte.org/projets/biglux/(...)
  
  sinon j'avais pris des notes il y a quelques temps
  http://wiki.eagle-usb.org/wakka.php?wiki=SyntheseParole(...)
  
  gnome-speech quand tu as 4 fenêtres qui s'ouvrent au démarrage de session, c'est presque rigolo, mais fatigant à la longue :-)
- [^]Re: Enonceur de messages pour le français
  
  Posté par Frédéric COIFFIER (Jabber id, ) le 01/03/2005 à 13:11. (lien). Évalué à 3.
  Effectivement, du côté de BigLux, il y a eu des travaux pour Festival (malheureusement, pas de fichier son pour juger de la qualité) :
  http://www.culte.org/projets/biglux/(...)
  
  A priori, l'utilisation de MBROLA comme moteur semble plus performant mais malheureusement MBROLA n'est pas libre... Sinon, il est vrai que le rendu avec ce moteur est très bon (mais je n'ai aucune idée de ce qui se fait commercialement [pas pu essayer la démo de FT R&D])
  
  Enfin, sur le site de BigLux, une étude va être faite pour essayer d'optimiser le rendu avec Festival d'après ce que je viens de lire. En tout cas, leurs travaux semblent vraiment intéressants !
  
  Pour ce qui est de KTTS, je pense qu'il ne devrait pas être difficile de supporter de nouveau moteur... Même si ce n'est pas le cas pour la 3.4, une requête pourraient être faite pour les versions suivantes !

[^]Re: Enonceur de messages pour le français

Posté par peco () le 02/03/2005 à 15:06. (lien). Évalué à 1.
En français, je ne sais pas, mais il existe une version en Espéranto :
http://www.cybercom.net/~dcoffin/esperanto/(...)

On peux ajouter soi même une voix à Festival. Ca prend un peu de temps, mais ça peut être amusant !
- [^]Re: Enonceur de messages pour le français
  
  Posté par anonimulo () le 02/03/2005 à 22:06. (lien). Évalué à 3.
  Ouais mais c'est de la triche la syntèse vocale pour l'Esperanto.
  1 lettre == 1 son et toujours le même, l'accent toujours sur l'avant-dernière syllabe, kaj tiel plu, le bonheur du programmeur fainéant.
  
  Les vrais hommes sont capables de faire de la synthèse vocale pour des phrases en francais comme : "Les poules couvent au couvent"

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : KDE 3.4 RC1

Le lien du LiveCD

LiveCD mais pourquoi faire ?

[^]Re: LiveCD mais pourquoi faire ?

[^]Re: LiveCD mais pourquoi faire ?

[^]Re: LiveCD mais pourquoi faire ?

[^]Re: LiveCD mais pourquoi faire ?

Vivent les RC

[^]Re: Vivent les RC

[+] [^]Vivent les RC, mais au bon endroit.

[^]Re: Vivent les RC, mais au bon endroit.

[^]Re: Vivent les RC, mais au bon endroit.

[+] [^]Re: Vivent les RC, mais au bon endroit.

[^]Re: Vivent les RC, mais au bon endroit.

[^]Re: Vivent les RC, mais au bon endroit.

[^]Re: Vivent les RC, mais au bon endroit.

[^]Re: Vivent les RC, mais au bon endroit.

[^]Re: Vivent les RC, mais au bon endroit.

[^]Ok, j'ai bouletté.

[^]Re: Vivent les RC, mais au bon endroit.

KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

[^]Re: KDE 3.4

captures

[^]Re: captures

LiveCD (traduction ?)

Enonceur de messages pour le français

[^]Re: Enonceur de messages pour le français

[^]Re: Enonceur de messages pour le français

[^]Re: Enonceur de messages pour le français

[^]Re: Enonceur de messages pour le français

[^]Re: Enonceur de messages pour le français