Le 16/10/2024 à 16h 30

Le 16/10/2024 à 10h 04

Le 26/01/2024 à 09h 52

Le 26/01/2024 à 06h 20

Le 25/01/2024 à 14h 36

Le 10/06/2022 à 08h 55

Il s’agit d’une synecdoque : on remplace le tout par une partie de ce tout.

Le 15/04/2022 à 09h 36

D’accord, merci pour les précisions.

Effectivement, avoir 10ans d’expérience et arriver à 1 982,19 € brut, c’est la douche froide.

Le 15/04/2022 à 09h 02

Donc selon cette fiche, un nouvel entrant avec 10 ans d’ancienneté (donc 5 comptabilisé) entre au 3ème échelon (Ingénieur d’études hors classe) ou au 4ème échelon (Ingénieur d’études classe normale). C’est bien ça ?

Le 25/03/2022 à 10h 05

C’est une idée reçue, les ambassades ne sont pas ni ne sont considérées comme des enclaves dans le pays hôte, elles sont soumises aux mêmes lois que ce dernier.
En revanche, le pays hôte n’a pas le droit d’y pénétrer sans l’accord du chef d’ambassade.

Le 27/02/2022 à 11h 11

Je n’ai accusé personne de troller. Vous avancez un argument et j’en avance un autre. Quel est le problème ?
D’ailleurs je constate que votre propos a évolué. Au début vous accusiez clairement les langages d’être les problèmes (en disant qu’ils n’étaient pas sérieux notamment), maintenant vous reconnaissez que c’est uniquement la manière dont on les utilises.

En revanche, je n’aime pas particulièrement java et son écosystème.
Je suis d’ailleurs d’accord pour dire que c’est une mauvaise solution dans beaucoup de situations.

Je vais continuer à me faire l’avocat du diable mais vous ne mentionnez que ce qu’Orange a “perdu” en passant de C++ à Java mais jamais ce qu’ils ont pu gagné (temps de dev ou facilité à trouver du personnel compétent, par exemple).
Comme je le disais, l’informatique c’est avant tout des compromis et il n’y a pas que les performances brutes qui comptent.

Le 26/02/2022 à 09h 13

wanou a dit:

Je ne vise que JAVA dans ma critique et je peux te dire que je n’ai jamais vu un autre langage créer des lags comme java quand il démarre son ramasse miette et fige les programmes de manière impromptue et non contrôlable. Devant utiliser au quotidien des programmes écrits en java, c’est, en plus des interfaces utilisateurs pas ergonomique du tout, très pénible.

Les applis Android sont majoritairement écrites en Java (ou en tout cas tournent dans une JVM donc avec un garbage collector) et elles ne posent généralement pas de problèmes de performances.
Peut on en conclure que le langage n’est pas en faute ?

Je ne crois pas que cela soit possible en java. Peut-être que je me trompe.

Je voulais dire que si un outil n’est pas approprié, il faut en changer. Si utiliser Java et son garbage collector pose problème, il faut envisager d’utiliser une autre solution.
Il ne faut pas blâmer l’outil mais la manière dont on l’utilise donc.
Personne n’aurai l’idée de dire qu’un marteau est nul car on ne peut pas visser avec. Là c’est pareil.

Oui mais les threads sont exécutés séquentiellement sur un seul coeur. L’interpréteur Python n’étant pas ré-entrant, il est impossible de bénéficier de l’exécution simultanée des tâches. C’est ce que j’appelle le faux multi-tâche.

C’est pourtant expliqué dans la première phrase de la doc… (je commence à me poser des questions sur votre bonne foi)

“spawn

The parent process starts a fresh python interpreter process."

Cet appel démarre un nouvel interpréteur. Si il y a plusieurs interpréteur, nécessairement, ils s’exécutent en parallèle.

Encore une fois, je ne nie pas l’intérêt des scripts mais je ne trouve pas sérieux d’utiliser les languages de script, fusent-ils compilés à la volée ou non, pour des projets d’envergure. Ce que l’on reproche très régulièrement aux gros programmes écrits en java, peu importe la version de ce dernier, c’est la consommation énnorme de mémoire et de ressources processeur pour pas grand chose. C’est pareil pour les amoureux du javascript qui voudraient s’en servir pour tout. Le débat dans ces cas là n’est pas de grater un poil de c*l de perf mais d’arrêter de mettre les machines à genoux par des programmes basés sur des mauvais choix de languages.

Le manque de discernement est plutôt à chercher chez les promoteurs du javascript à toutes les sauces.

Perso, je n’envisage le javascript que côté client, là où il est adapté au besoin.

On en revient au même problème : la qualité, ça se paye. Avoir des programmes correctes qui répondent bien aux besoins (souvent farfelus) de ceux qui les demandes, ça prend du temps et de l’argent.
Quand on a pas de temps ni d’argent, ça donne des résultats de mauvaise qualité et le langage n’est pas à blâmer la dedans.

Je ne peux que vous conseiller de vous intéresser de plus prêt à ce qui se fait ailleurs et les raisons qui ont poussé ces gens à faire ces choix.
Pourquoi Node a été créé alors qu’il existe déjà d’autres solutions ?
Pourquoi Typescript alors qu’il existe déjà d’autres langages typés ?
Pourquoi Go (qui se base sur l’utilisation d’un garbage collector d’ailleurs) alors qu’il existe déjà C++ ?
Pourquoi Java alors qu’il existe déjà C++ ?
Les gens qui font et utilisent ces choses ont certainement de bonnes raisons de les faire vu la taille ces projets et le succès qu’elles rencontrent.

J’ai le sentiments que vous êtes très fermé à ces nouveautés pour des raisons qui ont l’air plus idéologique ou à cause d’idées reçues que réellement techniques (sans jugement de valeur, c’est ce que je ressens en lisant votre message).

Il est parfaitement possible de faire une API Rest d’envergure tout à fait viable et performante avec Node (le combo Typescript/NestJS est d’ailleurs vachement bien)
Il est parfaitement possible de faire une interface utilisateur en java performante (voir Android)
Il est parfaitement possible de faire du multi-thread en Python
Il est parfaitement possible de faire un programme tout pourri qui rame et qui bouffe toutes les ressources en C++ ou en Rust

La faute n’en revient pas a l’outil mais à celui qui l’utilise mal.

Le 25/02/2022 à 07h 25

wanou a dit:

Merci pour cette critique construite. Je vais essayer de mon côté d’étayer un peu mes propos.

Au plaisir, je vais tâcher de faire au moins aussi bien

Basiquement, les languages de script permettent de coder très rapidement des programmes mais ce qui fait leur souplesse constitue également leur talon d’achile. J’ai cité la compilation en exemple car l’interprétation, même sous forme de bytecode, ne remplacera jamais du code natif en terme de vitesse d’exécution. On peut cependant arger que même les processeurs x86 pratiquent l’interprétation mais c’est un autre débat.

Encore une fois, l’utilisation classique de Java, c’est de le compiler via javac pour produire un bytecode et de donner ce dernier à la JVM qui va le compiler à la volée en natif.
Il en est de même pour le javascript (si il tourne dans V8 au moins et il me semble que le moteur JS de mozilla aussi).

Dans énormément de cas, la vitesse d’exécution n’est pas le problème. Faire une API ultra optimisé a l’infini, ça a peut être utile si elle doit servir des millions de requêtes à la seconde mais ça n’arrive pas si souvent que ça. Dans l’immense majorité des cas, le facteur limitant est de toute façon ailleurs (réseau, disque, parfeu par exemple) et le programme passe son temps à se tourner les pouces.

Quand je dis “sérieux”, je pense aussi à la capacité de tel ou tel language à se préter à des projets d’envergure. C’est ma définition de logiciel. Dès lors, l’absence de typage fort rend souvent les choses complexes avec les languages de script où des problèmes d’intégration surviennent en partie à cause de cela.

Chaque outil a ses avantages et ses inconvénients, bien sûr. Personne n’a jamais prétendu qu’un outil était parfait dans toutes les situations (et si quelqu’un l’a fait, il se trompe).

Le paradigme objet aide il est vrai à l’intégration mais les grand principes de la POO ne sont pas tous bien implémentés. Java par exemple qui se pose en référence en la matière ne gère même pas l’héritage multiple. C’est risible je trouve. Ceux qui ne voient pas en quoi cela est important peuvent regarder le fonctionnement de Qt pour y voir une utilisation massive de l’héritage multiple.

Je ne crois pas que Java ai déjà prétendu être la référence des langages objets.
Depuis Java 8, il est possible d’hériter de plusieurs interfaces.
Je ne connais pas assez Qt pour en parler mais il est tout à fait possible (et même assez simple) de faire de très belles et fluides interfaces utilisateurs en Java, par exemple sur Android. (note : je ne dis pas que toutes les applications Android ou java sont bonnes, je dis qu’il est tout à fait possible de faire des choses biens). Donc à moins d’avoir mal compris, le fait que Qt utilise massivement l’héritage multiple n’est pas une condition nécessaire à faire des choses biens.

Enfin, je ne considère pas comme sérieux un language pour lequel la gestion de la mémoire n’est pas accessible au programmeur. Le comportement du ramasse-miettes et la gestion globale de la mémoire de java rend impossible tout contrôle des latences des intefaces utilisateurs et c’est la raison pour laquelle je trouve qu’élever java au rang du c ou du c++ est malhonète. La consommation de mémoire élevée est une caractéristique forte des languages interprété même si j’arrive à faire des traitement assez dingue sur des tables de données d’un milions de lignes en mémoire en perl.

La mémoire est toujours accessible par le programmeur. Faire un new en Java ou en C++ va bien provoquer une allocation mémoire. Déclarer une variable en javascript via bien créer une entrée dans la pile. Même en Prolog la mémoire est accessible au programmeur.
J’imagine que vous voulez juste parler de la libération de la mémoire et même dans ce cas là, ça se discute.
Est-ce que Rust est mauvais car on ne libère pas la mémoire à la main ?
Est-ce que Java est mauvais car on ne libère pas la mémoire à la main ?
Est-ce que C++ est mauvais quand on l’utilise avec une library de garbage collection ? (https://v8.dev/blog/high-performance-cpp-gc)

Bien sûr que non et je ne comprends pas du tout ce genre de remarque que je trouve très élitiste en plus d’être fausse (confusion entre le langage et l’implémentation).
La bonne manière de choisir et d’utiliser un outil, c’est d’en comprendre les tenants et les aboutissants. Si l’utilisation d’un garbage collector pose problème lors de l’exécution, alors il faut envisager de s’en passer. Si gérer la libération de la mémoire à la main pose problème, il faut envisager de laisser un outil s’en charger.

Pour enfoncer le clou, la gestion du multi-tâche est devenu une caractéristique importante et j’ai été très déçu récement quand en tentant de me mettre au python, j’ai constaté qu’il n’était pas réentrant et que de ce fait, un programme python ne sais pas utiliser plus d’un coeur d’exécution.

Il est possible de faire du multithread en python : https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods =>
“spawn

The parent process starts a fresh python interpreter process.

fork

The parent process uses os.fork() to fork the Python interpreter."

Sur ce thème, j’ai été ému en lisant le tuto sur rust et j’ai commencé à m’y mettre car je consisère ce langage comme une base très solide pour construire de belles choses légères, rapides. Le rust apporte un sacré coup de jeune aux languages compilés et redonne de l’intérêt à ce type de programmation. Là où j’aurai peut-être choisi perl ou python pour une api rest que j’ai commencé, j’ai chosi de la faire en rust avec la bibliothèque rocket et cela est prometteur.

Je n’ai pas grand chose à dire là dessus, je suis d’accord pour dire que Rust apporte des nouveautés bienvenues et que c’est un langage qui mérite de l’intérêt.

D’une manière général, je trouve votre discours trop dichotomique. Soit c’est bien, soit c’est pas bien mais il n’y a pas d’entre deux. Or l’informatique, c’est avant tout des compromis.

Et en parlant de compromis, je dirai que vous omettez une chose : le prix.
Le nerf de la guerre, c’est l’argent.
Faire de l’optimisation mémoire de poil de cul en C++, c’est une chose. Le faire en un temps raisonnable et avec un coût raisonnable, c’en est une autre.
Ensuite la maintenabilité entre en jeu. Qui peut maintenir les programmes optimisés au poil de cul ? A quel coût ?
Et donc la question ultime : est-ce que ça en vaut le coût ? (pour les pinailleurs, je sais qu’on dit “coup” mais il est littéralement question d’argent ici)
La réponse a cette dernière question est évidemment a la discrétion de chacun et c’est pourquoi dire d’un outil qu’il est mauvais de façon univoque alors qu’il répond précisément a certaines problématique est, selon moi, une erreur.

Le 23/02/2022 à 13h 41

Ça permet de retrouver tous les avantages de l’interprété.

Le use case classique, c’est d’être facilement cross-platform.
Le code à exécuter reste le même partout et il suffit d’implémenter un interpréteur pour les plateformes qu’on veut supporter.

Un autre use case peut être de sauter la phase de compilation pour passer directement à l’exécution et donc gagner du temps de développement. C’est d’ailleurs ce qu’ils expliquent sur le lien que j’ai donné :
“For some tasks, C and its compile/ link/execute/debug process are not productive. As computer hardware becomes cheaper and faster, to be productive and cost effective, script computing in C/C++ can be an appealing solution”

Je ne rentrerai pas dans le débat “c’est nul ou c’est bien”, ce n’est pas le sujet.

Le 23/02/2022 à 11h 32

Un langage ne définit jamais son mode d’execution, simplement sa syntaxe et sa sémantique. Il n’est écrit nul part dans la spec ECMAScript que le code ne peut pas être compilé ou qu’il doit être executé par un interpréteur.

Par exemple :

• du Java peut être compilé par le compilateur javac.


• du Javascript peut être réellement compilé si le moteur utilisé est V8. https://v8.dev/docs => “V8 compiles and executes JavaScript source code”. V8 est le moteur utilisé par Node ou par Chrome entre autre donc des projets très sérieux.


• du C peut-être interprêté : https://www.drdobbs.com/cpp/ch-a-cc-interpreter-for-script-computing/184402054 => “Ch is a complete C interpreter that supports all language features and standard libraries of the ISO C90 Standard”

Bref, la définition de script ou pas script n’est pas si évidente que ça.

Dans tous les cas, la définition de logiciel est :
“En informatique, un logiciel est un ensemble de séquences d’instructions interprétables par une machine et d’un jeu de données nécessaires à ces opérations.”

Donc même le script le plus basique est un logiciel et il n’y a aucune escroquerie technique là dedans.

Le 17/01/2022 à 16h 28

(reply:1924390:127.0.0.1)

L’équipe en charge déclare deux choses :

• “la base de données sur laquelle l’algorithme était entraîné était biaisée”
  => Les données étaient biaisées et il était donc impossible d’en tirer un résultat satisfaisant





• “le projet a été accueilli pour le moins froidement par les professionnels du droit”
  => On peut en conclure que pas grand monde dans le milieu n’était chaud pour continuer à mettre des ressources sur ce projet

Deux très bonnes raisons d’arrêter les frais.

Si vous avez d’autres informations sur ce qui s’est passé, donnez-les mais les insinuations malveillantes sans fondements sont malvenues.

Le 17/01/2022 à 13h 28

Y’a pas de magie, il faut bien que quelqu’un l’écrive, l’algo en question. Or là, ils ont jugé que c’était trop compliqué d’écrire quelque chose qui aurait des résultats satisfaisants surtout si les données de bases sont biaisés.
Vu le domaine touché, j’imagine bien toute la complexité que peut prendre ce genre de projet.

En gros, pour l’instant ils sont faces à un mur donc ils stoppent. Je trouve ça assez légitime pour le coup.

Le 14/12/2021 à 10h 02

Pour être tout à fait précis, FranceConnect n’est ni plus ni moins qu’une implémentation d’OpenId Connect, lui même étant une surcouche à OAuth2.
D’ailleurs ils proposent même un plugin Keycloak sous licence MIT très correctement documenté. Pour une fois qu’un projet de ce style repose sur une base standard et solide, je trouve très malvenu de cracher dessus comme certains le font.

Le 25/11/2021 à 10h 33

(quote:1914578:Trit’)
DDG utilise l’index de Bing, donc oui : si Bing déréférence Wish, DDG va par conséquent être aussi concerné (et d’ailleurs, je crois qu’il fait partie des moteurs ayant reçu l’injonction).

Des moteurs qui ne déréférencent rien ? S’il y en a (et on parle de vrais moteurs avec leur propre indexeur, pas juste des surcouches utilisant l’indexeur des autres, tels StartPage, DDG, Ecosia, Qwant…), ils doivent être tellement confidentiels (parfois parce que payants, comme Neeva) que seule une niche doit les connaître.

DDG n’est pas juste une sourcouche à Bing. Une minute de recherche suffit pour trouver l’information.

Le 19/11/2021 à 11h 59

Je pense que tout le monde y gagnerai à faire preuve de rigueur dans les commentaires, surtout sur des sujets clivants comme celui-ci.
Choisir des valeurs arrangeantes et citer des sources du calibre de celle-là, ce n’est pas rigoureux.

Sur ce, je ne me prononce pas sur le fond du débat du coût d’un fonctionnaire, je ne connais pas assez le sujet.

Le 19/11/2021 à 11h 11

Le site en question “évalue” le coût sur 73ans, pas sur 40.
Ce site omet de comparer avec un salarié du privé.
Ce site donne des chiffres conditionnels : “Si un fonctionnaire gagne XY alors …”. Rien n’est dit sur les chiffres réels.

La source du site (Le Point) utilise une rhétorique bien connue pour ne pas justifier ses propos du type “Tout le monde sait que …”. Je cite :
“On sait que les fonctionnaires, par rapport au privé, […]”. Ce n’est pas sérieux.

La deuxième source pointe vers le site fonctionea.fr sans préciser sur quels articles précisément ils se sont basés et en quoi cela appui leur propos. Ce n’est pas sérieux non plus.

Cet article est au mieux inutile, au pire mensonger et trompeur et n’a dans tous les cas pas plus de valeur qu’une discussion de comptoir.

Le 26/10/2021 à 08h 11

J’ai été facteur dans une petite ville il y a une dizaine d’année. Ma tournée comportait aussi bien du courrier que des colis de tous types (de la lettre papier-bulle de 5g jusqu’à la tondeuse complète de 30kg, qui est la limite max). Toutes les tournées de tous le bureau à au moins 40km aux alentours fonctionnaient identiquement.

Les seuls endroits que je connaisse qui n’appliquent pas ce système sont les grandes villes.

Le 16/10/2021 à 06h 18

Idem ici. J’ai un dual screen 1440p 144hz en displayport avec une 1070. Sur X11, c’est fluide. Sur Wayland, j’ai l’impression d’être à 60Hz tellement ça saccade.

En regardant les notes de version et en creusant un peu la doc, le support de Wayland avec une CG Nvidia est annoncé comme “disponible” seulement (pas “Optimal” donc) et que les choses commenceront à être correct avec les driver 495 qui devraient être disponible d’ici quelques semaines.

Le 15/09/2021 à 12h 01

Je tente également, sait-on jamais !

Le 03/09/2021 à 13h 54

Je suis complètement en phase avec ça et je suis le premier à critiquer (au sens noble) les choix techniques.

En relisant tout notre échange, je me rends compte que je n’ai cité que toi, (j’ai tilté sur le coup de la rocket science, que j’ai peut-être mal interprété d’ailleurs ?), et je me suis un peu emporté mais le ressenti que j’ai eu en lisant les commentaires, c’était “ils sont cons, ils font tel techno, ce ne sont pas de vrais devs”.

Le 03/09/2021 à 11h 15

KP2 a dit:

Désolé de partir du principe que les devs ne sont pas des tanches… je ne sais pas si tu essayes vraiment de les defendre là

Je n’essaie de défendre personne et je n’ai pas non plus dit que les devs étaient des tanches. Je dis que l’argument “Moi je sais mieux parce que j’ai de la bouteille” n’est pas un argument recevable, surtout sur internet.

C’est toi qui les excuse en disant qu’ils sont probablement trop nuls pour savoir ce qu’ils font…

Je n’ai rien dit de tel. Merci de t’en tenir à mes propos et de ne pas en inventer.
Et les excuser de quoi ? Pour quelle faute ? D’avoir fait des choix techniques ?

Ben justement, ils ne disent pas pourquoi ils ont fait ce choix. Et j’ai du mal a avaler l’histoire du budget contraint ou du manque de compétences.

Que tu ai du mal à l’avaler ou pas, peu importe. Et je n’ai pas dit que c’était la raison qui les a poussé à faire leur choix et je ne dis pas non plus que leur choix est bon ou mauvais (car je ne sais pas pourquoi ils l’ont fait). Je dis que les jugements à l’emporte pièce sur base de rien, c’est malvenu et ça caractérise les experts en tout (mais surtout en rien).

Le 03/09/2021 à 09h 54

D’abord, ton argument d’autorité n’a aucune valeur. Des devs avec 20 ans de bouteille qui ne font pas mieux que des débutants, j’en croise régulièrement.

Ensuite, tu reconnais ne rien connaître du contexte de développement de leur logiciel mais tu te permets de les juger.
Note que je ne dis pas que tu as tort sur le fond. Qu’ils aient choisis ça par effet de mode ou à cause d’un budget limité ou autre, j’en sais rien et toi non plus. Je dis que tu as tort sur la forme (et dans la démarche).
Un peu de bienveillance, pitié.

Plutôt que de les dénigrer car ils ont fait un choix qui ne te plaît pas, essayes de comprendre pourquoi ils l’ont fait, c’est bien plus important et intéressant (et peut-être, un jour, admettre que c’était pas si bête que ça compte tenu du contexte en fin de compte).

Le 03/09/2021 à 06h 32

Ben si… Connaître sur le bout des doigts chaque spécificité de chaque API de chaque OS (en se mettant à jour en permanence bien sûr), c’est compliqué, même quasiment impossible.

D’autant que dans toutes vos élucubrations, vous oubliez le nerf de la guerre. Combien de budget alloué pour développer les applications en question ? Tous vos fantasmes d’optimisation, d’efficacité, de sécurité et j’en passe dépendent presque exclusivement de ce paramètre, que vous ne connaissez pas.
Cracher sur celui ou ceux qui ont pondu une appli sans connaître ni les contraintes imposées, ni le temps, ni le budget, ni le personnel alloué, c’est digne des experts en tout genre qui pullulent sur Facebook et Twitter.

Donc dire “lol c’est facile”, c’est non. C’est pas facile. Prendre les autres pour des crétins, ça c’est facile.

Le 30/06/2021 à 15h 54

carbier a dit:

Dassault n’as pas attendu le vote électronique. C’est fascinant cette proprentsion à imaginer les pires choses: pour le vote papier qui te dit qu’il n’y a pas une caméra avec reconnaissance faciale dans l’isoloir ?

Ce n’est pas le sujet de ma réponse. Je répondais à l’affirmation erronée “id unique anonyme pour vérification à posteriori => coercition impossible”.
Sur le fond, je suis d’accord avec le fait que le vote papier n’élimine pas totalement ce problème.

Le 30/06/2021 à 12h 11

Si tu peux prouver le contenu de ton vote une fois l’élection terminée alors on peut te mettre la pression pour que tu fournisses cette preuve. Il peut donc y avoir coercition.

Le 24/06/2021 à 12h 14

Si tu as 10 images qui se basent sur la même image de java, tu as une seule copie.
Si tu as 10 images qui se basent sur 10 images de java différentes , tu as 10 copies du JRE.

Les containers marchent par couche. Les couches ne sont jamais dupliquées.

En clair, si tu as 50 images qui commencent par exemple par :
FROM openjdk

alors tu as une seule fois openjdk sur ton disque, y compris au runtime.

Le 24/06/2021 à 07h 29

Effectivement, dit comme ça, je comprend mieux ce qui te pose problème.
Je nuancerai juste ton propos en rappelant que les systèmes de packaging ne font pas de magie : il exécutent des scripts qui ont été écrits spécifiquement pour eux et pour chaque package.
Si le logiciel X fait une migration de données automatiquement, c’est bien qu’un script a été écrit spécifiquement pour ce logiciel et qu’il est exécuté (par le système de packaging ou pas).
La difficulté actuelle, c’est qu’il faut re-écrire les scripts pour les adaptés au système de containers.

Et je nuancerai aussi la question de la duplication de dépendance. Si plusieurs containers se basent sur la même image de base, cette image de base n’est pas dupliquée sur le disque (ni les couches intermédiaires en fait). Si tu lances 90 containers MySQL sur la même machines, tu n’as pas 90 fois l’image dupliquée.

Et pour rebondir sur la niouse, ce système permet du coup de très facilement mettre à jour les dépendances car on n’a pas à se soucier de savoir si ce qu’on va modifier va être compatible ou pas avec ce qui est déjà déployé. (Oh non, je peux pas mettre javaX IBM car JavaX Oracle est déjà présent, oh non, c’est openSSL N qui est installé et on a besoin de openSSL N+1, etc)

Le 23/06/2021 à 16h 51

Ce problème n’est pas lié aux containers et dans le pire des cas, il n’y a ni problème ni difficulté à appeler manuellement un script qui se situe à l’intérieur du container.
Quelques logiciels gèrent d’ailleurs eux même les migrations lorsqu’un container est déployé, comme Nextcloud par exemple.

Le 23/06/2021 à 15h 34

Les volumes répondent précisément à cette problématique.

Le 18/05/2021 à 09h 32

(reply:1874091:Trit’)

Ces valeurs (192kHz, 44,1Khz, etc) sont les fréquences d’échantillonnage donc il faut diviser par deux pour avoir la fréquence max échantillonnée.

Le 17/05/2021 à 19h 24

Serait-ce la journée de la diptérophilie ?

Le 17/05/2021 à 17h 22

Inodemus a dit:

C’est sûr que par définition, c’est plus dangereux, mais l’utilité n’est pas la même non plus, et on limite cette dangerosité justement en limitant leur portée. Les variables locales ne deviennent pas null toutes seules, puisque c’est local, on voir facilement où et quand elles peuvent être modifiées, à l’inverse des variables plus globales où c’est beaucoup plus dur et source d’erreurs.

C’est justement là qu’est le truc. Le meilleur moyen de signaler quelles valeurs peuvent être modifié, c’est de rendre toutes les valeurs non-modifiables par défaut et d’ajouter un mot clef précis qui signifie “le code a été conçu avec le fait que cette valeur soit une modifiée”.
Donc avec cette pratique, tu te protèges toi même des erreurs de programmation et tu aides les autres à comprendre ton code.

Je ne trouve pas l’analogie correcte vu que je parle de variables locales, alors que les access que tu cites sont plutôt globaux dans le sens où n’importe qui qui a une référence peut les utiliser, c’est pour ça qu’on en limite l’accès, parce que la portée est plus grande.

Les comparaisons sont toujours un peu limitées pour argumenter, c’est sûr. Mais les cas d’usages sont un peu similaires : quand quelqu’un va utiliser ou repasser sur ton code, il faut qu’il comprenne le plus rapidement possible comment a été conçu ce dernier.
Donc l’effet est double : tu sécurises ton code contre tes propres erreurs (en te forçant à réfléchir à si oui ou non tel ou tel valeur doit être modifiée) et tu le rends plus explicite, plus auto-descriptif, ce qui aide les autres à comprendre ce que tu as fais.

On peut s’en passer, mais ça ne me paraît en rien être une obligation, ni même être meilleur, ni systématiquement plus clair, juste différent, un peu comme le récursif contre l’itératif, ou simplement les différents paradigmes de programmation. Ca dépend du problème posé, des traitements à faire à chaque itération, et de l’impact en performances des API que tu cites (qui peut exister ou pas et dépend de leur implémentation ainsi que de la puissance disponible). Mais j’imagine que c’est effectivement ce qui est encouragé ici.

On est bien d’accord sur le fond. A moins d’avoir des contraintes particulières, la clarté et l’homogénéité du code est plus importante que le reste (y compris les performances). D’autant qu’il y a autant de bonnes pratiques que de programmeurs.

Le 17/05/2021 à 11h 15

Inodemus a dit:

Ca dépend franchement de sa portée. Et il y a rarement besoin de déclarer des constantes au niveau local, le plus souvent les constantes utilisées à ce niveau sont déjà déclarées (en constante du coup) à un niveau plus global.

Non, ça ne dépend pas de sa portée, une variable est par définition plus dangereuse qu’une constante car son contenu peut changer et donc passer par des états anormaux (null pour ne citer que le plus connu, avec les fameux NullPointerException qui font toujours plaisirs).

C’est un peu comme les access modifiers. Rien ne t’empêche de tout mettre public et charge à celui qui utilise ce que tu as fait de pas faire de conneries.

Euh, je suis pas sûr qu’on désigne la même chose avec le terme variable. Moi je penses surtout aux variables locales à une fonction, qui sont finalement les plus nombreuses avec la plus petite portée. Je vois pas bien comment on peut s’en passer, la moindre boucle for en a déjà une et n’est qu’un cas parmi d’autres, et ne parlons pas des fonctions où il y a un minimum d’algorithmique.

On parle bien de la même chose. Comme l’a dit BarbossHack, dans biens des cas, les variables ne sont pas utiles.
En changeant un peu de paradigme, on s’en passe très facilement. Arrêter de faire des boucles for et utiliser les api de programmation fonctionnelle disponible dans plein de langages par exemple (.filter(), .map(), .reduce(), etc). Je suis bien conscient qu’il y a des cas où ce n’est pas possible de s’en passer mais souvent, on peut. En plus le code est plus clair.

Le 17/05/2021 à 09h 53

C’est une question de bonnes pratiques. Une variable est plus dangereuse qu’une constante.
C’est un peu comme sudo sur linux. Ça ne sert qu’a t’indiquer que ce que tu es en train de faire peu avoir de grosses conséquences.

En plus, dans les langages récents (j’inclus java 8 dedans), les variables ne sont pas souvent utiles au final.

Le 16/04/2021 à 16h 04

(quote:1868051:brice.wernet)
Et pourquoi un protocole HTTP qui ne maintient pas ses connexions, forçant à créer des mécanismes complexes et coûteux (et qu’il a fallu sécuriser au fur et à mesure des années) pour conserver une session utilisateur, un peu au hasard, pour voir s’il relance une requête dans les 20 minutes???

Quels mécanismes coûteux et complexes ?

Le fait qu’HTTP ne maintienne pas les connexions permet de créer des applications qui supportent bien mieux la charge et surtout permettent plus facilement d’assurer la scalabilité. Je dirai même que c’est le principe de maintenir une connexion ouverte qui est coûteux et complexe (en plus de ne servir à rien 99% du temps).

Pour la question de maintenir une session ouverte, c’est la même raison qu’au dessus : ça sert à rien, ça consomme de la ressource, c’est complexe et ça empêche la scalabilité (les sticky sessions dans un cluster par exemple).
Un mécanisme comme JWT répond bien mieux à ce besoin là et est moins complexe.

Comme toujours, il y a des exceptions mais en général dans le cas du web, faire du stateless, c’est mieux que de faire du statefull.

Le 09/04/2021 à 15h 14

De très bonnes solutions permettent de faire du streaming musique/film/etc auto-hébergé, quasiment clef en main et même presque gratuitement. Plex, Emby et Jellyfin pour les plus connus. Un petit coup de docker par dessus pour ne même pas avoir à gérer l’install et pour pouvoir faire les updates facilement et ça tourne presque comme par magie.

Évidemment, il faut avoir la connexion internet à domicile qui va bien.

Le 26/03/2021 à 17h 51

Précisément, contrairement à une VM, un conteneur Docker ne tourne pas de manière isolée indépendante de l’OS hôte.
Du point de vue du conteneur, il y a de l’isolation mais du point de vue l’hôte, il n’y en a pas. Pour s’en convaincre, il suffit de lancer un conteneur quelconque et de faire un “ps -aux” sur le système hôte. Le processus du conteneur apparaîtra dans la liste. Ce n’est pas le cas avec une VM.

Et on peut tout à fait faire tourner un OS complet avec Docker. Il existe des images Ubuntu/Fedora/etc.
Ce qu’on ne peut pas faire tourner avec Docker, c’est un noyau à part. Car par définition, il se base sur le noyau de l’hôte pour exister.

A contrario, une VM utilise son propre noyau.

Le 26/03/2021 à 17h 14

Docker, ce n’est pas de la virtualisation.
Docker utilise les outils à sa disposition pour isoler les processus comme les cgroups ou apparmor mais il n’y a pas de virtualisation d’une quelconque manière derrière ça.

En tout cas il est clair que Docker n’est pas du tout conçu pour faire ce que Shadow propose (bien que quelqu’un ai créé une image qui contient doom et qui est conçu pour être connecté en ssh avec x11 forwarding mais ça tourne à 2fps, même avec une bonne machine)

Le 23/02/2021 à 17h 36

Le gros point noir de Bitwarden et qui n’est pas mentionné dans l’article, c’est qu’une fois un élément partagé avec une organisation, il n’est plus possible de le départager. Le mot de passe appartient à l’organisation et le seul moyen de supprimer le partage, c’est de supprimer complètement l’élément. A utiliser avec précaution donc.

Le 17/02/2021 à 11h 03

Bien sûr, le fait de faire tourner le logiciel sur ton propre matériel ne le rend pas gratuit. Ce qui coûte cher dans ce cas précis, c’est de développer, pas d’héberger.

Le principe est le même pour énormément de logiciels. (Oracle ou IBM ne me contrediront pas)

Concernant le conteneur en lui même, il ne respecte pas quelques unes des bonnes pratiques de docker. Il contient plusieurs processus (la DB, le logiciel de gestion, le serveur web et probablement d’autres que j’oublie) et je pense que c’est pour ça qu’il est aussi gourmand.

Le 17/02/2021 à 10h 49

Tu peux auto-heberger Bitwarden même en version gratuite.

edit : en fait la question n’est pas ça mais plutôt :
Tu peux utiliser bitwarden en version gratuite même sans l’auto-heberger.

Le 15/01/2021 à 07h 29

(quote:54550:brice.wernet)
Tu dois pouvoir limiter les perfs et la vitesse maxi du ventilateur dans le BIOS. Les NUC permettent de mettre le curseur un peu où on veut (y compris sur la balance CPU/GPU si on est en headless)

Je m’en sers comme serveur (Debian + 100% des services sous docker) donc les moments où il turbine vraiment sont rare. En fait pour l’instant, ça n’arrive que quand le serveur minecraft redémarre

Le 14/01/2021 à 14h 38

J’ai un NUC8i5BEH2 équipé d’un SSD NVMe. A faible charge, il est absolument silencieux. Par contre dès que la charge monte, le ventilateur se mets à souffler très fort et il n’est vraiment plus silencieux du tout.
Il est chez moi en bas des escaliers et je l’entend à travers une porte fermée (quand il souffle, sinon il ne fait aucun bruit, même avec l’oreille collée dessus).

Le 08/05/2020 à 10h 02

A ma connaissance quand le téléphone inite un stream, il envoie simplement une petite appli html/js/css au chromecast pour initier l’affichage de ce qui va être streamé. Ensuite il y a deux cas :

 

• le contenu est local (tes photos persos sur ton téléphone) : c’est bien le téléphone qui fournit la data a afficher. Par exemple si tu affiches les photos présentes directement sur ton téléphone.
  


• le contneu est en ligne (netflix et compagnie) : c’est le téléphone qui initie le chromecast en lui disant ce qu’il doit aller chercher en ligne. Par exemple quand tu lances netflix, le chromecast se connecte sur internet aux serveurs de netflix et va chercher le flux vidéo dont il a besoin sans passer par ton téléphone. D’ailleurs ce comportement peut se vérifier facilement : tu lances un stream netflix sur ton chromecast et tu éteins l’appareil qui a initié le stream (ou tu coupe le wifi). Le chromecast continuera à streamer la vidéo (en tout cas dans mes souvenirs, ça marche comme ça).

Le 20/04/2019 à 11h 07

C’est simple : les ordis calculent 1 000 fois plus vite qu’avant mais

font 2 000 fois plus de choses. Donc ça prend plus de temps. Et comme c’est relativement bien fait, à part le temps de calcul, tout est invisible aux yeux des utilisateurs (qui s’empressent de ne pas comprendre et de râler).

Pour les temps de maj, il est toujours plus simple de recréer un système de 0 plutôt que d’en modifier un.

 

Ca se vérifie très bien dans d’autre gros logiciels genre SAP qui comporte plusieurs centaines de tables et pèse plusieurs centaines de Go pour une installation fraiche (de tête, ce ne sont pas des chiffres exacts). La philosophie dans ce genre de logiciel étant : c’est trop dangereux de supprimer ou modifier l’existant donc on ne modifie ou on ne supprime jamais. On ne fait que rajouter.

J’imagine facilement le merdier que ça doit être de gérer un OS comme Windows ne serait-ce que pour assurer la retro-compatibilité avec les vieux logiciels.



Donc plutôt que de passer du temps à optimiser l’espace disque ou la consommation de ram qui ne sont plus vraiment problématiques aujourd’hui vu les capacités du matériel, on optimise ce qui coûte le plus cher : le temps de dev.

Une équipe complète (chef de projet, développeurs, testeurs, consultants en sécu), c’est, pour les moins chères, 400€ par jour et par personnes et ça monte souvent à plus de 1000€ jour/homme.

Donc il suffit de compter : pour une équipe de 6-8 personnes, on peut compter 4-8000€/jour/homme au bas mot.



Tu serai prêt à payer combien pour que Windows consomme moins de ram ? Ou les pilotes de ta carte graphique ? Ou que sais-je ?

Les acheteurs ont parlés, et ils ne sont pas prêts à payer tout ça quand un simple upgrade de machine suffit.

 

Le ratio prix/résultat est simplement trop faible pour que ce soit intéressant.

Le 27/06/2018 à 15h 40

Est-ce qu’il serait possible d’ajouter un filtre en haut de page qui permettrait de masquer les offres avec ODR ? Comme ça tout le monde y trouverai son compte.



Grillé.