« La conception même de Linux fait qu’il met fin aléatoirement à des processus en cours d’exécution. Et pourtant, c’est le système le plus répandu côté serveur.
Chaque appareil que j’ai plante régulièrement d’une façon ou d’une autre. »
Même si l’Oomk est une réalité, force est de constater qu’on observe rarement le genre de comportement mentionné en second sous Linux. Impossible de se souvenir en avoir rencontré ces dernières années. En revanche dans le paquet de copie d’examen distancié du jour, j’avais un magnifique écran bleu de la mort ; sans doute considéré comme une excuse valable…
L'article m'a fait l'effet d'un apple/chrome fanboy qui ne sait pas de quoi il parle. C'est dommage parce que sur le fond je suis d'accord. Mais je ne sais pas de quoi je parle non plus.
Posté par Psychofox (Mastodon) .
Évalué à 5.
Dernière modification le 06 mai 2021 à 17:17.
Ouais le coup de l'oomkiller c'est un peu une fausse critique. Il préfère un système qui freeze quand il n'a plus de mémoire (et donc qui te force à killer toutes les applis via un cold reboot), ou un système qui fera le ménage de lui-même dans ce cas ?
C'est un comportement de secours quand on ne surveille pas son système de toute manière, faut y alelr pour le déclencher.
Pour le reste il y a du vrai. Cela-dit de temps en temps je test par exemple de vieux bureaux ou WM et me rend vite compte que oui, ils sont véloces, mais non je ne travaille pas moi-même plus rapidement avec eux et jusqu'à présent il y a souvent un truc qui me fait revenir à gnome3. En général le truc bête comme sa flexibilité dans un contexte laptop qui est régulièrement branché à des écrans et autres périphériques divers et variés.
Ouais le coup de l'oomkiller c'est un peu une fausse critique. Il préfère un système qui freeze quand il n'a plus de mémoire (et donc qui te force à killer toutes les applis via un cold reboot), ou un système qui fera le ménage de lui-même dans ce cas ?
Pourquoi ça ferait un freeze?
Sous Haiku, quand il n'y a plus de mémoire, malloc() se met à retourner NULL, et les applications peuvent traiter le problème et afficher un message de type "désolé, y'a plus de mémoire, essaie de fermer une application pour faire de la place".
Et on laisse l'utilisateur (ou l'application elle-même) décider quoi fermer.
Sous Linux, avec l'OOM Killer activé, malloc ne retourne jamais NULL. Et donc les applications n'ont aucune chance de pouvoir intercepter et traiter l'erreur. Elles se font tuer directement.
Sous Linux, avec l'OOM Killer activé, malloc ne retourne jamais NULL. Et donc les applications n'ont aucune chance de pouvoir intercepter et traiter l'erreur. Elles se font tuer directement
C'est un peu (mais alors vraiment «un peu» hein, pas beaucoup) plus subtil que ça.
De mémoire, l'overcommit à 3 réglages:
0
Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default.
1
Always overcommit. Appropriate for some scientific applications. Classic example is code using sparse arrays and just relying on the virtual memory consisting almost entirely of zero pages.
2
Don’t overcommit. The total address space commit for the system is not permitted to exceed swap + a configurable amount (default is 50%) of physical RAM. Depending on the amount you use, in most situations this means a process will not be killed while accessing pages but will receive errors on memory allocation as appropriate.
Trad grossière:
0: rejet des demandes ridicules, c'est à dire supérieure à un seuil réglable.
1: plus de mémoire? Rien à foutre, en voici.
2: pas d'overcommit, mon préféré pour tout système sur lequel je fais des trucs que j'ai pas envie de perdre pour cause de freeze.
Après, il paraît, mais j'ai plus le lien, qu'ils ont corrigé le problème de l'oomkiller qui se déclenchait trop tard. Perso, je m'en fout, j'ai toujours considéré cette feature comme un appel à coder comme des porcs, chose que je ne considère pas normale. Perso, je préfère un système prévisible, qui ne tuera pas au hasard une application critique parce qu'elle ose accéder à un espace mémoire que le noyau lui à pourtant réservé ni ne partira en thrashing.
Je ne connais pas ses règles, mais force est de constater qu'il existe des programmes pour faire (mieux) le boulot à sa place, parce que faire confiance à l'oomkiller du noyau, c'est s'exposer au thrashing.
Personnellement, je désactive l'overcommit, ce qui est une solution comme une autre.
D'autres ont implémenté et utilisent earlyoom, qui est sûrement une meilleure solution puisque ça évite que des veaux comme les navigateurs webs ne se «ferment» régulièrement parce que malloc commence subitement à faire son job et que les devs ont pas vérifié son retour, ou alors ont juste fait un if( NULL == ( lol = maloc( ul ) ) ){ abort(); } en appellant ça de la gestion… (ça, c'est quand c'est bien foutu, après tout, sinon c'est segfault par déréférencement de nullptr).
M'enfin, je suis d'accord: il est prévisible, l'oomkiller: il attend que ton système deviennent inutilisable (non, tu peux pas, dans ce cas, basculer sur un TTY pour tuer un truc toi-même: j'ai bien dit inutilisable) avant d'intervenir. De toutes les occurrences de l'oomkiller, en fait, ce comportement en décrit 95%. Expérience pure debian, donc peut-être que d'autres distro le configurent mieux, j'en sais.
Impossible de se souvenir en avoir rencontré ces dernières années
Dans mon ancienne entreprise où on utilise npm/nodejs, slack, vscode le tout sur 8 Go de RAM. La construction du projet enclenchait très souvent l'OOM. Du pur délire.
git is great because linus did it, mercurial is better because he didn't
Le simple fais d'insérer une disquette sur un 286 pouvait lui amener un virus.
On a beaucoup progressé sur la sécurité et pourtant dans le même temps on a augmenté le risque se façon délirante en ayant des machines éternellement connectées. Cela amène beaucoup de code "inutile" du point de vu du fonctionnement pure.
Il oubli d'autres choses sûrement mais ce point me suffit.
Et je suis bien content de pouvoir acheter sans me ruiner un processeur qui peut calculer une clef SSH décente.
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.
Même si je suis d'accord sur la tendance à l'embonpoint des programmes, il faut aussi comparer ce qui est comparable. La plupart des programmes actuels sont bien plus complexes que leur équivalent il y a dix ans, et il faut prendre en compte toutes leurs fonctionnalités, pas juste la base.
Pour le clavier Android par exemple, ce n'est pas qu'une appli qui "dessine 30 caractères à l’écran". Il y a le support des emojis, des gifs et la partie réseau qui va avec, la suggestion de mots, la correction orthographique, la saisie gestuelle et vocale, le support de plusieurs langues/alphabets. Plus sûrement du cache car c'est preferable (en tout considéré en tant que tel par Google) d'avoir une application rapide que d’économiser de la RAM.
Est ce qu'on pourrait utiliser moins de RAM pour faire tout ca ? Oui je le pense clairement. Et une bonne partie de la consommation de mémoire vient des pratiques de programmation actuelle.
Mais ca aidera pas d'oublier que la plupart des applications sont beaucoup plus complexes, que ce soit pour les fonctionnalités ou la sécurité.
Mais ca aidera pas d'oublier que la plupart des applications sont beaucoup plus complexes, que ce soit pour les fonctionnalités ou la sécurité.
Je ne sais pas si c'est la plupart, vraiment.
Après, le problème c'set que je ne sais pas comment il mesure, notamment, il n'est dit nulle part si c'est la mémoire résidente, ou la mémoire partagée qui est affichée. C'est vraiment très, très différent, même si 150Mo c'est de toute façon trop pour un clavier à mon avis.
Perso, quand je mesure, je préfère me concentrer sur le RSS, la mémoire résidente réservée à l'application en question. C'est bien souvent plusieurs ordres de grandeur en-dessous, et je pense plus révélateur, même si le VSZ permets d'estimer un peu le besoin de l'application si elle était seule sur le système.
De toute façon, les 2 sont à prendre avec des pincettes.
Les meilleurs moteurs de série pour usage automobile ont des rendements pouvant atteindre, dans des conditions optimales, 36 % pour un moteur à essence à allumage commandé et 42 % pour un moteur Diesel à rampe commune haute pression4
En quoi est-ce contradictoire avec ce qu'il écrit ?
Les voitures modernes utilisent 98 % — pour ne pas dire 100 % — de ce que permettent les limites physiques actuelles induites par la conception de leurs moteurs.
Si un moteur à explosion a au mieux 36% de rendement et que tu construis un moteur qui a effectivement un rendement de 36%, tu fais le mieux qu'il est possible de faire.
Bof … S'il n'y avait pas eu de pression de la part des gouvernements et états européens pour pousser l'électrique (avec rendement bien plus élevé), on serait resté tel quel pendant bien longtemps encore, tout simplement parce que le pétrole ne coûte pas suffisamment cher pour se préocuper d'un autre moyen de locomotion avec meilleur rendement ( c'est un peu la même chose que de dire que le matériel coûte moins cher que le développement). Et si on pousse le raisonnement, il n'y auraiot plus de moteur essence mais que des moteurs diesels qui ont un meilleur rendement.
Nos moteurs à explosion thermiques approchent approchaient l’optimum de rendement il y a de cela fort longtemps. Et malheureusement les pressions gouvernementales ont plutôt tendance à réduire l’efficacité car l’idée derrière les normes c’est un peu : la pollution oui, mais plus loin ; plus de CO2, mais moins de particules fines ; plus de réchauffement climatique, et plus de production industrielle, pourvu qu’il y ait des couillons pour croire qu’écrire Green/éco/bleu à l’arrière va sauver la planète, et acheter des produits neufs pour en remplacer d’autres parfaitement fonctionnels.
Vous ne vous êtes jamais demandé pourquoi votre téléphone a besoin de 30 à 60 secondes pour démarrer ?
Un Android oui. Un iPhone 12 mets 5 secondes montre en main. Pour une fois qu'Apple ne fait pas quelque chose de bloat.
Et puis, il y a le poids. Les applications web pourraient s’ouvrir jusqu’à 10 fois plus vite si on bloquait simplement toutes les publicités.
Il n'y a pas que les publicités. Il y a les tonnes de polices embarquées, le Javascript de 12 millions de ligne de code à charger. Etc. Là c'est pas un problème de technologie et de performance, juste un problème d'éducation.
git is great because linus did it, mercurial is better because he didn't
J'ai tout de même l'impression qu'en ce moment c'est très tendance de se plaindre de ce genre de choses non ? Et les gens qui s'en plaignent, ben ce sont les personnes qui ont contribué à cet état de chose. À partir de là, on fait quoi ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Et c'est vite oublier qu'on a toujours le choix, notemment dans le monde du libre. Rien ne nous oblige à utiliser gnome ou kde, on peut toujours utiliser fvwm, icewm ou windowmaker. On commence même à voir des wm légers pour wayland. On peut toujours utiliser abiword et gnumeric pour de la petite bureautique, on une multitude d'outils légers et/ou en ligne de commande/curse pour les trucs les plus à la mode. On peut même démarrer et utiliser alpine linux sur une sdcard ou une raspberry pi comme pc de bureau. On peut toujours recompiler son noyau pour n'avoir que les modules nécessaire à notre hardware.
Au milieu des années 90, la fréquence du proco était en quelques dizaines de Mhz et la ram en Mb, mais il fallait débourser une coquette somme et l'encombrement au mètre carré était tout autre avec ce gros écran cathodique. Chaque nouveau périphérique impliquait l'installation manuelle de drivers, maintenant on branche et ça marche.
On peut toujours utiliser abiword et gnumeric pour de la petite bureautique
On n'en parle pas assez, mais ils sont vraiment très bien en plus, ces logiciels. Ils répondent largement aux besoin de monsieur tout-le-monde, et sont, au moins en terme de poids de stockage, nettement plus léger que leurs versions LO (important en campagne, avec un réseau de merde).
Aucun de ses composants n'est obligatoire et tous apportent des fonctionnalités intéressantes.
Pour le web, c'est désolant mais heureusement il y a des extensions de navigateur qui te donnent un contrôle fin sur quoi charger ou non, on peut choisir d'ignorer les plus lourds et la plupart des applications web proposent une api rest que tu peux utiliser pour éviter de devoir charger la page dans ton navigateur.
Aucun de ses composants n'est obligatoire et tous apportent des fonctionnalités intéressantes.
La création dynamique des périphériques dans /dev n'est pas spécialement nécessaire. Ce sont des points d'entrés spéciaux, en espace disque ça pèse rien. Avoir à les créer dynamiquement nécessite de gérer les permissions à la main et donc écrire des règles udev. Chez nous on doit en écrire pour changer les permissions des ports série pour que notre application ne tourne pas en root. Donc on est obligé de faire tourner udev (ou mdev) juste pour ça. Dans un système comme OpenBSD on fait un chmod/chown et ça persiste. Bien sûr udev reste utile pour d'autres choses comme charger des modules à la volée.
Pour ce qui est de l'audio, non ALSA seul est rarement utile. Enfin si sur une machine totalement statique. Mais sur un ordinateur portable où on va pouvoir le docker et donc faire apparaitre une carte son externe, un casque audio USB, une enceinte bluetooth il est primordial de faire tourner PulseAudio pour changer de périphérique à la volée sans éditer un asound.conf à chaque fois. PulseAudio a mis un certain temps à se stabiliser et voilà qu'on le jette pour passer à PipeWire. Il est bien loin le temps du « quand ça marche, ne touche à rien ». Chez OpenBSD il y en a qu'un seul : sndio.
Pourquoi avoir fait /sys alors qu'on a déjà /proc ? Sans parler du de l'architecture monstre qu'ils sont avec si peu de cohérence. Sur le papier l'idée est bonne, dans la pratique elle l'est moins.
git is great because linus did it, mercurial is better because he didn't
# Encore un qui n’utilise pas assez GNU/Linux
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10. Dernière modification le 06 mai 2021 à 14:09.
Même si l’Oomk est une réalité, force est de constater qu’on observe rarement le genre de comportement mentionné en second sous Linux. Impossible de se souvenir en avoir rencontré ces dernières années. En revanche dans le paquet de copie d’examen distancié du jour, j’avais un magnifique écran bleu de la mort ; sans doute considéré comme une excuse valable…
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Encore un qui n’utilise pas assez GNU/Linux
Posté par Lutin . Évalué à 6.
L'article m'a fait l'effet d'un apple/chrome fanboy qui ne sait pas de quoi il parle. C'est dommage parce que sur le fond je suis d'accord. Mais je ne sais pas de quoi je parle non plus.
[^] # Re: Encore un qui n’utilise pas assez GNU/Linux
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 06 mai 2021 à 17:17.
Ouais le coup de l'oomkiller c'est un peu une fausse critique. Il préfère un système qui freeze quand il n'a plus de mémoire (et donc qui te force à killer toutes les applis via un cold reboot), ou un système qui fera le ménage de lui-même dans ce cas ?
C'est un comportement de secours quand on ne surveille pas son système de toute manière, faut y alelr pour le déclencher.
Pour le reste il y a du vrai. Cela-dit de temps en temps je test par exemple de vieux bureaux ou WM et me rend vite compte que oui, ils sont véloces, mais non je ne travaille pas moi-même plus rapidement avec eux et jusqu'à présent il y a souvent un truc qui me fait revenir à gnome3. En général le truc bête comme sa flexibilité dans un contexte laptop qui est régulièrement branché à des écrans et autres périphériques divers et variés.
[^] # Re: Encore un qui n’utilise pas assez GNU/Linux
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Pourquoi ça ferait un freeze?
Sous Haiku, quand il n'y a plus de mémoire, malloc() se met à retourner NULL, et les applications peuvent traiter le problème et afficher un message de type "désolé, y'a plus de mémoire, essaie de fermer une application pour faire de la place".
Et on laisse l'utilisateur (ou l'application elle-même) décider quoi fermer.
Sous Linux, avec l'OOM Killer activé, malloc ne retourne jamais NULL. Et donc les applications n'ont aucune chance de pouvoir intercepter et traiter l'erreur. Elles se font tuer directement.
[^] # Re: Encore un qui n’utilise pas assez GNU/Linux
Posté par freem . Évalué à 5.
C'est un peu (mais alors vraiment «un peu» hein, pas beaucoup) plus subtil que ça.
De mémoire, l'overcommit à 3 réglages:
Trad grossière:
0: rejet des demandes ridicules, c'est à dire supérieure à un seuil réglable.
1: plus de mémoire? Rien à foutre, en voici.
2: pas d'overcommit, mon préféré pour tout système sur lequel je fais des trucs que j'ai pas envie de perdre pour cause de freeze.
Après, il paraît, mais j'ai plus le lien, qu'ils ont corrigé le problème de l'oomkiller qui se déclenchait trop tard. Perso, je m'en fout, j'ai toujours considéré cette feature comme un appel à coder comme des porcs, chose que je ne considère pas normale. Perso, je préfère un système prévisible, qui ne tuera pas au hasard une application critique parce qu'elle ose accéder à un espace mémoire que le noyau lui à pourtant réservé ni ne partira en thrashing.
[^] # Re: Encore un qui n’utilise pas assez GNU/Linux
Posté par Anonyme . Évalué à 6.
L’OOM Killer n’a rien d’aléatoire, son fonctionnement est documenté, et la sélection du process se fait selon des règles précises.
[^] # Re: Encore un qui n’utilise pas assez GNU/Linux
Posté par freem . Évalué à 4.
Je ne connais pas ses règles, mais force est de constater qu'il existe des programmes pour faire (mieux) le boulot à sa place, parce que faire confiance à l'oomkiller du noyau, c'est s'exposer au thrashing.
Personnellement, je désactive l'overcommit, ce qui est une solution comme une autre.
D'autres ont implémenté et utilisent earlyoom, qui est sûrement une meilleure solution puisque ça évite que des veaux comme les navigateurs webs ne se «ferment» régulièrement parce que malloc commence subitement à faire son job et que les devs ont pas vérifié son retour, ou alors ont juste fait un
if( NULL == ( lol = maloc( ul ) ) ){ abort(); }en appellant ça de la gestion… (ça, c'est quand c'est bien foutu, après tout, sinon c'est segfault par déréférencement de nullptr).M'enfin, je suis d'accord: il est prévisible, l'oomkiller: il attend que ton système deviennent inutilisable (non, tu peux pas, dans ce cas, basculer sur un TTY pour tuer un truc toi-même: j'ai bien dit inutilisable) avant d'intervenir. De toutes les occurrences de l'oomkiller, en fait, ce comportement en décrit 95%. Expérience pure debian, donc peut-être que d'autres distro le configurent mieux, j'en sais.
[^] # Re: Encore un qui n’utilise pas assez GNU/Linux
Posté par David Demelier (site web personnel) . Évalué à 4.
Dans mon ancienne entreprise où on utilise npm/nodejs, slack, vscode le tout sur 8 Go de RAM. La construction du projet enclenchait très souvent l'OOM. Du pur délire.
git is great because linus did it, mercurial is better because he didn't
# sécurité
Posté par blobmaster . Évalué à 3.
Il a pas tord sur le fond mais il exagère un peu.
Dans son analyse il oubli la sécurité.
Le simple fais d'insérer une disquette sur un 286 pouvait lui amener un virus.
On a beaucoup progressé sur la sécurité et pourtant dans le même temps on a augmenté le risque se façon délirante en ayant des machines éternellement connectées. Cela amène beaucoup de code "inutile" du point de vu du fonctionnement pure.
Il oubli d'autres choses sûrement mais ce point me suffit.
Et je suis bien content de pouvoir acheter sans me ruiner un processeur qui peut calculer une clef SSH décente.
[^] # Re: sécurité
Posté par freem . É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é à:[^] # Re: sécurité
Posté par xenom . Évalué à 5.
Même si je suis d'accord sur la tendance à l'embonpoint des programmes, il faut aussi comparer ce qui est comparable. La plupart des programmes actuels sont bien plus complexes que leur équivalent il y a dix ans, et il faut prendre en compte toutes leurs fonctionnalités, pas juste la base.
Pour le clavier Android par exemple, ce n'est pas qu'une appli qui "dessine 30 caractères à l’écran". Il y a le support des emojis, des gifs et la partie réseau qui va avec, la suggestion de mots, la correction orthographique, la saisie gestuelle et vocale, le support de plusieurs langues/alphabets. Plus sûrement du cache car c'est preferable (en tout considéré en tant que tel par Google) d'avoir une application rapide que d’économiser de la RAM.
Est ce qu'on pourrait utiliser moins de RAM pour faire tout ca ? Oui je le pense clairement. Et une bonne partie de la consommation de mémoire vient des pratiques de programmation actuelle.
Mais ca aidera pas d'oublier que la plupart des applications sont beaucoup plus complexes, que ce soit pour les fonctionnalités ou la sécurité.
[^] # Re: sécurité
Posté par freem . Évalué à 1.
Je ne sais pas si c'est la plupart, vraiment.
Après, le problème c'set que je ne sais pas comment il mesure, notamment, il n'est dit nulle part si c'est la mémoire résidente, ou la mémoire partagée qui est affichée. C'est vraiment très, très différent, même si 150Mo c'est de toute façon trop pour un clavier à mon avis.
Perso, quand je mesure, je préfère me concentrer sur le RSS, la mémoire résidente réservée à l'application en question. C'est bien souvent plusieurs ordres de grandeur en-dessous, et je pense plus révélateur, même si le VSZ permets d'estimer un peu le besoin de l'application si elle était seule sur le système.
De toute façon, les 2 sont à prendre avec des pincettes.
# J’me disais bien
Posté par Sacha Trémoureux (site web personnel) . Évalué à 10.
J’me disais bien qu’on en avait déjà parlé !
https://linuxfr.org/users/vincentd/journaux/un-developpeur-qui-denonce
https://linuxfr.org/users/nono/liens/software-disenchantment
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Pour ce qui est de la comparaison avec la voiture ......
Posté par totof2000 . Évalué à 3. Dernière modification le 06 mai 2021 à 19:49.
il s'est complêtement planté :
https://fr.wikipedia.org/wiki/Rendement_d%27un_moteur_%C3%A0_explosion
Les meilleurs moteurs de série pour usage automobile ont des rendements pouvant atteindre, dans des conditions optimales, 36 % pour un moteur à essence à allumage commandé et 42 % pour un moteur Diesel à rampe commune haute pression4
On ne peut pas vraiment parler d'efficacité.
[^] # Re: Pour ce qui est de la comparaison avec la voiture ......
Posté par Jean-Baptiste Faure . Évalué à 5.
En quoi est-ce contradictoire avec ce qu'il écrit ?
Si un moteur à explosion a au mieux 36% de rendement et que tu construis un moteur qui a effectivement un rendement de 36%, tu fais le mieux qu'il est possible de faire.
[^] # Re: Pour ce qui est de la comparaison avec la voiture ......
Posté par totof2000 . Évalué à 0.
Bof … S'il n'y avait pas eu de pression de la part des gouvernements et états européens pour pousser l'électrique (avec rendement bien plus élevé), on serait resté tel quel pendant bien longtemps encore, tout simplement parce que le pétrole ne coûte pas suffisamment cher pour se préocuper d'un autre moyen de locomotion avec meilleur rendement ( c'est un peu la même chose que de dire que le matériel coûte moins cher que le développement). Et si on pousse le raisonnement, il n'y auraiot plus de moteur essence mais que des moteurs diesels qui ont un meilleur rendement.
[^] # Re: Pour ce qui est de la comparaison avec la voiture ......
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 0.
Nos moteurs
à explosionthermiquesapprochentapprochaient l’optimum de rendement il y a de cela fort longtemps. Et malheureusement les pressions gouvernementales ont plutôt tendance à réduire l’efficacité car l’idée derrière les normes c’est un peu : la pollution oui, mais plus loin ; plus de CO2, mais moins de particules fines ; plus de réchauffement climatique, et plus de production industrielle, pourvu qu’il y ait des couillons pour croire qu’écrire Green/éco/bleu à l’arrière va sauver la planète, et acheter des produits neufs pour en remplacer d’autres parfaitement fonctionnels.« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Quelques notes
Posté par David Demelier (site web personnel) . Évalué à 8.
Un Android oui. Un iPhone 12 mets 5 secondes montre en main. Pour une fois qu'Apple ne fait pas quelque chose de bloat.
Il n'y a pas que les publicités. Il y a les tonnes de polices embarquées, le Javascript de 12 millions de ligne de code à charger. Etc. Là c'est pas un problème de technologie et de performance, juste un problème d'éducation.
git is great because linus did it, mercurial is better because he didn't
# C'est pas un peu la mode du moment ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 06 mai 2021 à 20:37.
J'ai tout de même l'impression qu'en ce moment c'est très tendance de se plaindre de ce genre de choses non ? Et les gens qui s'en plaignent, ben ce sont les personnes qui ont contribué à cet état de chose. À partir de là, on fait quoi ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: C'est pas un peu la mode du moment ?
Posté par Psychofox (Mastodon) . Évalué à 6.
Oui.
Et c'est vite oublier qu'on a toujours le choix, notemment dans le monde du libre. Rien ne nous oblige à utiliser gnome ou kde, on peut toujours utiliser fvwm, icewm ou windowmaker. On commence même à voir des wm légers pour wayland. On peut toujours utiliser abiword et gnumeric pour de la petite bureautique, on une multitude d'outils légers et/ou en ligne de commande/curse pour les trucs les plus à la mode. On peut même démarrer et utiliser alpine linux sur une sdcard ou une raspberry pi comme pc de bureau. On peut toujours recompiler son noyau pour n'avoir que les modules nécessaire à notre hardware.
Au milieu des années 90, la fréquence du proco était en quelques dizaines de Mhz et la ram en Mb, mais il fallait débourser une coquette somme et l'encombrement au mètre carré était tout autre avec ce gros écran cathodique. Chaque nouveau périphérique impliquait l'installation manuelle de drivers, maintenant on branche et ça marche.
[^] # Re: C'est pas un peu la mode du moment ?
Posté par freem . Évalué à 4.
On n'en parle pas assez, mais ils sont vraiment très bien en plus, ces logiciels. Ils répondent largement aux besoin de monsieur tout-le-monde, et sont, au moins en terme de poids de stockage, nettement plus léger que leurs versions LO (important en campagne, avec un réseau de merde).
[^] # Re: C'est pas un peu la mode du moment ?
Posté par David Demelier (site web personnel) . Évalué à 3.
On peut toujours utiliser ce qu'on veut en WM mais sur certains points on ne peut toujours rien faire :
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C'est pas un peu la mode du moment ?
Posté par Psychofox (Mastodon) . Évalué à 4.
Aucun de ses composants n'est obligatoire et tous apportent des fonctionnalités intéressantes.
Pour le web, c'est désolant mais heureusement il y a des extensions de navigateur qui te donnent un contrôle fin sur quoi charger ou non, on peut choisir d'ignorer les plus lourds et la plupart des applications web proposent une api rest que tu peux utiliser pour éviter de devoir charger la page dans ton navigateur.
[^] # Re: C'est pas un peu la mode du moment ?
Posté par David Demelier (site web personnel) . Évalué à 5.
La création dynamique des périphériques dans /dev n'est pas spécialement nécessaire. Ce sont des points d'entrés spéciaux, en espace disque ça pèse rien. Avoir à les créer dynamiquement nécessite de gérer les permissions à la main et donc écrire des règles udev. Chez nous on doit en écrire pour changer les permissions des ports série pour que notre application ne tourne pas en root. Donc on est obligé de faire tourner udev (ou mdev) juste pour ça. Dans un système comme OpenBSD on fait un chmod/chown et ça persiste. Bien sûr udev reste utile pour d'autres choses comme charger des modules à la volée.
Pour ce qui est de l'audio, non ALSA seul est rarement utile. Enfin si sur une machine totalement statique. Mais sur un ordinateur portable où on va pouvoir le docker et donc faire apparaitre une carte son externe, un casque audio USB, une enceinte bluetooth il est primordial de faire tourner PulseAudio pour changer de périphérique à la volée sans éditer un asound.conf à chaque fois. PulseAudio a mis un certain temps à se stabiliser et voilà qu'on le jette pour passer à PipeWire. Il est bien loin le temps du « quand ça marche, ne touche à rien ». Chez OpenBSD il y en a qu'un seul : sndio.
Pourquoi avoir fait /sys alors qu'on a déjà /proc ? Sans parler du de l'architecture monstre qu'ils sont avec si peu de cohérence. Sur le papier l'idée est bonne, dans la pratique elle l'est moins.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: C'est pas un peu la mode du moment ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
La solution à "y'a trop de code" serait donc d'ajouter du code pour empêcher le code de s'exécuter… intéressant comme approche…
# et pourtant
Posté par steph1978 . Évalué à 3. Dernière modification le 07 mai 2021 à 22:32.
et
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.