Bon, on l'a déjà vu ce lien, comme dit plus bas, et dans l'ensemble, je ne dirais pas être d'accord avec tout, mais la boulimie des programmes me paraît quand même évidente.
Pour le citer:
L’application clavier de Google consomme constamment 150 Mo de mémoire. Est-ce qu’une application qui dessine 30 caractères sur un écran est réellement cinq fois plus complexe que Windows 95 tout entier ?
Perso, je ne crois pas a ton argument de la sécurité la :)
Tiens, example tout con, à mon dernier taf, mon patron voulait une sorte de Kiosque (mobilier urbain), un truc con hein, qui remplace un afficheur 4 lignes 20 colonnes, un pavé tactile 12 touches et 4 sets de 3 diodes, juste utiliser un écran tactile 800 par 600 à la place (bon, et se débarrasser d'une liaison RS232 ainsi que d'un équipement à la stabilité douteuse, je pense).
La première tentative à été d'utiliser ÉtronJS (c'est de la ça exactement que viens ma haine pour cette merde, et c'est la seule «tech» à déclencher en moi un sentiment de dégoût, même systemd j'arrive à le défendre et accepterais de l'utiliser si payé pour, c'est dire!), ce qui implique donc d'avoir Xorg.
Ben, entre les SIGILL, les plantages non identifiés, les freezes, les 80Mio de stockage compressé (et donc de transfert sur des petits forfaits de moins d'une 100aine de megs/mois) et autres emmerdes causées par le Xorg, ça a été un fiasco.
Ça ressemblait probablement à cette fameux appli clavier de google...
La 2nde solution à été de passer par la SDL2 en mode framebuffer. Pas franchement terrible non plus, parce que cette lib invite les gens à l'over-engineering, on le sent, que ça gère l'OpenGL, vraiment.
Sauf qu'en fait, on s'en foutait, de l'OpenGL, on voulait un truc simple et rapide. Et le pire, c'est que ça gérait même pas correctement la dalle tactile!
Bref, le code "final" était... pas réutilisable.
La 3ème (et dernière à ma connaissance, j'irai passer sur une borne pour vérifier, un de ces 4) solution à été:
implémentation manuelle des rotations (obligé, la dalle tactile avait 270° de rotation, la graphique 90°) et d'une transparence simple en software (rendu d'une image complète de 800x600 inférieure à 20ms sauf si abus de widgets transparents)
Au final, ma solution ne marcherait pas pour une UI classique, forcément, pas de problème a partager l'espace avec d'autres applications, par exemple.
Par contre:
le code de la lib est lisible en entier en moins d'une journée (surface d'attaque)
un développeur junior est capable de comprendre comment elle fonctionne (vérifié) avec peu d'aide (maintenabilité...)
la taille de l'application avec images et symboles debug est inférieure à 10megs (je prend large, ça date, et oui je mesurais, pour cause de contraintes réseau: faut l'envoyer, en 2G dans l'Eure, le binaire hein...),
ça juste marche.
moins de fonctionnalités potentielles: fontes PSF1 et PSF2 uniquement, faut oublier les anti-alias, les vidéos, les pdf, les fondu... qui ne sont peut-être pas si utiles que ça?
moins de 20Mio de RAM allouée (Beaucoup moins. Je prend large, parce que j'ai plus accès et que je me base sur ma mémoire)
moins de 2 mois pour avoir la lib et les premières versions de l'application fonctionnelles (pas parfaites, mais fonctionnelles, ce qui était le but premier: avoir un truc qui marche, vite, parce que les clients commençaient à râler fort, très, très fort)
Tout ça, malgré un code au final pas opti du tout (tant sur la RAM que sur le CPU, je sais ou il est possible d'optimiser sévèrement... à commencer par ne pas refaire une image qui n'a pas été changée, ou mettre à jour sur les zones altérées...)
Si le code était libre, je te mettrai au défi de trouver une faille de sécurité dans la lib qui gérait les widgets (donc, le rendu et les entrées, c'est codé en C++ donc moins de fuites mémoire potentielles qu'en C :p).
En terme de temps de rendu, afficher une trame et faire le job derrière en mono-process, mono-thread, c'était moins de 20ms, à cause de la transparence et des rotations (ça coûte cher, très cher, une transposition de tableau quand, comme moi, on n'a jamais sérieusement touché aux matrices et seulement 10 ans avant). Juste la rotation, c'était moins de 10ms (oui, la transparence à été implémentée avec un if sur chaque pixel, histoire de tuer le CPU). À peu près (pour 480K pixels, hein) les deux tiers du temps comparé à:
les éditeurs de textes modernes ne peuvent pas le faire en 16 ms.
[^] # Re: sécurité
Posté par freem . En réponse au lien Le désenchantement du logiciel. Évalué à 6.
Bon, on l'a déjà vu ce lien, comme dit plus bas, et dans l'ensemble, je ne dirais pas être d'accord avec tout, mais la boulimie des programmes me paraît quand même évidente.
Pour le citer:
Perso, je ne crois pas a ton argument de la sécurité la :)
Tiens, example tout con, à mon dernier taf, mon patron voulait une sorte de Kiosque (mobilier urbain), un truc con hein, qui remplace un afficheur 4 lignes 20 colonnes, un pavé tactile 12 touches et 4 sets de 3 diodes, juste utiliser un écran tactile 800 par 600 à la place (bon, et se débarrasser d'une liaison RS232 ainsi que d'un équipement à la stabilité douteuse, je pense).
La première tentative à été d'utiliser ÉtronJS (c'est de la ça exactement que viens ma haine pour cette merde, et c'est la seule «tech» à déclencher en moi un sentiment de dégoût, même systemd j'arrive à le défendre et accepterais de l'utiliser si payé pour, c'est dire!), ce qui implique donc d'avoir Xorg.
Ben, entre les SIGILL, les plantages non identifiés, les freezes, les 80Mio de stockage compressé (et donc de transfert sur des petits forfaits de moins d'une 100aine de megs/mois) et autres emmerdes causées par le Xorg, ça a été un fiasco.
Ça ressemblait probablement à cette fameux appli clavier de google...
La 2nde solution à été de passer par la SDL2 en mode framebuffer. Pas franchement terrible non plus, parce que cette lib invite les gens à l'over-engineering, on le sent, que ça gère l'OpenGL, vraiment.
Sauf qu'en fait, on s'en foutait, de l'OpenGL, on voulait un truc simple et rapide. Et le pire, c'est que ça gérait même pas correctement la dalle tactile!
Bref, le code "final" était... pas réutilisable.
La 3ème (et dernière à ma connaissance, j'irai passer sur une borne pour vérifier, un de ces 4) solution à été:
/usr/include/linux/fb.hAu final, ma solution ne marcherait pas pour une UI classique, forcément, pas de problème a partager l'espace avec d'autres applications, par exemple.
Par contre:
Tout ça, malgré un code au final pas opti du tout (tant sur la RAM que sur le CPU, je sais ou il est possible d'optimiser sévèrement... à commencer par ne pas refaire une image qui n'a pas été changée, ou mettre à jour sur les zones altérées...)
Si le code était libre, je te mettrai au défi de trouver une faille de sécurité dans la lib qui gérait les widgets (donc, le rendu et les entrées, c'est codé en C++ donc moins de fuites mémoire potentielles qu'en C :p).
En terme de temps de rendu, afficher une trame et faire le job derrière en mono-process, mono-thread, c'était moins de 20ms, à cause de la transparence et des rotations (ça coûte cher, très cher, une transposition de tableau quand, comme moi, on n'a jamais sérieusement touché aux matrices et seulement 10 ans avant). Juste la rotation, c'était moins de 10ms (oui, la transparence à été implémentée avec un
ifsur chaque pixel, histoire de tuer le CPU). À peu près (pour 480K pixels, hein) les deux tiers du temps comparé à: