Mareo a écrit 54 commentaires

Justement il y a une différence capitale entre une adresse MAC qui est une information qui se situe au niveau de la trame et une option DHCP qui est directement dans le paquet, cette distinction est importante parce que le contenu du paquet DHCP peut être authentifié via un mécanisme spécifique au protocole, voir la RFC 3118 qui est une extension pour DHCPv4 et la section 21 de la RFC 3315 pour DHCPv6.

Utiliser des adresses MAC comme identifiant est une pratique répandue mais c'est une habitude qu'il faudrait perdre. En l'occurrence, dans le cas de DHCP, c'est sur l'option « client-identifier » qu'il faut jeter son dévolu[1], c'est un identifiant stable qui identifie une interface de façon unique et pérenne : en cas de changement de carte réseau il ne sera pas nécessaire de reconfigurer le serveur DHCP. Ça permet également d'éviter la confusion des couches (le serveur DHCP ne devrait pas manipuler des adresses de la couche liaison).

DHCPv6 a une option équivalente, qui identifie une machine (et pas une interface, DHCPv6 ayant un mécanisme spécifique pour identifier les interfaces).

[1] « DHCPv4 servers that conform to this specification MUST use the 'client identifier' option to identify the client if the client sends it. » RFC 4361

C'est une initiative excellente, Stéphane Bortzmeyer déplore souvent le fait que de nombreux projets lié au p2p se lancent sans jamais se préoccuper de ce qui a été fait avant, regrouper ces informations est un pas dans la bonne direction !

Pour ce qui est des différents types de centralisation, il serait intéressant de développer un peu la partie technique en mentionnant par exemple qu'il y a, parmi les systèmes centralisé, des système qui sont également réparti (comme le DNS).
Parfois un système centralisé et réparti est préférable à un système décentralisé, c'est le cas quand on cherche la tolérance aux pannes mais que l'ont veut des identificateurs à la fois unique et parlants (c.f. cet excellent article)

Dans la partie où tu parles de la « Robustesse aux pannes et aux attaques » des ces réseaux, si cette robustesse est évidente pour ce qui est des pannes ou des attaques par déni de service, ça l'est beaucoup moins pour d'autres type d'attaque si le protocole n'a pas été pensé dès le départ pour les éviter, ainsi si il n'y avait pas de vérification des condensats des morceaux des fichiers téléchargés via bittorrent, un seul client malicieux pourrait faire de gros dommage, c'est l'occasion de mentionner le problème des généraux byzantins.

Tu ne peux rien déduire de pertinent en te basant sur les seules moyennes, avec l'écart type, oui, tu pourrais tirer des conclusion ; en attendant ton message n'est que spéculations sans fondement.
Tu as le droit d'avoir tes langages de prédilections et tu n'as absolument pas besoin d'essayer de le justifier en te basant sur des statistiques qui ne montrent au final qu'une seule chose : les gens utilisent les langages qu'ils connaissent, le Java, le C, le C++ et Python étant plus enseignés que le Ruby, c'est normal qu'ils soit plus utilisés.

Tu ne devrais pas essayer d’émettre de critique d'un langage que tu ne maîtrise manifestement pas.

Ça dépend des pays, au Japon par exemple c'est tout à fait légal, ça ne l'est pas en France.
D'ailleurs, il ne s'agit pas seulement de la diffusion mais aussi de la possession qui est illégale.

Est-ce une bonne chose dans un cas comme dans l'autre ? Je ne sais pas.

L'association IP/Port à un instant T correspond toujours à une personne unique.
Le vrai problème c'est que ça rend impossible l'utilisation d'autres protocoles de que TCP, UDP et ICMP…

Merci pour ces encouragements !
Je suis cependant un tout petit peu triste du manque de retour, je m'attendais à plus de questions.

J'ai préféré passer sur ce détail pour ne pas compliquer inutilement cette partie qui reste quand même une petite digression.
Cependant, si on sort du cas particulier de GRUB, il est tout à fait possible de ne pas inclure de MBR sur le disque et la limite artificielle des 44(0|6) octets disparaît. (Même si c'est l'exception plutôt que la norme, un disque peut être utilisé sans être partitionné).

Merci pour la précision.

Non, iPXE est un vrai bootloader à part entière : il est capable de charger un kernel ou un initramfs et de booter dessus, et il ne fait pas que du PXE (dhcp puis tftp ou tftpm) mais gère tout un tas d'autres protocoles : HTTP, FTP, FCoE, iSCSI et très prochainement NFS, je suis en train de travailler dessus en ce moment.

La seule différence avec un bootloader classique est qu'il n'est pas capable de lire sur un block device, il est cependant capable de lire le permier secteur de premier disque local pour en extraire le MBR et l'executer (et donc généralement passer la main à un autre bootloader). Ça se fait avec la commande :

sanboot --no-describe --drive 0x80

Un « éclat » peut-être ?

Beaucoup des devs d'udev sont en fait des employés de RH qui bossent parfois aussi sur Fedora. Du coup sur cette décision, faire la distinction n'a pas vraiment de sens.

Il y a eu un très gros thread à ce sujet sur la ML des devs de Gentoo, une bonne partie n'étant pas spécialement pour le déplacement de /bin, /lib etc dans /usr parce que ça cassait toutes les installations avec un /usr séparé sans initramfs pour le monter (ah bah oui, on fait comment pour monter la partition sans /bin/mount ?), sans parler du fait que ce n'est pas conforme au FHS qui, étant peut-être d'une clarté discutable sur ce qui doit être dans /bin et qui doit être dans /usr/bin, fixe quand même quelques principes.

Au final toutes les distributions seront forcées de suivre l'exemple de Fedora car udev ne fonctionnera plus sinon (je ne me souviens plus des raisons exacte). Il apparaît en fait que les devs d'udev sont les même que que ceux qui ont poussé Fedora sur cette voie, de façon plus ou moins unilatérale. Cette situation est loin de plaire à tout le monde, d'autant qu'un fork d'un projet de la complexité et de l'importance d'udev n'est pas envisageable, ce qui signifie que les autres distributions devront se plier à leurs décisions.

Je me demande encore quel est l’intérêt de tout migrer vers /usr, puisque les dossiers /lib, /bin et /sbin ne disparaîtrons pas, il y a trop de scripts avec des chemins hardcodés dedans, /bin/sh en est un bon exemple, pour que quiconque soit assez fou pour en imposer le retrait définitif. Les symlinks vont rester très, très, très longtemps…

Dans le liens vers le plaidoyer de Mike Haertel, il affirme que GNU grep est rapide car il évite de lire les flux octet par octet, or ce n'est pas possible en UTF-8 à cause du fait que les caractères sont de taille variable.

Ceci explique peut être, en partie, la lenteur que tu observes.

Une petit piste pour ta réflexion, même si ça ne me semble pas utilisable en l'état pour du SSL :

Secret_réparti

Corrige moi si je me trompe, mais l'ICANN a bien joué son rôle : il a bien dit que ce n'était à lui de couper, et n'a pas coupé. Neutralité.

Effectivement l'ICANN n'a pas coupé wikileaks et est restée neutre, en revanche, le ministère dont elle dépend ne l'est pas lui.

http://www.numerama.com/magazine/17457-70-noms-de-domaine-pi(...)

Morceau choisi :
"Contacté par Torrentfreak, le propriétaire de Torrent-Finder a expliqué que son domaine a été pris de force, sans le moindre avertissement préalable et sans décision rendue par un tribunal. Son hébergeur, GoDaddy, n'a pas non plus pu fournir la moindre explication, indiquant que la procédure est venue de l'ICANN."

Dans ces cas là, quoi qu'en dise l'ICANN, c'est bien elle qui exécute, en toute neutralité, assurément.

Si ça a merdé, ce n'est pas au niveau DNS, mais au niveau du choix du gestionnaire de DNS fait par Wikileaks.
[...] la faute revient principalement aux admins Wikileaks... (à commencer par utiliser des serveurs DNS gratuits pas dimensionnés pour tenir la charge, plutôt que de prendre les siens ou un prestataire qui soit plus costaud)

Dans ce cas là, avoir mis en place ou pas des DNS perso n'y aurais rien changé, puisque c'est la zone entière qui était bloquée par le registrar, l'excuse du DDoS était un faux-fuyant, c'est évident.
Je suis près à parier que la situation aurait été la même, quel qu'aurait été le registrar choisi, quand un état peut mettre suffisamment de pression pour vous couper votre hébergement et vos sources de revenu, faire faire sauter un enregistrement DNS par une association sous sa tutelle c'est plus que facile.

Va falloir trouver autre chose pour légitimer une division (entre ceux qui ont les TLD officiels, et ceux qui ont le .42) d'Internet.

Personne ici ne prêche pour une division, ceux qui ont le .42 ont aussi les ccTLDs et gTLDs.

Cette question à été posée plusieurs fois déjà de manière différente dans les articles cité par mon journal. Cette réponse reflète uniquement mon point de vue et jet t'invite à lire ces articles, pour une réponse peut être plus proche de cette des instigateurs du projet.

"N'y a t'il pas de contradiction entre une volonté de démocratisation et les barrières mises en place sur le "qui et pourquoi" et le contenu des sites adressé"

Il ne s'agit pas de faire un TLD fourre-tout qui perdrait alors sa fonction de classification, idéalement, .fr devrait être réservé aux contenus francophones, .com aux contenus commerciaux, etc. Il me semble alors naturel qu'un nouveau TLD cherche à regrouper une communauté précise.
N'oublions surtout pas qu'il s'agit d'une expérience, voyons jusqu'où elle nous amène pour en tirer des enseignements, si cette expérience est une réussite, alors il sera envisageable de démarrer d'autres projets similaires, chacun ouvert sur un domaine particulier, sur une communauté particulière, géré démocratiquement et non plus unilatéralement comme c'est la cas maintenant.

C'est, à mon sens, de cette façon là qu'il faut comprendre "volonté de démocratisation".

"[...] et les barrières techniques de fait pour une majorité d'utilisateurs non geeks"

C'est un gros obstacle effectivement, la seule possibilité de le surmonter actuellement, c'est que les FAIs ajoutent la zone dans leurs DNS, c'est très loin d'être acquis, malheureusement.
Ce projet ne peut pas avoir la prétention de résoudre le problème de la gestion des noms de domaine en un jour et de façon globale, il faudra du temps et de l'investissement de la part de tous pour y arriver. C'est d'autant plus vrai qu'il s'agit d'un problème politique et qu'il ne pourra pas être réglé autrement que de façon politique.

En bref, en fait de démocratisation, ça risque d'être un TLD fait par et pour des geeks, dans le contenu et dans les faits ...

Encore une fois notre seul espoir de voir cette expérience aboutir, c'est de la faire connaître, de la soutenir, d'y contribuer.
Déjà faire prendre conscience que la gouvernance actuelle du DNS est incompatible avec la neutralité du net est un progrès, les faits qui se sont déroulés lors de "l'affaire wikileaks" sont un véritable tremplin pour cette prise de conscience, il serait stupide de ne pas l'utiliser pour commencer à changer les choses !

Je comprends que ce genre de projet provoque le scepticisme surtout quand on connaît l'histoire de projets similaires qui n'ont jamais véritablement percés, mais c'est ce scepticisme qui les tues en fin de compte...

Je terminerai par une constatation toute simple, quand un registre vends un nom de domaine, est-ce vraiment le nom de domaine qu'il vend ou les gens qui utilisent le DNS actuel pour le résoudre ?

d'après la RFC 1123, une IP, l'existence, ou l'inexistence, d'un nom de domaine identique n'y changera absolument rien.

Whenever a user inputs the identity of an Internet host, it SHOULD
be possible to enter either (1) a host domain name or (2) an IP
address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
the string syntactically for a dotted-decimal number before
looking it up in the Domain Name System.

Le but, pour le moment en tout cas, n'est pas de proposer une racine alternative, juste un TLD "libre", si là est ta question.

À propos d'OpenNIC, une petit piste : http://www.opennicproject.org/forums?func=view&id=629&am(...)

Personnellement, je ne connais pas une seule application qui cherche à résoudre une adresse IP plutôt que de s'y connecter directement.

Je vous remercie d'avoir passé mon journal en dépêche.
Je crois, par contre, que le lien vers la charte du .fr à sauté, à titre indicatif c'était : http://www.afnic.fr/data/chartes/charte-fr-2010-03-16.pdf

En fait il y a bien eu une coupure qui n'a été que très brève, le temps que je te réponde, le site était de nouveau en ligne.
Le site est accessible en https aussi du coup ;)

Visiblement l'hébergeur du site a des petits soucis, fort heureusement, ça n'affecte pratiquement pas les serveurs DNS du TLD : 4 sur les 6 actuellement en place fonctionnent toujours.
Espérons que ça ne dure pas trop longtemps...

Je me permet également d'ajouter ce lien : http://www.bortzmeyer.org/files/racines-alternatives.pdf
Qui, même si il n'est qu'indirectement lié à ce projet, apporte des informations qui me semblent l'éclairer sous un angle différent.

On me signale que j'ai oublié de mentionner un fait important :
C'est cet article qui a déclenché le buzz initial autour du projet :
http://geekfault.org/2010/12/19/la-nouvelle-mode-geek-avoir-(...)

Twitter à également beaucoup contribué à son essor.