flan a écrit 1865 commentaires

j'avais compris le contraire : des conteneurs Docker classiques qui tournent sur du Windows.

ta vision des choses est correcte quand chaque couche est bien isolée et que tu peux la remplacer sans affecter les autres couches.
C'est le cas en réseau avec les couches les plus basses : tu peux changer ton Ethernet par du Wifi sans affecter les logiciels.

En revanche, le RAID, les volumes logiques et le système de fichiers doivent savoir comment chacun fonctionne pour avoir des performances correctes (c'est d'ailleurs pour ça que les cartes RAID matérielles sont déconseillées avec ZFS). Un SSD, un RAID matériel ou un disque SATA classique (la couche la plus basse) ne demanderont pas les mêmes choses au système de fichiers (la couche la plus haute) pour être performants.
Peut-être que le LVM aura aussi envie de connaître l'état des systèmes de fichiers pour faire ses volumes logiques (avec les fichiers creux qui ont une taille réelle plus petite que celle affichée ou les données dédupliquées, les fichiers compressés, les anciennes versions de fichier, la taille réellement utilisée n'est plus la même que celle théoriquement utilisée).

Accessoirement, on peut considérer que l'ensemble des trois forme une seule couche. En tant qu'utilisateur, ça ne me choque pas plus que ça d'avoir un seul logiciel qui se débrouille pour prendre mes disques durs et me découper ça en une série de partitions, en mettant du LVM ou du RAID s'il veut.

Le lien entre JVM et Java est quand même très légèrement plus fort que celui entre IEEE754 et C. La JVM a été pensée pour le Java (et Java a été pensé pour fonctionner sur la JVM), IEEE754 n'a pas été pensé spécialement pour le C, le C n'a pas été pensé pour IEEE-754 (et fonctionne sur des processeurs qui ne sont pas compatibles IEEE754).
Si tu veux être compatible Java (un des buts est de réutiliser des libs Java), tu es obligé d'être compatible JVM. S'ils n'avaient pas besoin de cette compatibilité Java, ils n'auraient pas eu de problème avec la JVM…

Ce que j'ai décrit n'est qu'un des aspects où on aboutit à vrai bug au runtime, mais il y a régulièrement des petits trucs qui ne s'expliquent que grâce au Java (notamment la gestion des types primitifs Java) et qui ne devraient pas expliquer si Scala n'était pas compatible Java.

Et quand tu utilises la lib standard Java, tu te retrouves avec une doc en… Java (surprenant ! ), avec des exemples en Java bien orientés objet comme il faut.

Si c'est comme Scala, c'est un inconvénient pour moi.
On se retrouve avec deux langages à connaître au lieu d'un seul si on veut comprendre ce qui se passe et utiliser la lib standard.
exemple tout bête : en Scala, tout objet hérite du type Any. Plus exactement, presque tout le monde hérite de AnyRef qui hérite de Any, sauf les int/float (eln fait les types primitifs de Java) qui héritent de AnyVal qui hérite de Any. Rien de très choquant là-dedans quand on connaît Java. Ça, c'est la théorie. Maintenant, si on veut faire un Array de Any et mettre dedans des String et des int, pas de souci d'après le système de types… sauf que ça casse à l'exécution pour un problème de type, alors que la grande promesse de Scala est de résoudre tous les problèmes de type à la compilation.
Normal : sous le capot on a un type primitif de Java qui ne se caste pas bien comme un objet Java.

Maintenant, ce problème ne devrait pas exister en Scala, et il est indispensable de connaître des subtilités de Java pour comprendre le comportement de Scala.
Quant à la lib standard, c'est en fait essentiellement celle de Java, donc il on se retrouve à mélanger deux styles de programmation qui n'ont pas grand-chose à voir.

La dédup est la déduplication. Le système de fichiers se rend compte tout seul que deux blocs (qui appartiennent probablement à deux fichiers différents) sont identiques. Du coup, il n'en stocke qu'un exemplaire. Quand tu n'as que des fichiers différents c'est bien sûr totalement inutile, mais quand tu stockes beaucoup de VM (par exemple), avec chacune un OS complet, tu as autant de copies du même fichier que de VM. Là ça peut apporter un gros gain de place.

Tu peux assez facilement créer des formulaires avec une interface graphique. C'est le cas avec Wordpress pour les formulaires de contact : tu as une grosse dizaine de briques de base (ligne de texte, date, courriel, heure, bloc de texte, choix de valeurs, …) que tu choisis pour créer ton formulaire personnalisé et qui est validé automatiquement.
Certes, ça ne plaira pas à 100% des gens, mais peut-être à 95% (voire davantage).

Je ne comprends pas pourquoi utiliser un framework signifie utiliser 150 000 dépendances. Quand tu utilises Django en Python, tu installes Django… et c'est tout. (bon, ok, il faut probablement rajouter gunicorn ou un équivalent).
Rien n'oblige à installer beaucoup plus de dépendances, je pense que s'il est fréquent d'avoir quelques dépendances supplémentaires, le nombre de dépendances à avoir est beaucoup plus faible avec Django qu'avec bower.

Autre projet : PY14, pour convertir du Python en C++ 14 (https://github.com/lukasmartinelli/py14/blob/master/README.md)
Le projet n'a pas l'air encore très abouti, cependant.

(perso j’ai du mal à voir en quoi git clone && npm install est tellement plus pénible que tar xzf, mais admettons…),

Quand tu travailles sur un réseau déconnecté, tu prends goût aux .deb/.rpm, voire aux .tar.gz quand ça reste correct.

ou alors il aime bien recommencer à zéro quand il trouve que son code actuel n'est pas terrible (attitude quand même assez fréquente)

oui, désolé, j'y ai pensé au début, mais je ne me souvenais plus du nom exact et j'ai oublié de le retrouver à la fin du message :(

Avec la transition (assez longue) vers Python 3, quelques Cassandre avaient prédit la fin de Python.
On voit qu'au contraire, le langage est bien vivant. C'est d'ailleurs un des langages interprétés avec le plus d'implémentations concurrentes.
Certes, les versions Java (Jython) et C# (IronPython) sont mortes, mais on se retrouve avec quelques projets qui sont bien vivants :

• cpython, la version historique,
• pypy (autre implémentation),
• brython (implémentation en JS),
• cython (pour compiler un surensemble de Python)
• nuitka (autre compilateur Python),
• pyjion (un JIT pour cpython),
• pyston (implémentation par Dropbox utilisant LLVM),
• numba (compilateur orienté vers le calcul scientifique).

C'est également le signe que pas mal de gens attendent plus de perfs de la part de cpython, pour l'utiliser dans des domaines pour lesquels il n'était pas prévu à la base, avec deux problèmes qui reviennent fréquemment : la gestion de la mémoire et le GIL (global interpreter lock, qui empêche d'utiliser à fond plusieurs coeurs).

Évidemment cela présentera un avantage compétitive par rapport aux 49 autres entreprises. Quelques années plus tard, quand ce sera le tour d'une autre entreprise d'aller moins bien, la même chose se produira; elle pourra en plus argumenter que "notre concurrent fait ça, on n'a pas le choix". Au final, tout le monde aura perdu ses droits. Ces "négociations" pour le sauvetage/chantage de l'emploi ne fera qu'entrainer un nivèlement par le bas pour tout le monde.

Accessoirement, on a ce problème à l'échelle européenne : on se retrouve avec de grosses différences de protection sociale (et donc des coûts de production différents). Fatalement, ça ne laisse que deux choix possibles : casser les protections sociales pour aligner tout le monde sur le moins disant (solution actuelle), ou abandonner l'union monétaire (ce que préconise de plus en plus d'économistes).

à défaut de physique quantique, une bonne scie suffit :o

Il ne parle pas de sacrifier son propre bien-être, il dit que considérer uniquement des cas particuliers (et découper la société en catégories distinctes qu'on pousse à s'affronter) détruit la notion de bien commun et de société tout court.

(et je ne vois pas ce que vient faire le fascisme, à la rigueur le sacrifice de l'individu au bien commun est plutôt du communisme, même si c'est tout autant violent)

C'est sûr qu'on trouvera toujours des cas tirés par les cheveux (ou pas), qui mettent à mal le type hinting, l'inférence de type, et toutes ces notions issues du typage statique.

Parfois, ces choses (qui ne sont pas possibles avec un langage à typage statique) sont bien pratiques, nous sommes d'accord. Cependant, je suis persuadé qu'il est possible de les limiter à quelques cas bien précis et bien délimités, avec 99% du code qui pourrait être en typage statique (avec toutes les garanties que cela apporte).
En tout cas, c'est comme ça que j'essaie de construire mon code, ça augmente certes le nombre de variables (vu que je me force à ne pas utiliser des types différents avec la même variable) mais ça augmente la sécurité (vu que l'inférence de type de Pycharm fonctionne beaucoup mieux).

Mais il faut regarder les chiffres donnés partout après les élections : on donne les pourcentages des votes exprimés et le taux de participation.
S'il y a 80% d'abstention : on verra en grand titre dans les journaux « X a gagné avec 51% des voix et seulement 20% de votants »,
S'il y a 80% de blancs : on verra en grand titre dans les journaux « X a gagné avec 51% des voix et 100% de participation ».

J'ai un peu l'impression que Shinken ajoute cette même intelligence, alors que c'est vendu comme une solution de supervision.

Tiens, c'est rigolo car le principal argument pour libéraliser un marché est que les prix sont censés baisser pour le consommateur…

La Russie n'a que 150 millions d'habitants, c'est-à-dire à peine deux fois plus que la France. Si elle arrive à avoir une armée complète, je ne vois pas pourquoi la France n'y arriverait pas, sachant que la France a un territoire beaucoup plus petit.

Quant aux États-Unis, jamais ils n'exporteront le F-22 dont la chaîne de production est de toute façon fermée.

Ta regexp est trop laxiste.
Celle-ci devrait mieux fonctionner : "((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?).){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)"

N'étant pas dév. web (et pas spécialement intéressé par le domaine, d'ailleurs), mais étant amené à concevoir régulièrement des interfaces web, je suis parti sur du Bootstrap pour avoir quelque chose de correct (même si ce n'est pas original).

J'avoue que la différence entre Semantic UI et Boostrap ne me semble pas suffisante pour justifier un nouvel investissement de ma part (d'autant que le gros avantage de Boostrap est d'avoir plein de plugins). Mais ça me permet au moins de savoir qu'il existe autre chose et de garder un œil sur ce qui se fait ailleurs.

La limite pour pas pouvoir prolonger un CDD dans la fonction publique c'est 6 ans… 6 ans de CDD, c'est pas acceptable et tes gens compétents, ils devraient pas être en cdd du tout. Ça tombe bien, la fonction publique (qui a par ailleurs bien des défauts), permet que tes gens compétents aient un statut (celui de fonctionnaire)

Euh… encore faut-il qu'il y ait un concours adapté. Et d'ailleurs, les CDD ne sont censés n'être signés que quand il n'y a pas de corps de fonctionnaire donnant la compétence demandée.
j'ai été en CDD dans la fonction publique, et le seul concours qui m'était accessible (avec le poste que je voulais) était destiné à des Bac+3, donc en-dessous de mon niveau d'études et j'aurais perdu en terme de rémunération. Du coup, 6 ans de CDD obligatoires.

Bon, sinon, on peut maintenant, à titre expérimental, être en CDI avant les 6 ans.

"La taille minimale du module est de 2048 bits, pour une utilisation ne devant pas dépasser l’année 2030"
Désolé, ça fait pas très rassurant, ce minimale, ça sous-entends que c'est parce que bon, tu insistes avec ta connerie, on va écrire ça même si on aurait aimé mettre plus. Et on met une date en plus, pas lointaine (dans 15 ans, on se dit qu'on pourra casser la chose, donc si c'est dumpé… La durée de la clé ne dit rien sur la durée de l’intérêt des données)

Je ne vois pas en quoi ce n'est pas très rassurant, et je vois encore moins pourquoi ils n'auraient pas mis 3 072 ou même 4 096 s'ils avaient vraiment voulu mettre plus.
Le "minimal" est même obligatoire pour que la phrase ait un sens, et je suis sûr que tu ne te serais pas privé de la critiquer s'il n'avait pas été présent : cela signifierait qu'une clef de 3 072 ne conviendrait pas.

L'ANSSI fait des recommandations dans des cas d'usage bien précis. Si tu as des données que tu veux préserver jusqu'en 2030 (plein de données sont périssables et pourraient être dévoilées dans 15 ans sans préjudice aucun), tu peux utiliser des clefs de 2 048 bits. Si tu es du genre "ceinture et bretelles" et que tu as de l'argent à mettre dans ton CPU (oui, le SSL a un coût), c'est encore mieux de mettre du 3 072 bits, bien évidemment.
Essaie de faire les deux (2 048 et 4 096 bits), tu remarqueras une vraie différence sur le nombre de connexions qu'encaisse ton apache (j'avais fait le test il y a quelques années, c'était non négligeable même si je ne me souviens plus des chiffres).

En effet, il n'y a que ChakraCore (le moteur JS), sous licence MIT.