🚲 Tanguy Ortolo a écrit 12706 commentaires

c'est le USBID qui permet de determiner le peripherique (le HUB, le clavier ou la souris)

Si c'est la seule façon de faire, c'est ennuyeux parce que lui voulait discriminer par port USB utilisé plutôt que par modèle de périphérique...

L'identifiant USB, ça identifie le fabricant et le modèle. Ce n'est pas un numéro de série...

il y avait un projet 'MPX' je crois, mais je ne sais ou ils en sont.

Ils en sont au point que c'est inclut dans X.Org de base, ça s'appelle XInput 2.

En revanche ça n'a strictement rien à voir avec ce qui nous intéresse ici : XInput 2 ça sert à utiliser plusieurs entrées (pointage et saisie) sur un seul serveur graphique, or là on cherche à utiliser affectées plusieurs entrées à plusieurs serveurs graphiques.

Je ne serais pas surpris que linux-libre ne prenne pas en charge le chargement de fimwares externes. Si c'est bien le cas, c'est une excellente raison qu'il ne soit pas utilisé par Debian, parce que ce serait en conflit avec le cinquième point du contrat social Debian, qui dit en gros : on ne mettra pas d'obstacle à l'utilisation de logiciels non libres.

Nan, parce que 75%, c'est un gros chiffre en grande partie à cause de Universe...

Justement. Du jour au lendemain, 75% des paquets de Ubuntu se retrouveraient orphelins. Je t'assure que ce serait la merde, et pas qu'un peu.

Et vrai question, pour savoir si les distros sont liées ou pas: peut on passer d'une debian à une ubuntu et vice versa?

Ça a peu de chance de bien fonctionner, mais ça ne doit pas être impossible. C'est totalement non pris en charge, probablement très tendu à réaliser, mais ça doit pouvoir se faire.

il y'a juste un outils nommé "mom" qui se charge de voir si il n'y aurait pas des modifs dans les paquets Debian qui devrait être fusionnées dans le paquet Ubuntu

Quelque chose comme 75% des paquets d'Ubuntu sont repris de Debian sans la moindre modification. Pour ces paquets là il n'y a rien à faire que de reprendre la nouvelle version de Debian.

sans Debian, Ubuntu peux

... stagner jusqu'à ce que les logiciels présents soient devenus trop vieux pour être compatibles avec les nouveautés.

Debian is dying, tué par ubuntu

Ou pas. Si c'était le cas, les premiers à mourir derrière, ce seraient Ubuntu, qui dépendent très fortement de Debian. Ils sont les premiers intéressés à la survie de Debian...

Ne surtout pas utiliser dd_rescue. Ce logiciel est conçu sur un principe très mauvais : lorsqu'il tombe sur un bloc illisible, il réessaie immédiatement de le lire de façon plus précise.

C'est une grosse connerie, parce que lorsqu'un disque dur a du mal à un endroit particulier, insister peut aggraver la panne. Cela peut par exemple endommager une tête de lecture alors que seul le plateau était abîmé.

Le comportement censé dans ce genre de cas, c'est donc de sauter immédiatement les blocs défectueux, pour essayer de récupérer le plus vite possible ceux qui n'ont pas de problème, et seulement ensuite, de revenir dessus pour voir si on peut en tirer quelque chose. Et ça, c'est le comportement de GNU ddrescue.

Hein ? La languette en question ne serait pas qu'un bout de plastique sans le moindre lien avec l'électronique de la carte ? Comme les bouts équivalents des cassettes audio ?

En asie

En Birmanie, par exemple. C'est un pays gouverné par une junte militaire composée de malades mentaux qui basent leurs décisions sur l'astrologie. Un jour, ces tarés ont décidé que rouler de l'autre côté [que ce qu'ils faisaient jusqu'alors] c'était wachement plus astrologique, du coup ils ont fait changer ça du jour au lendemain...

[...] prennent un malin plaisir à faire des trucs dans leur coin sans utiliser les normes et standards internationaux. Ni pousser pour une harmonisation.

Ça marche aussi en remplaçant le sujet par « Microsoft ». :-þ

Bref, entretien par IRC c’est la merde assuré !

Ah non alors ! J'ai interrogé des gens par IRC pour un projet scolaire, et j'ai moi-même passé des entretiens de pré-embauche par IRC, alors ce n'était pas de la meyrde d'abord.

Tiens, j'en profite pour signaler que, s'il existe un paquet Debian pour Seeks, celui-ci ne fait pas encore partie de Debian ; ceci dit son mainteneur est tout à fait intéressant pour l'y intégrer, et il est possible que cela se fasse effectivement après relecture et sponsorisation1. Après, c'est une information non officielle que je livre là, étant donné que je n'ai pour le moment qu'échangé quelques messages avec le responsables du paquet de Seeks.

1 La sponsorisation, c'est l'envoi par un développeur Debian — appelé le sponsor — d'un paquet réalisé par un contributeur — appelé le mainteneur ou responsable du paquet — qui n'est pas encore membre du projet Debian, tout simplement parce que l'envoi dans Debian est grosso modo réservé aux membres du projet Debian.

Ah, ben ça... On n'est jamais mieux servi que par soi-même, donc l'idéal — je parle en debianiste, donc à adapter un peu au besoin — c'est de faire un rapport de bug indiquant la nouvelle version, et éventuellement de préparer soi-même le paquet mis à jour en le proposant au mainteneur. Parfois on en arrive même à adopter des paquets, comme ça. :-)

Et, en l'occurrence, ça n'a pas choqué outre mesure ma conseillère d'avoir une date au format imposée avec des slashs et toutes les autres dates séparées par des tirets.

Je m'inquiète d'avantage pour les risques de mauvaise compréhension dus à l'ordre de présentation de la date, qui est à l'inverse de la notation traditionnelle française... Pour peu que des gens se mélangent les pinceaux avec la notation aberrante1 qui prévaut chez les anglo-saxons, ça peut devenir horrible.

1 Là je ne me retiens pas de mettre un qualificatif, parce que l'infâme taré qui a inventé cette notation mérite réellement d'être fouetté avec des fibres optiques jusqu'à ce que congestion s'ensuive.

Moi j'utilise autant que possible la notation ISO 8601.

Pas exactement : tout comme moi, tu utilises plutôt la RFC 3339, qui est basée sur la norme ISO. La norme ISO propose plusieurs variantes, en permettant par exemple d'écrire aussi bien 2011年11月22日 que 20111122, alors que la RFC se restreint à notation unique. Par ailleurs, la RFC autorise l'utilisation de l'espace plutôt que de la lettre T pour séparer la date de l'heure, pour des raisons de lisibilité.

Bref, ça donne ça :

• date : 2011年11月22日 ;
• heure : 14:31+01:00 ;
• date et heure : 2011年11月22日 14:31+01:00.

C'est assez lisible pour être compris par n'importe qui de pas trop ignare, je pense.

Bref, chaque notation a ses avantages et ses inconvénients.

Pas d'accord. Les notations Europe/Paris et UTC+0100 ont chacune leurs avantages et inconvénients certes, en revanche les sigles1 comme CET n'ont aucun avantage, que des inconvénients.

Après, complètement pluzun pour la date et l'heure en ISO. Il faudra que je regarde comment c'est pris pour des trucs comme les chèques...

1 Cela fait plusieurs fois que je me retiens d'ajouter des qualificatifs, mais je sens que je vais finir par craquer... :-)

Si. :-)

Est-ce que c'est un outil qui provoque des blo

D'accord, mais dans ce cas parler d'un outil en mode texte serait plus léger que de parler d'un outil fonctionnant dans un environnement en mode texte. :-)

Mais comme toute bonne feature dans XMPP elle n'est implémentée par 0.1 client.

Elle pourrait être implémentée dans la tribune, et tant pis pour les clients externes qui auraient un mode dégradé, en somme.

Honnêtement, à part pour les passionnés ou professionnels utilisant l'heure à un niveau international, UTC ça veut rien dire pour les gens.

Il faudrait que je sonde les gens normaux que je connais. Mais à mon avis, tous ceux qui sont concernés par les problèmes de décalages horaires comprennent les indications comme UTC+0100, UTC+0200, UTC-0500 ou UTC-0400. Alors que pour comprendre les sigles comme CET, CEST, EST ou EDT, il faut... un glossaire ou un cerveau de machine. :-D

Il gère un peu de coloration syntaxique

Pas exactement. Ce qu'il fait, c'est qu'il affiche en couleurs le gras et le souligné, pour être précis. Comme les pages de manuel ont du gras et du souligné, most les affiche en couleur, c'est tout. Il n'y a pas grand chose de syntaxique là-dessus, c'est juste une façon originale d'afficher ce que d'autres pageurs affichent de façon plus classique.

heure : 21 h CET ;

En français, on dit 21:00 UTC+0100. Typiquement :

$ LC_TIME=fr_FR.UTF-8 date 
mardi 22 novembre 2011, 10:07:43 (UTC+0100)

À comparer avec :

$ LC_TIME=en_US.UTF-8 date 
Tue Nov 22 10:08:06 CET 2011

En clair : ces sigles abscons de fuseaux horaires, qui obligent à chercher dans une encyclopédie pour comprendre ce qu'ils désignent, ne sont utilisés qu'en américain et en anglais. En français, pour indiquer une heure de façon univoque, on utilise les décalages par rapport à l'UTC, qui ont en outre l'avantage d'être directement compréhensibles.

Par ailleurs, si le but est plutôt d'indiquer le fuseau horaire utilisé, la façon la plus saine de procéder est plutôt d'utiliser les noms de la base d'Olson. Pour la France, c'est Europe/Paris.

Vous pourrez leur (nous) poser vos questions, lesquelles seront modérées (acceptées) a priori. Étant donné la courte durée de cette tchatche, nous avons décidé de procéder comme suit :

• quelques personnes clairement identifiées de l’équipe seront désignées pour modérer ; vous leur posez des questions en privé ;
• les questions sont publiées sur le canal IRC et le salon XMPP dans leur ordre d’arrivée.

Est-ce que je suis le seul à trouver ce fonctionnement très compliqué ? Ce genre de fonctionnement est habituellement mis en place pour les entretiens publics à très forte audience de type conférence de presse en ligne. J'ai en mémoire un entretien avec Éric Walter organisé par la Quadrature du Net : il y avait des centaines de participants et ce mode de fonctionnement était nécessaire pour que la conférence reste compréhensible. Mais pour une conférence DLFP, n'est-ce pas un peu trop ? Vous attendez sérieusement une affluence dépassant la cinquantaine de participants et une densité temporelle de questions dépassant les vingt à la minute ?