Cyrille Pontvieux a écrit 483 commentaires

Moi qui utilise en général des mots de passe à sécurité forte, j'ai déjà du mal à tous m'en souvenir (mais j'y arrive). Alors quand, dans une entreprise pour mon cas, on me demande de changer tous les mois, j'en reviens à choisir un mot de passe un poil plus court (oui parce que y'a des longueurs max aussi sinon c'est pas drôle), et je rajoute le mois derrière.

En en discutant avec plusieurs collègues au fil du temps, je me suis rendu compte que bcp de gens faisaient comme moi ou de manière similaire (un chiffre qui s'incrémente). Du coup, l'intérêt est carrément nul, alors que si on demandait à utiliser un mot de passe long et avec des caractères non-alpha, à changer tous les ans, ça serait sûrement plus sûr.

Certes, FF pourrait récupérer le codec à travers le système d'exploitation mais quid des OS pour lesquels le codec en question n'existe pas ?

Mais de toute façon pour l'instant, que le système puisse ou ne puisse pas lire du h264, tu n'as pas la vidéo. Alors si l'OS sait faire, tant mieux, sinon on n'a pas pire qu'actuellement.
Je vois pas où est le problème.

Oui c'est sûr que j'ai vachement envie de réencoder ma musique en mp3 pour la mettre sur la baladeur alors que la majorité de ce que j'ai est en vorbis. C'est sûr c'est plus pratique...

Je suis complètement d'accord et en ai fait l'expérience. C'est vrai que ces critères ne sont pas forcément justes, mais je conçoit qu'il faut bien des règles. Reste à savoir si les règles sont à revoir quand la société évolue…

Je ne vois pas le rapport. Le journal dit simplement que le noyau 2.6.32 sera supporté plus longtemps en terme de backport, et ce tant que certains des distributions concernées envoient des infos sur les patches à intégrer.
Il est toujours très simple en général, de changer de noyau sur une distrib pour un plus récent. Si, comme tu le dis un type a un processus PowerPC, a une nvidia et veut utiliser la libata et nouveau, il lui suffit de prendre un paquet d'un noyau plus récent ou de recompiler un kernel s'il a du temps à perdre. Et puis ça c'est le problème des distributions, pas de Linux. Ici Greg se propose de maintenir cette version plus longtemps tant que ces distributions jouent le jeu.
Si Ubuntu par exemple, n'intègre pas la version 2.6.33 comme tu le dis, ben c'est de sa faute et pas de la faute de Linux et encore moins de Greg.

Oui c'est vrai que c'est assez con cette phrase. En 83 il a lancé le mouvement du libre avec l'ambition d'écrire un système libre : GNU. Le système n'a jamais été fini en 83 (Hurd est toujours pas fonctionnel d'ailleurs) et Linux n'existait pas encore...

C'est Madame Michu.
Après quelques recherches, j'ai trouvé ça (c'est pas le top mais c'est un début) :
http://www.strategies.fr/blogs-opinions/idees-tribunes/11684(...)

Tiens d'ailleurs, pour ceux qui veulent pas/ne peuvent pas avec flash, voici un lien qui va bien :
ftp://www.mandrivafr.org/pub/screenshots/images/

Typique d'une utilisation à la con.

Du flash pour 7 copies d'écran...du grand n'importe quoi !

Ça a l'air d'être un très bon outil qui comble un gros manque des BIOS.

Comme grub2 arrive et que le liveUSB de ma distrib peut également utiliser maintenant grub2, je me demande dans quelle mesure ce module syslinux pourrait être adapté pour être lancé par grub2. Est-ce que c'est un binaire lançable depuis un gestionnaire de démarrage comme grub(2), lilo, syslinux, ou uniquement par syslinux.
J'ai du mal à comprendre la dépendance à syslinux. Peut-on m'expliquer svp.

C'est beta parce que grub2 n'a pas encore implémenter la pile réseau et donc ne peut servir de remplaçant complet à grub.

Heuh, pas en 777, sinon ça revient à donner le droit d'exec sur des scripts qui seraient posés sur la clé. Plutôt a-x+rwX (c'est à dire 777 uniquement pour les répertoires).

Complètement faux.

Les ACLs ne fonctionnement que s'ils sont actifs sur la distribution/OS. Sinon, c'est les droits POSIX qui s'appliquent.
J'ai essayé d'utiliser une clé USB en ext2, j'ai laissé tombé devant les différences de comportement en fonction des distrib. Et j'ai pas testé sur Mac et BSD.

Y'a un manque dans ext mais c'est normal car basé sur POSIX et POSIX ne prévoit pas ce cas de figure. Il faudrait pouvoir bypasser les droits sur un répertoire dans ext (sur / pour une clé USB donc) pour écrire systématiquement comme "root:root" en 777. Il faudrait que cette possibilité soit de base dans ext.

Bref dire que techniquement, actuellement il n'y a pas de soucis c'est se voiler la face.

Ahhh dit comme ça, je suis bien d'accord.

Sauf que tu masques intentionnellement ou non des killer-features comme on dit. L'audio, la video, ça vient doucement sur Jabber. Quand ce sera là, il sera alors possible de "remonter la pente par effet boule de neige inverse". Mais là en l'état, c'est trop de "fonctionnalités" de perdu pour le petit gars sur MSN. Pourtant comme tu le dis, Jabber a également des super fonctionnalités (messages hors ligne y compris dans les chatrooms, ressources, meta-contact, échange de fichiers simplifié - aidé par les clients certes, html dans les messages, attaquable avec une API simple - depuis un forum par exemple, gestion des droits dans les chatrooms, meta-contacts, GPG - pour certains clients, SSL, ...), mais apparemment ce n'est pas assez "killer". Skype a réussi à fédérer une communauté (un réseau pour reprendre ton terme, qui va ptre mieux) alors que le marché était pris. Y'a plusieurs personnes qui ont un client MSN et le client Skype. C'est donc que c'est tout à fait possible de faire en sorte que les gens adhèrent à un nouveau réseau, mais pour cela il faut une fonctionnalité de poids qui fasse pencher la balance. Pour l'instant j'ai l'impression qu'il y a beaucoup de choses très intéressantes de mon point de vue, mais apparemment pas du point de vue des gens.
Il est également important d'assurer de la publicité afin de se faire connaitre. Les gens veulent ce qu'on leur propose à tout bout de champs, pas forcément ce qui est mieux.

Je répondais au monsieur qui a écrit le journal et j'indiquais un serveur et ma raison perso.
Je vois pas en quoi j'ai dis qu'il fallait utiliser des passerelles ?

Maintenant, puisque c'est apparemment le débat :

J'utilise une passerelle vers MSN (je suis français et c'est l'IM le plus utilisé ici).
Un client multi-protocole ? Lequel ? Parce que moi j'aime bien avoir un vrai client Jabber, pas un Pidgin qui sait faire autant du XMPP que le driver nv sait faire de la 3D (troll inside :p)
Je ne vois pas en quoi je suis "limité" par ma passerelle (les fonctionnalités de ma passerelle me conviennent parfaitement). En tout cas pas moins que si j'utilise Pidgin. Par contre je serai limité sur XMPP.
Deux clients ? Pas pratique tout simplement. Ah mince...j'ai pas changé mon statut sur l'autre client...Ah zut faut que je change mon avatar sur les deux clients... Et puis sympa pour les contacts qui sont justement sur les deux protocoles.
J'ai _un_ contact sur Yahoo. Faut que j'installe un client Yahoo aussi ? Bref, un client par protocole c'est pas une solution.

Migrer mes contacts ? Mais j'en ai rien à faire de les migrer. Ça fait longtemps que j'ai arrêter d'essayer. Ils changeront bien d'eux même s'ils veulent un proto ouvert ou certaines fonctionnalités. Certains ont déjà changé, d'autres pas encore, certains ne changeront jamais.

Pour finir je ne suis pas "éternellement sur un protocole propriétaire", je le suis quand je dis à ma passerelle de se connecter et j'ai déjà plusieurs personnes sur Jabber. C'est mon droit de préférer utiliser un protocole ouvert au mieux, et avec un protocole fermé en bout de chaîne au pire - Si je veux. Je n'ai jamais dis que je comptais abandonner les protocoles propriétaires (MSN ici). Tant que Jabber n'offre pas des fonctionnalités qui attireront les gens, ils y aura toujours bcp d'utilisateurs de protocoles de merde comme MSN...

Ensuite pour ce qui est de ma vie privé, tout va bien. Les amis je leur téléphone, je les vois s'ils habitent près de chez moi. Ce qui ne m'empêche pas de discuter avec des anciens collègues de boulots, des amis à l'autre bout de la France ou du monde, les petits gars de ma distro, l'équipe de mon association/site.

Bref, me faites pas dire ce que j'ai pas dis, j'ai juste donner l'adresse d'un serveur Jabber.

Même chose pour moi, je ne prends que des données sur les *-look. Je m'amuse pas à installer le moteur Aurora en utilisant un paquet sur *-look mais en utilisant mon gestionnaire de paquets. Par contre, aucun souci à utiliser un style Aurora (pour continuer dans cet exemple) dispo sur un site *-look. Ce n'est que des données, sans package et qui "s'installe" (extraction + copie) pour l'utilisateur en cours, pas pour le système.

Et puis bon, le titre du journal est un peu faux. Que je sache les distro Linux n'utilisent pas toutes des ".deb". C'est quoi cette généralisation à la con ?

Certains serveurs proposent des passerelles XMPP, donc tu peux migrer tes contacts.
Il existe aussi une JEP (je sais plus laquelle désolé) pour échanger une liste de contacts entre compte, bon ça faut que les deux serveurs et le client l'implémente, donc c'est pas gagné.
Il exisn.te aussi des clients qui te permettent de faire cette migration.

Moi j'en pense que j'ai lâché mon compte chez eux assez rapidement.
Pas de passerelle (oui je trouve ça important pour pouvoir discuter avec ceux n'ayant pas encore migré) et pas stable (j'avais sans arrêt des déconnexion du serveur, ou tous mes contacts qui disparaissaient), avec des délais d'envoi des messages (plusieurs dizaines de secondes avant réception par mon correspondant, quelque soit le serveur Jabber qu'il utilisait - on avait fait des tests).

J'ai finalement, depuis quelques années maintenant, trouvé un serveur qu'il est bien :) : jabber.cz
Ouais c'est tchèque, et des fois j'ai du mal à comprendre les annonces qui passent sur le serveur. Mais bon ça tourne sur du ejabberd et y'a pas mal de services dispo...et c'est très stable et fiable.
Comment j'ai fait pour le trouver ? J'avais simplement essayer au pif dans une liste (qui était dispo sur jabber.org d'ailleurs)...

Voilà, c'était mon petit commentaire qui trouvera peut-être une utilité pour quelqu'un cherchant un bon serveur Jabber non-maison.

Ah merci beaucoup, je ne suis pas très fort en règle udev, et effectivement avec mon imprimante/scanner Brother, je n'arrivais pas à scanner avec mon compte normal.
Pourquoi ne pas créer un autre fichier .rules ? genre 61-libsane-brother.rules Comme ça pas de problème en cas d'update de sane :p

Parce que c'est idiot de proposer comme solution au problème du fichier "u" se créant de le supprimer, mais que je la première proposition se valait je suppose drôle alors que les suivantes non.

Mais pas du tout. OVF c'est juste un format d'échange de "machine virtuelle". Il ne définit pas du tout le format du stockage disque virtuelle, qui peut être vmdk, vdi, qcow, ...
Ce n'est pas du tout une solution satisfaisante.
Par expérience (au taff), même avec un OVF, un disque dur virtualisé en vmdk (lisible par VirtualBox et VMWare), avec un windows XP émulé, ça n'est pas compatible entre les deux logiciels pré-cités.
En effet dans les deux cas, il existe des additions clients (indispensable si on veut du copier/coller, des performances correctes). Le matériel émulé étant différent en fonction de l'éditeur, ça part en couille avec les additions VBox et VMWare installés conjointement....tout du moins sous Windows. Sous Linux ça plante Xorg, mais une petite édition du fichier xorg.conf et c'est bon. À faire à chaque changement de virtualiseur, c'est un peu casse-couille tout de même.
Bref, le chemin est encore très très long avant de voir une interopérabilité correcte entre les logiciels de virtualisation.

En effet, et je pense qu'il serait bien d'ajouter simplement la propriété "border-radius". Comme ça quand elle sera disponible, pas besoin de changer ta CSS.

Merci pour le lien du journal, j'ai dû passer à travers cet été...et je me suis toujours posé la question de comment faire justement !!

Et quoi, c'est pas faux non ?

C'est un inconvénient connu des systèmes GNU/Linux. La diversité implique le choix (et ça c'est bien) mais aussi une certaine complexité (heureusement toute relative).

Suffit de regarder le bordel de la gestion du son sous Linux. Si y'avait pas eu de choix, ce serait probablement mieux intégré. Mais ce choix a également permis d'explorer de nouvelles voies et d'adapter des gestionnaires de sons (j'espère qu'on dit comme ça) à des cas précis (temps réel, transport sur le réseau, simplicité de codage des applis, ...)

Pour le coup du temps d'extinction, c'est dû à un fc-cache et autre trucs du genre qui est lancé à l'extinction.
Moi j'ai désactivé ce genre de choses (si mes souvenirs sont bons, ça doit être dans un /etc/rc.d/rc.6).