Dans le cas de Google, ce qui est vendu, ce n'est pas toi mais l'exposition qu'offre une requete. D'ailleurs, je te conseille de faire un tour sur Google adwords pour te démystifier ca: quand tu poses une enchere publicitaire, tu ne le fais pas sur un profil d'utilisateur, mais bien sur une requete.
Faux. Ça s'appelle le “Real-time bidding”, ces informations sont négociées à chaque impression, en fonction de la localisation, de ton historique de navigation, de ton profile, etc. C'est comme le High Frequency Trading, mais c'est toi la marchandise qui est échangée à haute vitesse.
Rien de bien nouveau. La spéculation, faire du chiffre en étant le premier quelque part,… ça existait avant le bitcoin et ça existera après. Il y en a qui ont le culot d'acheter des terrains pas chère et qui les revendent avec une plus valu monstrueuse alors que leur seul mérite c'est de les avoir acheter assez tôt. Quand certains achètent des actions d'une boite pour 3 fois rien et qu'ils les revendent 5 ans après le triple du prix c'est le même principe.
Moi je vois quand même des choses différentes : le terrain, c'est un bien limité. L'entreprise, c'est quelque chose qui doit « créer de la valeur », à priori sans limite supérieure. Soit tu fais comme dans le Far West et chacun se sert jusqu'à ce qu'il n'y en ait plus, et tant pis pour ceux qui ne se sont pas servis, soit tu te dis au bout d'un moment qu'il faudrait quand même trouver des règles équitables, car sinon c'est trop vite le bordel et certains vont devenir « injustement » riches. Dans un autre commentaire, une moule parlait de « jalousie » : bien que pour certains c'est peut-être ça, le but au final c'est quand même, pour moi et sûrement d'autres, d'être équitable. Et donc, de ne pas participer à une chose si celle-ci n'est pas équitable.
Bitcoin n'est pas équitable (oui, comme plein d'autres « marchés » ou autres distributions de ressources) et donc je n'ai pas envie d'y participer. Je trouve ça dommage que d'autres le fassent, car ce faisant ils augmentent l'attrait global vers ce système inéquitable. Comme cette donation pour OpenBSD : le mec la fait en en parlant bien, histoire de crédibiliser cette monnaie. Donc, ceux qui y participent ne sont pas seulement « chanceux », ils entraînent également d'autres personnes dans ce cercle inéquitable en rendant ce système plus « respectable ». Après, dans l'absolu, oui, on ne va pas empêcher machin de faire ci ou ça, mais bon, les lois qu'on a obéissent à une certaine morale, généralement.
Tu peut évidement trouver que c'est mal, que spéculer sur une monnaie c'est mal (ça n'est pas lié qu'au bitcoin ça même les autres monnaies sont touchées), etc, mais ça n'est pas vraiment un problème de bitcoin c'est, je sais pas, le modèle ou le système économique qui est comme ça.
Oui, effectivement. Est-donc pour ça qu'il ne faut rien faire contre ? Commencer par ne pas promouvoir un tel système en n'y participant pas est déjà pas mal.
Quand on voit la réponse de Lennart https://bugzilla.redhat.com/show_bug.cgi?id=833105, on ne peut s'empêcher de voir la mauvaise foi de partout : il ignore l'utilisation de SIGSTOP seulement si un flag/variable d'environnement est mis, dit que ça peut être utilisé pour autre chose, mais là c'est dans le cas où le process l'utilise sur lui-même, il indique qu'il ne voit pas de différence entre appeler une fonction de la libc et introduire une dépendance à sa lib (il doit s'en foutre du boulot de mise à jour de tous les paquets, même les plus vieux/exotiques/etc…), … Alors que le rapport original demande juste une simple mesure pour être compatible optionnellement avec certains programmes !
Il est trop reulou. Techniquement, c'est à dire au niveau des capacités, je trouve que systemd bat de loin tous les autres. Ça serait la raison qui me fait le supporter. Mais entre son implémentation lourdingue, sa volonté de vouloir tout remplacer d'un coup (génial), l'intégration de tout dans systemd ce qui rend udev et d'autres utilitaires essentiels forcément dépendants de systemd sans toujours de bonne raisons, le « j'en n'ai rien à foutre des autres qui ne peuvent pas suivre », et l'ego démesuré de ce mec… c'est super chiant. Alors oui, je ne vois pas de solution aussi « bien » que la sienne, mais on sent tellement une sorte d'imposition de l'avis de RedHat sur un paquet de choses d'un coup, et que plein de monde va être largué parce que non compatible, que ça fait très peur.
J'ai déjà vu aussi des noirs et des femmes mal se comporter.
Rien que ce commentaire aux sous-entendus lourds montre ton sexisme et ton racisme. En quoi la couleur de peau de quelqu'un ou son sexe devrait dicter les caractéristiques de son comportement ? Est-ce que si un noir ou une femme fait quelque chose de « mal », il faut en tirer des conclusions venant d'une caractéristique qu'il n'a pas choisi ? Pourquoi opères-tu un tel classement pour après rétorquer que, quand même, « ils se victimisent », « yen a des pas biens » (pour paraphraser Didier Super), etc. Crois-tu que ton sexe ou ta couleur de peau va te faire changer ta manière de penser ?
Ce qui influe sur ta manière de penser, dans le contexte de cette discussion, c'est ce que « la société » (les préjugés de ta culture, etc) va dire à propos de caractéristiques que tu as mais que tu n'as pas choisi. Effectivement, au début, il n'y a aucune raison de discriminer là-dessus, comme toi et d'autres se plaisent à dire. Mais la réalité, l'histoire, la culture, font qu'aujourd'hui il existe ce genre de discriminations. Elles sont bêtes, mais malheureusement présentes dans l'esprit de beaucoup de gens. Alors, soit on attend tranquillement que ça change magiquement, soit on se dit que, ces personnes discriminées étant moins puissantes, il faut rééquilibrer les choses en étant un peu plus ferme.
Forcément, quand tu invoques la pseudo-persécution des homme blancs, c'est ridicule, car un puissant qui invoque la persécution, ça fait bien rire ceux qu'il domine. Alors après, je ne parle pas de toi en particulier : tu es sûrement un homme blanc très bien, qui fait plein de choses géniale pour le libre, mais ne discrimine jamais les gens sur leur sexe ou leur couleur de peau. Mais, malgré toi, tu représentes le dominant. « Horreur », cries-tu, car on se met à te discriminer sur des critères que tu ne peux pas choisir ! Et oui, ça fait mal, hein ?
Et bien maintenant, en tant qu'homme blanc parfait qui ne discrimine jamais injustement, essaye un peu de regarder autour de toi toutes les actions que tu fais, les remarques que tu sors, et demande-toi à quel point elles peuvent être blessantes pour ces catégories discriminées. Là, tu as été offusqué par un thread sur linuxfr ! Imagine le truc quand tu te prends tous les jours des remarques, conscientes ou inconscientes, directes ou indirectes, sur ta condition à laquelle tu ne peux rien. Et ne me sors pas l'exemple de cette conversation : le threads qui bachent les hommes blancs, ça représente peanuts par rapport au reste. Mais vraiment que dalle de rien de rien. Et en plus tu fais partie d'une catégorie qui n'a pas à se plaindre (hou, que je suis méchant de te traiter ainsi). Rien que le fait de continuer à garder ta position est une insulte pour toutes les victimes de discrimination. Relis ce thread en te mettant à la place de quelqu'un qui les vit tous les jours. Ah non, pardon, tu ne peux pas, parce qu'en fait, ça ne sont pas vraiment des victimes, ils le font exprès. Bon, tant pis.
Oui, bon, l'authentification par secret partagé (ici un mot de passe), c'est bien, c'est pas trop compliqué même si comme tu le montres, il existe beaucoup de moyens de se foirer, mais quand même, depuis un bout de temps on a inventé d'autres moyens d'authentification. Certes, il nécessitent une modification des protocoles, et ne sont pas de simples moyens de « stockage de mots de passe ». Mais ils ont souvent d'autres avantages, le premier étant par exemple de ne jamais dévoiler le mot de passe au serveur en question. Au vu de la réutilisation massive des mots de passe de la part des utilisateurs pour différents services, ça me semble une qualité pas du tout négligeable.
Comme exemple, je pense par exemple à SCRAM http://tools.ietf.org/html/rfc5802, RFC 5802. Ça se base sur TLS pour l'authentification du serveur, et permet d'authentifier l'utilisateur sans qu'il ne donne son mot de passe, et sans que le serveur puisse se faire passer pour le client pour d'autres services (c'est un peu dérivé de la propriété précédente, certes), tout en évitant bien sûr le problème de dévoilement du secret côté serveur en cas de vol de la base. En bonus, je crois (mes souvenirs sont mauvais) qu'il évite les écueils classiques du channel-binding, i.e. il indique l'information qu'on peut utiliser comme étant suffisante pour identifier la personne à partir de ce canal, afin d'éviter le MITM (bon, c'est pas clair du tout dit comme ça…) ; cf RFC 5056 http://tools.ietf.org/search/rfc5056 si vous voulez creuser.
Si si, c'est juste avec l'ipv6 que j'ai un problème, pas l'ipv4.
Gni ? J'ai jamais dit ça… Franchement, entre ne pas citer ce à quoi tu réponds, et ta syntaxe/grammaire déplorable, j'ai vraiment beaucoup de mal à te comprendre et ça me fatigue.
Si je rajoute la 1ere, j'ai:
default via fe80::ee30:91ff:fee0:dfc0 dev eth0 metric 2
default via fe80::ee30:91ff:fee0:dfc0 dev eth0 proto ra metric 1024 expires 1782sec
default via fe80::12bd:18ff:fee4:5040 dev eth0 proto ra metric 1024 expires 1782sec
Donc sans RA…
C'est une question ? Une affirmation ? C'est le résultat de ip -6 route, je suppose, mais je ne sais pas ce qu'est la partie que tu cites dessus. En gros, là, tu vois qu'il y a eu une route à priori rajoutée à la main, et deux autres par RA. Je ne comprends pas ce qui ne va pas, et ce que tu veux, bref, exprimes-toi clairement sinon moi j'arrête.
Gentoo le permet, par contre si JE me plante, mon dédié sera inaccessible. Je devrai passer en rescue, réparer, rebooter, gros risque.
T'as toujours l'IPv4, hein. Et je ne connais pas les dédiés, mais c'est si difficile que ça d'avoir une console série sur ta machine ?!
J'ai besoin d'au moins une ip par machine virtuelle, et donc vu que c'est environs 3000 sites d'hébergés, plus de 30 machines virtuelles…
Cf ce que j'ai dit plus bas, ça m'étonnerait que tu veuilles réellement mettre ces IP sur ton « hyperviseur »…
je confirme, je ne suis pas encore maitre de l'ipv6…
Pas de problème ; je te conseille d'aller lire http://livre.g6.asso.fr/ si tu veux te former un peu.
Cette route reviens aprés le /etc/init.d/net.eth0 restart
Bah… à toi de comprendre pourquoi. Mais du coup, je me dis, que tu te lances dans IPv6 que tu connais mal avec une distro que tu maîtrises mal… tout ça sur une machine ou tu ne peux pas te permettre d'essayer des trucs à peine risqués… ça ne me paraît pas super génial.
ipv6 sous la forme XXXXX/64 dans la config.
Bah, du coup je comprends pas, et je ne peux pas t'aider là-dessus.
Désolé, ma co merde (adsl), et donc réécrire 3x la même chose, au final je fait plus gaffe à l'orthographe.
Gni ? Tu ne peux pas copier ton message quelque part (ou l'écrire autre part) avant de poster ?…
Oui, c'est la même chose que ipv4 (ip failover d'ovh) mais en ipv6,
OK.
c'est pour avoir tel et tel ip sur mes vm en vserver.
Ah non, je ne comprends pas en fait. C'est du failover pour ta machine ou pour tes VMs ? Si c'est pour tes VMs, pourquoi les attribues-tu à l'interface de ton « hyperviseur » (en quelques sortes) ?
Pourrais-tu décrire plus précisément ton setup ? Parce que tu n'as toujours pas dit clairement ce que tu voulais obtenir, et comment tu avais fait jusqu'à maintenant. Tu veux « connecter » tes VMs au net ? Tu veux les bridger ou les router ?
La configuration manuel est recommande, surtout pour évité les faille dhcp et les coupure lors du renouvellement d'ip qui est fixe…
Les « failles » DHCP ? Mouai, moyen détourné de dire « on sait pas gérer un DHCP » (de la part d'OVH)… Et les coupures lors du « renouvellement » d'IP, tu parles encore du DHCP ? Ou d'autre chose ?! Je ne comprends pas trop sinon : une IP fixe mais « renouvelée » ?…
Je peu le mettre en fix? Apparement j'ai trouver comme le mettre en fix sous gentoo la passerelle ipv4 et ipv6.
Normalement une bonne distro te le permet. Sous debian c'est l'attribut "gateway" dans /etc/network/interfaces. Je connais mal Gentoo.
le /56, je sais pas d'ou ça viens, c'est pas dans ma config, j'y est mit que: X:X:X:X:1/64 jusqu'as X:X:X:X:5000/64
Houla, pourquoi tu veux mettre toutes ces IP sur ta config ?
donc oui c'est …a505::/64 la plage qui est bonne.
OK. Si ce /56 apparaît, c'est que tu ne dois pas complètement maîtriser ta config… c'est pas super bon signe pour arriver à correctement gérer ce problème. Elle est indiquée en "proto kernel" ce qui indiquerait (je crois) qu'elle est configurée manuellement, et pas à travers un RA. Si tu veux vérifier que ça ne vient pas par un RA, tu peux soit sniffer les RA, soit l'effacer (ip -6 route del …) et voir si elle revient (quand tu acceptes les RA, i.e. pas quand le forwarding est activé, à moins que tu aies appliqué le workaround que j'ai décrit).
Ovh m'as indiquer ces réglages,
Lesquels exactement ? J'avoue qu'avec l'orthographe assez limite en plus, j'ai du mal à te comprendre précisément.
peu étre qu'il faut que je mette juste X:X:X:X:1/64 dans mon interface…
Moi c'est ce que je te conseillerais, si tu n'utilises que ce /64.
OK, on voit en gros que les RA sont valables 1/2h, c'est à peu près le temps au bout duquel tu vois que ça déconne ? Si c'est ça, c'est que soit les routeurs n'envoient pas assez souvent de RA, soit tu les bloques d'une manière ou d'une autre.
Par contre, je vois un autre problème : ta conf. C'est quoi ce /56 sur eth0 ? C'est pas bon, on met toujours un /64 sur un segment Ethernet. Je suppose que c'est que le …a505::/64 qui est le « bon » ? Indique nous ta configuration qu'on en sache plus.
Ah, du coup je comprends, je pense : ça « déconne » 1/2h après que tu actives le forwarding ? C'est normal, car un routeur (qui n'est pas un nœud comme les autres) n'accepte par les RA par défaut. Il faut soit que tu les spécifies manuellement (la méthode traditionnelle ; tu peux demander à celui qui gère les routeurs de « sortie » s'il les configure avec des adresses link-local spécifiques que tu pourrais ajouter manuellement, genre fe80::1), soit que tu dises au kernel d'accepter les RA avec le sysctl net.ipv6.conf.all.accept_ra = 2. Attention, ainsi, il se configurera automatiquement avec une adresse genre SLAAC sur eth0. Si tu n'en veux pas, mets le net.ipv6.conf.all.autoconf = 0.
Heu… ça marche très bien juste avec "-6", hein, depuis un bout de temps. Si j'avais à me taper la commande complète à chaque fois, ça me soulerait… (d'habitude, quand je tape, ça ressemble plus à "ip -6 a a 192.168.8.1/24 dev eth0" ou des trucs du genre — même sans le "-6" dans ce cas particulier où ip reconnaît que c'est une IPv6).
Bon, ça ne t'intéresse peut-être pas, mais imaginons que dans le futur, IPv6 soit partout, et qu'il suffit à accéder à l'Internet tout entier. Quelle solution pour ton problème alors ? Et bien… tu enlèves le serveur au milieu et tu relies les switchs. Et c'est tout.
Comme ça, tes machines auront deux adresses, pour chacune des Freebox, et auront deux routes par défaut, pour passer par l'une ou l'autre des Freebox. Si le réseau tombe sur une, normalement elle doit se rétracter de l'annonce de son préfixe, et en fonction du timeout fixé, tes machines passeront sur l'autre (ça n'est pas au niveau d'un failover à la miliseconde, mais c'est fait pour être acceptable pour ceux qui ne font pas trop attention à la haute disponibilité).
Niveau équilibrage de charge, ça ne va peut-être pas être top, sachant que beaucoup de machines sont implémentées pour choisir le routeur ayant fait l'annonce la plus récente et seulement lui, mais on pourrait potentiellement améliorer ça. Voire s'amuser à faire un switch qui bidouille les router-advertisement pour modifier la priorité du RA s'il le fait passer d'un « côté » ou de l'autre (certains switchs manageables font déjà du filtrage de RA).
Bref, ça serait génial, mais malheureusement, on doit encore se coltiner IPv4 pour un bout de temps…
Est-ce que le script est invoqué avec l'option “exit on error” ? Si c'est le cas, ça expliquerait le comportement que tu vois. En bash, ça se change avec :
Ce que Debian essaye (essayait ? je ne connais pas l'état d'avancement exact) de résoudre avec les “build profiles”, cf. https://wiki.debian.org/DebianBootstrap
Un autre processeur manycore, Tile64 (produit par Tilera, une boite fondée par un prof au MIT), coûte dans les ~12000$ (ça inclut la chaîne de compilation basée sur gcc, la carte d'extension, etc.).
D'ailleurs je les trouve intéressant, car ils ont super bien collaboré avec l'upstream, et on retrouve leur support dans le noyau et dans gcc dès aujourd'hui. Voir http://www.tilera.com/ et http://www.tilera.com/scm/. Un bon avantage sur ce « Kalray » (au fait, c'est un communiqué commercial cette news ?).
Apparemment, c'est fait par des collègues des développeurs de l'excellent BIRD http://bird.network.cz/, au sein du labo de l'association qui gère le TLD .cz : https://labs.nic.cz/. Balaises ces thèques !
C'est marrant, j'avais déjà fait la même il y a trois ans pour mon premier SSD, et j'ai réitéré l'opération il y a six mois pour un autre, et ça marche effectivement très bien. Sauf que j'ai rendu l'opération encore plus transparente : je fais une hibernation / suspend-to-disk avant d'ajouter le SSD. Comme ça, le disque est vu comme ajouté « dynamiquement ». Du coup, moins système n'a même pas vraiment redémarré, et est pourtant passé d'un disque a l'autre…!
Je pense que leur but est de différencier deux choses :
1 - le problème est lié à une tâche automatique d'un programme contenant un bug.
Tâche codée par un humain, qui a peut-être oublié de mettre un ! (not) dans sa condition (genre « if (virement_sepa) », rapport au commentaire plus bas qui parle plus précisément de l'origine), par exemple.
2 - un pinpin a écrit 3400000000 au lieu 3400000 dans le champ texte.
Bah voilà, c'est juste que dans un cas c'est un programmeur qui l'a mal tapé, dans l'autre un « banquier ».
La différence entre les deux est que le point 2 suggère un problème lié directement à une personne ayant commise une erreur dans son action. Le point 1 suggère un bug technique.
Non, comme je l'ai montré.
Et quand tu as un bug provenant d'un logiciel dont tu n'es pas l'auteur et que d'ailleurs tu ne sais même pas comment il est fait puisque tu n'es pas développeur. Bin oui, ça vient bien de la machine et non de toi.
Et bien tu blâmes le fournisseur de ton logiciel, qui ne pourra pas blâmer la machine mais un humain, et ainsi de suite.
[^] # Re: Évolution
Posté par benoar . En réponse au journal Système de Dé-ciblage (google and co) pour augmenter l'anonymat. Évalué à 2.
Faux. Ça s'appelle le “Real-time bidding”, ces informations sont négociées à chaque impression, en fonction de la localisation, de ton historique de navigation, de ton profile, etc. C'est comme le High Frequency Trading, mais c'est toi la marchandise qui est échangée à haute vitesse.
Voir https://support.google.com/adxbuyer/answer/166635?ref_topic=27574&rd=1 par exemple, et généralement les infos sur le fonctionnement de la régie de Google : https://support.google.com/adxbuyer/#topic=21122
[^] # Re: Bof
Posté par benoar . En réponse au journal Nourrir les vaches ! Openbsd a reçu des fonds.. Évalué à 2.
Moi je vois quand même des choses différentes : le terrain, c'est un bien limité. L'entreprise, c'est quelque chose qui doit « créer de la valeur », à priori sans limite supérieure. Soit tu fais comme dans le Far West et chacun se sert jusqu'à ce qu'il n'y en ait plus, et tant pis pour ceux qui ne se sont pas servis, soit tu te dis au bout d'un moment qu'il faudrait quand même trouver des règles équitables, car sinon c'est trop vite le bordel et certains vont devenir « injustement » riches. Dans un autre commentaire, une moule parlait de « jalousie » : bien que pour certains c'est peut-être ça, le but au final c'est quand même, pour moi et sûrement d'autres, d'être équitable. Et donc, de ne pas participer à une chose si celle-ci n'est pas équitable.
Bitcoin n'est pas équitable (oui, comme plein d'autres « marchés » ou autres distributions de ressources) et donc je n'ai pas envie d'y participer. Je trouve ça dommage que d'autres le fassent, car ce faisant ils augmentent l'attrait global vers ce système inéquitable. Comme cette donation pour OpenBSD : le mec la fait en en parlant bien, histoire de crédibiliser cette monnaie. Donc, ceux qui y participent ne sont pas seulement « chanceux », ils entraînent également d'autres personnes dans ce cercle inéquitable en rendant ce système plus « respectable ». Après, dans l'absolu, oui, on ne va pas empêcher machin de faire ci ou ça, mais bon, les lois qu'on a obéissent à une certaine morale, généralement.
Oui, effectivement. Est-donc pour ça qu'il ne faut rien faire contre ? Commencer par ne pas promouvoir un tel système en n'y participant pas est déjà pas mal.
[^] # Re: Euh...
Posté par benoar . En réponse au journal Système de Dé-ciblage (google and co) pour augmenter l'anonymat. Évalué à -2.
Tu comprends qu'on puisse te trouver extrêmement lourd avec ce genre de commentaire ? Non ? T'as rien de mieux à foutre ?…
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 9.
Quand on voit la réponse de Lennart https://bugzilla.redhat.com/show_bug.cgi?id=833105, on ne peut s'empêcher de voir la mauvaise foi de partout : il ignore l'utilisation de SIGSTOP seulement si un flag/variable d'environnement est mis, dit que ça peut être utilisé pour autre chose, mais là c'est dans le cas où le process l'utilise sur lui-même, il indique qu'il ne voit pas de différence entre appeler une fonction de la libc et introduire une dépendance à sa lib (il doit s'en foutre du boulot de mise à jour de tous les paquets, même les plus vieux/exotiques/etc…), … Alors que le rapport original demande juste une simple mesure pour être compatible optionnellement avec certains programmes !
Il est trop reulou. Techniquement, c'est à dire au niveau des capacités, je trouve que systemd bat de loin tous les autres. Ça serait la raison qui me fait le supporter. Mais entre son implémentation lourdingue, sa volonté de vouloir tout remplacer d'un coup (génial), l'intégration de tout dans systemd ce qui rend udev et d'autres utilitaires essentiels forcément dépendants de systemd sans toujours de bonne raisons, le « j'en n'ai rien à foutre des autres qui ne peuvent pas suivre », et l'ego démesuré de ce mec… c'est super chiant. Alors oui, je ne vois pas de solution aussi « bien » que la sienne, mais on sent tellement une sorte d'imposition de l'avis de RedHat sur un paquet de choses d'un coup, et que plein de monde va être largué parce que non compatible, que ça fait très peur.
[^] # Re: asshole detector
Posté par benoar . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 2.
Rien que ce commentaire aux sous-entendus lourds montre ton sexisme et ton racisme. En quoi la couleur de peau de quelqu'un ou son sexe devrait dicter les caractéristiques de son comportement ? Est-ce que si un noir ou une femme fait quelque chose de « mal », il faut en tirer des conclusions venant d'une caractéristique qu'il n'a pas choisi ? Pourquoi opères-tu un tel classement pour après rétorquer que, quand même, « ils se victimisent », « yen a des pas biens » (pour paraphraser Didier Super), etc. Crois-tu que ton sexe ou ta couleur de peau va te faire changer ta manière de penser ?
Ce qui influe sur ta manière de penser, dans le contexte de cette discussion, c'est ce que « la société » (les préjugés de ta culture, etc) va dire à propos de caractéristiques que tu as mais que tu n'as pas choisi. Effectivement, au début, il n'y a aucune raison de discriminer là-dessus, comme toi et d'autres se plaisent à dire. Mais la réalité, l'histoire, la culture, font qu'aujourd'hui il existe ce genre de discriminations. Elles sont bêtes, mais malheureusement présentes dans l'esprit de beaucoup de gens. Alors, soit on attend tranquillement que ça change magiquement, soit on se dit que, ces personnes discriminées étant moins puissantes, il faut rééquilibrer les choses en étant un peu plus ferme.
Forcément, quand tu invoques la pseudo-persécution des homme blancs, c'est ridicule, car un puissant qui invoque la persécution, ça fait bien rire ceux qu'il domine. Alors après, je ne parle pas de toi en particulier : tu es sûrement un homme blanc très bien, qui fait plein de choses géniale pour le libre, mais ne discrimine jamais les gens sur leur sexe ou leur couleur de peau. Mais, malgré toi, tu représentes le dominant. « Horreur », cries-tu, car on se met à te discriminer sur des critères que tu ne peux pas choisir ! Et oui, ça fait mal, hein ?
Et bien maintenant, en tant qu'homme blanc parfait qui ne discrimine jamais injustement, essaye un peu de regarder autour de toi toutes les actions que tu fais, les remarques que tu sors, et demande-toi à quel point elles peuvent être blessantes pour ces catégories discriminées. Là, tu as été offusqué par un thread sur linuxfr ! Imagine le truc quand tu te prends tous les jours des remarques, conscientes ou inconscientes, directes ou indirectes, sur ta condition à laquelle tu ne peux rien. Et ne me sors pas l'exemple de cette conversation : le threads qui bachent les hommes blancs, ça représente peanuts par rapport au reste. Mais vraiment que dalle de rien de rien. Et en plus tu fais partie d'une catégorie qui n'a pas à se plaindre (hou, que je suis méchant de te traiter ainsi). Rien que le fait de continuer à garder ta position est une insulte pour toutes les victimes de discrimination. Relis ce thread en te mettant à la place de quelqu'un qui les vit tous les jours. Ah non, pardon, tu ne peux pas, parce qu'en fait, ça ne sont pas vraiment des victimes, ils le font exprès. Bon, tant pis.
# Encore du secret partagé…
Posté par benoar . En réponse au journal L'art de stocker des mots de passe. Évalué à 4.
Oui, bon, l'authentification par secret partagé (ici un mot de passe), c'est bien, c'est pas trop compliqué même si comme tu le montres, il existe beaucoup de moyens de se foirer, mais quand même, depuis un bout de temps on a inventé d'autres moyens d'authentification. Certes, il nécessitent une modification des protocoles, et ne sont pas de simples moyens de « stockage de mots de passe ». Mais ils ont souvent d'autres avantages, le premier étant par exemple de ne jamais dévoiler le mot de passe au serveur en question. Au vu de la réutilisation massive des mots de passe de la part des utilisateurs pour différents services, ça me semble une qualité pas du tout négligeable.
Comme exemple, je pense par exemple à SCRAM http://tools.ietf.org/html/rfc5802, RFC 5802. Ça se base sur TLS pour l'authentification du serveur, et permet d'authentifier l'utilisateur sans qu'il ne donne son mot de passe, et sans que le serveur puisse se faire passer pour le client pour d'autres services (c'est un peu dérivé de la propriété précédente, certes), tout en évitant bien sûr le problème de dévoilement du secret côté serveur en cas de vol de la base. En bonus, je crois (mes souvenirs sont mauvais) qu'il évite les écueils classiques du channel-binding, i.e. il indique l'information qu'on peut utiliser comme étant suffisante pour identifier la personne à partir de ce canal, afin d'éviter le MITM (bon, c'est pas clair du tout dit comme ça…) ; cf RFC 5056 http://tools.ietf.org/search/rfc5056 si vous voulez creuser.
[^] # Re: loguer les paquets refusés
Posté par benoar . En réponse au message ipv6 pas compatible avec iptables ou ovh?. Évalué à 3.
Gni ? J'ai jamais dit ça… Franchement, entre ne pas citer ce à quoi tu réponds, et ta syntaxe/grammaire déplorable, j'ai vraiment beaucoup de mal à te comprendre et ça me fatigue.
C'est une question ? Une affirmation ? C'est le résultat de ip -6 route, je suppose, mais je ne sais pas ce qu'est la partie que tu cites dessus. En gros, là, tu vois qu'il y a eu une route à priori rajoutée à la main, et deux autres par RA. Je ne comprends pas ce qui ne va pas, et ce que tu veux, bref, exprimes-toi clairement sinon moi j'arrête.
[^] # Re: Les bases
Posté par benoar . En réponse au message ipv6 pas compatible avec iptables ou ovh?. Évalué à 2.
Chez moi ça marche.
[^] # Re: loguer les paquets refusés
Posté par benoar . En réponse au message ipv6 pas compatible avec iptables ou ovh?. Évalué à 3.
T'as toujours l'IPv4, hein. Et je ne connais pas les dédiés, mais c'est si difficile que ça d'avoir une console série sur ta machine ?!
Cf ce que j'ai dit plus bas, ça m'étonnerait que tu veuilles réellement mettre ces IP sur ton « hyperviseur »…
Pas de problème ; je te conseille d'aller lire http://livre.g6.asso.fr/ si tu veux te former un peu.
Bah… à toi de comprendre pourquoi. Mais du coup, je me dis, que tu te lances dans IPv6 que tu connais mal avec une distro que tu maîtrises mal… tout ça sur une machine ou tu ne peux pas te permettre d'essayer des trucs à peine risqués… ça ne me paraît pas super génial.
Bah, du coup je comprends pas, et je ne peux pas t'aider là-dessus.
Gni ? Tu ne peux pas copier ton message quelque part (ou l'écrire autre part) avant de poster ?…
[^] # Re: Les bases
Posté par benoar . En réponse au message ipv6 pas compatible avec iptables ou ovh?. Évalué à 2.
OK.
Ah non, je ne comprends pas en fait. C'est du failover pour ta machine ou pour tes VMs ? Si c'est pour tes VMs, pourquoi les attribues-tu à l'interface de ton « hyperviseur » (en quelques sortes) ?
Pourrais-tu décrire plus précisément ton setup ? Parce que tu n'as toujours pas dit clairement ce que tu voulais obtenir, et comment tu avais fait jusqu'à maintenant. Tu veux « connecter » tes VMs au net ? Tu veux les bridger ou les router ?
Les « failles » DHCP ? Mouai, moyen détourné de dire « on sait pas gérer un DHCP » (de la part d'OVH)… Et les coupures lors du « renouvellement » d'IP, tu parles encore du DHCP ? Ou d'autre chose ?! Je ne comprends pas trop sinon : une IP fixe mais « renouvelée » ?…
[^] # Re: loguer les paquets refusés
Posté par benoar . En réponse au message ipv6 pas compatible avec iptables ou ovh?. Évalué à 2.
Normalement une bonne distro te le permet. Sous debian c'est l'attribut "gateway" dans /etc/network/interfaces. Je connais mal Gentoo.
Houla, pourquoi tu veux mettre toutes ces IP sur ta config ?
OK. Si ce /56 apparaît, c'est que tu ne dois pas complètement maîtriser ta config… c'est pas super bon signe pour arriver à correctement gérer ce problème. Elle est indiquée en "proto kernel" ce qui indiquerait (je crois) qu'elle est configurée manuellement, et pas à travers un RA. Si tu veux vérifier que ça ne vient pas par un RA, tu peux soit sniffer les RA, soit l'effacer (ip -6 route del …) et voir si elle revient (quand tu acceptes les RA, i.e. pas quand le forwarding est activé, à moins que tu aies appliqué le workaround que j'ai décrit).
Lesquels exactement ? J'avoue qu'avec l'orthographe assez limite en plus, j'ai du mal à te comprendre précisément.
Moi c'est ce que je te conseillerais, si tu n'utilises que ce /64.
[^] # Re: Les bases
Posté par benoar . En réponse au message ipv6 pas compatible avec iptables ou ovh?. Évalué à 2.
C'est bizarre toutes ces adresses sur eth0, qui ont en plus à priori été configurées à la main (valid_lft forever…). C'est toi qui fait ça ?
[^] # Re: loguer les paquets refusés
Posté par benoar . En réponse au message ipv6 pas compatible avec iptables ou ovh?. Évalué à 3.
OK, on voit en gros que les RA sont valables 1/2h, c'est à peu près le temps au bout duquel tu vois que ça déconne ? Si c'est ça, c'est que soit les routeurs n'envoient pas assez souvent de RA, soit tu les bloques d'une manière ou d'une autre.
Par contre, je vois un autre problème : ta conf. C'est quoi ce /56 sur eth0 ? C'est pas bon, on met toujours un /64 sur un segment Ethernet. Je suppose que c'est que le …a505::/64 qui est le « bon » ? Indique nous ta configuration qu'on en sache plus.
Ah, du coup je comprends, je pense : ça « déconne » 1/2h après que tu actives le forwarding ? C'est normal, car un routeur (qui n'est pas un nœud comme les autres) n'accepte par les RA par défaut. Il faut soit que tu les spécifies manuellement (la méthode traditionnelle ; tu peux demander à celui qui gère les routeurs de « sortie » s'il les configure avec des adresses link-local spécifiques que tu pourrais ajouter manuellement, genre fe80::1), soit que tu dises au kernel d'accepter les RA avec le sysctl net.ipv6.conf.all.accept_ra = 2. Attention, ainsi, il se configurera automatiquement avec une adresse genre SLAAC sur eth0. Si tu n'en veux pas, mets le net.ipv6.conf.all.autoconf = 0.
[^] # Re: cookie monster
Posté par benoar . En réponse au journal Firefox et les cookies tiers. Évalué à 2.
+1, il fait partie de mon triptyque d'extensions indispensables pour naviguer correctement sur Internet : Adblock plus, NoScript et Cookie Monster.
[^] # Re: Les bases
Posté par benoar . En réponse au message ipv6 pas compatible avec iptables ou ovh?. Évalué à 2.
Heu… ça marche très bien juste avec "-6", hein, depuis un bout de temps. Si j'avais à me taper la commande complète à chaque fois, ça me soulerait… (d'habitude, quand je tape, ça ressemble plus à "ip -6 a a 192.168.8.1/24 dev eth0" ou des trucs du genre — même sans le "-6" dans ce cas particulier où ip reconnaît que c'est une IPv6).
[^] # Re: loguer les paquets refusés
Posté par benoar . En réponse au message ipv6 pas compatible avec iptables ou ovh?. Évalué à 2.
Et pour ça, Wireshark est ton ami, il te propose un paquet de filtres super sympas pour t'aider à chercher.
# En IPv6
Posté par benoar . En réponse au message Configuration réseau avec 2 freebox pour collocation. Évalué à 2.
Bon, ça ne t'intéresse peut-être pas, mais imaginons que dans le futur, IPv6 soit partout, et qu'il suffit à accéder à l'Internet tout entier. Quelle solution pour ton problème alors ? Et bien… tu enlèves le serveur au milieu et tu relies les switchs. Et c'est tout.
Comme ça, tes machines auront deux adresses, pour chacune des Freebox, et auront deux routes par défaut, pour passer par l'une ou l'autre des Freebox. Si le réseau tombe sur une, normalement elle doit se rétracter de l'annonce de son préfixe, et en fonction du timeout fixé, tes machines passeront sur l'autre (ça n'est pas au niveau d'un failover à la miliseconde, mais c'est fait pour être acceptable pour ceux qui ne font pas trop attention à la haute disponibilité).
Niveau équilibrage de charge, ça ne va peut-être pas être top, sachant que beaucoup de machines sont implémentées pour choisir le routeur ayant fait l'annonce la plus récente et seulement lui, mais on pourrait potentiellement améliorer ça. Voire s'amuser à faire un switch qui bidouille les router-advertisement pour modifier la priorité du RA s'il le fait passer d'un « côté » ou de l'autre (certains switchs manageables font déjà du filtrage de RA).
Bref, ça serait génial, mais malheureusement, on doit encore se coltiner IPv4 pour un bout de temps…
# Les bases
Posté par benoar . En réponse au message ipv6 pas compatible avec iptables ou ovh?. Évalué à 3.
La base pour diagnostiquer, c'est de nous donner l'état de la table de routage et des adresses :
Et n'as-tu pas plus précis que « quelques dizaines de minutes » ?
As-tu activé des options spéciales ? Pourrais-tu nous donner le résultat de la commande suivante pour voir :
# Exit on error ?
Posté par benoar . En réponse au message Ctrl+c ferme xterm. Évalué à 2.
Est-ce que le script est invoqué avec l'option “exit on error” ? Si c'est le cas, ça expliquerait le comportement que tu vois. En bash, ça se change avec :
Mais je ne sais pas pour csh.
[^] # Re: Choix ?
Posté par benoar . En réponse à la dépêche CentOS et Red Hat unissent leurs forces pour une plateforme communautaire stable. Évalué à 3.
Ce que Debian essaye (essayait ? je ne connais pas l'état d'avancement exact) de résoudre avec les “build profiles”, cf. https://wiki.debian.org/DebianBootstrap
[^] # Re: Le prix du Kalray
Posté par benoar . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 5.
D'ailleurs je les trouve intéressant, car ils ont super bien collaboré avec l'upstream, et on retrouve leur support dans le noyau et dans gcc dès aujourd'hui. Voir http://www.tilera.com/ et http://www.tilera.com/scm/. Un bon avantage sur ce « Kalray » (au fait, c'est un communiqué commercial cette news ?).
# Tiens, encore cz.nic
Posté par benoar . En réponse au journal Le serveur DNS Knot. Évalué à 5.
Apparemment, c'est fait par des collègues des développeurs de l'excellent BIRD http://bird.network.cz/, au sein du labo de l'association qui gère le TLD .cz : https://labs.nic.cz/. Balaises ces thèques !
# Avec encore moins d'interruption
Posté par benoar . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 6.
C'est marrant, j'avais déjà fait la même il y a trois ans pour mon premier SSD, et j'ai réitéré l'opération il y a six mois pour un autre, et ça marche effectivement très bien. Sauf que j'ai rendu l'opération encore plus transparente : je fais une hibernation / suspend-to-disk avant d'ajouter le SSD. Comme ça, le disque est vu comme ajouté « dynamiquement ». Du coup, moins système n'a même pas vraiment redémarré, et est pourtant passé d'un disque a l'autre…!
[^] # Re: Et pourquoi pas ?
Posté par benoar . En réponse au journal Un bug inhumain. Évalué à 2.
Tor_t_. Le tort tue.
Tâche codée par un humain, qui a peut-être oublié de mettre un ! (not) dans sa condition (genre « if (virement_sepa) », rapport au commentaire plus bas qui parle plus précisément de l'origine), par exemple.
Bah voilà, c'est juste que dans un cas c'est un programmeur qui l'a mal tapé, dans l'autre un « banquier ».
Non, comme je l'ai montré.
Et bien tu blâmes le fournisseur de ton logiciel, qui ne pourra pas blâmer la machine mais un humain, et ainsi de suite.
[^] # Re: [HS] le mauvais réflexe Amazon
Posté par benoar . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 2.
Faux, c'était une circulaire qui visait une action particulière http://www.france-palestine.org/Boycott-Desinvestissement,20332 se basant sur une interprétation particulière d'un vieux texte http://www.liberation.fr/politiques/2010/11/19/il-est-desormais-interdit-de-boycotter_694697 qui ne tiendrait sûrement pas lieu de « cas général ».