Oui, c'est ça qui est génial. Et je trouve dommage de ne pas avoir ce genre de puissance dans un langage compilé.
Je n'ai pas non plus parlé des Hooks que je trouve totalement génial car on remplace des classes et des High Order composant illisible par… des appels de fonctions tout simple !
Vu que tout ça est implémenté en Javascript, cela doit pouvoir se faire en autre chose.
C'est l'api qui te fait croire cela et qui simplifie tout.
Par contre, en vrai, il utilise la techno du "shadow DOM", ou il reconstruit un DOM, fait un "diff" et ne met à jour que les parties intéressantes. Je pense aussi qu'il fait une liaison entre l'object graphique généré et ses entrées, si l'entrée bouge, la fonction est relancé.
L'appli maintenable par un stagiaire, je n'y crois pas trop. L'avantage est justement de ne pas avoir le bordel de dépendance dans tous les sens. Cela ne se voit que sur des applis un peu grosses et/ou dynamiques.
La lourdeur de react&Co, c'est la techno web derrière, pas le concept de programmation.
Est-ce que ce genre de lib 2d peut servir de fondation à une structure imitant react ou vue ? en gros, les widgets seraient vue comme le DOM du navigateur web.
L'idée est vraiment de coder des appels de fonctions avec des entrées, et le framework appel la fonction à la demande, pas en passant par en dessous, avec tous les effets de bord de la terre imaginable.
Redux rajoute un cycle d’événement qui modifie l'état global qui ensuite modifie le rendu complet (le tout optimisé par le framework en dessous).
J'ai l'impression qu'il sont parti sur des interfaces "à l'ancienne" avec les call-back back de l'enfer.
Depuis que j'ai développé avec React (mais Vu.js, ELM, angular, sont pareil), c'est difficile de revenir en arrière.
Le principe de ces toolkit est d'avoir des fonctions qui retournent des éléments graphiques selon des entrées (que l'on peut cascader). Des setters sont transmis en profondeur pour modifier l'état global de l'application (ce qui génère un événement pour redessiner la partie concerné automagiquement). C'est beaucoup plus simple à écrire que de savoir quoi modifier selon l'action.
Dans les toolkit graphique, tout redessiner est très couteux, on gère donc des modifications qui deviennent un enfer à tenir cohérent.
J'ai eu une stagiaire, que je devais limite engueulé pour la pousser à ne pas se dévaloriser ("Si je n'étais pas meilleur que toi, à quoi bon avoir 20 ans d'expérience" "Tu apprends, là")
C'est moi où les filles sont souvent victime du syndrome de l'imposteur ? Je me rappelle d'une amie qui se sentaient toujours non pertinente pour devenir leader technique sur le sujet dans son domaine pointu qu'elle pratique depuis 10 ans…
"Tout d’abord, la consommation électrique n’est pas égale à la consommation énergétique. "
25% de l'énergie est électrique, le reste c'est le pétrole des véhicules et du chauffage.
"Aux Etats-Unis, les postes électriques ont un rendement moyen d’environ 30 pourcents. "
euh… J'imagine qu'il est question du rendement de centrale thermique 30% à 50% de l'énergie primaire convertie en électricitié.
"Ainsi, en multipliant dans un premier temps tous les chiffres par 3, on obtient une représentation un peu plus réaliste de la consommation d’énergie réelle de nos équipements électroniques."
oui mais on s'en fout.
"Ensuite, un autre point, trop souvent négligé, concerne la consommation d’énergie de l’infrastructure sous-jacente à de nombreuses technologies"
Ce n'est pas oublié, c'est juste négligeable devant les terminaux.
"L’énergie utilisée pour produire tous ces gadgets électroniques est considérablement plus élevée que l’énergie consommée pendant leur fonctionnement."
50 / 50 % pour la production de CO2 en France, pour un produit en chine, cela fait moins d'énergie pour la prod que pour la vie.
" Ceci était, pendant la majeure partie du 20ème siècle, assez différent ; les processus de fabrication n’étaient alors pas aussi énergivores. "
Justement non, un ordinateur prend toujours à peu pret la même quantité à être produite quelques soit sa puissance.
"L’énergie utilisée pour produire tous ces gadgets électroniques est considérablement plus élevée que l’énergie consommée pendant leur fonctionnement."
"l’énergie nécessaire … – est dérisoire comparée à l’énergie consommée durant son fonctionnement, en phase d’utilisation."
"Les voitures actuelles sont désormais bardées de circuits intégrés, de même que plein d’objets qui existaient depuis longtemps sous une forme analogique."
euh… une voiture actuelle consomme 3 ou 4 fois moins de pétrole qu'avant. Une puce c'est en gros un kilo de CO2.
"L’énergie grise d’une puce mémoire excède à elle seule la consommation énergétique d’un ordinateur portable sur les 3 ans de sa durée de vie prévisionnelle. "
Un disque dure était donné pour 45 kg de CO2 d’après greenit, l'équivalent de sa vie.
"Les économies d’énergie réalisées par le numérique seront largement absorbées par sa propre empreinte croissante. "
La VM ne cassera pas. Mais le code aura plus de droit pour faire tourner un code injecté. De plus, c est openbar sur les ressources de l application elle meme.
C'est pas faux. Mais j'ai l'impression que compromettre le service a bien plus d'impact si il est kernel, même en mono-application. L'application peut avoir un nombre de capacité réduite, qui limiterait beaucoup l'effet d'injection de code.
D'une part car il y a pleins de trucs inutiles dans Linux et je ne suis pas certains qu'il soit modulaire à ce point.
De mémoire, make menuconfig donnait une monstrueuse liste d'option de compilation du noyau. Dans le cas d'un noyau pour VM, une grande partie des drivers sont inutiles ainsi que les modules, etc… bref, si, Linux est extrêmement configurable.
D'autre part parce que de ce que je comprends quand tu pars sur ce type de déploiement tu ne veux pas de découpage userland/kernelland.
si tu veux ça tu as tort. Un des principes de la sécurité est la réduction de la surface d'attaque et la réduction de privilège des applications. Comme on ne fait plus tourner de serveur en root, on ne vaut pas d'application en mode kernel ! Tu n'as pas envie de refaire Heartbleed.
Tout est ton appli et si tu ajoute une gestion des droits et les commutations de contexte tu perds beaucoup de performance pour un truc dont tu n'a pas besoin.
C'est vrai en théorie. Mais avoir à la fois le niveau de performance de Linux et son niveau de sécurité est très complexe, et pas prêt d'arriver. Il existe des piles IP coté application très rapide, mais pas sécurisé. Bref, faire mieux que Linux est illusoire à court terme.
L'idée n'est pas de modifier Linux, mais de le configurer "à poil" dans une VM, pour ne faire tourner qu'une seul application, tout en bénéficiant de ses perfs et de sa sécurité.
Oui, c'est le principe des unikernel, sauf que je n'ai jamais vu personne tenté le coup avec Linux complet.
Dans le cas d'une VM, on est sur des méthodes "crash only" pour l'arret. Cela veut dire que l'application tourne ou crash. Donc le kernel panic n'est pas vraiment un problème (sauf peut être pour le debug ou les log), le soft est relancé. concernant la gestion de signaux, je ne sais pas si le runtime go le gère.
Concernant l'acpi, dans le cadre d'une application unikernel, on s'en fout un peu, je pense.
D'ailleurs 70 Mo me parait beaucoup. Un kernel, c'est une dizaine de mega, la libc 6, l'application une dizaine aussi. J'imagine que l'image n'est pas optimisé pour ne tourner qu'en VM et emporte plein de drivers et de dépendance.
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
Oui, c'est ça qui est génial. Et je trouve dommage de ne pas avoir ce genre de puissance dans un langage compilé.
Je n'ai pas non plus parlé des Hooks que je trouve totalement génial car on remplace des classes et des High Order composant illisible par… des appels de fonctions tout simple !
Vu que tout ça est implémenté en Javascript, cela doit pouvoir se faire en autre chose.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 6.
C'est l'api qui te fait croire cela et qui simplifie tout.
Par contre, en vrai, il utilise la techno du "shadow DOM", ou il reconstruit un DOM, fait un "diff" et ne met à jour que les parties intéressantes. Je pense aussi qu'il fait une liaison entre l'object graphique généré et ses entrées, si l'entrée bouge, la fonction est relancé.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 4.
L'appli maintenable par un stagiaire, je n'y crois pas trop. L'avantage est justement de ne pas avoir le bordel de dépendance dans tous les sens. Cela ne se voit que sur des applis un peu grosses et/ou dynamiques.
La lourdeur de react&Co, c'est la techno web derrière, pas le concept de programmation.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
Est-ce que ce genre de lib 2d peut servir de fondation à une structure imitant react ou vue ? en gros, les widgets seraient vue comme le DOM du navigateur web.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 6.
C'est comme les slot de Qt ? On est loin de redux (https://redux.js.org/) ou de l'architecture d'ELM (https://guide.elm-lang.org/architecture/).
L'idée est vraiment de coder des appels de fonctions avec des entrées, et le framework appel la fonction à la demande, pas en passant par en dessous, avec tous les effets de bord de la terre imaginable.
Redux rajoute un cycle d’événement qui modifie l'état global qui ensuite modifie le rendu complet (le tout optimisé par le framework en dessous).
"La première sécurité est la liberté"
# Trop simple ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 7.
J'ai l'impression qu'il sont parti sur des interfaces "à l'ancienne" avec les call-back back de l'enfer.
Depuis que j'ai développé avec React (mais Vu.js, ELM, angular, sont pareil), c'est difficile de revenir en arrière.
Le principe de ces toolkit est d'avoir des fonctions qui retournent des éléments graphiques selon des entrées (que l'on peut cascader). Des setters sont transmis en profondeur pour modifier l'état global de l'application (ce qui génère un événement pour redessiner la partie concerné automagiquement). C'est beaucoup plus simple à écrire que de savoir quoi modifier selon l'action.
Dans les toolkit graphique, tout redessiner est très couteux, on gère donc des modifications qui deviennent un enfer à tenir cohérent.
"La première sécurité est la liberté"
[^] # Re: Go with C
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 4.
C'est uniquement un problème de LGPL, licence qui n'est plus si commune.
"La première sécurité est la liberté"
[^] # Re: Ça m'énerve
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Différences de genres dans la contribution au code libre. Évalué à 4.
J'ai eu une stagiaire, que je devais limite engueulé pour la pousser à ne pas se dévaloriser ("Si je n'étais pas meilleur que toi, à quoi bon avoir 20 ans d'expérience" "Tu apprends, là")
"La première sécurité est la liberté"
[^] # Re: Ça m'énerve
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Différences de genres dans la contribution au code libre. Évalué à 6.
C'est moi où les filles sont souvent victime du syndrome de l'imposteur ? Je me rappelle d'une amie qui se sentaient toujours non pertinente pour devenir leader technique sur le sujet dans son domaine pointu qu'elle pratique depuis 10 ans…
"La première sécurité est la liberté"
[^] # Re: Ça m'énerve
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Différences de genres dans la contribution au code libre. Évalué à 5.
Je me suis dit que l'année suivante, on allait tenter un singe.
"La première sécurité est la liberté"
[^] # Re: Ça m'énerve
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Différences de genres dans la contribution au code libre. Évalué à 4.
un expert il y a quelques années :
"vous vouliez une stagiaire, elle a été nulle : on arrête les frais, l"année prochaine on prend un mec."…
"La première sécurité est la liberté"
[^] # Re: fake news
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Greycess Knight RPG : de la 1.0.0 à la 1.0.1. Évalué à 1.
Parce que c'est un tissu de n'importe quoi : de la bouillie.
C'est long de décortiqué chaque ligne.
"Combien d’énergie nos gadgets high-tech consomment-ils réellement ? "
C'est en gros 50/50 pour les ordinateurs entre production et vie (en France, cf greenit).
"doublé d’ici 2022 et triplé à l’horizon 2030"
2 à 4%, mais 50% pour le chauffage, 20% pour le transport, etc…
https://www.statistiques.developpement-durable.gouv.fr/edition-numerique/chiffres-cles-energie-2021/image/conso-finale-energ-secteur-CGDD.svg
"Tout d’abord, la consommation électrique n’est pas égale à la consommation énergétique. "
25% de l'énergie est électrique, le reste c'est le pétrole des véhicules et du chauffage.
"Aux Etats-Unis, les postes électriques ont un rendement moyen d’environ 30 pourcents. "
euh… J'imagine qu'il est question du rendement de centrale thermique 30% à 50% de l'énergie primaire convertie en électricitié.
"Ainsi, en multipliant dans un premier temps tous les chiffres par 3, on obtient une représentation un peu plus réaliste de la consommation d’énergie réelle de nos équipements électroniques."
oui mais on s'en fout.
"Ensuite, un autre point, trop souvent négligé, concerne la consommation d’énergie de l’infrastructure sous-jacente à de nombreuses technologies"
Ce n'est pas oublié, c'est juste négligeable devant les terminaux.
"L’énergie utilisée pour produire tous ces gadgets électroniques est considérablement plus élevée que l’énergie consommée pendant leur fonctionnement."
50 / 50 % pour la production de CO2 en France, pour un produit en chine, cela fait moins d'énergie pour la prod que pour la vie.
" Ceci était, pendant la majeure partie du 20ème siècle, assez différent ; les processus de fabrication n’étaient alors pas aussi énergivores. "
Justement non, un ordinateur prend toujours à peu pret la même quantité à être produite quelques soit sa puissance.
"L’énergie utilisée pour produire tous ces gadgets électroniques est considérablement plus élevée que l’énergie consommée pendant leur fonctionnement."
"l’énergie nécessaire … – est dérisoire comparée à l’énergie consommée durant son fonctionnement, en phase d’utilisation."
"Les voitures actuelles sont désormais bardées de circuits intégrés, de même que plein d’objets qui existaient depuis longtemps sous une forme analogique."
euh… une voiture actuelle consomme 3 ou 4 fois moins de pétrole qu'avant. Une puce c'est en gros un kilo de CO2.
"L’énergie grise d’une puce mémoire excède à elle seule la consommation énergétique d’un ordinateur portable sur les 3 ans de sa durée de vie prévisionnelle. "
Un disque dure était donné pour 45 kg de CO2 d’après greenit, l'équivalent de sa vie.
"Les économies d’énergie réalisées par le numérique seront largement absorbées par sa propre empreinte croissante. "
cf la voiture…
"La première sécurité est la liberté"
# fake news
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Greycess Knight RPG : de la 1.0.0 à la 1.0.1. Évalué à 3.
https://solar.lowtechmagazine.com/fr/2009/06/embodied-energy-of-digital-technology.html est un ramassis de n'importe quoi, qui mélange énergie primaire, rendement et CO2 !
"La première sécurité est la liberté"
[^] # Re: Ça va faire mal aux boutons...
Posté par Nicolas Boulay (site web personnel) . En réponse au lien Bientôt la fin des CDN ?. Évalué à 3.
On dirait que le partage de font n est pas suffisant pour justifier de données les fonts. Un cache de tout le serait, je pense.
"La première sécurité est la liberté"
[^] # Re: Très intéressant !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Compter automatiquement les mots prononcés sur les chaînes d'information continue. Évalué à 3.
Au niveau moteur de recherche https://quickwit.io/ semble bien indiqué pour chercher des mots dans des To de données.
"La première sécurité est la liberté"
[^] # Re: Besoin d'expliciter le init ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux et BusyBox, un duo parfait pour s'amuser. Évalué à 4.
La VM ne cassera pas. Mais le code aura plus de droit pour faire tourner un code injecté. De plus, c est openbar sur les ressources de l application elle meme.
"La première sécurité est la liberté"
[^] # Re: Besoin d'expliciter le init ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux et BusyBox, un duo parfait pour s'amuser. Évalué à 4.
C'est pas faux. Mais j'ai l'impression que compromettre le service a bien plus d'impact si il est kernel, même en mono-application. L'application peut avoir un nombre de capacité réduite, qui limiterait beaucoup l'effet d'injection de code.
"La première sécurité est la liberté"
[^] # Re: Besoin d'expliciter le init ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux et BusyBox, un duo parfait pour s'amuser. Évalué à 5.
De mémoire, make menuconfig donnait une monstrueuse liste d'option de compilation du noyau. Dans le cas d'un noyau pour VM, une grande partie des drivers sont inutiles ainsi que les modules, etc… bref, si, Linux est extrêmement configurable.
si tu veux ça tu as tort. Un des principes de la sécurité est la réduction de la surface d'attaque et la réduction de privilège des applications. Comme on ne fait plus tourner de serveur en root, on ne vaut pas d'application en mode kernel ! Tu n'as pas envie de refaire Heartbleed.
C'est vrai en théorie. Mais avoir à la fois le niveau de performance de Linux et son niveau de sécurité est très complexe, et pas prêt d'arriver. Il existe des piles IP coté application très rapide, mais pas sécurisé. Bref, faire mieux que Linux est illusoire à court terme.
L'idée n'est pas de modifier Linux, mais de le configurer "à poil" dans une VM, pour ne faire tourner qu'une seul application, tout en bénéficiant de ses perfs et de sa sécurité.
"La première sécurité est la liberté"
[^] # Re: intérêt ?
Posté par Nicolas Boulay (site web personnel) . En réponse au lien Des chercheurs créent une nouvelle méthode d'authentification à base de fibres de soie . Évalué à 3.
On dirait qu'un carré dans un coin de papier pris en photo macro peut revenir au même, non ?
"La première sécurité est la liberté"
[^] # Re: OpenCL, portabilité et performance en général
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 3.
si tu as le temps, tu pourrais tenter de trouver les combinaisons HW/SW qui passent le test ?
"La première sécurité est la liberté"
[^] # Re: OpenCL, portabilité et performance en général
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 4.
Il manque une suite de teste complète ?
"La première sécurité est la liberté"
[^] # Re: Il faut comparer ce qui est comparable
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Éco-responsabilité du numérique et calcul d'impact. Évalué à 4.
Si les secteurs utiles compensent les secteurs inutiles, ce n'est pas de la décroissance, mais de la "croissance verte".
"La première sécurité est la liberté"
[^] # Re: bref, j'ai écrit un init qui se configure en Lua
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux et BusyBox, un duo parfait pour s'amuser. Évalué à 3. Dernière modification le 01 février 2022 à 08:47.
Il y a une niche pour des unikernel basé sur Linux : tu n'as besoin que d'un seul utilisateur, pas de paquet, etc…
J'imagine qu'il doit y avoir une autre niche pour un concept d'unikernel sous docker (sans le kernel donc).
"La première sécurité est la liberté"
[^] # Re: Besoin d'expliciter le init ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linux et BusyBox, un duo parfait pour s'amuser. Évalué à 3. Dernière modification le 01 février 2022 à 08:44.
Oui, c'est le principe des unikernel, sauf que je n'ai jamais vu personne tenté le coup avec Linux complet.
Dans le cas d'une VM, on est sur des méthodes "crash only" pour l'arret. Cela veut dire que l'application tourne ou crash. Donc le kernel panic n'est pas vraiment un problème (sauf peut être pour le debug ou les log), le soft est relancé. concernant la gestion de signaux, je ne sais pas si le runtime go le gère.
Concernant l'acpi, dans le cadre d'une application unikernel, on s'en fout un peu, je pense.
D'ailleurs 70 Mo me parait beaucoup. Un kernel, c'est une dizaine de mega, la libc 6, l'application une dizaine aussi. J'imagine que l'image n'est pas optimisé pour ne tourner qu'en VM et emporte plein de drivers et de dépendance.
"La première sécurité est la liberté"
[^] # Re: Dumb tvs
Posté par Nicolas Boulay (site web personnel) . En réponse au lien LG annonce de nouvelles fonctions de ciblage publicitaire pour ses téléviseurs "intelligents". Évalué à 4. Dernière modification le 31 janvier 2022 à 17:30.
Ma LG ne diffuse pas encore de pub. J'ai interdit tout ce qui est possible d'interdire dessus (il y a alexa par exemple, donc un micro).
J'avais déjà prévu de lui couper internet après la fin des mises à jour, je lui couperait sans doute à la première publicité.
"La première sécurité est la liberté"