Je connaissais pas Balena Etcher. Je suis d'accord que le gain n'est pas évident si il s'agit d'un sélecteur de fichier + un appel a dd.
Dans le cas de 1p, c'est pas evident a dire, le process ne stop pas vraiment et il y en a plusieurs qui tourne. Lorsqu'on ouvre une nouvelle fenetre de l'app, on tape 50MB de ram et le cpu reste a moins de 1% une fois l'app stabilisée. C'est franchement honnête je trouve. J'imagine que derrière ce choix il y aussi la volonté d’éviter que le code soit différent par plateforme, pour auditer le code source ca doit faciliter les choses.
Mais je suis d'accord que c'est un peu l'exception dans un ocean d'horreurs, 1p ont juste bien bosse sur leur app. Ca veut dire que si on maîtrise le framework il est possible de faire une app en electron qui ne soit pas une usine a gaz. Ce n'est peut etre juste le framework le problème...
[^] # Re: simple léger rapide...
Posté par flagos . En réponse au journal VSCodium & support python : pyright. Évalué à 2.
Je connaissais pas Balena Etcher. Je suis d'accord que le gain n'est pas évident si il s'agit d'un sélecteur de fichier + un appel a dd.
Dans le cas de 1p, c'est pas evident a dire, le process ne stop pas vraiment et il y en a plusieurs qui tourne. Lorsqu'on ouvre une nouvelle fenetre de l'app, on tape 50MB de ram et le cpu reste a moins de 1% une fois l'app stabilisée. C'est franchement honnête je trouve. J'imagine que derrière ce choix il y aussi la volonté d’éviter que le code soit différent par plateforme, pour auditer le code source ca doit faciliter les choses.
Mais je suis d'accord que c'est un peu l'exception dans un ocean d'horreurs, 1p ont juste bien bosse sur leur app. Ca veut dire que si on maîtrise le framework il est possible de faire une app en electron qui ne soit pas une usine a gaz. Ce n'est peut etre juste le framework le problème...