Moonz a écrit 3542 commentaires

> il faudra prendre le code d'un resolver DNS existant et l'adapter à tes besoins.
C’est déjà ce que j’ai fait à gros coups de scripts Python + shell avec unbound, je cherchais juste si une solution plus maintenue était possible.

> Et par curiosité je ne vois pas dans quelle situation on peut se retrouver à exiger des réponses DNS aussi rapides et "stables".
Deux situations :
- Quand j’étais en résidence étudiante, on avait pas d’UDP autorisé sur l’extérieur, et le serveur DNS qui tombait régulièrement les vendredis soir et rétabli le lundi matin. C’est à cette époque que j’avais fait ces scripts, d’ailleurs.
- Là (ce qui m’a incité à ressortir mes vieux scripts, voir qu’ils marchent plus, et chercher une solution plus maintenue), je suis sur une je-sais-pas-quoi box avec une QoS merdique, et je ne sais pas pour trop quelle raison, chaque résolution DNS prend plusieurs secondes (si je me fie à mon "looking up" dans la barre d’état de firefox).

Sauf que là où je veut mettre en place cette solution, UDP est bloqué au niveau de la gateway vers internet, donc pas la peine de penser à utiliser un DNS externe.
De toute façon, un DNS externe sera toujours plus lent qu’un DNS local, et la vitesse de résolution m’importe :)

> ce qu'il te faudrait en fait c'est simple un DNS secondaire (en mode esclave)
> qui serait donc mis à jour quand le primaire change
> mais qui conserverait les données quand le DNS primaire
Pas vraiment, un esclave est le miroir d’un maître, hors ici je n’ai pas de maître, puisque je veux pouvoir cacher n’importe quoi de la base DNS entière, sans pour autant faire un miroir de la base DNS entière.
C’est bien un récursif qui cache les résultats d’un autre récursif que je cherche, pas un miroir d’un authoritative.

> La société la meilleure c'est quelque chose de très subjectif
Ben oui, parce que les critères de jugement sont subjectifs. Untel privilégiera les prix faibles, tel autre la ponctualité, tel autre l’amabilité du personnel, etc.

> maintenir des choses utiles mais pas forcément intéressantes financièrement.
Ce qui est une demande profondément égoïste ; ça veut dire : je veux déménager à pétaouchnok-les-bains pour profiter du cadre de vie calme et agréable de la campagne, mais pour ce qui est du coût de ce choix de vie, pas question de le supporter, la société (c’est-à-dire : les autres contribuables qui ne prennent jamais le train) doit le prendre en charge. Les avantages pour ma pomme, les inconvénients pour « la société ».

De quatre, parce qu’il FAUT régulièrement raconter des conneries, comme l’a si bien expliqué la Vraie Religion dans sa célèbre parabole : http://jesrad.wordpress.com/2008/07/31/letrange-rencontre/

D’ailleurs, ça fait super longtemps que j’ai pas raconté de foutaises sur DLFP, tiens. Heureusement que ce message est là pour renouer avec cette très saine et très sainte habitude.

En transport de passager grand public ? Tu m’intéresses fortement là, surtout s’ils ont un système de réservation sur internet un poil moins horrible que la SNCF. Un petit lien ?

> Ta position n'est pas défendable
Je me demande où tu as réussi à inférer mon opinion de mes messages. Surtout que tu as inféré complètement a côté de ma position.

> Hors pour avoir santé, motivation,formation il faut le payer soit en impôts sociétés, soit en impôts sur les gens (mais il faut qu'ils aient un salaire).
Ou en salaires (au sens de salaire net cette fois), ça marche aussi :)

> La vision court-termiste du gouvernement de tirer vers le bas les masses salariales pour être compétitif est stupide et ne marche pas
Pour le gouvernement : tu parles de quoi, en mesures concrètes ?
(mais sur le fond, je suis d’accord, le contrôle des prix, ça marche pas des masses, même quand ce prix s’appelle salaire)
(je passe volontairement la question des entreprises : je sais où le débat va nous amener (très loin), et je pars en vacances demain ;))

Si pour chaque opération d’une ligne tu dois définir une fonction, je te raconte pas le plat de spaghettis résultant si ta chaîne de traitement est un poil plus longue que ce que je t’ai montré. Je préfère encore la solution de la macro.

Heu… non. Le salaire est un prix, fixé par la loi de l’offre et de la demande. Le prix porte sur le salaire chargé (puisque c’est le coût marginal d’un employé du point de vue de l’entrepreneur). Une augmentation des charges se traduit donc, ceteris paribus, par :
- soit une baisse du net afin que le salaire (du point de vue économique, donc chargé) reste constant
- soit une augmentation du chômage si le net ne peut baisser

Les bénéfices, pertes et dividendes sont le résultat :
1. du taux d’intérêt, qui n’est évidemment pas directement dépendant de la répartition des charges
2. des erreurs d’appréciation des différents agents économiques, des rigidités dans l’ajustement de la structure de production. Ça peut effectivement être influencé par une augmentation des charges, mais de manière transitoire uniquement.

Allez, au pif, remplacer chaque pixel d’une image par sa distance avec la moyenne de la matrice :


float *data;
int width, height;

float avg = 0;
int pos, x, y;
for(y = 0, pos = 0; y < height; ++y, pos += pitch) {
    for(x = 0; x < width; ++x, ++pos) {
        moy += data[pos];
    }
}
avg /= width * height;
for(y = 0, pos = 0; y < height; ++y, pos += pitch) {
    for(x = 0; x < width; ++x, ++pos) {
        data[pos] -= avg;
    }
}


(oui, je sais, tu peux faire une macro, mais c’est encore plus moche)

Les protocoles réseaux, à fortiori avec sécurité renforcée genre IPsec, ont souvent une part d’aléatoire, qui te rend impossible des tests unitaires exacts bit-à-bit. Enfin, si, tu peux tester

> La faille DNS était une faille de spec.
C’est bien ce que je dis : un code correct au regard de la spec peut très bien introduire une vulnérabilité.
Il faut voir que tu as souvent plusieurs algorithmes pour implémenter une spec. Quand la spec te dit « prenez un nombre aléatoire », tu as plusieurs manières de faire.
Mais certains algorithmes qui respectent la spec peuvent introduire des failles. L’exemple de debian et OpenSSL. En gros, la spec elle dit, « générez un nombre aléatoire. ». La version de debian a fait comme ça (c’est imagé hein) :
srand(getpid()); rand()
Ça respecte la spec. Un relecteur qui connaît le C, qui a la spec sous les yeux, il dira : OK, pas de faille introduite. Mais il y en a une : l’entropie de getpid() n’est pas assez grande.
On est encore là dans un cas simple, mais c’est juste pour dire que sans compétences en sécurité des réseaux et des chiffrements, non, un programmeur C lambda n’est pas forcément capable de reconnaître une faille ou une backdoor en regardant le code. Et même quelqu’un ayant de telles compétences risque d’avoir du mal si c’est plus évolué que srand(getpid()), sauf à faire une analyse en profondeur du code (ce qui prend du temps et/ou de l’argent).

Non. Quand j’en suis à me dire que la répétition de "item = getNextElement()" est chiante, je prend un langage un peu plus expressif que le C/C++ :)
Ben oui : en C, ce genre de répétition est courant, et pas toujours évitable (dans cet exemple du while oui). Si je suis en C, c’est que je me suis préparé à avoir ce genre de répétitions très légèrement irritantes parce que dans le contexte les avantages du C surpassent ce léger inconvénient.

Ben, une boucle for :


for(item = getNextItem(); item; item = getNextItem()) {
}


> Déjà on apprendra à l'insee que dans un graphique on met toujours un titre.
Le titre était dans la page HTML, et j’ai bien précisé qu’il était tiré de mon lien plus haut. D’ailleurs, tu as très bien trouvé tout seul.

> Je t'invite à regarder le graphique 2, puis de continuer à m'expliquer que les patrons paient beaucoup trop de charges...
J’ai jamais dit qu’ils payaient « trop » de charges (c’est un jugement de valeur, et quand sur un fil j’essaie de rester factuel comme c’est le cas en ce moment, j’explicite quand je passe en mode jugement de valeur), juste que
1. les charges constituaient la majeure partie du coût du travail, avant le salaire net
2. le coût du travail est le plus élevé parmi les pays de l’OCDE

Sinon, je regarde à ta page 3, et j’y lis :
« La baisse des cotisations patronales de sécurité sociale observée depuis les années 1980 a toutefois été partiellement neutralisée par une hausse des prélèvements portant sur les risques ne relevant pas de la sécurité sociale (cf. graphique 1.b), notamment pour le financement des régimes de retraite complémentaire et de l’assurance chômage. Les prélèvements sociaux à la charge de l’employeur couvrant ces autres risques ont augmenté régulièrement entre 1980 et 2008 (de 10,30 % à 15,93 %). »
Donc, pour eux, l’assurance chômage (second poste de charge si tu prend le document de la CCI linké plus haut, le premier étant la retraite) et le financement des régimes de retraite complémentaire, ils le décomptent pas dans le sous-total qui leur permet d’affirmer que les contributions patronales ont baissées.
De plus, ça ne concerne que les bas salaires : à 1,5 SMIC, ladite baisse est beaucoup moins sensible. Il est donc intéressant de voir la moyenne. On peut donc retourner voir l’INSEE :
Taux de cotisations patronales, 1975 (projection probablement surévaluée) : 32.7%
Taux de cotisations patronales, 1984 (projection probablement surévaluée) : 40%
Taux de cotisations patronales, 1992 : 38.9%
Taux de cotisations patronales, 2004 : 39.8%
D’après le document de la sécurité sociale que tu as linké, ça n’a pas diminué entre 2004 et 2008.
Donc oui, baisse modérée relativement à 1984 (-0.2%, la vache de baisse significative), mais relativement à 1975, hausse importante (+7.1%), et relativement à 1992, faible hausse (+0.9%).

De toute façon, à la limite, l’évolution, on s’en fout un peu ; ce qui compte, c’est la situation hic et nunc, et pour ça, je te renvoie au graphique de l’OCDE cité par Wikipédia.

> Sans rire, des codeurs qui sont capables de faire une revue de code C, il en existe des dizaines de milliers dans le monde, et
Une faille réseau, ça peut être quelque chose de bien plus subtil qu’un code évidemment faux, ça peut être un algorithme correctement implémenté mais mathématiquement faible. La faille DNS qui a fait du bruit il y a quelques temps en est un excellent exemple : le code fait ce qu’on lui demande (pas de bug ni de faille dans le bug lui-même), mais c’est ce qu’on lui demande qui peut être problématique.

Ce n’est pas ma remarque. Ce que Aldoo dit, c’est : « on paye beaucoup pour avoir beaucoup de services, c’est un choix de société ».
Ce que je dis, c’est : « pourquoi en faire un choix de société, c’est-à-dire imposé à tous, alors qu’on pourrait très bien en faire un choix personnel (payer moins de charges et recevoir moins de services/payer plus pour en recevoir plus) selon ses préférences personnelles ? »

Effectivement, j’ai lu trop vite. Mea culpa.

Bon, je sors du Wertfrei pour entrer dans le jugement de valeur :
> Enfin cela reste un choix de société plus que défendable.
Pourquoi vouloir en faire un choix de société alors que cela pourrait être un choix individuel ?

> C'est triste de voir les salariés comme un coût alors qu'ils sont plutôt une richesse
Heu, les salaires sont un coût pour l’entreprise, à moins de vouloir réécrire le dictionnaire, les bouquins d’économie et revoir tous les principes de comptabilité.

> les baisses de charges continues depuis quelques dizaines d'années
Où ça ?
http://www.insee.fr/fr/ffc/ipweb/ip1214/img/graphique1_t.jpg

(tiré de mon lien plus haut)

Et donc, l’intérêt de mettre des clauses limitatives qui sont légalement nulles, c’est de ?…

> Si personne ne l'a fait, c'est qu'a-priori personne n'en voit l'intérêt, j'imagine donc que peu de monde considère l'usage d'une VM comme un inconvénient.
Non, juste que ceux qui considèrent que c’est un inconvénient se contentent d’aller voir ailleurs, C/C++/Objective-C, D, Go, ooc, Vala rien que pour des langages compilés qui produisent du code natif… le choix est large.

Théoriquement, c’est possible avec xmlvm [http://www.xmlvm.org/overview/]. Après, j’ai jamais essayé.

> Ensuite reste à voir si côtiser pour la sécu doit s'appeler une taxe...
Charges_sociales : Les cotisations font partie des taxes sur les traitements et salaires.

Taxe : En droit français, la taxe est un prélèvement obligatoire perçu d'autorité à l'occasion d'un service rendu.
Alors, à moins que les cotisations sociales ne soient pas un prélèvement obligatoire, ou que la sécu ne soit pas un service rendu, il s’agit bien d’une taxe.

Facile, on est de loin les plus taxés de l’OCDE :
http://commons.wikimedia.org/wiki/File:Cotisations_sociales_(...)