chtitux a écrit 432 commentaires

C'est pareil pour le Bitcoin : tu peux réécrire toute la chaîne, et à toi les bitcoins !

Je pense que git pourrait être utilisé pour certifier les données : le commit précédant est utilisé pour signer le suivant. Et il suffit de déclarer le condensat du premier commit à l'administration fiscale pour qu'elle puisse vérifier toute la chaîne. Ou prendre une photo du journal du jour avec le hash du premier commit.

Pour remplacer les "stubs" par le vrai contenu des articles, il y a un plugin de TinyTinyRSS très bien fait :
https://github.com/mbirth/ttrss_plugin-af_feedmod

Je l'utilise depuis plusieurs mois, et ça marche très bien. La configuration est un peu hardue, mais une fois en place, quel plaisir !

Globalement, ça marche comme ça :

• si l'URL du feed match une regex, il va télécharger la page de l'article
• il va remplacer le contenu du flux par le contenu défini par le chemin xpath de la conf

Comme la liste des TLDs est longue comme le bras, Mozilla a pris l'initiative d'en dresser la liste exhaustive sur http://publicsuffix.org/ . Elle est utilisée par Opera et Google Chrome.

La liste est sur http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1 .
La partie des .museum est édifiante, avec une liste de chaque ville qui a demandé un sous domaine...

Je pense que ce journal aurait plus sa place dans les forums dépêches cinémas !

On n'avait pas parlé d'un processus de migration journal->dépêche si le journal était de qualitaÿ (comme celui-ci) ?

Il y a aussi Munin (prononcé "munine") : http://munin-monitoring.org/
C'est un démon qui récupère des données de sondes et qui trace les données dans des jolis courbes avec rrdtool.
Ca donne par exemple http://munin.ping.uio.no/ping.uio.no/colosseum.ping.uio.no.html .

Tant qu'à faire, autant l'appeler Novell !

dans le cas du vote par correspondance [...], on peut se filmer en direct en montrant bien le bulletin, le mettre dans l'enveloppe, et la poster

Certes, mais dans un isoloir, on peut aussi se filmer en train de mettre un bulletin dans l'enveloppe, puis l'enveloppe dans l'urne.

On peut toujours vendre et acheter des voix (ce n'est pas le principe des promesses "démagogiques" ?), mais avec le vote par correspondance, c'est sûrement plus facile de tricher (forcer quelqu'un à voter pour tel ou tel candidat, voter à sa place, etc.).

Ça donne le portail de... Virgin Mobile. Un auteur d'un blog en fait part sur http://tuxicoman.jesuislibre.net/2011/05/virgin-mobile-bloque-orange-fr.html

À ce niveau là, c'est assez lamentable quand même...

En fait, la BU aurait dû lui répondre :

Nous utilisons un certificat auto-signé à cause du manque de moyens attribués à l'université.
Je comprends tout à fait votre refus d'accepter un tel certificat auto-signé. Je vous invite à passer nous voir pour que nous puissions vous transmettre de visu l'empreinte de notre certificat, que vous pourrez ensuite importer dans votre base d'autorités de confiance.

Et « un certificat en carton » ne veut pas dire grand chose. Le certificat est-il « juste » auto-signé, ou est-ce une vraie erreur : adresse ne correspondant pas au sujet du certificat, certificat expiré, certificat signé par une autorité qui n'est pas de confiance, etc.

Donc avec un certificat en carton, on est sûr que notre mot de passe ne pourra pas être lu par quelqu'un d'autre que celui qui envoi le certificat, mais on ne peut s'assurer de l'identité de la personne qui reçoit le mot de passe.

Dans le cas d'un mot de passe, c'est un secret partagé entre l'utilisateur et le site. Quand on le communique, l'objectif est qu'il ne soit intercepté par personne d'autre que le site, donc il faut s'assurer d'[au moins] 2 conditions :

• que personne ne va pouvoir voir le mot de passe pendant la transmission (chiffrement)
• que la personne avec qui on communique est bien la bonne (authentification)

Avec un certificat en carton, on a juste le premier point. Donc dans le cadre de la transmission d'un mot de passe, le certificat en carton n'est pas suffisant.

Je ne connais pas d'ailleurs de cas d'utilisation où seul le chiffrement est utile, et l'on se moque de savoir à qui on envoi les données. Mais éclairez moi, je suis curieux d'en connaître un !

Il doit faire probablement une grande partie des merges (cf https://github.com/mirrors/linux-2.6/commits/master ) et il ne doit pas être crédité de l'auteur du commit (ce qui est normal, git sépare bien auteur et commiter).

Ça suppose qu'il lit une grande partie des patches, qu'il les commente, qu'il dit ce qui ne va pas et demande probablement à l'auteur original de corriger. Donc à la fin, même s'il a repéré et aurait pu corriger le patch, il n'est pas l'auteur de celui-ci, donc en SLOC, il représente peu.

Et moinssez-moi, je n'avais pas compris :
modem-routeur <---- câble RJ 45 --->{fiche femelle RJ45}{fiche mâme RJ11}--> téléphone

Oui, mais pas l'inverse.
S'il tire un câble RJ45 de son modem-routeur à son téléphone, et que son téléphone n'a qu'une prise RJ11, il se retrouvera avec une prise RJ45 à brancher dans une fiche RJ11.
Là, pas moyen de faire sans adaptateur.

J'utilise pour ma part une sauvegarde incrémentielle avec rsync via ssh, mais qui me permet de restaurer très facilement les données en utilisant les hard links côté sauvegarde.

Ce sont juste 3 commandes, très largement inspiré par http://blog.interlinked.org/tutorials/rsync_time_machine.html :

#!/bin/sh
date=`date "+%Y-%m-%dT%H-%M-%S"`

# / at the end is mandatory !
SOURCE_DIR=/media/documents/perso/
TARGET_HOST=backup-server.mondomaine.tld
TARGET_USER=chtitux
TARGET_DIR=/var/backups/calvin/perso

# -6 is for IPv6 ONLY
# $SOURCE_DIR/rsync-exclude has to exist
# RTFM rsync too ;)

rsync -6 --archive --one-file-system --hard-links \
  --human-readable --inplace --numeric-ids --delete \
  --partial --progress \
  --compress \
  --delete-excluded \
  --exclude-from=$SOURCE_DIR/rsync-exclude \
  --link-dest=$TARGET_DIR/current \
  $SOURCE_DIR $TARGET_USER@$TARGET_HOST:$TARGET_DIR/incomplete_back-$date 
  
ssh $TARGET_USER@$TARGET_HOST "mv $TARGET_DIR/incomplete_back-$date $TARGET_DIR/back-$date \
  && rm -f $TARGET_DIR/current \
  && ln -s back-$date $TARGET_DIR/current"

• À la première synchronisation, tout est envoyé dans un dossier distant qui finira par s'appeler /var/backups/calvin/perso/back-2011-04-30T15-58-21 , et un lien symbolique fait pointer /var/backups/calvin/perso/current vers ce dossier
• Les fois suivantes, ça compare ma copie locale à /var/backups/calvin/perso/current , et ça transfert le différentiel vers /var/backups/calvin/perso/incomplete_back-2011-04-30T15-58-21
• rsync utilise les hard links pour représenter les fichiers qui n'ont pas changés : à la fin du transfert avec rsync, mon répertoire distant incomplete_back-2011-04-30T15-58-21/ contient donc les nouveaux fichiers et les fichiers qui n'ont pas changé, sans que ça prenne de la place supplémentaire (modulo l'espace disque occupé par un lien)
• à la fin du transfert via rsync, ssh renomme incomplete_back-2011-04-30T15-58-21/ en back-2011-04-30T15-58-21/ , et recrée le lien symbolique current vers ce dernier
• finalement, mon dossier current/ contient donc l'ensemble de ma dernière sauvegarde, donc rsync compare toujours au dernier état. Si je veux restaurer, il faut juste que je copie current/* , je n'ai rien à assembler moi-même. De plus, si j'interromps une sauvegarde, je vais avoir un répertoire incomplete_back-2011-04-30T15-58-21/ qui traîne dans le répertoire des backups, mais ça n'impactera pas la prochaine sauvegarde (qui se fera depuis la dernière complète)
• J'ai donc :
  • un transfert de ce qui change uniquement
  • une copie distante facilement restaurable
  • un transfert sécurisé via ssh (et clé publique)
  • une tolérance face aux coupures pendant la sauvegarde
  • l'obligation d'avoir un système de fichier qui prend en charge les hard links (ext?, ça marche, je n'ai pas testé avec NTFS)

Si vous voyez des améliorations à faire, je suis preneur également !

D'ailleurs, si de telles données sont enregistrées, à qui peuvent-être elles vendues sans que les utilisateurs crient au scandale ?

• À un futur pompiste qui cherche à s'installer, c'est OK ?
• Au gouvernement pour refaire l'autoroute sur laquelle je passe tous les jours, pas de problème ?
• À ma radio qui m'annonce la position des bouchons, ça m'arrange ?
• À la police, qui veut encore réduire ma vitesse et faire de l'argent sur le dos du citoyen-que-je-conduis-trop-bien,-même-trop-vite, ah ben non, c'est du vol !

La réaction du PDG de TomTom est d'ailleurs intéressante : « Nous n'aimons pas cela car nos clients ne l'apprécient pas ».
Donc la prochaine fois, ils choisiront leur client pour la revente des données, mais la vie privée n'a rien à voir là dedans.

Et si certains savent comment TomTom récupère de telles données, cela m'intéresse, car le GPS en lui-même est un système passif.
Est-ce un envoi lors d'une synchronisation avec un ordinateur, pendant une mise à jour des cartes ? Ou via un réseau GSM avec une puce dans le GPS ?

En même temps, l'article du 20 Minutes suisse précise bien que les propriétaires des TomTom « étaient au courant que TomTom pouvait revendre ces données à des sociétés tierces ».
Alors peut-être que c'était écrit au fin fond du manuel de l'utilisateur, mais c'était écrit.

Ça fait surtout hurler les conducteurs parce qu'une grande majorité s'en sert justement pour... échapper au radars, et que finalement, on leur en rajoute en utilisant le même moyen.
Je trouve au contraire que c'est de bonne guerre : la police a besoin de connaître les endroits les plus fréquentés par automobilistes, et TomTom le revend des données probablement très précises sur les déplacements des néerlandais.

Les données ont probablement été anonymisées (si tant est que TomTom peut accéder à l'identité du propriétaire du GPS), donc il n'y a pas vraiment de problème de vie privée.

Et tenez vous bien : il paraît même que votre opérateur de téléphonie mobile utilise vos positions enregistrées par ses antennes pour améliorer sa couverture et qualité de service.
Inadmissible !

Ton outil ne fonctionne que si les développeurs nomment leur version correctement. Ça peut paraître évident, mais il y a des cas où ça ne fonctionne pas, parce que la numérotation a été chaotique, comme ... htop, que tu cites comme exemple !

La dernière version de htop est la 0.9 d'après le site officiel, mais la numérotation du début n'a pas été très cohérente : après la 0.1, ce sont les versions 0.11, 0.12 et 0.13 qui ont été publiées.
Ils sont revenus à une numérotation plus logique pour la 0.2 (0.2, 0.2.1, 0.3), et sont maintenant arrivés à la 0.9.
cf http://htop.sourceforge.net/index.php?page=downloads

Cela risque d'être amusant de voir comment htop va s'en sortir pour ne pas s'emmêler dans les versions supérieures à 0.10.

En attendant, même si ton outil facilitera la détection des nouvelles versions, rien ne vaut une surveillance humaine. Peut-être qu'il faut développer un standard pour la publication des nouvelles versions des logiciels...

Et j'aimerai bien voir le mien également, et comme je ne vais pas pourrir tout un journal pour ça, je pourri juste le fil de commentaire.
Combien y a-t-il d'avatars animés différents ?

À mon humble avis, l'abandon de l'OpenID tient du problème de limite d'accès à la recherche.
Il est beaucoup plus facile de créer automatiquement 42 comptes OpenID que 42 comptes Facebook, la principale raison étant que la création d'un compte Facebook requiert un email valide et une résolution d'un captcha, et que la création d'un OpenID... rien du tout (il est tout à fait possible de monter son propre fournisseur d'OpenID qui créée des milliers de comptes d'un coup, voire d'avoir un fournisseur qui réponde positivement à n'importe quelle demande d'authentification).

Je trouve que ta réaction sur "ils proposent l'authentification via Facebook, je boycotte" est un peu exagérée, parce que tu peux toujours bloquer tout ce qui provient de *.facebook.com , le site continue à fonctionner sans perdre en fonctionnalités. Mais c'est une décision toute personnelle qui t'appartient.

Avant que Free puisse utiliser le réseau d'Orange, il va falloir que FreeMobile couvre 25% de la population avec son propre réseau.
Même si FreeMobile recrute pas mal en ce moment, l'obtention des 25% risque de prendre quelques mois. Nous pourrons d'ailleurs remercier en grande partie la population parisienne qui aime s'entasser pour faciliter l'objectif.

Une fois cet accord mis en place, il sera intéressant de voir si le tarif sera le même quand on sera connecté avec une antenne FreeWifi et une antenne Orange. (comme « illimité depuis le réseau FreeWifi, mais payant depuis les autres »). Ça risque d'être fun pour téléphoner depuis un train...

Il semble qu'un McDo soit tout à fait adapté à votre demande :
- une connexion WiFi
- des prises électriques
- de la place pour 8 personnes
- des chaises et des tables

En plus, vous pourrez^W devrez vous rassasier.

(J'aurai bien attendu vendredi, mais ça risque d'être trop tard :)

Plus sérieusement, une telle rencontre dans un bar doit pouvoir s'envisager : avoir une connexion WiFi, 8 chaises et 2 tables, ça doit pouvoir se faire.
Il faudra probablement s'adapter (difficile d'avoir le silence complet, devoir consommer quelques bières pour atteindre http://xkcd.com/323/ ), mais c'est tout à fait réaliste (pour des budgets personnels réduits).

Oui mais non.
Déjà, un utilisateur arrivera difficilement à tomber sur son ordinateur en testant son adresse v6 "au pif". (mais s'il se connecte en IPv6 à un hôte, l'hôte récupère son IPv6, on est d'accord) (et qu'il a supprimé son IPv6 calculée à partir de la MAC, ce que ne fait pas la RFC en question : elle ajoute une IP aléatoire pour les connexion sortantes)

Ensuite, l'hôte verra des connexion provenant d'IP différentes. L'hôte ne pourra pas être sûr à 100% que c'est le même ordinateur. (Sauf s'il se base sur d'autres informations comme des cookies, etc.)

Enfin, l'hôte ne connaît pas la structure de son IPv6 a priori.
En France, Nerim & Free ont déjà des préfixes de tailles différentes. Pour savoir que c'est la même Freebox qui se connecte, il faut identifier à quelle bloc l'IPv6 appartient, connaître la structure des IPv6 du bloc et enfin reconnaître la même IPv4 dans l'IPv6.
Alors certes, c'est possible (comme les 2 raisons au dessus), mais ça reste plus compliqué : il faut maintenir une base de données à jour, interroger le RIPE, etc.

Avoir une IPv6 avec un suffixe aléatoire est déjà un plus pour l'anonymat sur l'Internet.

Avec la version Chrome 10.0.634 (dernière version "dev channel"), des ppa Ubuntu/Chrome, j'ai :
DONE! Your browser's total score is 12555 out of a possible 50000.

Pour ceux qui sont intéressés par la petite phrase "Il a fallu faire accepter le patch aux développeurs GCC pour avoir des goto en assembleur", voici quelques informations :
- Le mail d'annonce du patch : http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01556.html
- Le commit semble être http://gcc.gnu.org/viewcvs?view=revision&revision=151701
- Ce commit date de septembre 2009, donc plus de 15 mois !
- GCC 4.4.5 est sorti en octobre, donc le patch est soit dans celui-ci, soit dans celui d'après.

Cela me semble surprenant de la part de l'équipe noyau de demander un compilateur "récent" (il faut voir le temps que met gcc pour être mis "en production" dans Gentoo : http://packages.gentoo.org/package/sys-devel/gcc , on en est encore à la 4.4.4).

Qu'en est-il des autres compilateurs ? Est-il devenu impossible de compiler le noyau avec autre chose que GCC, a-t-il toujours fallu GCC, ou le code fonctionne avec d'autres compilateurs ?

Je viens de tomber par hasard sur
if [ -e /proc/cmdline ]; then #linux only - future proofing against BSD and Hurd :)
.....
fi
dans /lib/udev/hdparm

Donc il y a bien quelques tests dans /proc et des comportements différents si ce n'est pas Linux comme noyau. (et les tests concernent les *BDE et le Hurd. Ça doit être pour bientôt la prochaine release ;)