Aldoo a écrit 2794 commentaires

Bon, quelques pistes intéressantes déjà chez FUSE :

http://fuse.sourceforge.net/wiki/index.php/FileSystems

Notamment RelFS et Mediadatabase.

La question c'est si ce n'est pas un peu compliqué pour que ma boulangère installe ça dans sa boutique...

En parlant de Wesnoth...

Ça pourrait être sympa d'utiliser le frontend graphique de Glest avec le gameplay et les scenarii de Wesnoth.

J'ai l'impression que ces 2 projets ont pris des directions complètement opposées mais complémentaires.

L'un est plutôt pas très joli (désolé !) mais tout le reste déchire : de vraies quêtes, une histoire prenante, des unités nombreuses et équilibrées, etc, etc

L'autre, c'est un moteur 3D qui en met plein la vue, mais le jeu est strictement limité à se battre contre une IA sur quelques cartes mais sans campagne, ni même de mode multi-joueur.

Les deux mis ensemble pourraient faire pâlir pas mal de jeux proprio du genre, enfin, pas les RTS, puisque le résultat serait du tour par tour.

Reste à trouver de bonnes volontés pour faire les modèles 3D des unités de Wesnoth.

Tiens, Microsoft devrait faire pareil pour Windows ;-)

Microsoft Windows XPbetaSP2 est sorti, maintenant ils se disent qu'il est temps d'arriver au stade Vista alpha... (?!)

Oui mais non !

Le contrat peut très bien avoir des clauses invalides dans le droit français ou d'un autre pays. À ce moment-là elles sont réputées nulles, mais pas le contrat dans son entier !

Une question qui se pose aussi, quand on utilise MSN, et que l'on accepte donc tacitement un contrat avec Microsoft, de quel droit on dépend ? Français ? Américain ?

Euh, c pas parce que Microsoft dit "Faut pas !" que c'est illégal !

Bon, maintenant, dans ce cas particulier, je ne sais pas si ça l'est.

Ça me rappelle les déboires d'amaroK, et de son logo en tête de loup vue de profil. À une époque ils avaient retiré un temps ce logo car quelqu'un s'était rendu compte qu'il ressemblait beaucoup trop à celui d'Elfquest.

http://www.kde-look.org/content/show.php?content=18848&f(...)

Finalement ils l'ont remis.

Théoriquement il n'y a que toi qui peut lire ton trousseau, même non crypté.

Seulement :
1 - root peut lire ton trousseau (mais comme dit plus haut, si on n'a pas confiance en root... )
2 - si les droits en lecture ne sont pas limités à ton compte utilisateur, c'est embêtant
3 - si ton système se fait infiltrer et que quelqu'un gagne les droits de ton compte utilisateur, tu te fais prendre tes password
4 - si tu es dans un environnement physique non sûr (situation très courante !), quelqu'un pourrait profiter de ton compte et de tes passwords. D'où l'intérêt de crypter, d'où l'intérêt du gestionnaire de trousseau, où des options permettent que le trousseau se ferme, soit après chaque utilisation, soit après une certaine période de temps. Tu peux aussi gérer l'accès au trousseau appli par appli.

Maintenant si tu es dans une situation où ça ne te dérange pas que ton trousseau soit ouvert une bonne fois pour toutes, la solution avec le module de PAM m'a l'air pas mal.

>> 3) re-password du user pour apt-get des maj de sécu !
Je ne suis ni débianeux ni ubunteux, mais ce ne serait pas plutôt le password du root qu'on te demande, là ?

J'ai cru entendre qu'Ubuntu avait une manière assez spéciale de gérer le root... ça a peut-être un rapport ?

> Bof, ça c'est de toute façon le cas. Rien n'empêche le root de, par
> exemple, patcher gnome-keyring pour logguer les mots de passe. Je
> crois que de manière générale, il faut soit faire confiance à son root,
> soit ne pas toucher à la machine.

Je pense qu'effectivement, on n'a pas trop le choix, à moins d'être carrément parano, et de stocker son trousseau de clés sur une "clé" USB... et encore. Non, de toute manière, le root peut changer n'importe quel morceau de programme de l'OS ou autre. Si on n'a pas confiance dans le root, on ne peut pas avoir confiance dans la machine sur laquelle on travaille.

Bref, l'utilisation actuelle des différents wallets est bancale. Et ta solution avec le module pour PAM me semble la voie à explorer (sauf pour les trousseaux non cryptés).

Le password de login est renseigné au login manager, application lancée en root, qui va ouvrir une session utilisateur.

Le password du trousseau te sert à décrypter le contenu de ton trousseau, via et pour les applications utilisateur. Le trousseau est, je le répète, *crypté*, et est donc illisible sans clé pour tout le monde (y compris root). Ceci permet d'avoir une certaine confidentialité dans un environnement où l'on n'est pas soi-même l'administrateur du système.

Si tu es admin et seul utilisateur de ta machine, tu peux plus ou moins résoudre le problème du "double login" en choisissant d'être loggué automatiquement sur ton compte utilisateur sans demande de password (pas très secure, mais pourquoi pas).

Cela dit, si tu es le seul utilisateur de ta machine, tu n'as pas forcément besoin de crypter ton trousseau de clés (sauf si tu penses qu'on peut s'introduire frauduleusement sur ton système), et tu peux donc choisir un mot de passe vide (en tout cas, c'est possible avec le kwallet de KDE).

Revenons au problème initial : si on veut ni login automatique, ni password vide pour le trousseau, peut-on imaginer un système où le fait de se logguer "libère" la clé de déchiffrement du trousseau ?
Je ne dis pas que c'est impossible (il faudrait un peu d'imagination pour trouver un protocole sécurisé), mais dans l'état des choses, pour faire cela, il faudrait que le login manager (processus root) puisse d'une certaine manière transmettre la clé au gestionnaire de trousseau, ce qui veut dire que root aurait moyen de connaître la clé de déchiffrement du trousseau, et donc toutes les clés stockées dans le trousseau. Bref, ce n'est pas gagné.

Voilà, c'était à un truc comme ça que je pensais ! (pour la partie protocole).
Associer un morceau balisé, plus une proposition d'envoi de l'image.

Pour la partie utilisateur, il y a le cliquodrome. Ce serait bien d'y ajouter un raccourci clavier ctrl+lettre, puis chaîne représentant l'émoticône.

En fait, en y réfléchissant, je trouve assez foireuse la manière dont fonctionnent les emoticônes actuellement : c'est-à-dire remplacer automatiquement un texte tappé par une image.

Outre les problèmes des standardisation, il y a aussi le problème tout bête qui se pose quand on veut effectivement tapper ce texte.

Alors à l'âge d'aujourd'hui, où l'on utilise des clients graphiques, qui communiquent entre eux en XML (au moins pour XMPP), ce serait peut-être le moment d'utiliser l'expressivité de ce langage, avec des balises dédiées à l'envoi d'émoticônes, non ? (Qui propose une JEP ? :-p )

Au niveau client, on insérerait l'émoticône avec un raccourci clavier du genre ctrl+, puis code de l'icône, ou bien en accédant au menu déroulant de choix. Rapide, efficace, sans bavure.

Pour les smileys les plus courants (pour lesquels il y a consensus sur l'interprétation), on peut se permettre de conserver l'ancien système, c'est-à-dire, la conversion automatique en émoticônes.

Qu'en pensez-vous ?

on ne devrait pas relayer les poissons de site en site

...
...
on relaye bien les trolls !

Ah cette période va être chargée d'événements, avec la sortie de GNU/Hurd, et aussi je crois la prochaine debian en stable, wow !

Ou plutôt les transformer en .pdf.

Pour un document destiné à être lu (ou imprimé) uniquement, c'est bien mieux, c'est aussi standard, et le windowsien moyen a quasiment toujours Adobe Reader sur sa machine.

Pareil pour Psi (enfin, la version après la prochaîne d'après ce que j'ai compris... mais la version de dev fonctionne).

J'apprends des choses en lisant cette news : que Tapioca est aussi un client à part entière. Je pensais que c'était juste une lib pour être utilisée dans d'autres clients !

En fait, ce serait plutôt intéressant qu'ils ne se limitent pas à la musique libre.

Vous vous rappelez tout ce qu'on a pu dire sur DADVSI et les disquaires d'occasion ?

Eh bien, c'est l'occasion de montrer qu'on peut encore partager de la musique (copyrightée et tout le barda) sur des bases légales inattaquables.
Et si jamais ces bases légales étaient malgré tout attaquées, ce serait un exemple fort pour montrer l'absurdité de DADVSI.

Je vois qu'il y a des idées dans la team Kopete !
Enfin, ne trahissez pas l'esprit du projet.

Moi, je l'aime bien comme il est le Kopete (enfin, j'aimerais avoir plein de nouvelles fonctionnalités, comme le SIP, la machine à café, et tout..., j'aimerais aussi que tous les bugs soient corrigés, etc., etc.... mais bon, j'aime bien le fonctionnement global ;-) ).

Donc du flashy, oui, mais en option ! (avec éventuellement un packaging spécial djeunz pour la version windows)

PS : et au fait, est-ce que vous retenez libTapioca comme framework unifié pour la VoIP ?

Rien que le fait qu'il existe 7 licences CC, cela montre déjà qu'il existe de multiples conceptions de la liberté.

Ce qui est clair c'est que toutes ces licences possèdent certaines qualités du "libre", au moins la redistribution libre (et donc potentiellement gratuite).

On pourrait alors qualifier de libre une licence qui a des qualités de liberté, et alors tout CC serait libre (c'est plus ou moins la tendance dans la terminologie de Jamendo). Le problème c'est qu'on ne parle alors plus de la même chose quand on parle de la liberté d'une musique ou d'un logiciel.

La question c'est si on a besoin d'une terminologie unifiée pour décrire les licences d'utilisation de toute oeuvre de l'esprit. Il faut admettre que ce serait bien pratique de pouvoir se comprendre. Il faut aussi admettre que ça ne va pas être facile de changer des habitudes désormais fortement ancrées aussi bien dans la communauté du LL que maintenant dans celle de la ML ! Cela aurait dû faire partie du boulot de la fondation CC de clarifier cette terminologie.

Kopete, c'est une bonne base... mais là tu prêches des convertis. Kopete ne tournant que sous KDE, et KDE ne tournant pour l'instant que sur des plateformes à public "averti".

Psi, ça tourne partout (enfin, là où QT existe, mais ça inclue Linux Windows et MacOSX, ce qui est déjà pas mal !).

Pour revenir à Kopete, c'est vrai qu'en dehors de sa dépendance à KDE, je pense que c'est le client IM le plus près du but. Il n'y a qu'à voir les thèmes déjà disponibles sur KDE-look, et la facilité de définir des actions quelconques pour chaque événement (En utilisant DCOP, on peut faire pas mal de choses. J'ai déjà vu trainer un script implémentant l'effet fenêtre vibrante du wizz !).
Mais bon, voilà, à vouloir trop en faire, ce n'est plus si simple que ça. Rien que l'aspect multiprotocole et le concept de métacontact... et puis toute la personnalisabilité, fidèle à l'esprit KDE... Ça peut convenir à certains ados, mais seulement les plus duveteux (pour ne pas dire les plus barbus ;-) !).

Enfin voilà, Kopete a son public (dont je fais partie), mais il ne correspond pas au cahier des charges de Nicolas Blanco. On en reparlera quand KDE pour windows pointera le bout de son nez.

Pourrait-on suggérer à fd.o de publier une recommandation pour pallier ces problèmes ?
Au fond, il s'agit bien de mettre au point un protocole entre applications plein écran, le serveur X, et l'environnement de bureau ?

Certes, il sera très difficile de donner les instructions pour refaire le morceau à l'identique. Mais à cela j'objecterai que :

1 - pour rejouer à l'identique (ou presque), on a toujours le fichier mp3/ogg/flac/...
2 - pourquoi vouloir rejouer avec les mêmes sentiments ? L'art de l'interprétation c'est savoir y mettre un peu de ses propres sentiments.
3 - même dans le cas des logiciels, fournir les sources ne garantit pas qu'on obtiendra forcément le même binaire compilé : ça dépendra de l'architecture sur laquelle on compile, de la version du compileur, des différents drapeaux utilisés, etc.

Bref, pour revenir à la musique, je pense que des informations purement techniques comme les partitions et les réferences des instruments devraient suffire pour donner le qualificatif de "source ouverte". De même que la page imprimée d'une recette de cuisine suffirait, bien qu'elle ne remplace pas le savoir faire du chef.

Comme quelqu'un l'a remarqué plus haut, comme bon petit client d'IM opensource et multi-plateforme, on a déjà Psi.
Très bien foutu, mais austère, il a pourtant su s'imposer sur de nombreux bureaux.

Maintenant, l'idée de Nicolas Blanco, c'est qu'il faut être capable de s'adresser aux djeunz ziva wizzeurs kikoo lol, et pour ça proposer le client bien foutu (comme Psi), mais aussi super flashy jacky qui clignote de partout.

Il se trouve que Psi est fait en Qt, et qu'on peut donc facilement changer le thème graphique des widgets pour radjeunir l'interface. Voilà pour la djeunitude graphique statique.

On a aussi la chance que Psi utilise le protocole Jabber, qui est très bien documenté, et très facilement extensible (et a déjà été étendu de nombreuses fois). Qu'est-ce qui empêche d'implémenter les wizz et autres émoticônes personnalisées dans une extension du protocole ? La fondation Jabber n'avaliserait certainement pas ces ajouts, mais peu importe : le client Psikodjeunz (fork de Psi créé pour l'occasion) resterait compatible avec les autres clients jabber sur l'essentiel. D'ailleurs cette situation se produit régulièrement avec certains clients jabber originaux.

En plus des fonctionnalités flashy d'MSN, il faudrait songer à en inventer quelques nouvelles, qui seraient le truc en plus qui ferait migrer depuis MSN. Bon, il y a déjà l'absence de pub, c'est déjà énorme ! Sinon, je verrais bien un système d'interfaçage avec des sites webs sociaux à la sauce Flickr, Youtube, Jamendo, Wikipedia... (ajoutez ici vos service préférés !), avec un moyen facile de dégager tout ce dont on ne se sert pas, pour ne pas surcharger l'interface.

Bon bon... qui crée psikodjeunz.sf.net ?

Je pense que dans le cas de la musique ce serait bête de se limiter au 100% libre, au sens FSF, tout bêtement parce que de la musique aussi libre que ça, ça n'existe quasiment pas.

L'offre sous CC pullule, mais seules 2 des licences permettent à la fois rediffusion, modification et usage commercial.
Et encore, aucune de ces licences n'oblige à fournir le "source" (ce seraient les partitions, la liste des références des instruments,... peut-être d'autres détails techniques nécessaires à la "recompilation"/réinterprétation de l'oeuvre... à voir, je ne suis pas musicien !). Bref on est plus dans le freeware (freesic ?) que le free software.

Pourtant, on ne va pas cracher sur ceux qui autorisent la rediffusion gratuite de leur oeuvre, car c'est déjà un premier pas vers la "librisation".
Mais peut-être sera-t-il nécessaire en un second temps de faire un peu de propagande/pédagogie pour remettre les pendules à l'heure.

Certainement pas "backporter" !
Si tu tiens vraiment aux anglicismes, plutôt "backporté"...

Mais évidemment un verbe plus français serait mieux venu, tant qu'il est bien mis au participe passé !