ckyl a écrit 3877 commentaires

Donc moi je garde mon serveur perso (avec les limites expliquées ci-dessus).

En même temps c'est pas comme si tu avais eu le choix ;)

Toutes les sources que j'ai vu parlent bien d'un développement & infra maison pour les besoins maison. Celui d'une partie de l'état français d'assurer la confidentialité de ses échanges.

Pas de devenir éditeur logiciel ou fournisseur SaaS pour ses citoyens.

Ca rend le concept de clé dans le header ou de lien de clé dans le header totalement bancale, voire dangereux.

C'est pourtant la mode, d'HPKP à HSTS en remontant jusqu'à l'identification d'un serveur SSH.

https://en.wikipedia.org/wiki/Trust_on_first_use

L'intersection entre sécurité et utilisabilité semble assez vide. Vu que les solutions sures qui exposent le problème du tiers de confiance ou de canal d'échange sécurisé pour l’amorçage ne sont pas utilisées, on semble essayer du TOFU un peu partout en se disant que c'est peut être moins pire que la situation actuelle.

mais ça fait le job :)

Non. Voir https://git-scm.com/docs/gitignore -> Pattern format.

Bash étant turing complet tu vas bien finir par implémenter la gestion correcte de cette petite fonctionnalité. N'oublie pas que le .gitignore n'est pas forcément dans CWD il peut être plus haut (tu es dans un projet) ou bien plus bas et multiple (CWD ou ses fils contient plusieurs projets). Une fois que tu auras trouvé la solution tu pourras recopier ça à chaque fois que tu utilises grep. Ou alors tu mets ça dans un outils réutilisable que tu pipe mais alors ton appel standard à grep va toujours être un pipe de 3km de long alors tu vas faire un alias ou enrober ça dans un outil. Oh wait…

Ensuite tu passes aux fonctionnalités suivantes comme les globing pattern, la recherche dans les fichiers compressés, la recherche multi-threadée, la gestion d'encoding .

Dans une vue ops d'intervention se limiter aux outils standards est cohérent (standard pouvant varier selon les environnements on peut aller jusqu'à strictement POSIX). Les outils dont on parle sont eux parfaitement adaptés aux problématiques dev. Leur comportement par défaut correspond souvent à ce que l'on veut et les cas d'utilisations courants sont couverts avec quelques options simples plutôt que des kilomètres de pipe à base de sed | cut | awk | parallel | grep -v | variables d'environnement obscures.

Et on peut facilement maitriser les deux monde si on évolue dans les deux mondes.

Le lien que tu m'a donné plus haut parle de stack de 2Kio (pour Go 1.5 ça a peut être évolué) soit si tu en lance un par connexion pour le C10K, si je ne me suis pas trompé dans mes comptes on est dans les 20Tio de mémoire consommée.

Heu 2Kio * 10 000 çà doit être plus proche des 20 Mio que des 20 Tio non ? :)

long currentTime = System.currentTimeMillis();

Dans ce cas il faut utiliser System#nanoTime et non System#currentTimeMillis. nanoTime est monotone alors que currentTimeMillis ne l'est pas (oui le nommage est pourri et il faut savoir lire entre les lignes de la doc)

https://docs.oracle.com/javase/9/docs/api/java/lang/System.html#nanoTime--
https://docs.oracle.com/javase/9/docs/api/java/lang/System.html#currentTimeMillis--

s'il va dans le passé subitement, il obtiendra un bpm négatif et ça correspondra bien à la réalité perçue du point de vue du script : il fait ce qu'on lui a demandé

Si tu peux bien sur inventer le besoin et la spécification que tu veux, je pense que la majorité des personnes saines d'esprit comprendrons l’énoncé du problème en CLOCK_MONOTIC et non en CLOCK_REALTIME. Ta vision me semble pour le moins farfelue.

Je vois peu de cas pendant lesquels ça peut arriver, mais par exemple comment se comporte la fonction pour récupérer l'heure si un changement d'heure à lieu pile au mauvais moment?
Pour moi, ce qu'il a fait, c'est le genre de choses qui rendent un programme robuste.

Si tu veux rendre un programme robuste, enfin surtout correct, tu utilises une horloge monotone pour mesurer un écart de temps. Ce que la version C++ faisait correctement et qui s'est perdu ici :)

Le ∞ c'est juste utile si tu dépasses la résolution.

Regardez ce que vous pouvez stocker pour 10€ par mois, ça ne va pas chercher loin

534 GB dans S3 ;)

Et que dire du niveau de protection des navigateurs sur smartphone? pourquoi ne parler que des navigateurs de bureau quand le plus gros du tracking se fait sur les navigateurs mobiles qui sont quasi dépourvus de protection.

Regarde ce que font les apps sur mobile et un Firefox sur Android te paraitra le top niveau vie privée… Les apps c'est juste effrayant (et beaucoup plus difficile à analyser / tracer / bloquer).

En dehors de sa syntaxe parfois difficile à mémoriser pour les expressions compliquées et de sa gestion des number, le plus gros reproche que j'avais à faire à jq ce sont ses performances. Il plafonne à quelques MB/s.

As tu une idée si les autres outils sont un peu moins limités de ce côté là ?

Évidemment aujourd'hui on pourrait dire que c'était un bon choix mais il y a 2 ans c'était moins évident. Mettre 100/150 € de plus pour ce critère c'est pas simple

Effectivement. L'autre solution c'est de miser sur les modèles qui ont historiquement un bon support LineageOS (tu ne peux jamais savoir au moment de l'achat) et ton téléphone sera mort avant que tu n'ai plus de mises à jour. Mais c'est pas forcément très grand publique :(

Avec cette stratégie tu as le beurre (MAJ) et l'argent du beurre (un moto G c'est donné)

Par contre l'amélioration des performances du patch… Ça va être dur, le TLB se fait défoncer obligatoirement, et c'est ce qui coûte cher.

Surtout que le problème s'est déjà posé il y a 15 ans lorsque l'on voulait pouvoir donner 32 bits d'adressage à un processus sur un CPU 32. Ça nous remonte en 2003, ça s'appelait le 4G/4G split et ça faisait grosso modo la même chose: virer le noyau de l'espace d'adressage du processus et vider le TLB à chaque syscall. Si ma mémoire est bonne, on n'a jamais trouvé d'astuce pour optimiser le truc et le surcoût de l'époque est similaire aux premiers benchmarks qui sortent (30% pour les charges qui font pleins de syscall, 5% lorsqu'il y a peu de syscall).

D'ailleurs je suis preneur de critique sur ce logiciel, pour voir si je pourrais me l'approprier…

Je ne connais pas LessPass mais:

• Comment fais tu pour changer un mot de passe ? (X s'est fait trouer ou simplement rotation régulière forcée ou souhaitable)
• Comment fais tu pour gérer les groupes de sites avec la même authentification ?

Le logiciel étant sans état, l'état se retrouve dans ton cerveau. Le but initial était de virer cet état de ton cerveau…

Si tu lui colles une DB aux fesses comme cela semble être possible pour garder l'état de counter et autres options côté serveur, pourquoi s'embêter avec un système "compliqué" plutôt qu'un bête stockage des mdp en clair dans une base ? Niveau sécu ca revient au même.

Comme ca je ne suis pas super convaincu. La version stateless à des limitations assez fortes et je ne vois pas d’intérêt à la version stateful par rapport à d'autres.

Mais qui investirait dans une société sans une contrepartie ?

Tout ceux qui ont des parts de GOOG, AMZN, TSLA, EBAY et un bon paquet d'autres ? (la question n'était pas pourquoi)

Surtout que le BC vient de rentrer en bourse, comme n'importe quelle autre monnaie

Non, pas du tout.

Tu as juste l'introduction au CBOE de contrats à terme portant sur la valeur du BC en dollar observé dans quelques places d'échanges de BC. Aucun BC ne change de main, personne ne manipule de BC, c'est juste un pari en fait. Tu pourrais tout aussi bien parier sur la valeur du tube de dentifrice en euros observé dans les 4 supérettes du coin que ce serait la même chose.

La beauté des produits dérivés, c'est permettre de spéculer sur n'importe quoi sans avoir à s'embêter avec n'importe quoi. Rien à voir avec la notion de monnaie et c'est pas demain que le BC arrivera au FOREX.

Je pense simplement que c'est le genre d'entreprise qui confond stage et CDD

Pourquoi supposer que ce sont des stagiaires ou CDD qui ont fait ça ? Il y a une masse significative de gens parfaitement incompétents parmi les gens en CDI, qu'ils aient 1 mois ou 10 ans d'expérience d'ailleurs. Après il y en a moins, ils ont été déplacé middle manager / product owner, ou jouent au consultant mais ne produisent plus rien.

Le fait qu'on parle d'optimisation pour ce genre d'évolution montre où on en est !

Oui elle s'applique. En pratique pour les petites boîtes c'est ton activité qui est taxée et non ton foncier.

Ton foncier étant négligeable, tu vas être imposé au forfait minimum qui est décidé par ta commune où ta communauté de commune. Le montant max est encadré par la loi par palier de CA, mais si tu veux savoir le montant exact la seule façon de le savoir c'est de demander à ta commune où ton centre des impôts. Il faut que tu demandes le taux et la base de la CFE. Ce que tu paies = base * taux.

À ma connaissance les seuls qui y échappe sont les auto entrepreneurs artisans travaillant avec leur main. Jamais vu d'autres exonération. Pour de la profession libérale tu y passes à coup sûr.

Il manque surtout un "Je ne veux pas y travailler et je travaille chez par ce que ça correspond à mes valeurs !". Par ce que évidement les 46% occupent un poste actuellement éthique à leurs yeux ;)

Tout ça correspond aux différentes passes d'optimisation de la JVM : on passe graduellement d'une méthode utilisée une fois donc entièrement interprétée, à une méthode identifiée comme critique pour le fonctionnement de l'application donc compilée et optimisée à fond par la JVM.

Et maintenant tu vas passer aux choses sérieuses et faire une vraie analyse ou des vrais tests ? ;-)

Si tu veux essayer de comprendre un peu ce qu'il se passe en vrai JITWatch est un excellent outil.

tl;dr:

1. Tu récupères linux-hsdis-amd64.so quelque part. Historiquement via le projet Kenai mais le site est down maintenant. Si tu le trouves pas, tu te frappes une compilation d'OpenJDK en debug. Tu le places dans $JDK/jre/lib/amd64/server/hsdis-amd64.so. hsdis te permet de sortir sortir le code assembleur généré par HotSpot
2. Tu tournes ton appli -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+LogCompilation -XX:+PrintAssembly -XX:-UseCompressedOops -XX:LogFile=mylogfile.log
3. Tu lances JitWatch

Ça te permettra de comprendre les différentes phases de compilation d'une même méthode, explorer la compile chain (ie. ce qui a été compilé, pas compilé, inliné, appels virtuels etc.), voir l'assembleur généré à chaque étape, voir les intrinsics utilisés etc.

En général le combo JITWatch / JMH bien utilisé te permettent de comprendre beaucoup de choses. Côté JMH, souvent la clé pour se genre de truc c'est de jouer avec les options de la JVM pour prendre différentes mesures. Ici tu pourrais tester un -Xint pour empêcher toute compilation, puis -XX:TieredStopAtLevel=X si tu penses que ce tu observes est lié aux 5 niveaux de compilation d'HotSpot. Les logs de compilations sont aussi super utiles, de même que la sortie assembleur.

Avec ces deux outils tu peux mettre en place un joli cycle d'itérations ou tu appliques bêtement la méthode scientifique. Attention un bench sert à valider un modèle de performance et pas à le découvrir. Voilà, tu viens de découvrir comment occuper tes 5 prochaines années ! Si j'ai 5 minutes a tuer je regarderais ton test.

Note: Je ne rentre pas sur le terrain de la pertinence de ton test, savoir expliquer ce que l'on observe est déjà bien rigolo :-)

Je n'ai pas regardé le fonctionnement de cette fonction Random() en java. Mais il y a de forte chance qu'elle fasse appelle à de l'entropie, au système ou bien d'autres trucs à durée aléatoire.

Non, Random c'est une bête congruence linéaire. Si tu veux un générateur pour la crypto -> SecureRandom

Je surligne sur liseuse (et exporte le tout en Markdown en incluant le contexte de la citation vers ma base de doc perso). J'utilise des marque page 3M sur les livres papiers (ils sont fins et permettent d'être positionnés exactement au bon endroit).

Et c'est encore le physique qui gagne :(

Je retrouve généralement plus vite ce que je cherche dans un vrai livre. Le fait d'avoir à explorer 3 / 4 post-it reste plus rapide que de chercher dans un amas de texte.

Le principal, peut-être le seul, problème que j’ai avec ma liseuse, c’est l’impossibilité (en pratique) de « feuilletter » un livre

J'ai un problème similaire avec les livres "techniques".

La lecture sur liseuse est très linéaire et sans "repère dans l'espace". J'ai beaucoup plus de mal à me souvenir de ce que j'ai lu sur liseuse et a retrouver rapidement ce que je cherche quelques semaines / mois / années après. Je compense en prenant des notes à la main à coté, mais c'est suffisamment notable pour que je rachète quelques incontournables en version arbre mort.

Aucun soucis pour les romans ou autre par contre.

Moi ce qui m'étonne le plus, c'est le côté par cœur, en direct.

Le processus de recrutement de Google est connu et il t'es présenté bien en amont.

Par exemple pour un poste de SRE on te suggèr(e|ait) très fortement de (re)lire quelques papiers de Google (GFS / big table / Chubby / Spanner etc.), de (re)lire quelques bouquins comme TCP Illustrated, The Practice of Programming, UNIX Programming environment ou Practice of System and Network Administration, on te file même des liens vers des blogs de mec relatant leur expérience avec le recrutement de Google. IIRC, le premier screening vient après.

Tu n'es donc pas à froid, tu peux parfaitement planter quelques questions et c'est vraiment de la pipi de chat par rapport à la suite. Tu n'as pratiquement aucune chance de passer le reste sans bosser très sérieusement. En SRE les sujets sont très vastes, en SWE le niveau d'algo à coder sur tableau blanc est juste débile.

Si tu n'es pas prêt à ça il ne faut effectivement pas y aller. Mais tu es parfaitement au courant de tout dès le début. En fait c'est une discipline à part entière qui n'a pas forcément de lien direct avec ton travail de tout les jours. Libre à chacun de penser que c'est un bon moyen de recruter ou non. Et libre à chacun d'accepter le jeu pour obtenir une offre (tu peux parfaitement penser que c'est complètement débile mais te donner les moyens de chopper un poste).

Ça me donne vraiment pas envie de postuler pour une boîte qui fait subir ce type de tests débiles à des développeurs surtout quand ils ont du code visible sur le web!

Les Big 4..X, et beaucoup qui les suivent, utilisent ça pour décider de te t'appeler mais s'en foutent complètement pour le recrutement. Tout le monde est traité exactement pareil.

Le truc intéressant avec Google c'est qu'ils documentent souvent leurs objectifs, leurs process et le rationnel derrière. Ça peut te permettre de te faire une idée de savoir si c'est vraiment idiot ou non.

Genre quand le mec en face lui répond qu'il a tort sur la taille d'une adresse MAC alors que non c'est le recruteur qui dit n'importe quoi

Le recruteur ne lui dit pas qu'il a tord sur l'adresse MAC. Si tu regardes TOUTES les réponses où le recruteur lui dit que c'est une mauvaise réponse c'est aussi par ce qu'il fait la réponse la plus cryptique et courte possible.

Sauf si le recruteur n'a pas suivi la procédure, tu as en face un mec qui s'introduit clairement comme un recruteur non expert technique et qui te présente l'exercice comme étant un simple filtre et qu'il fait principalement du pattern matching. Dans ce contexte qu'est ce qui te parait le plus malin ?

1. Faire le l33t comme il l'a fait
2. Faire des phrases un peu plus longues, donner la réponse évidente en premier, développer un poil ta pensée… ce qui maximise tes chances que ta réponse soit considérée valide.

Si tu relis sa réponse sur "returns an inode", je suis sur que tu peux la reformuler sans aucun effort pour que ça passe comme une lettre à la poste.

Je n'ai pas compris pourquoi j'ai du faire le 3e entretien (avec deux ingénieurs sur leur temps de travail), c'était une perte de temps pour tout le monde (eux comme moi) de manière assez incroyable.

Statistiquement c'est certainement pour une très mauvaise raison mais au bénéfice du doute:

1. Ils voulaient calibrer leur interview
2. Ils voulaient entraîner un nouvel interviewer sur quelqu'un qui n'avait aucun risque
3. Le critère que l'on t'a donné n'était en fait pas totalement bloquant et aurait pu être compensé