Le problème, c'est qu'une machine IPv4 sans configuration qui reçoit un paquet IPv6, quel qu'il soit, il ne comprend pas. Quelles que soient les solutions de transitions, il faut une mise à jour pour qu'un équipement IPv4 soit capable de reconnaître un paquet IPv6. Et ça, c'est pour les solutions simples ou chaque équipement à une IPv4 publique. Tu rajoutes les NAT au dessus de ce bazar et c'est vraiment la merde.
Le pb, c'est tout les protocoles qui échange des adresses ip.
Sinon la transition aurait été plus simple : avant d'arrivé chez le client, l'entête ipv6 est reconverti en ipv4
Avec les 64 bits pour l'identifiant d'interface, on permet de l'auto-configuration sans état. Et sans risques de collisions.
Le fait d'utiliser l'adresse MAC est une mauvaise idée :
- celle-ci commence a saturée (utilisé par ethernel, wifi, bt, ...)
- elle est quelques fois random
- c'est pas très respectueux de la vie privée
- ca bouffe qd même 48 bits.
Il est certain qu'en voyant IPv6 uniquement comme de l'IPv4 avec plus d'adresses, on ne va pas progresser. Cette nouvelle architecture est loin d'être anodine, on passe d'une gestion des adresses en nombre ultra-limité à un nombre quasi-infini, d'abondance.
Le pb c'est ipv6 va être au final utiliser seulement pour avoir plus adresse.
Et dans ce cas, il y avait moyen d'étendre ipv4 bien plus simplement.
Par exemple en faisant un encodage à la utf-8 :
les adresses existante continue d'être valide, mais on a la possibilité d'avoir de nouvelles adresses étendue.
En se débrouillant bien ces adresses étendues sont droppé par les anciens équipement (sans conflicter avec d'autres protocoles).
Au final on a :
- un nombre adresse illimité
- un encodage qui permet de garder des adresse retenable par des humains (la taille grossi progressivement)
- un compat avec ipv4, ce qui permet de migrer en douceur. On ne fait qu'étendre le réseau existant, on ne crée pas un réseau //.
J'aimerais bien configurer le NAT de mon opérateur mobile.
Tu l'auras peux être l'ipv6 sur ton mobile. Par contre attend toi a un forfait costaud...
Déja que pour avoir des ports ouverts en ipv4 il faut raqué...
Sauf que pour le moment tu as 2 réseaux disjoins ipv6 et ipv4.
Tu peux facilement faire un pont ipv4 vers ipv6 (il suffit de faire une bijection entre les ipv4 et des ipv6).
Par contre pour faire un pont ipv6 vers ipv4 il faudra faire du NAT vu que nb(ipv6) > nb(ipv4).
Donc dans 222 jours ceux qui n'auront plus ipv4 seront Naté ;)
Et vu que pour le moment la majorité de l'internet est sur ipv4, les FAI ont tout interret a récupérer le max d'adresse ipv4 tant qu'il y en a.
Aujourd'hui avoir seulement une ipv6 est suicidaire (tu es coupé du monde).
Et j'en reviens a l'echec d'IPV6. ipv6 c'était pas seulement plus d'adresse, c'etait censé amené d'autre fonctionnalité intéressante (mobilité, ...). Sauf que ça n'a pas l'air d'avoir marché...
Et la transition est merdique : 2 réseau disjoins...
Si les professionnels sont réticents à passer à IPv6, c'est parce que ça brise leurs petites habitudes IPv4, et que ça leur entraîne des coûts pour le changement de matos etc.
C'est bien ce que je disais ça leur apporte rien. Que des frais pour le nouveau matos.
Sinon, même niveau user c'est chiant. Va retenir une ipv6 : impossible. Et puis c'est chiant a taper.
Là c'est un exemple avec Netfilter, mais j'imagine que tout pare-feu capable de faire du NAT peut en faire autant.
C'est pas le cas de la freebox par exemple.
Si autant de professionnel sont rétissant à passer sur ipv6, ca montre pas un echec de ipv6 ?
On passe pas dessus parce qu'il est sexy, mieux, nous simplifie la vie.
Non on est forcé de passer dessus, mais c'est tellement compliqué qu'on profite de ipv4 jusqu'au dernier moment (ie c'est le manque d'adresse ipv4 qui nous force la main).
Combien de fournisseur vont switcher complétement à ipv4 et ne pas mettre seulement en place un système de tunnel ?
Combien de temps on va devoir garder ipv4 ? Que faire de tout le matos que l'on a et qui ne supportera jamais ipv6 (routeur, console, ...). On va devoir émulé ipv4 au dessus d'ipv6 (ce qui revient a faire un NAT).
Vu les plages fournies en ipv6 (au moins /64), on va pouvoir tenir combien de temps ?
Posté par M .
En réponse à la dépêche Firesheep.
Évalué à 3.
Depuis l'arrivée du cookie, c'est devenu le moyen de maintenir une session pour les utilisateurs des sites.
Il me semble qu'il y a d'autres moyens que les cookies. Notamment un n° de session dans l'url.
Dans le C en 20H Il
existe une multitude d’éditeurs de texte qui permettent de saisir des programmes : Emacs (que
j’utilise en ce moment même), Kate, Bluefish, Gedit...
Pas de vim et l'auteur utilise emacs. Comment être crédible après ça ?
Alors que dans une autre école d'igne (assez réputé), la première semaine on avait des TP unix :
- sur un bon vieux sunos
- fvwm comme dm
- shell tcsh en mode vi par défault
- editeur vi (pas vim), nedit ou emacs
Et vérif des connaissances au partiel de la toussaint.
Et ben je me rappel qu'il y en a qui en ont souffert (entre ceux qui n'avait quasiment jamais touché a un ordi et ceux qui ne connaissait que les GUI MS)...
PS : bon heureusement il des personnes bienveillante avait compilé des soft alternatif (vim, ...)
PPS : ca se passait il y a seulement 7 ans.
PPPS : sinon on avait aussi le MSDNAA, a l'époque on le téléchargeais pas, on devait copier des CD (au moins 5 pour visual). Et ben je crois que je les ai jamais installé, la seul fois que j'ai essayé il fallait faire tout un tas de MAJ...
Cette belle idée du "mécanisme d'attente adaptable" avait donc été implémentée dans le noyau 2.6.30 pour la plus grande satisfaction de tous. Depuis ce temps là, les processus attendaient un peu avant de s'endormir quand ils rencontraient un mutex pris par un autre processus.
Il aurait été bon de préciser que ça marche qu'en smp. En mono coeur, on peut attendre autant qu'on veut, tant qu'on a la main, le mutex sera pas relâché...
compilateur qui est malheureusement axé pas mal apple :
- la target principal est darwin x86 et arm. Le support des autres os tient parfois du hack ou n'est pas correct (au niveau ABI). Le support des autres archi (sparc, ppc) est pauvre.
- support de la cross compilation marche bien que sous MacOS
- le support de arm est orienté sur les coeurs récent (utilisé dans les iphone). Pour les plus vieux armv5, il existe des bugs qui n'interresse pas les développeurs.
De plus il se fait passer pour gcc, mais ne l'émule pas toujours correctement.
Ca avance, mais il n'a pas l'air d'être encore bon pour faire des trucs industriel sous Linux.
C'est bien de lister ce que supporte les media player...
Toolchain Features
* Supported Target Languages: C, C++, Python
* Complete Cross-Compiler and Sysroot generation
* Support for external CodeSourcery toolchain for ARM targets
* Modularized distribution.
* Multiple supported C libraries: eglibc, glibc, uClibc
* SIMD Optimizations: NEON, VFP, AltiVec, MMX, SSE.
* Generic CPU support or target specific fine tuning optimizations.
En gros vous supporter plusieurs version de gcc
* OPKG Packaging
Quel version ?
Parce que la dernière fois que j'ai regarder, chacun le patchait dans son coin (openmoko, openwrt, ...)
L'étape de synchro a la main me parait un peu limite.
Dans les logiciels de sous titre que j'avais vu, il y avait moyen d'avoir la courbe audio pour les synchroniser précisément et pas le faire à l'oreille.
a mettre en // avec https://panopticlick.eff.org/ qui montre comment en exploitant les infos fournies par le navitageur, on peut creer une sorte d'empreinte.
Comme quoi le web c'est de plus en plus une usine a gaz.
Il y a une époque ou le navigateur (client), n'était qu'un bête lecteur qui ne renvoyait aucune info vers l'extérieur (en dehors des formulaires tapé par l'utilisateur).
Avec le javascript, AJAX, html5 et les divers plugins le navigateur devient un véritable OS, qui envoie, reçoit des données dynamiquement.
En plus de ces cookies, j'avais vu un article sur un site qui arrivait a faire une emprunte (fingerprint) assez unique d'un navigateur avec toutes les infos qu'il renvoyait (user agent, plugins supportés, ...).
A quand un navigateur vraiment sécure ?
noscript aide pas mal, mais c'est assez contraignant (surtout que pas mal de site on des comportements indéfinis sans js).
idem pour les Cookie HTTP.
En fait il faudrait totalement repensé les navigateurs pour qu'il se comporte comme un véritable OS : un site <-> un user.
- les données sont isolées entre les sites. Et les même données d'un site se retrouve toute au même endroit.
Il peut y avoir des groupe pour partager les données entre site, tout comme des options pour controller la persistance des données.
- On peut attribuer des limitations aux scripts/page (pas plus de n % de cpu, de la ram)
Pour la petite histoire au boulot on a des oscilo qui tourne sur windows.
Les clefs usb servent a sauvegarder des captures d'écrans.
Et ben l'autorun est activé sur ces osillos et on a eu une belle diffusion de virus via des oscillos qui sont partagée entre plusieurs équipes.
Bon on critique Windows, mais linux n'est pas forcement mieux. Certains desktop user-friendly tente à se rapprocher du comportement de windows. Et Linux a aussi des failles de sécu.
[^] # Re: Questions naïves
Posté par M . En réponse à la dépêche IPv4 est mort, vive IPv6 !. Évalué à 1.
Et franchement niveau perf, je demande a voir.
[^] # Re: Questions naïves
Posté par M . En réponse à la dépêche IPv4 est mort, vive IPv6 !. Évalué à 0.
[^] # Re: Questions naïves
Posté par M . En réponse à la dépêche IPv4 est mort, vive IPv6 !. Évalué à 2.
Le pb, c'est tout les protocoles qui échange des adresses ip.
Sinon la transition aurait été plus simple : avant d'arrivé chez le client, l'entête ipv6 est reconverti en ipv4
Avec les 64 bits pour l'identifiant d'interface, on permet de l'auto-configuration sans état. Et sans risques de collisions.
Le fait d'utiliser l'adresse MAC est une mauvaise idée :
- celle-ci commence a saturée (utilisé par ethernel, wifi, bt, ...)
- elle est quelques fois random
- c'est pas très respectueux de la vie privée
- ca bouffe qd même 48 bits.
Il est certain qu'en voyant IPv6 uniquement comme de l'IPv4 avec plus d'adresses, on ne va pas progresser. Cette nouvelle architecture est loin d'être anodine, on passe d'une gestion des adresses en nombre ultra-limité à un nombre quasi-infini, d'abondance.
Le pb c'est ipv6 va être au final utiliser seulement pour avoir plus adresse.
Et dans ce cas, il y avait moyen d'étendre ipv4 bien plus simplement.
Par exemple en faisant un encodage à la utf-8 :
les adresses existante continue d'être valide, mais on a la possibilité d'avoir de nouvelles adresses étendue.
En se débrouillant bien ces adresses étendues sont droppé par les anciens équipement (sans conflicter avec d'autres protocoles).
Au final on a :
- un nombre adresse illimité
- un encodage qui permet de garder des adresse retenable par des humains (la taille grossi progressivement)
- un compat avec ipv4, ce qui permet de migrer en douceur. On ne fait qu'étendre le réseau existant, on ne crée pas un réseau //.
[^] # Re: ...
Posté par M . En réponse à la dépêche Firesheep. Évalué à 2.
Sois tu es en http et c'est en clair comme les cookies.
Sois tu es en https et c'est pas en clair
[^] # Re: ipv6
Posté par M . En réponse à la dépêche IPv4 est mort, vive IPv6 !. Évalué à -2.
[^] # Re: Le problème : l'arriérisme ambiant
Posté par M . En réponse à la dépêche IPv4 est mort, vive IPv6 !. Évalué à 3.
Tu l'auras peux être l'ipv6 sur ton mobile. Par contre attend toi a un forfait costaud...
Déja que pour avoir des ports ouverts en ipv4 il faut raqué...
[^] # Re: ipv6
Posté par M . En réponse à la dépêche IPv4 est mort, vive IPv6 !. Évalué à 3.
Tu peux facilement faire un pont ipv4 vers ipv6 (il suffit de faire une bijection entre les ipv4 et des ipv6).
Par contre pour faire un pont ipv6 vers ipv4 il faudra faire du NAT vu que nb(ipv6) > nb(ipv4).
Donc dans 222 jours ceux qui n'auront plus ipv4 seront Naté ;)
Et vu que pour le moment la majorité de l'internet est sur ipv4, les FAI ont tout interret a récupérer le max d'adresse ipv4 tant qu'il y en a.
Aujourd'hui avoir seulement une ipv6 est suicidaire (tu es coupé du monde).
Et j'en reviens a l'echec d'IPV6. ipv6 c'était pas seulement plus d'adresse, c'etait censé amené d'autre fonctionnalité intéressante (mobilité, ...). Sauf que ça n'a pas l'air d'avoir marché...
Et la transition est merdique : 2 réseau disjoins...
[^] # Re: ipv6
Posté par M . En réponse à la dépêche IPv4 est mort, vive IPv6 !. Évalué à 1.
C'est bien ce que je disais ça leur apporte rien. Que des frais pour le nouveau matos.
Sinon, même niveau user c'est chiant. Va retenir une ipv6 : impossible. Et puis c'est chiant a taper.
[^] # Re: Pas besoin de NAT pour faire de la sécurité bon marché
Posté par M . En réponse à la dépêche IPv4 est mort, vive IPv6 !. Évalué à 2.
C'est pas le cas de la freebox par exemple.
# ipv6
Posté par M . En réponse à la dépêche IPv4 est mort, vive IPv6 !. Évalué à 5.
On passe pas dessus parce qu'il est sexy, mieux, nous simplifie la vie.
Non on est forcé de passer dessus, mais c'est tellement compliqué qu'on profite de ipv4 jusqu'au dernier moment (ie c'est le manque d'adresse ipv4 qui nous force la main).
Combien de fournisseur vont switcher complétement à ipv4 et ne pas mettre seulement en place un système de tunnel ?
Combien de temps on va devoir garder ipv4 ? Que faire de tout le matos que l'on a et qui ne supportera jamais ipv6 (routeur, console, ...). On va devoir émulé ipv4 au dessus d'ipv6 (ce qui revient a faire un NAT).
Vu les plages fournies en ipv6 (au moins /64), on va pouvoir tenir combien de temps ?
# ...
Posté par M . En réponse à la dépêche Firesheep. Évalué à 3.
Il me semble qu'il y a d'autres moyens que les cookies. Notamment un n° de session dans l'url.
# ...
Posté par M . En réponse à la dépêche Les Framabooks sont de sortie. Évalué à 7.
Il
existe une multitude d’éditeurs de texte qui permettent de saisir des programmes : Emacs (que
j’utilise en ce moment même), Kate, Bluefish, Gedit...
Pas de vim et l'auteur utilise emacs. Comment être crédible après ça ?
Comment ca on est vendredi.
[^] # Re: et pour le C ?
Posté par M . En réponse au sondage J'indente mon code source avec. Évalué à 2.
# hurd
Posté par M . En réponse au journal Il est de retour !. Évalué à 10.
Pourtant il était parti avec quelques années d'avance ;)
# ...
Posté par M . En réponse au journal la Geste de l'Estudiant.. Évalué à 6.
- sur un bon vieux sunos
- fvwm comme dm
- shell tcsh en mode vi par défault
- editeur vi (pas vim), nedit ou emacs
Et vérif des connaissances au partiel de la toussaint.
Et ben je me rappel qu'il y en a qui en ont souffert (entre ceux qui n'avait quasiment jamais touché a un ordi et ceux qui ne connaissait que les GUI MS)...
PS : bon heureusement il des personnes bienveillante avait compilé des soft alternatif (vim, ...)
PPS : ca se passait il y a seulement 7 ans.
PPPS : sinon on avait aussi le MSDNAA, a l'époque on le téléchargeais pas, on devait copier des CD (au moins 5 pour visual). Et ben je crois que je les ai jamais installé, la seul fois que j'ai essayé il fallait faire tout un tas de MAJ...
# Attente optimiste sur les mutex
Posté par M . En réponse à la dépêche Le noyau Linux 2.6.36 est disponible. Évalué à 7.
Il aurait été bon de préciser que ça marche qu'en smp. En mono coeur, on peut attendre autant qu'on veut, tant qu'on a la main, le mutex sera pas relâché...
[^] # Re: Merci Apple
Posté par M . En réponse à la dépêche LLVM 2.8, ça avance !. Évalué à 3.
- la target principal est darwin x86 et arm. Le support des autres os tient parfois du hack ou n'est pas correct (au niveau ABI). Le support des autres archi (sparc, ppc) est pauvre.
- support de la cross compilation marche bien que sous MacOS
- le support de arm est orienté sur les coeurs récent (utilisé dans les iphone). Pour les plus vieux armv5, il existe des bugs qui n'interresse pas les développeurs.
De plus il se fait passer pour gcc, mais ne l'émule pas toujours correctement.
Ca avance, mais il n'a pas l'air d'être encore bon pour faire des trucs industriel sous Linux.
# ...
Posté par M . En réponse à la dépêche Sortie du projet OpenBricks: un framework pour Linux embarqué.. Évalué à 2.
Supported Filesystems
* EXT 2/3/4
* JBD
* ReiserFS
* JFS
* XFS
* GFS2
* OCFS2
* FUSE
* ISO9660 / Joliet / UDF
* FAT16 / FAT32 / NTFS
Par de support de fs nand, c'est pratique pour l'embarqué...
Sinon la liste des fonctionalitées fait vraiment pipo
Key Features
* Multi-Cores SMP optimizations.
* Support for SMT HyperThreading.
* Hardware Cryptographic Acceleration: SHA1, MD5, AES …
Ca vient du kernel et ca va dependre du hardware que l'on aura...
Media Players
* libplayer Audio/Video abstraction framework
* FFmpeg
* MPlayer
* Xine
* GStreamer
* VLC
* VDR (Video Disk Recorder)
[...]
Key Audio/Video Profiles
* Video Codecs: MPEG 1/2/4, H.264, Theora, VC-1, VP8 …
* Audio Codecs: MP3, Vorbis, AAC, AC-3, DTS …
* Protocols: CDDA, DVD, DVB-C/S/T, V4L2, Bluray …
* Streaming: RTP, RTSP, ASF, MMS, WebM …
C'est bien de lister ce que supporte les media player...
Toolchain Features
* Supported Target Languages: C, C++, Python
* Complete Cross-Compiler and Sysroot generation
* Support for external CodeSourcery toolchain for ARM targets
* Modularized distribution.
* Multiple supported C libraries: eglibc, glibc, uClibc
* SIMD Optimizations: NEON, VFP, AltiVec, MMX, SSE.
* Generic CPU support or target specific fine tuning optimizations.
En gros vous supporter plusieurs version de gcc
* OPKG Packaging
Quel version ?
Parce que la dernière fois que j'ai regarder, chacun le patchait dans son coin (openmoko, openwrt, ...)
PS : ca apporte quoi ?
# synchro
Posté par M . En réponse au journal Universal Subtitles. Évalué à 5.
Dans les logiciels de sous titre que j'avais vu, il y avait moyen d'avoir la courbe audio pour les synchroniser précisément et pas le faire à l'oreille.
[^] # Re: euh
Posté par M . En réponse au journal Upgrade de Lenny à Squeeze à la coyote.... Évalué à 6.
ca me rappel un autre OS...
# ...
Posté par M . En réponse à la dépêche blogARM.net organise une pétition pour avoir un Linux sur l'AC100. Évalué à 3.
Certains drivers ?
# panopticlick
Posté par M . En réponse à la dépêche Cadriciel d'espionnage/gestion de témoin de connexion evercookie 0.3. Évalué à 5.
# ...
Posté par M . En réponse au journal Cadriciel d'espionnage.. Évalué à 4.
Il y a une époque ou le navigateur (client), n'était qu'un bête lecteur qui ne renvoyait aucune info vers l'extérieur (en dehors des formulaires tapé par l'utilisateur).
Avec le javascript, AJAX, html5 et les divers plugins le navigateur devient un véritable OS, qui envoie, reçoit des données dynamiquement.
En plus de ces cookies, j'avais vu un article sur un site qui arrivait a faire une emprunte (fingerprint) assez unique d'un navigateur avec toutes les infos qu'il renvoyait (user agent, plugins supportés, ...).
A quand un navigateur vraiment sécure ?
noscript aide pas mal, mais c'est assez contraignant (surtout que pas mal de site on des comportements indéfinis sans js).
idem pour les Cookie HTTP.
https://addons.mozilla.org/en-US/firefox/addon/6581/ a l'air pas mal pour brouiller les pistes, mais il n'est pas très actif.
En fait il faudrait totalement repensé les navigateurs pour qu'il se comporte comme un véritable OS : un site <-> un user.
- les données sont isolées entre les sites. Et les même données d'un site se retrouve toute au même endroit.
Il peut y avoir des groupe pour partager les données entre site, tout comme des options pour controller la persistance des données.
- On peut attribuer des limitations aux scripts/page (pas plus de n % de cpu, de la ram)
# ...
Posté par M . En réponse au journal Le retour de la revanche du Pentagone. Évalué à 5.
Les clefs usb servent a sauvegarder des captures d'écrans.
Et ben l'autorun est activé sur ces osillos et on a eu une belle diffusion de virus via des oscillos qui sont partagée entre plusieurs équipes.
Bon on critique Windows, mais linux n'est pas forcement mieux. Certains desktop user-friendly tente à se rapprocher du comportement de windows. Et Linux a aussi des failles de sécu.
Au passage sous Mac, ca donne quoi ?
[^] # Re: Désolé
Posté par M . En réponse à la dépêche Un nouveau serveur httpd : Ashd, A Sane HTTP Daemon. Évalué à 2.