galactikboulay a écrit 620 commentaires

Dans la partie lisibilité, on pourrait rajouter l'indentation - pour avoir corrigé des programmes d'étudiants qui mettaient tout au même niveau, je peux dire que c'est vraiment ignoble pour comprendre ce que le code fait.

Appliquer un concept connu (et encore, ici, c'est un cas de figure particulier assez simple) sur du matériel grand public et l'enrober d'une interface, c'est intéressant, certes. Qualifier ça de révolutionnaire ou d'innovant, faut pas pousser non plus.

Certes il faut faire des backups quoiqu'il arrive, mais statistiquement, avec une dépendance sur 2 disques, le crash va arriver beaucoup plus vite.

Ce genre de fonctionnalité ça s'appelle du automated disk tiering, et ça existe depuis un moment.
Mais bon, c'est Apple, donc c'est forcément révolutionnaire…

Oups, je crois que j'ai sauté dedans à pieds joints ;)

Normalement (bon je parierais pas ma vie non plus là dessus), ça devrait mieux fonctionner: les auteurs du draft ont pris en compte le NAT dès le départ, et les éléments spécifiques à MPTCP passent sous forme d'options TCP. Et a priori, si la connexion ne passe pas, il y a un fallback sur du TCP standard, ce qui a le mérite de ne pas tout casser.

Je ne suis pas spécialiste de SCTP, mais comme c'est "à part" de TCP et d'UDP (n° de protocole IP différent), je doute que ce soit très bien géré par tous les firewalls ou des routeurs faisant du NAPT.

Juste une petite remarque: MPTCP n'est pas exclusif à IPv4, ça supporte IPv6 également (voir le message ADD_ADDR). Si j'ai bien compris le draft, une connexion devrait même pouvoir utiliser des adresses IPv4 et IPv6 en même temps.

Arch c'est le Gnome des distribs en fait ? /o\

Là on ne parle pas de réaliser des prototypes pour de nouveaux protocoles, mais bien de suivre quelquechose d'existant.
On est dans la phase "Tu demandes à tout le monde de la suivre".

Dans le cas ou tu est dans une machine virtuelle, eth0 pourrai être ta seule interface vers l'hôte. Nulle par il dit qu'il veut router 127/8 à travers un vrai lien…

Oui mais justement, le 127.0.0.0/8 n'est pas censé sortir de la machine (qu'elle soit virtuelle ou pas). D'ailleurs ce subnet a un rôle bien précis, c'est le loopback, rien d'autre. Est-ce que c'est stupide d'avoir réservé à l'origine un /8 pour ça ? A l'heure actuelle, oui, ça parait complètement saugrenu (évidemment à l'époque où ça a été décidé, personne ne pensait qu'IPv4 aurait un tel succès).

Et qu'est ce que tu veux qu'un développeur noyau fasse de plus pour déployer IPv6 quand tu à déjà une stack qui marche ?!

Justement, rien de plus, ils ont développé tout ce qu'il fallait, tout est là. En fait, ils ne devraient même pas se préoccuper de savoir si il y a encore des adresses dispo en v4 ou pas. Trouver des solutions à ce genre de problématique et pondre les normes, c'est le boulot de l'IETF et autres.

Ça serait plutôt aux experts réseaux de ton genre de se bouger le cul. Ça et les développeurs d'applis en espace utilisateur.

A part le fait que je ne prétends pas être un expert, le problème est à mon sens de moins en moins à ce niveau, mais plus sur le "contenu" accessible en v6. Il suffit de voir le nombre de "gros" sites qui sont toujours en v4… Il y aussi le souci des FAI et des hébergeurs qui sont encore loin de tous proposer une connectivité v6 par défaut.

Pour contre dire le travail de quelqu'un qui bosse depuis longtemps sur les problématique réseau dans le noyau linux il en faut un peu plus que quelqu'un qui affirme que 3 plages d'adresses privées suffisent. Par exemple il faudrait que tu commence à avoir un argument ça sera cool.

J'ai déjà répondu plus haut: si tu as épuisé les 3 plages d'adresses privées disponibles en IPv4, il va falloir sérieusement se pencher sur l'utilisation d'IPv6 pour répondre à ton besoin. C'est ce qu'a fait Comcast assez tôt, plutôt que de rajouter de la rustine. L'auteur du patch cite comme exemple "For example to address a pool of virtual guests behind a load balancer" => pourquoi ne pas les adresser directement en IPv6 ?

Les règles codées en dur c'est mal, quelque soit la RFC, la norme ISO où je ne sais quoi.

Quand Microsoft, Apple ou je ne sais qui ne suivent pas les RFC et introduisent des incompatibilités, les libristes poussent une gueulante, et à juste titre. Par contre là, c'est un développeur du noyau Linux donc ça devient acceptable ? J'aurais bien aimé voir les réactions si c'était MS qui avaient pondu ce truc tiens.
Après, ton exemple de example.{com,net,org} est juste ridicule (on passera sur le fait que ce n'est pas le noyau qui fait la résolution DNS), ces domaines étant affectés à l'IANA. L'IANA te garantit juste que tu peux les utiliser en test, et qu'elle ne les affectera pas à une autre entité. En pratique, ça marche comme n'importe quel autre domaine, donc il n'y a rien à coder en dur nulle part, que ce soit noyau ou résolveur DNS.

Tu sais utiliser autre chose que des arguments d'autorité (et traiter les autres de débiles mentaux accessoirement) ?
Encore une fois, parce que tu n'as toujours pas l'air d'avoir saisi le sens de ma remarque, ce n'est pas parce que c'est un très bon développeur que ça fait de lui un expert réseau, ce qui est un domaine assez différent.
Son patch risque d'inciter les gens à faire des choses sales. D'ailleurs il dit que c'est orienté "host internal", mais l'exemple qu'il donne, c'est de router un morceau de 127. vers eth0, et que ça ne le dérange pas que les gens utilisent ça pour leur adressage interne dans leur réseau…
Et pourtant la RFC recommande quand même fortement que ça ne se balade pas sur les liens.

Ah je note que pondre du code pour le noyau Linux fait automatiquement du développeur un expert réseau, c'est magique !

Oui, et donc plutôt de continuer à faire de la tambouille moisie en IPv4, la conclusion de Comcast, c'est qu'il faut passer … à IPv6.

Bon tu peux ignorer mon post plus bas /o\
Bonjour la complexité si tu dois faire ça partout dans ton réseau, surtout si tu t'appelles Orange, SFR ou Free et que t'as des milliers de routeurs dans ton réseau… Et le GRE, c'est pas forcément la panacée à gérer pour des routeurs hardware.

Je ne comprends pas ce que GRE serait censé apporter pour ce cas là, tu peux détailler ?

Pour moi, ce patch c'est du gros n'importe quoi de gars qui n'a jamais fait de réseau de sa vie.
"On manque tellement d'adresses IP" -> de toute façon qu'est-ce que ça change ? ça ne sera jamais routé sur l'Internet public. Pour du local, il y a déjà 172.16.0.0/12, 192.168.0.0/16 et 10.0.0.0/8, je crois qu'il y a quand même de quoi faire!
S'il se sent concerné par un manque d'adresses IP, qu'il travaille au déploiement d'IPv6, ça sera certainement plus utile.

• sizeof(char) vaut toujours 1 d'après la norme.
• on ne caste pas le retour de malloc() / realloc()
• on teste les codes de retour

Honnêtement non (et je sais que c'est pas bien). Je ne vais pas sur des sites "bizarres" donc ça limite déjà pas mal (même si on est d'accord que ça n'a rien d'une sécurité absolue).
Cela dit, pour la faille en question, comme ça ne concerne JRE 7 ce n'est pas un problème puisque je n'utilise pas cette version.

Les seules applets Java que j'utilise sont pour des choses bien spécifiques en interne: accès aux consoles de machines HP via iLO par exemple.

Je n'avais pas noté que les caravanes sont tirées par des boeufs et des moutons…

Et qui surveille les surveillants ?

J'en déduis que le Boson de Higgs aime le pastis, j'ai bon ?

Comme l'a dit imbolcus, c'est une offre orientée "particuliers", Cisco a racheté Linksys pour avoir des parts dans ce secteur.

Pour les professionnels, tu pourras aussi avoir tes routeurs dans "le cloud" avec le CSR-1000V, mais là ce sera juste un IOS (IOS-XE, qui s'appuie sur un noyau Linux) qui tournera dans une VM. Par contre évidemment, la conf sera "locale".

Sur le principe, ça ressemble fortement à ce que fait Free, où la config de la Freebox (modifiable via une page web) est stockée sur les serveurs de Free, non ?

Après, pour l'accès au réseau domestique à distant, bah on dirait juste … du VPN.