Yann Hodique a écrit 176 commentaires

Sais-tu si ça marche de ce côté-là ?

J'avais écrit un article sur le sujet il y a un moment (https://yann.hodique.info/blog/nix-in-custom-location/). Utiliser un overlay pour ça est relativement élégant (note que je n'ai plus le problème actuellement, il est possible que les instructions nécessitent une mise à jour).
Cachix n'existait pas à l'époque, j'aurais probablement utilisé ça comme moyen de distribuer ma propre version de Nix utilisant ${HOME}/nix

mouais, en même temps 5 sur 45 c'est quand même plus de 10% du temps.
Soit une approximation seulement 80% plus efficace que pile ou face, ce qui en fait un modèle assez pourri dans l'ensemble. (en tout cas je suis personnellement plus exigeant que ça sur les modèles que j'utilise pour des stats sur du temps de compilation…)

Par ailleurs il faut tout de même remarquer que la situation inverse est clairement juste hypothétique: sur les 5 exemples en question il y a:

• 1 situation différente: en 1824, personne n'a eu la majorité absolue du collège électoral, et le président a été élu par le congrès en n'ayant ni la majorité du collège, ni la majorité relative des votes
• 4 situations où un républicain a eu la majorité du collège, mais pas la majorité des votes: 1876, 1888, 2000 et 2016

Ce qui est assez normal, vu que la raison est que fondamentalement le vote d'un habitant d'un état peu peuplé (typiquement plus conservateur) compte un poil plus que celui d'un habitant d'un des grands états (typiquement plus libéral).

Donc bon, c'est d'un biais assez marqué qu'il s'agit, pas d'un effet statistiquement neutre.

D'ailleurs tout le monde est d'accord que c'est pourri en fait…

Évidemment quand il a écrit ça, c'est parce qu'il pensait que Obama avait bénéficié de ce problème en 2012 (ce qui était complètement faux, il avait gagné 5 millions de votes supplémentaires)

Le passage suivant me perplexifie:

Le ramasse-miette n'interagit pas bien avec la production d'images. Sur les serveurs dédiés à la préparation des images, il est facile et préférable d'intégrer le ramasse-miette comme préliminaire à la procédure de production des images.

Qu'est-ce que ça veut dire au juste? Si ça se réfère au fait que la production d'images entraîne la création temporaire d'objets "Dangling" (ce qui est vraiment un bug particulièrement énervant de Docker), je vois mal pourquoi rendre le processus synchrone ou asynchrone changerait quoi que ce soit au problème, sauf à imposer une seule image en cours de création à un instant T, ou à stopper complètement le processus de création le temps d'un "gc". Dans les 2 cas, ça ne me semble pas particulièrement réaliste comme contrainte, pour un serveur dédié à cette activité.

Est-ce qu'il ne vaudrait pas mieux suggérer une configuration fiable pour ces cas? (quitte à prendre une hypothèse sur le temps maximal de construction d'une image par exemple)

Et si je suis complètement à côté de la plaque, une explication (voire un ajout au README) serait bienvenue ! :)

Projet sympa sinon. Si je peux me permettre une suggestion, des instructions pour construire une image statique de ton programme lui donnerait de la visibilité: la plupart des systèmes pour lesquels il serait vraiment utiles n'ont pas OCaml, et souvent aucun moyen (simple) de l'installer (immutable infrastructure et tout ça).
Ou encore mieux… fournir une image docker de ton programme (dans le style docker-in-docker)

Bon en même temps, quand emacs est déjà dans le tableau, ne pas utiliser TRAMP pour l'édition à travers SSH, c'est dommage: TRAMP a le bon goût de lancer les processus directement côté serveur, du coup pas de pénalité particulière sur tout ce qui est ctags/make/git/… (petit bémol, il faut pouvoir travailler exclusivement avec des chemins relatifs, tout ce qui est absolu pose évidemment un problème de traduction dans la couche TRAMP)

au niveau le plus fondamental, la différence est pas si énorme: dans les 2 cas, les crédits sont conditionnés par ta capacité financière à rembourser, et ta "compétence" à rembourser. La différence est qu'en France par exemple la "compétence" est présumée totale, alors qu'aux US elle est présumée nulle.
Du coup, avant d'avoir un crédit immobilier, tu auras eu un crédit voiture. Et avant le crédit voiture, une collection de cartes de crédit. Et avant la collection, une seule plafonnée à $500, que tu auras d'ailleurs avancés à la banque, histoire d'être vraiment sûr :D

Après, tout le reste c'est juste les conséquences de cette différence de base.

C'est comme ça que j'en arrive à acheter ma voiture à crédit sur 4 ans alors que j'ai le cash en banque. Bon en même temps, vu mon credit score, le crédit en question est à 0%, donc c'est pas non plus affolant comme situation…
En règle général, quand on a les moyens le crédit ne coûte rien, voire peut rapporter pas mal.

Et tous mes achats (exceptées quelques factures pour des organismes qui ne prennent que la carte de débit) sont à crédit, c'est vraiment la norme aux US. Faut voir ça comme un test: est-ce que tu es capable de configurer tes comptes pour rembourser tout ton crédit chaque mois, ou est-ce que tu vas craquer sous la pression des $150k que tu as "disponibles" sur l'ensemble de tes cartes :)
Si tu tiens le coup, on te prêtera peut-être les 2-3 millions nécessaires à l'acquisition de ton 3 pièces ;)

Après c'est sûr, le système est pas tendre pour les gens qui ne savent/peuvent pas gérer. Mais bon, d'une façon ou d'une autre, c'est toujours un peu le cas.

oui clairement. Je sais pas ce que ça donne en France, mais dans n'importe quelle conf de codeurs dans la Silicon Valley, il n'y a virtuellement que ça.
La plupart des startups "hype" n'achètent que ça (sauf les quelques windows shops, évidemment), et dans les grosses boîtes que je connais, à vue de nez je dirais que c'est au bas mot 80% des machines de dev (massivement des macbook pro)

oui c'est particulièrement débile, et dans mon cas a provoqué pas mal de problèmes assez obscures dans des infras de build/test avec des politiques de cache complexes… N'importe quel code d'erreur (4xx ou même 5xx) aurait été détecté de façon triviale… vachement content de passer du temps là dessus.

Tout à fait, d'ailleurs il est bien connu que chaque homonyme de Stephen King bénéficie de droits d'auteur identiques sur l'ensemble de leur oeuvre collective (c) Stephen King. Après tout c'est leur faute, pour avoir un nom qui n'est pas 100% unique.

Ça c'est une interprétation de robot un peu basique, heureusement fort différente de l'esprit de la loi (et même de sa lettre), qui est celui qui compte. Sans même parler du fait que le copyright au sens propre ne s'applique pas partout, loin de là, son transfert obéit à des règles un peu plus complexes que le contrôle technique d'une étiquette telle qu'un nom de domaine. En gros, un copyright mal exprimé ou ambigu (tel qu'ici) nécessite une clarification, il n'est (évidemment, ajouterai-je) pas automatiquement "flottant"…

Moui, je conçois que l'impossibilité de vérification d'un vote acheté soit un frein théorique à la corruption, mais je ne suis pas du tout convaincu que ça en soit un en pratique (après j'ai rien contre le fait d'aimer la théorie, hein).

Hypothèse 1: on ne s'intéresse qu'aux élections impliquant une masse importante de votants. Sinon de toute façon l'avantage majeur du vote électronique, qui est la facilité/rapidité, s'efface massivement, sans parler du fait qu'on peut "vérifier" relativement facilement: si il me faut acheter 5 voix pour avoir la majorité absolue et qu'au final je ne l'ai pas, ça va pas être super dur d'aller casser la figure aux 5 gugusses que j'ai payés.

Si je suis acheteur de voix pour cette élection, j'ai un budget qui correspond à la valeur perçue. Comme tout investissement, il y a une part de risque (je ne reçois pas forcément ce que j'ai acheté), qui se transforme en quelque chose d'observable au moment du résultat. Plus la part de risque est faible (jusqu'à tomber à 0 pour le token qui me garantit que je fais ce que je veux), plus le coût d'une unité grimpe (puisque j'ai besoin de moins d'unités pour obtenir le résultat souhaité). Inversement, si je n'obtiens pas ce que je veux, l'investissement baisse puisque le risque est trop grand pour justifier le résultat. C'est typiquement un problème d'assurance: au fil du temps ça converge.
Le prix d'un vote doit donc refléter au plus près la probabilité que le votant fasse ce à quoi il s'est engagé (sur un panel assez large, je suis convaincu que c'est assez précis).
Ne pas oublier non plus que personnellement jamais personne ne m'a proposé d'acheter mon vote, ce qui m'incite à penser que les acheteurs de voix ne tapent pas non plus au hasard, mais se concentrent sur les populations les plus "fiables" pour X raisons, et que donc la probabilité en question peut être ajustée à la hausse selon des critères précis qui ont probablement assez peu de rapport avec l'esprit civique, ou l'esprit de contradiction, etc.

Hypothèse 2: les vendeurs de votes sont susceptibles de vendre lors de plusieurs scrutins

Maintenant si je suis vendeur de mon vote, il est dans mon intérêt que le prix monte, ou du moins ne baisse pas. Étant donné que si je suis malhonnête dans ma corruption (sic) mon gain baisse statistiquement, j'ai (statistiquement encore) intérêt à respecter le contrat avec l'acheteur.
Quand on y pense, les sondages sont relativement précis alors même que la personne sondée n'a quasiment aucune raison de dire la vérité (c'est un peu simpliste, il y a des raisons indirectes).

Bref, tout ça pour dire que je ne suis pas convaincu du tout qu'il n'y ait pas d'achats de votes maintenant alors qu'il n'y a aucune garantie, ni qu'il y en aurait davantage avec une garantie plus forte à l'achat, sous réserve que les échantillons soient suffisamment grands (assez grands pour rendre la cabale anti-acheteur impossible). Et oui, j'ai pleinement conscience de décrire la main invisible du marché de la corruption :D

En somme, il me semble que s'il fallait sacrifier une des propriétés du vote papier, c'est probablement de loin celle qui m'inquiète le moins (je ne suis toujours pas pour, mais c'est un autre problème :)).

oui je pense qu'il ne faut pas chercher trop loin, c'est juste que des gens sont frustrés par ce qu'ils n'avaient pas compris, et cherchent un échappatoire, tout en continuant à moyennement comprendre ce qu'ils racontent :)

Je ne pense pas que la notion d'utilisateur soit vraiment étendue en GPL v3. Je suppose que tu te réfères aux mesures anti-tivoization, mais c'est un cas un peu différent (l'utilisateur tourne un truc libre, a les sources, mais concrètement ne peut rien en faire). En ce qui concerne la portée sur les SaaS, la GPL a explicitement renoncé à ce but (fournir un service n'est pas distribuer le soft), et encourage l'utilisation de l'AGPL spécifiquement pour couvrir cet aspect.
cf ce blog par exemple.
(et évidemment ça n'a toujours rien à voir avec la distinction commercial/non-commercial)

disclaimer: je n'ai aucun contexte sur le projet lui-même, je me contente de réagir sur des points généraux

tu dis:

celui-ci est alors basculé sous une double licence : non libre en cas d'usage commercial et soumise à un paiement, libre GPL en cas d'utilisation non commerciale

ça n'a aucun sens, puisque la GPL ne s'oppose pas à l'utilisation commerciale. Donc même si c'était la formule choisie (et je ne pense pas que ce soit le cas, en tout cas le gist que tu pointes pour le texte de la double-licence n'a rien de commun avec la GPL, et n'est certainement pas libre), un utilisateur "non-commercial" serait licencié sous les termes de la GPL et pourrait donc parfaitement redistribuer sous GPL, y compris à des utilisateurs "commerciaux", bref ça ne peut pas marcher pour forcer les cas d'utilisation commerciale à utiliser l'alternative non-GPL.

Pour ce qui est du changement de licence lui-même, il doit être approuvé par l'ensemble des auteurs (au sens juridique) si il n'est pas de fait compatible avec la licence précédente (cf les astuces type "GPL v2 ou ultérieur", ce qui revient à une approbation au préalable). Si on migre d'une licence GPL à une licence incompatible, il y a forcément un accord à trouver.

Et oui, la licence AGPL a été conçue précisément pour ce genre de cas (service), où le programme lui-même n'est en fin de compte pas distribué et où donc la GPL n'a pas de portée.

Bref, de ce que tu en dis (encore une fois, je n'ai pas cherché à en savoir plus), les seuls à être potentiellement dans l'illégalité semblent être les mainteneurs (sous réserve qu'il y ait effectivement des contributeurs dont le copyright n'a pas été transféré et qui n'ont pas approuvé le changement, sinon ils font bien ce qu'ils veulent)

En tout cas ça me semble être en effet un superbe cas d'école d'incompréhension des implications de ce qu'on fait…
La GPL c'est pas un "truc cool" qu'on taggue sur son projet pour faire djeunz, c'est un document légal écrit dans l'esprit d'une volonté politique, celle de la FSF. Si on n'adhère pas, faut utiliser autre chose (et légalement), c'est pas ce qui manque.

c'est précisément ce que je dis explicitement un peu plus loin.
Mon équation se lit au sens strict: le couple (PIN, carte) est essentiellement la clef privée (pour toutes les opérations légales). Tu sembles lire ça comme "le couple (PIN, carte) donne la clef privée", ce qui serait effectivement faux. Et oui, pour les cartes où le changement de PIN est possible (ce qui n'est pas toujours vrai), la relation d'équivalence est temporelle: les anciens PINs ne servent à rien

oui tout à fait, j'ai fait un raccourci plus qu'approximatif et bien malheureux. D'autant plus bête que tout ce qui se rapporte à la signature du certificat est complètement hors-sujet dans ce que je raconte :)

Ça n'a pas grand chose à voir, le fait que quelqu'un connaisse le PIN ne va faire une différence que dans le cas où il se trouve en possession de la carte elle-même, puisque c'est ce qui "débloque" la clef privée pour utilisation pendant la session.
En gros, PIN + carte = clef privée, mais PIN seul ou carte seule ne servent à rien.
Et autant la recherche de PIN en ayant la carte n'est pas totalement absurde: ( de chances de succès, avec N le nombre d'essais disponibles avant blocage permanent et M le nombre de chiffres dans le PIN), autant la recherche de carte en ayant le PIN a assez peu de chances d'aboutir, sauf à recourir à la coercition physique ;)

Pour utilisation (en chiffrement j'imagine) sur des documents que l'ont veut garantir secrets pour l'état, la vraie question est de savoir si l'état a la clef privée. Il y a globalement 3 cas de figure:
- la clef est générée hors-carte, injectée dans la carte, signée, et sauvegardée par l'état (cas d'utilisation: l'état se réserve explicitement le droit d'usurper l'identité de la personne)
- la clef est générée hors-carte, injectée dans la carte, signée, et détruite (cas d'utilisation: l'état n'entend pas usurper l'identité, mais se fait confiance à lui-même pour que ça n'arrive pas)
- la clef est générée directement dans la carte, et signée (cas d'utilisation: l'état veut garantir l'impossibilité, y compris pour lui-même, d'usurper l'identité)

Si le processus utilise le 1er cas, effectivement aucune confiance à avoir. Si c'est le 2ème cas, la confiance équivaut à la confiance placée dans le mécanisme de destruction (et en particulier à celle placée dans l'impossibilité d'intercepter la clef avec destruction). Si c'est le 3ème cas, la confiance équivaut à celle qu'on a dans le fait que la carte ne peut jamais recracher la clef privée (autrement dit qu'elle n'est pas trouée, puisque ça fait partie des specs), et que la clef est de suffisamment bonne qualité pour ne pas se suicider (à savoir leaker des informations sur elle-même lors d'opérations légitimes). Au passage, évidemment la qualité d'une clef décroît avec le temps, à mesure que les attaques contre les algos qui l'ont générée se perfectionnent et/ou bénéficient de plus de puissance pour tourner.

Personnellement je n'utiliserais pas une clef générée hors-carte pour des secrets au niveau "gouvernemental"

Évidemment dans tous les cas, si on ne fait pas confiance en l'état pour respecter la procédure qu'il prétend utiliser (ou s'il ne prétend rien du tout), on est par défaut dans le 1er cas :)
Mais encore une fois c'est globalement indépendant du fait que le PIN soit ou non sauvegardé quelque part.

Pour ce genre de diff, voir "git diff --word-diff", ou carrément "git diff --color-words" (mon préféré pour les collaborations en LaTeX)

C'est simpliste comme raisonnement. La question n'est pas celle de la responsabilité (évidemment que le composant qui a le bug est responsable, et doit être corrigé), mais du maintien des fonctionnalités: si il existe un moyen de faire marcher, aussi moche soit-il, il est normal que tout composant ne l'utilisant pas soit perçu comme fautif.
En gros, non il n'est pas normal de remplacer un composant qui marche par un autre qui marche moins sous prétexte qu'un tiers est pourri. La bonne démarche est de (faire) corriger les bugs, puis seulement de procéder au remplacement, et d'utiliser les contournements dans l'intervalle. Forcément ça prend plus de temps (notamment parce qu'on ne peut pas mettre la pression sur le composant fautif par le biais d'utilisateurs frustrés), mais au moins il n'y a pas de dommages collatéraux.

Sinon en allant par là on pourrait aussi estimer que les applis n'ont pas à contourner les bugs des libs, les libs n'ont pas à contourner les bugs des drivers, les drivers n'ont pas à contourner les bugs du noyau, le noyau n'a pas à contourner les bugs du compilateur, et le compilateur n'a pas à contourner les bugs du CPU (et du reste du matos d'ailleurs). Alors oui, à la fin on aurait sans doute un système très élégant où tout le monde fait exactement ce qu'il doit…
Ou alors peut-être qu'on n'aurait rien du tout parce que tout le monde serait en train d'attendre qu'un fondeur produise le CPU parfait, alors qu'aucun fondeur ne survit plus de 3 mois puisque virtuellement personne n'achète de CPU (pourquoi faire quand on n'a même pas de compilo fonctionnel?)

Bref, sans pragmatisme on ne va pas très loin. Ou, dit autrement, le fantasme de la réécriture complète qui va corriger tous les problèmes par la pureté architecturale n'est que ça, un fantasme. De ce point de vue la gestion de l'introduction de PA était un désastre: pas d'un point de vue "scientifique", mais d'un point de vue d'ingénieur.
La seule raison pour laquelle c'est "passé", c'est que ce n'était "que" de l'audio.

C'est un fait, en matière d'informatique le monde entier tourne sur des workarounds dégueu.

Ah oui, intéressant, je n'avais pas relevé cette valeur qui est effectivement assez haute. Si je ne m'abuse, la valeur par défaut du noyau est 128, read_wakeup_threshold étant lui à 64.
Par curiosité, c'est quelle distribution ? (Google semble me suggérer que ça pourrait être redhat, mais je n'en ai pas sous la main)

Aussi, je pense qu'il faut prendre en considération le delta entre read_wakeup_threshold et write_wakeup_threshold pour se faire une idée plus précise, puisque c'est la "zone" dans laquelle le kernel souhaite maintenir l'entropie (puisque seul un "gros" consommateur d'entropie va être en mesure de faire descendre en dessous de read_wakeup_threshold). Au vu du comportement que tu observes, je soupçonne que read_wakeup_threshold est configuré relativement haut aussi ?

Mais effectivement avec des niveaux aussi hauts, ça peut être un peu overkill d'aller taper le userland pour restaurer de l'entropie alors qu'on n'est pas forcément vraiment en manque. Aux valeurs de base que je mentionnais plus haut, ça se justifierait davantage peut-être.

En y réflechissant un peu plus, ça me semblerait d'ailleurs étrange de configurer des valeurs aussi hautes pour les seuils. J'ai l'impression que ça rendrait l'ensemble des consommateurs plus à la merci des pics d'un gros consommateur: dans un cas où on a N petits consommateurs et 1 gros, dès que le gros passe tous les petits vont devoir attendre que l'entropie remonte à un niveau très élevé. Au contraire quand les seuils sont plus bas, on va réveiller tout le monde régulièrement, et probablement en pratique ralentir le gros au bénéfice des petits.

Bon en même temps il semblerait que certains consommateurs ajustent leur consommation en fonction du niveau disponible, pour rendre les choses encore plus complexes…

Ça semble pas trivial à ajuster proprement au profil d'utilisation tout ça :)

Vouloir faire ce que fait scdrand dans le noyau impliquerait, entre autres choses, de déplacer les pilotes de lecteurs de carte dans le noyau (actuellement, ils sont en espace utilisateur, gérés par le projet pcsc-lite notamment), ainsi que toute la logique de communication avec les cartes. C’est faisable, certes, mais c’est pas mal de boulot. Si je suis passé par scdaemon, c’est justement pour ne pas avoir à implémenter tout ce qu’il fait moi-même.

Je ne pense pas que ce soit nécessaire (et clairement ça ne serait pas souhaitable, pour les raisons que tu décris). Le kernel est tout à fait capable d'aller discuter avec le userland, en utilisant le usermode-helper.

Après la question est effectivement de savoir si le (super) user prête un token au noyau en prenant la responsabilité de la qualité de l'entropie, ou si le noyau décide de lui-même d'aller utiliser tout ce qui ressemble à du PKCS#15.
Je pense que les 2 scénarios ont du sens, en particulier je serais tenté d'utiliser l'approche module pour un scénario type "datacenter", où la sécurité physique est supposément gérée, et où les serveurs pourraient être "équipés" de smartcards (pour pallier l'absence de TPM peut-être ?), qui appartiendraient de ce fait au système

Je pense qu'il voulait dire que bien que le pool soit global, le niveau d'épuisement auquel réagir pourrait varier suivant le processus qui pourrait être utilisé pour réapprovisionner (le processus en question pourrait par exemple créer son fichier treshold propre, et l'enregistrer auprès du sous-système random). On pourrait notamment imaginer des sources d'entropie plus ou moins coûteuses/efficaces, qui seraient mises à contribution suivant l'urgence de la situation. Mais ça reste un peu artificiel.

Ceci dit, ça ne me semblerait pas délirant que scdrand respecte cette constante, qui est supposée représenter le seuil à partir duquel "quelqu'un" doit réapprovisionner le pool si possible, au lieu d'avoir son propre seuil.
Même si le seuil est relativement bas, le simple fait de réagir à une notification au lieu de vérifier périodiquement devrait permettre d'éviter encore plus les trous dans le niveau d'entropie.

Au passage, légèrement hors-sujet, je viens de tomber sur ce projet qui m'a l'air fort intéressant (mutualisation des sources d'entropie): http://www.vanheusden.com/entropybroker/
Justement les pertes de performance liées à la rareté de l'entropie en environnements virtualisés sont un de mes problèmes actuels, je suis content :)
Ça soulève pas mal de questions, bien sûr (notamment quant à la notion de distribution de confiance), mais c'est sympa de voir qu'il y a des tentatives de solution.

Assez en désaccord avec ta notion d'"inutile".
Pour moi le contenu inutile est essentiellement celui sans lequel la quantité d'information contenue dans le fil serait exactement la même, ce qui n'a pas grand chose à voir avec la qualité de la prose.
Exemple: un doublon d'un post brillant est parfaitement inutile, de même qu'une paraphrase d'un autre post pertinent, au même titre qu'une floppée de "me too".

Alors évidemment en écrivant "de la merde", on limite sérieusement ses chances d'atteindre un niveau de pertinence raisonnable, mais ça reste une simple implication.

Par contre, ce qui manque effectivement un peu à mon sens, c'est une échelle pour les posts "toxiques", qui tirent le ratio signal/bruit vers le bas.
Exemple typique tiré de plus haut: "les lauréats français de la médaille Fields viennent de l'X". Purement factuel, énoncé avec aplomb, et complètement faux (=> valeur négative). Le problème avec ce genre de commentaire c'est qu'il fait de la désinformation (probablement involontairement). Pas super grave me dira-t-on, l'ENS et l'X c'est pareil, tout ça…

Mine de rien j'étais assez content de ne pas avoir d'uniforme, et d'un point de vue plus fondamental, c'est complètement se méprendre sur les missions respectives de ces deux écoles (celle de l'ENS étant beaucoup plus compatible avec le type de recherche typiquement récompensé par les médailles Fields, autrement dit le résultat n'a rien d'un hasard), ce qui commence à ressembler un peu plus à un vrai problème (bien plus que d'ignorer leurs missions). Après tout, l'étape suivante pourrait être de décider unilatéralement qu'on n'a pas besoin des deux (puisque c'est "la même chose"), etc.

N'empêche, quelqu'un qui lirait ça sans lire la réfutation pourrait être induit en erreur, et propager l'"information". Encore une fois, dans le cas présent, pas franchement critique, mais le principe lui-même est assez dangereux. Appliqué à des données moins facilement vérifiables, c'est exactement ce qui nous mène à faire d'Internet un antre de désinformation, ce qui est franchement triste je trouve.

Le problème étant que ces erreurs/désinformation/etc. ne sont pas forcément totalement inintéressantes, dans la mesure où leur correction peut potentiellement déboucher sur des contenus parfaitement pertinents (et justes), mais aussi potentiellement hors-sujet. Dans ce sens, "inutile" est un peu rapide. Mais d'un autre côté, "pertinent" ferait franchement mal, donc…

L'un dans l'autre, un système binaire, aussi imprécis soit-il, n'est pas forcément une si mauvaise chose. Lisant moi-même les fils de commentaires en diagonale, ne dépliant les commentaires cachés que lorsqu'ils font partie d'une sous-discussion qui me semble globalement intéressante (je navigue généralement à 0), il est relativement rare que j'aie l'impression de rater quelque chose que j'aurais voulu voir (y compris lorsque je vérifie, donc).
Bref, en théorie c'est tout pourri, mais en pratique, sous réserve de régler le seuil en fonction de ses attentes propres, ça marche pas si mal :)

Moui, faut nuancer un peu quand même. Redhat est loin d'être parmi les employeurs les plus compétitifs et un rapide coup d'oeil à glassdoor me montre que le gars gagne probablement nettement moins qu'un développeur un poil expérimenté chez Google par exemple.

Je ne dis pas qu'ils ne sont pas bon, loin de là. Au contraire, je pense que le rapport qualité/prix est assez élevé. Il n'en reste pas moins que Redhat fait exactement comme toutes les autres boîtes: recruter les meilleurs parmi ceux qu'ils peuvent s'offrir, ce qui est différent des meilleurs dans l'absolu.

Bref je pense qu'il est assez légitime de dire que tel ou tel bout de code ne serait pas jugé acceptable ailleurs. Et la réponse n'est pas nécessairement que ceux qui l'affirment pourraient aller prétendre au salaire du gars qui a pondu le code, mais aussi parfois qu'ils gagnent déjà bien plus (ou bien assez) ailleurs.
Et puis y a pas que l'argent dans la vie non plus, donc l'argument "si tu peux faire mieux, va te faire payer à sa place" est beaucoup trop simpliste, peu importe la façon dont on aborde le problème.

Au passage, ce bout de code ne serait jamais accepté chez moi ;)
Ça n'en fait pas quelque chose d'intrinsèquement mauvais mais, selon la durée de vie du code en question, ça peut être un choix globalement rentable ou non: pour schématiser, capex-- vs opex++. L'argument des gens qui râlent contre ce code est qu'un système d'init devrait avoir pour vocation de durer dans le temps, donc avoir un coût de maintenance le plus faible possible (bon y en a aussi qui râlent parce que le code moche c'est Mal(tm), mais c'est un autre problème :)).
En même temps je comprends parfaitement Redhat, et une des spécificités du libre c'est que l'"opex" est mutualisé dans une certaine mesure, ce qui rend l'optimisation de "capex" plus attractive… En gros le point critique est d'être juste assez bon pour convaincre les autres d'adopter, et hop, par magie les coûts de maintenance sont partiellement transférés à des tiers. Finalement c'est un bel exemple de l'économie autour du libre :)

Un peu de promo pour le projet d'un pote: http://hopperapp.com/ qui a désormais une version Linux.
Ça ne joue pas dans la même cour que IDA, mais c'est très très correct et ça ne coûte pas un bras. Donc pour les cas où on n'a pas besoin de toute la puissance d'IDA (ce qui est quand même relativement fréquent), c'est pas mal du tout.
J'aime bien le décompilateur, qui permet de survoler rapidement le code simple.
(disclaimer: je m'en sers essentiellement sur du code ARM)

Non ce n'est pas le cas de tous, mais ce n'était pas non plus le propos de PBPG. Tout ce qu'il dit c'est que quelqu'un qui est en position de gagner X (pour X "gros") "relativement facilement" aux USA a beaucoup de mal à faire de même en Europe. Pour avoir quitté les USA il y a 2 ans, avoir bossé en France, Suisse et Angleterre depuis, et être rentré aux USA il y a 2 mois, je confirme la tendance.

Concernant le chiffre avancé (250k), il s'agit probablement du "package", donc pas seulement salaire fixe (mais aussi bonus, stock, etc.). Sans être courant, ce n'est effectivement pas du tout absurde dans le monde du soft, surtout avec 15 ans d'expérience.
Note qu'on parle de grosses boîtes, pas de startups (qui elles ont un package plus axé sur le stock, donc par définition incertain, en positif ou négatif)

oui et non…
3h dans l'absolu, pour évaluer la compétence de quelqu'un, c'est rien en effet. Par contre 3h pour une seule unité d'interview (ou de code ici) je trouve ça énorme.

Je n'ai jamais postulé chez MS, mais mon expérience des interviews aux US c'est généralement entre 5 et 10 slots d'1h, avec des gens différents, des sujets différents: de l'interview HR de base pour vérifier que tu rentres un minimum dans les cases, à la discussion informelle pour évaluer tes compétences en communication et ton capital sympathie, aux sujets techniques qui peuvent évoluer en discussion sur ton projet open-source dont le mec en face est utilisateur/contributeur (vécu :)).

En gros, on n'a pas le temps de s'ennuyer (y compris pour la journée d'entretiens de Google, qui te laisse avec du charbon fumant à la place du cerveau). Et si une interview particulière ne se passe pas trop bien (ce qui arrive souvent), il n'y a pas trop longtemps à attendre pour en être débarassé.

Par contre un "TP" plus ou moins bidon de 3h où je vais m'ennuyer comme un rat mort tout en n'étant pas certain de ce qui va satisfaire le type en face… personnellement si je sais à l'avance que c'est au programme je n'y vais pas (si je trouve la méthode de recrutement fondamentalement foireuse, il y a des chances que je n'aie pas envie de bosser avec les gens qui l'ont mise en place de toute façon).

Je ne cherche pas à tirer de conclusion, mais il est clair que la stratégie de recrutement a un impact direct sur le sous-ensemble de personnes qui vont accepter de suivre le processus. Parfois c'est exactement l'impact qu'on veut (je pense que Google/Microsoft/Apple/… sont globalement satisfaits de leurs embauches, quitte à rejeter des gens potentiellement valables), parfois non (ce qui se voit en général au fait que la boîte n'arrive pas à recruter, ou inversement recrute n'importe qui)

Bref je trouve quand même un peu que se plaindre du niveau des candidats, qui est peut-être effectivement faible, évite un peu trop facilement de se demander pourquoi Linus n'a pas postulé :)

pour avoir une approximation identique sous zsh:

compdef apti=aptitude