freem a écrit 5019 commentaires

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).

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é:

• libinput parce que le tactile c'est chiant
• /usr/include/linux/fb.h
• implémentation manuelle des fontes PSF1 et PSF2
• 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.

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.

Oui, et surtout… il est bien plus facile de visualiser 90° que PI/2 rad. Ou est-ce PI/4? Je me souviens jamais, tellement j'utilise souvent les radians. Bon, je suis pas vraiment un matheux, je le reconnais.

un flottant, avec le risque d'erreurs d'arrondi

D'ailleurs, je me pose tout le temps la question, au point d'en être arrivé à fuir les flottants autant que faire se peut, c'est quoi qu'il faut utiliser pour tester une égalité? Je veux dire, la valeur qu'il faut utiliser pour dire "+- foo", c'est combien?

PI cumule les tares : il est irrationnel

C'est limite un truc que j'ai tendance à appliquer aux matheux de manière générale XD /me ->[]

Voila qui serait une BELLE innovation qui pourrait faire le buz !

Pas une innovation, d'autres le font déjà, et depuis longtemps.

Ben, tu prends aussi des trucs système qui vérifie si systemd existe avant de lancer la tâche, ça complique évidemment les choses

Pas vraiment. Le problème de balancer un one-liner proviens du fait que cron exécute directement un shell, j'imagine. En soit, je trouve que c'est déjà une erreur, moi, il ne devrais pas être nécessaire de passer par /bin/sh comme intermédiaire. Oui, ça impliquerais que les scripts seraient des fichiers séparés, probablement one-liners, mais ça éviterais ce cas précis (tout en supprimant une couche d'exécution, cela dit, puisque ce serait alors uniquement le noyau qui ferait l'exécution, qu'il fera de toute façon).

Mon reproche est plutôt de la sorte de mélopée qui précède la commande: un nombre variable de nombres, qui peuvent parfois être des astérisques.
Je comprend bien que je ne suis pas un habitué des crontabs, mais voila, je trouve 0 * * * * incompréhensible moi. Quand je lis ça, j'ai besoin d'aller lire la page du manuel. En soit, ce n'est pas un drame de devoir aller lire la doc, mais voila on ne parle pas vraiment d'une doc super claire. Ah, pardon, peut-être celle-ci… nope, celle-la? Ah, oui, enfin!
La description de la partie la moins lisible est au milieu du bouzin, et ça deviens fun quand on commence à jouer avec les intervalles et les listes.
J'allais dire qu'il n'y a même pas d'exemple, ce qui eut été faux:

EXAMPLE CRON FILE         top
       # use /bin/sh to run commands, no matter what /etc/passwd says
       SHELL=/bin/sh
       # mail any output to `paul', no matter whose crontab this is
       MAILTO=paul
       #
       CRON_TZ=Japan
       # run five minutes after midnight, every day
       5 0 * * *       $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
       # run at 2:15pm on the first of every month -- output mailed to paul
       15 14 1 * *     $HOME/bin/monthly
       # run at 10 pm on weekdays, annoy Joe
       0 22 * * 1-5    mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
       23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
       5 4 * * sun     echo "run at 5 after 4 every sunday"

La, on commence a voir à quel point tout ça est lisible, en effet. Oui, c'est ironique.
C'est concis, ça oui, clairement, mais lisibilité s'en ressens pas mal, je trouve. Après, oui, je suis d'accord, ma solution custom (et dégueu) n'est pas idéale non plus, systemd n'est pas non plus parfait, chacun à ses forces, mais je préfère vraiment éviter cron, j'ai toujours peur qu'il me pète à la gueule.

dans systemd, tu dois te taper 10 lignes réparties dans 2 fichiers au minimum.

Je reconnais ne pas connaître les détails pour systemd, c'est peut-être moins concis, certes, je n'ai personnellement pas de bonne solution pour ça (ne faisant que très très rarement des planification de tâches, et jamais avec systemd).
Par contre, pour cron, j'ai ce genre de choses:

% cat /etc/cron.d/e2scrub_all 
30 3 * * 0 root test -e /run/systemd/system || SERVICE_MODE=1 /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron
10 3 * * * root test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r

Désolé, mais… j'ose espérer que systemd à quand même une config plus lisible.
Je préfère un truc verveux (bon, que ça soit coupé en 2 fichiers c'est dommage par contre) plutôt qu'un one-liner illisible sans être lourdement commenté (encore, ici, «la chance!» seul root est utilisé, donc tout s'aligne, et il n'y a que 2 lignes…).

Les rares fois ou je dois utiliser cron, je lis le manuel, plusieurs fois pour être sûr, puis j'écris une ligne, et je la relis plusieurs fois, en comptant les espaces…
Idéalement, je teste sur plusieurs périodes (jours/heures… pour les semaines ou les mois, c'est pas possible, et je crois qu'il peut pas gérer les années) que ça fonctionne vraiment, et dans tous les cas, je serre les fesses de pas m'être raté.

Le tout, alors que fonctionnellement le but est simplement de gérer des processus et leurs journaux, ce qui est très clairement du ressort d'outils comme systemd ou les daemontools (sauf que eux n'ont pas cette fonctionnalité, sauf peut-être nosh?).
J'ai beau ne pas être fan de systemd, il me semble difficile de considérer que sysVinit+rc.d+cron est une solution magnifique.
daemontools|runit + cron est un peu moins bancal, mais on se tape quand même le fait que les gestionnaires de processus sont incapables de planifier la gestion de processus, ce qui est pourtant leur coeur de métier…

En pratique, si ma machine est censée fonctionner non-stop, plutôt qu'installer cron, je préfère faire ça:

#!/bin/sh
#./run

# une "lib" de 26 lignes que je me suis faite
. /etc/runit/common

echo "starting $SVNAME"

test -e ./conf || die "config not found"

exec $COMMAND

#!/bin/sh
#./finish

. /etc/runit/common
test -e ./conf || die "config not found"

sleep $PERIOD

#./conf
PERIOD="1d"
COMMAND="foobar"

Ces fichiers sont placés dans un dossier type /etc/sv/task_$foo, qui contiens un sous dossier log, qui contiens un fichier run qui est un symlink vers /etc/runit/log.run.
Du coup, ça fait pas mal de monde pour de simple tâches planifiées.

Le résultat est moins bon et moins puissant qu'avec systemd (en plus ça pourrit mon arbo de processus :/) ou cron (sans parler d'anacron!), mais…
Comparé à cron, j'ai nettement plus confiance dans le fonctionnement ainsi qu'une meilleure facilité pour consulter les journaux d'une tâche spécifique.

Par chance je n'ai que rarement besoin d'y avoir recours. Sinon, le poids sur le système pourrais devenir problématique (dans le cas de runsvdir, il lance à chaque fois un processus pour gérer le daemon lui-même, et un autre pour les logs, ça fait donc 2 processus constants pour des tâches qui ne nécessitent des ressources que ponctuellement. Ce n'est pas énorme, mais c'est tout de même dommage de gaspiller, et ça ne se mets pas à l'échelle, contrairement à cron ou… systemd.)

Ici, je pense que systemd gagne haut la main.

Pas systemd, certes, mais j'utilise le même genre de choses.

Pour être plus explicite, voici mon .xinitrc actuel, bien que je pense migrer certaines choses vers ~/.profile ou équivalent, voire trouver une meilleure solution, plus portable, parce que les shell sont des horreurs de ce point de vue:

export SVDIR=$HOME/.config/services
runsvdir -P $SVDIR ............................................................ &
xrandr --output HDMI-3 --right-of HDMI-2
#urxvtd -o &
#unclutter -idle 2 -jitter 2 &
setxkbmap fr 
#(pidof mpd > /dev/null || mpd --no-daemon ~/.config/mpd/mpd.conf --stderr) &
xosview &
#claws-mail &
#/bigfiles/$USER/contrib/quassel/build/quasselclient &
numlockx on
exec ssh-agent chpst -P i3

Toutes les lignes zombifiées (d'ailleurs, c'est l'occasion de les virer, je devrais peut-être également ajouter xosview, je ne sais pas trop, il n'est pas vraiment critique à mon usage…), en fait, elles sont maintenant gérées par runsvdir.

Cela permets une vraie facilité de gestion et d'intégration, totalement indépendante de mon gestionnaire de fenêtres ou de mon bureau, ainsi que des avantages propres à diverses catégories d'outils:

• mpd: tendance à planter quand interruption de connexion réseau (locale ou distance) lors de écoute de webradio;
• unclutter: conflits avec certains jeux et applications qui capturent la souris;
• toute application que je pourrais fermer par accident alors que j'ai besoin de la présence continuelle, telle que le MUA ou le client IRC, ou encore urxvtd;

Au final, avec le temps je m'aperçois que j'utilise de plus en plus le mécanisme de gestion des daemon de mon système pour des tâches liées à l'utilisateur.
Ce n'est pas spécifique à systemd (puisque je n'utilise pas), de fait, mais je trouve ce type d'usage très pertinent et puissant, peu importe l'implémentation. Par contre, rien de tout ça n'est aisément réalisable avec l'ancêtre sysVinit et cette pile de shell qu'est rc.d (sans parler de la taille des scripts à écrire! beurk!).

Sur mon serveur perso, j'ai simplement créé une service runsvidir par mon utilisateur, ce qui semble être un équivalent de systemd --user, vu que pas de session interactive sur le serveur.

Tant qu'a avoir un outil qui gère les processus, je dirais que d'y intégrer le planificateur de tâche (qui gère des processus) fait clairement sens.
Surtout quand on voit la gueule de la config de cron…

Sur le fond, je suis d'accord, mais bon, je ne vois pas le rapport avec le sujet.
Ici, on parle du fait (avéré, que l'on n'aime ou pas systemd) qu'il est simple de mettre en place un outil qui automatise des actions lors d'un événement, sans avoir à devenir root (tant que l'utilisateur est connecté, si j'ai bien compris gUI, ce qui est tout à fait logique de mon point de vue).

Quitte à troller contre systemd, tu aurais été plus pertinent de relever le fait qu'il semble nécessiter 2 directives que j'aurais naïvement considéré comme faisant la même chose: Requires=maclef.mount, After=maclef.mount.

Pour en revenir à ton problème, si une mise à jour de systemd sur une Debian stable casse ton système, ce n'est pas la faute de systemd, mais de Debian, qui n'a pas assez bien fait son travail.
Tu as dès lors plusieurs solutions:

• passer à devuan, et te retrouver avec les bugs supplémentaires qu'elle contient, sans avoir d'avantage réel (debian permets toujours d'utiliser d'autres init, pour être exact, debian en à même ajouté)
• ne plus utiliser systemd sur debian. C'est ma solution. Elle nécessite quelques sacrifices, comme toujours lorsque l'on n'utilise pas les choix par défaut, mais selon le remplaçant choisit, la maintenance peut être vraiment, vraiment négligeable (quasi 0, en fait, comme pour systemd)
• contribuer à la résolution du problème. Cela passe par un rapport de bogues en bonne et due forme et un suivi, et peut aller jusqu'à proposer un workaround ou mieux, un correctif. Tu connais sûrement la chanson :)

Je peux tirer les fils moi-même, à grands coups de find/grep et cie, nah !

Un utilisateur n'ayant connu que systemd dira exactement la même chose, puisqu'il ne saura pas se dépêtrer du tas de spaghettis qu'est rc.d, le fameux outil de «gestion» des daemon historique, qui se pose traditionnellement au-dessus de sysVinit.

Et me concernant, moi qui n'aime pas non plus systemd (pour mes propres raisons), si j'avais le choix entre un retour à ces plas de spaghettis shell (parfois même avec de vrais bouts de bâches dedans, vive l'écologie), je choisirai systemd. Il répond à un réel problème, que la traditionnelle combinaison sysVinit+rc.d échoue à résoudre.

Pas la peine de le prendre comme ça…

En fait, c'est une question de ton et de contenu. D'autres ont répondu un contenu dans la même veine que toi, mais d'une autre façon.

Je te remets ton message, que tu puisses bien avoir le contexte:

A se demander comment on peut regarder des films 4K en streaming…

Shadow ? Stadia ? GeforceNow ça te parle ? Et crois-moi, c'est pas fait pour jouer au solitaire tout ça.

Voila. Je ne vois rien qui mérite sympathie la-dedans, contrairement au message auquel celui-ci répond. Ce n'est pas un problème, ça m'arrive moi aussi d'avoir ce type de réponses mais, quand on me répond sèchement, je ne suis pas surpris.

Tu dis:

juste que tu pouvais éviter de répondre à côté de la plaque en étant aussi sûr de toi.

puis:

Aujourd'hui, pas à ma connaissance mais je ne sais pas tout. Cela dit, les solutions étant uniquement logicielles, on peut très bien imaginer que ce soit un jour déployable par "tout un chacun" via des logiciels libres en prime.

Oui, donc, du coup, c'est bel et bien "compliqué", de mettre en place une telle archi, non? Notamment avec du LL?
Ce qui est ce que je disais, au final, ça fait même partie du titre.
Ou alors, je me trompe sur la définition du mot "compliqué"?

On va se retrouver comme dans le passé avec des applications GNOME et des applications pure GTK ne proposant pas la même ergonomie.

Depuis gtk3, j'ai remplacé la plupart de mes applications GTK par des applications Qt. Parce que je n'aime pas du tout l'ergonomie de gnome, mention spéciale pour l'ouverture de fichiers.
Je sais, je sais, ils ont fait appel à des pro, c'est étudié, bla bla bla. Je pense que les gens Qt aussi, ont fait appel à des pro, et je trouve de manière générale les applications Qt bien plus agréables à utiliser que tout ce qui viens de gnome.
D'ailleurs, un certain nombre d'applications aussi, a fait ce choix, je citerais notamment wireshark.

Je pense que la leçon à en fait finalement été comprise, justement. Reste à voir si les gens re-migrerons vers gtk… ce qui est fort peu probable, une migration de toolkit se fait pas à la légère (pour le dev, d'une part, et pour les utilisateurs, la résistance au changement n'est pas un mythe, pas plus que la mémoire).

Certains jeux libres sont magnifiques. Pour la comparaison avec des jeux AAA, je dirais que "the dark mod" est un jeu sublime, à ma connaissance 100% libre.

Il y a ensuite d'autres jeux qui ne sont que partiellement libres, les graphismes, le son, ou les trames d'histoire ne l'étant pas, tout en restant gratuits.
Je (re)joue depuis quelques temps à un mmo-rpg nommé planeshift, et je pense qu'ils ont fait ça (initialement au moins, ce truc est vieux, et ça se sent un peu) tout simplement parce qu'un mmo-rpg sans moyens financiers réels ne peut pas vraiment se permettre de se manger des forks agressifs par une société qui récupérerais le travail sans rien faire et en faisant payer ou revendant les informations des joueurs (à noter que je n'ai aucune garantie qu'ils ne le fassent pas eux-même, et que le public est pour le moins… peu nombreux depuis que j'y rejoue).
Dans leur cas, à minima maintenant, je pense que le libre ne les intéresse pas tant que ça, compte tenu du fait qu'ils migrent le client vers Unreal engine (je ne connais pas les détails), mais la préoccupation du fork et de la récupération par une entreprise me semble légitime. Oui, le libre le permets, et dans le cadre d'un mmo-rpg, il est clairement possible de se récupérer tout le travail, en faisant un fork, en hébergeant soi-même, et en faisant assez de communication autour pour éclipser le projet originel.
Comme les mmo sont, par nature, soumis à l'effet boule de neige, il est très possible de détruire les auteurs initiaux sans même apporter le moindre changement pratique voire en apportant des régressions (vente des données). Dans ce cas précis, le 100% libre me semble, je l'admets, peu pertinent (il existe d'autres mmo 100% libres, certes: ryzom, qui est plus proche d'un jeu pour transformer un humain en robot que d'un jeu, the mana world, un jeu en 2D aux graphismes inférieurs à ceux qu'avait wesnoth il y a 10 ans, de mémoire, et probablement d'autres que je ne connais pas).

Pour en revenir à la comparaison avec les AAA, bien souvent ce dont manquent les jeux libres, c'est du contenu solo. Les graphismes ont tendance à s'améliorer, vraiment: si je compare wesnoth avec ce que c'était quand j'ai découvert (version 1.4 de mémoire), ça n'a plus rien à voir (les ressources nécessaires non plus, d'ailleurs, mais peu importe) ou quand je regarde "the dark mod" auquel je ne joue plus parce que mes écrans actuels sont de trop mauvaise qualité, ça me ruinerait l'immersion…

Parce que c'est le moins amusant à créer, et que bien souvent il n'y a que des bénévoles derrière ces jeux, qui font ce qui les amuse ou rend le jeux qu'ils apprécient plus appréciable à leurs yeux. Il y a quelques jeux solo, mais généralement c'est très limité: widelands n'a qu'une petite dizaine de scénarios de campagnes, 0AD n'en a aucun, et pourtant ces jeux s'y prêtent, les FPS n'ont jamais vraiment d'histoires solo, au mieux on a nexuiz/xonotic et la liste de pseudo-tutoriaux au final assez dénués d'intérêt.
En contre-exemple, warzone2100, mais il était à l'origine un jeu commercial, closed-source. Wesnoth, l'ovni. Freedoom & co, abuse, aussi qui de mémoire à des cartes libres (pas le son?) mais pareil, jeu initialement close-source.

Si tu veux aider un projet de RPG à s'améliorer, OpenMW essaie de créer une suite d'exemple. Ce projet à réimplémenté le moteur d'elder scroll III, et est déjà bien meilleur que l'original sur pas mal de points (je suppose qu'il en reste ou il est au maximum equivalent…) notamment graphiques.
Ils ont également un éditeur de carte de leur cru, qui semble nécessiter encore du travail mais être utilisable (mieux que l'original? Pas sûr), et avec lequel il est prévu de faire cette fameuse suite d'exemple.
Je n'ai aucun doute que personne n'aura rien contre transformer une telle suite d'exemple en jeu complet, il faut "juste" faire le taf. En attendant, openmw est un bon moyen de jouer à morrowind, en y mettant au passage le contenu de tamriel rebuilt, si la licence des fichiers de jeu ne te dérange pas trop.

Autre site que je n'ai pas vu cité: libregamewiki et la petite liste de "planets" qui vont avec.

Personnellement, je ne joue plus qu'aux jeux dont j'ai une copie, qui tournent sous linux (via wine) ou dont je peux compiler le code. C'est sûr que ça réduit le périmètre, mais bon, tant pis.

Même un ping inférieur à 40ms s'ajoutera à celui entre le moteur de calcul et le serveur du jeu… bon, ça, en vrai, ça peut faire gagner de la latence potentiellement.

Je doute personnellement que ça soit "juste louer un PC chez le voisin", mais bon, peut-être…

OU alors ils ont autant d'actions chez l'un que chez l'autre, du coup peu importe :)

D'abord il y a des circuits dédiés pour ça,

C'est vrai.

ensuite le multi-cœurs et le multithread parallélisent en occupant le CPU/GPU sur des temps et des circuits qui seraient inoccupés

La plupart des jeux libres que je connaît sont incapables d'utiliser du multi-coeur CPU (ou alors, uniquement de manière très, très parcellaire)…
BOn, ça implique qu'il y a toujours au moins un coeur qui glande, certes. Reste à voir si tout ça, c'est valable sur un "Ordoid Go Super". Itou pour son réseau, en fait, parce que selon ou l'on habite, le wifi peut être plus ou moins performant, et être une nécessité (location en ville).

Je ne sais pas à quelle vitesse max ça va, cela dit, je n'ai même pas d'ordre d'idée.
Il semblerait que l'on parle de 600Mbps pour le 2.5GHz et 1300Mbps pour 5GHz, sauf que mon, ce sont les valeurs maxi, j'imagine, en salle blanche? Parce que la dernière fois que j'ai testé un transfert de disque en conditions réelle, ça allait clairement moins vite que le bout de fil téléphonique que j'utilise en guise d'éthernet, bridé par un switch 10/100.

Je ne connais pas les specs, mais je pressent l'ARM, qui de mémoire, à une puissance max par coeur moins élevée que l'x86_64?

Du coup, même si certains ont soulevé de bon points, je reste sur mon opinion pour l'instant: Compliqué. Enfin, pour une "game-boy" ça devrais pouvoir se faire en effet (j'avais zappé cet aspect du journal lors de ma réponse).

Shadow ? Stadia ? GeforceNow ça te parle ?

Non, désolé.
Du coup, tu pourrais expliquer dans les grandes lignes comment ça marche?

Personnellement, je sais que, quand le serveur est un peu trop loin de chez moi, que je passe les 100ms de ping, je commence déjà à le ressentir. Alors c'est sûr qu'il reste de la bande passante de libre (enfin, quand mon FAI merde pas, mais quand il merde de toute façon même "un solitaire multijoueur" ça serait compliqué…).

Je lis:

Nvidia recommended a 50 Mbit/s internet connection for the 1080/60p stream, but the service can also stream at 720p/60p for 25 Mbit/s connections,

ainsi que:

720p (1280×720 px

Effectivement, la compression semble impressionnante, sur le papier: le 720p se rapproche de mon écran le plus pourri, sans l'atteindre tout à fait (HD hein?). Par contre, ça consomme quand même du 25Mbit/s, même si mon FAI ne déconnait pas à bloc ces derniers mois, ça me serai impossible ici, et non, le 30 frames par seconde ne serait pas acceptable pour certains jeux.
Faudrait que j'essaie, pour voir, je suis curieux de savoir à quel point elle l'est: lossless ou pas, pour commencer, et si sans pertes, alors à quel point la dégradation est sensible.

Et malgré la lecture de l'article nvidia, je n'ai toujours aucune idée des contraintes techniques. Est-ce que le jeu est compilé avec le support d'une implémentation spécifique (voire propriétaire?) de sorte à ne faire que pré-calcul, plutôt que d'envoyer les trames brutes?

Bref, non, je ne connais pas. J'aimerai bien connaître, au moins d'un point de vue technique.
Du coup, j'aimerai bien que tu m'en dises plus, tu as l'air de considérer que tout ça est une évidence, et que ça s'applique donc à ce que n'importe qui peut se mettre en place chez lui… tu devrais pouvoir expliquer tout ça à l'inculte que je suis.

Tout est dans le titre.

Si le but est d'utiliser le GPU d'une machine distante, ça veut dire que les trames graphique de ton jeu doivent transiter directement sur le réseau, après "compilation" par OpenGL.
Concrètement, avec mes écrans (de mauvaise qualité), j'ai une résolution de 1366*768 et 1280*1024, 32 bits par pixel, bien qu'utiliser que 24 ferais le job (utilisons ça pour l'estimation).
Cela fait donc 3073.5 et 3840 kibioctets par trame.

Supposons que l'on veuille 60 trames par seconde: ça donne 180 et 225 Mebioctets par seconde à transférer. Avec des écrans de merde.
Alors, oui, on peu compresser, et gagner un peu de bande passante. Sauf que selon le jeu auquel tu joues, il ya des chances que tu ne gagneras pas tant que ça (les graphismes modernes sont parfois sublimes) sans perte de qualité.
Au fait… les débit des réseaux sont indiqués en bits par seconde, multiplions donc par… 8: 1440 Mib/s et 1800 Mib/s. Je n'ai pas pris en compte les coûts inhérents aux protocoles (probablement négligeables), ici, uniquement le poids de l'affichage. Même avec une compression de 50% (pas impossible, en fonction du jeu, on peut même aller plus loin, beaucoup plus loin) cela restera extrêmement gourmand en bande passante: ton réseau pourra-t-il l'encaisser?

Autre problème de performance, la latence: le réseau à une vitesse bien précise. Si tu as fibré entre tes machines, peut-être que c'est négligeable. Moi, ici, en wifi pour contacter la box (littéralement) derrière moi (pour des raisons de câble, je préférerai un bon ethernet mais… bref c'est pas le sujet) j'ai une latence de 130ms (c'est très surprenant d'ailleurs, je flaire le problème, je m'attendais à une poignée de ms, moins de 10).
C'est évidemment un problème (selon les jeux), puisque même si tu envoies beaucoup de trames par seconde, tu auras un délai évident.
Si en plus tu ajoutes de la compression pour avoir plus d'images, ben… tu augmentes tes délai, mécaniquement: il faut compresser, puis décompresser.

Dernier point: l'usage d'un réseau implique de partager la ressource. À la fois avec les autres utilisateurs du réseau, mais aussi avec les autres applications de ton poste. Ce qui va ajouter à la charge de ton réseau, et ce, surtout si tu as des applications qui "découvrent automatiquement", comme des imprimantes, un partage de fichiers, etc… parce que cela fonctionne avec du broadcast, augmentant l'occupation du point central et polluant les ressources des autres machines (bande passante, temps CPU).

Bref, pour jouer à un jeu en tour par tour, je pense que c'est faisable. Pour jouer à un RTS lent, peut-être. Pour un jeu nécessitant du réflexe et de l'adresse, c'est mort.

Alors pourquoi chiffrer si le but n'est pas d'avoir une communication dont on est sûr qu'elle est confidentielle ? Autant transmettre en clair.

Tout à fait. Personnellement, une simple signature type GPG serait à mes yeux largement suffisante pour de très nombreux cas d'usages du web.
Le chiffrement est parfois utile, je ne le nie pas (pas envie que les empreintes de mon code bancaire passent sur un réseau en clair…).
Si la signature change, je suis prévenu, et je peux me méfier. Si c'est un site sur lequel je vais souvent, il est possible que j'aie été prévenu à l'avance du changement. Il est aussi envisageable de signer la nouvelle clé avec l'ancienne.

Tout ça fonctionne. D'ailleurs, contrairement au modèle usité par le web, le TOFU permets de donner à quelqu'un une URI et une empreinte, de sorte à s'assurer qu'on parle de la même chose.
Dans le cas du web, c'est probablement faisable, mais clairement pas la philosophie retenue.
J'allais dire:

À la place, on à préféré fustiger les gens qui osent ne pas mettre en place l'usine à gaz nécessaire à la chaîne de confiance en disant "attention! danger! Vite, sauvez-vous!".

Mais après vérification, ce n'est pas le cas sur mes 2 navigateurs. J'étais pourtant persuadé d'avoir eu à contourner des écrans à la con pour ce type d'accès par le passé, du coup j'imagine que je me suis fait des films. Ou alors, ça a changé pour revenir à un comportement plus sain. Les deux sont possibles…

En cas de changement de clef, je n'ai aucun moyen de savoir si un changement de clef est légitime ou pas.

Et je n'ai aucun moyen de savoir avec le web qu'il n'y a pas de typo-squatting, ni aucun moyen d'être sûr que le domaine n'a pas été racheté au bon moment et un site à la même tronche mis en place.
Je n'ai donc aucune garantie dans les deux cas, à la première visite. Lors de la seconde, en revanche, avec un TOFU… si pas encore lu, voir le début de ce message (évitons une boucle infinie).

Un peu comme si tu avais une imprimante et qu'elle avait des soucis de bourrage et que au lieu de vouloir changer le drivers, tu accuses tous ces super papiers A4 avec des chatons en filligrammes pour faire du scrap booking.

Disons qu'avec une imprimante, il y a de grandes chance qu'une poignée d'individus puissent écrire un nouveau driver, alors qu'avec le web, plus d'un projet amateur s'y est essayé (et certains persistent, et jusqu'à présent, outre mozilla et google, personne ne parviens à supporter le web moderne complètement.
D'ailleurs, selon le navigateur que j'utilise, certains sites marchent, ou pas, donc j'imagine que c'est aussi valide pour les grands.

Je me demande, ça ne serait pas tout simplement lié au bloat, qui a pu être supprimé?

Par exemple, Debian à la (fâcheuse, pour mon usage à moi, bénéfique, compte tenu de leur ambition à l'universalité) tendance d'activer un maximum d'options lors de la compilation des paquets. Ce qui a causé de très, très gros problèmes de performances avec notamment la SDL: la plupart des programmes utilisant la SDL n'utilisent pas son support de DBus (je n'en connais aucun, en fait, mais je dis la plupart pour me garder une marge d'erreur…), mais SDL avait un bug bien sale lié à DBus qui bouffait la totalité du CPU pour que dalle, à flooder stdout/stderr (je me souviens plus) etc etc.
Bug que j'ai résolu à l'époque en compilant moi-même la SDL (depuis le paquet source debian) en virant toutes les dépendances inutiles (pour moi, j'entend et j'insiste) au passage.

J'ai appliqué la même chose sur un nombre réduit de paquets (mpv et mpd), le gain n'est pas super sensible (sur ma machine), certes, mais pas improbable qu'il existe bel et bien, malgré la faible échelle.

Il ne faut pas oublier que chaque dépendance, surtout des bibliothèques partagées, aura un impact à minima au chargement (résolution des symboles, vérifications des dépendances, voire tout simplement plus de données à lire depuis le disque dur!) et une distro qui installe moins de choses sera très probablement plus rapide.

Tiens, il y a des gens qui arrivent à utiliser minicom? Surprenant… quand j'ai dû interagir avec des ports série, j'ai trouvé microcom nettement plus facile à utiliser, et pourtant, c'est un outil des plus primitifs, et pour cause, il s'agit d'un des applets de busybox.
Configurer minicom, c'est un sacré bordel. Microcom impose de passer les options en ligne de commande, certes, mais au moins il n'essaie pas de modifier des trucs dans /etc par défaut. Quitte à utiliser un outil moins austère, clairement je privilégierai putty à minicom.

Au cas où, les raisons pour lesquelles je n'ai pas utilisé putty sous linux sont, dans l'ordre:

1) je n'y ai pas pensé, tellement à faire l'amalgame "putty == client ssh pour windows"… je continue parce que les autres raisons auraient été valables, si j'y avais pensé:
2) microcom (comme minicom) permets d'intervenir via une liaison ssh, depuis un headless
3) utiliser microcom avec un outil comme chat ou expect est plus simple, vu que c'est pas graphique

En vrai s'ils installent un Linux sur leur matériel ils pourraient toujours continuer à l'utiliser.

C'est donc plutôt l'OS non-libre qui est source d'obsolescence. Grâce à une navigateur OSS ils ont put pousser les limites mais à un moment l'OS te limite.

J'ai lu sans trop m'attarder sur les détails, j'ai sauté de larges portions de texte qui ne traitaient pas du "why", vu que c'est la seule section qui m'intéressait (toujours intéressant de savoir pourquoi quelqu'un lâche l'affaire je trouve), mais à moins que je n'aie raté un gros truc, le problème n'est pas l'OS, il n'en parle d'ailleurs jamais.

Quelques morceaux choisis:

and keeping up with new web features

Now that Firefox is on a four-week release schedule, it's just more than I feel I can continue

Besides various layout and DOM features we don't support well like CSS grid, there are large JavaScript updates we'll increasingly need which are formidably complex tasks.

Writing and maintaining a browser engine is fricking hard and everything moves far too quickly for a single developer now

You can make workarounds to gracefully degrade where we have missing HTML or DOM features, but JavaScript is pretty much run or don't,

the liberties taken by JavaScript minifiers are demonstrably not portable

Clairement, ces points me semble conforter la thèse que le web est source d'obsolescence.
D'ailleurs, il ne reste que 2 et demi (1) moteurs de rendu développés, dont un seul est toujours dans les mains du développeur initial (mozilla). Les autres sont des jouets. Tous, sans exception.
Et en réalité, ceux qui se basent sur blink sont "juste" des forks de chromium, il n'y a pas, à ma connaissance, d'application embarquant blink sans être un fork de chromium.

Le rythme de mises à jour frénétique des clients est probablement la 2nde grosse preuve du côté obsolescence-friendly du web, sans parler de la consommation de ressources croissante, le tout pour faire des choses que bien souvent on pourrait faire en natif plus efficacement (mais temps et coûts de développement initiaux largement supérieurs. Pour la maintenance, je n'en suis pas sûr, je ne serais pas surpris que le moyen ou long terme soit nettement moins cher avec du natif, mais je n'ai aucune preuve).

1: le demi, c'est webkit, parce que blink est un fork, et que webkit me semble à bout de souffle, je ne serai pas surpris d'apprendre sa mort dans peu de temps, disons 2 ans, max?

Il ne l'a jamais été…

Une forge logicielle, ce n'est pas juste un gestionnaire de version, ça se saurait, autrement.
Je dirais même que le composant le plus important d'une forge logicielle, c'est le bug-tracker, pas le logiciel de versionning.

Je note, ça pourra me servir!

Même si juste améliorer le visualiseur risque fort d'être très loin du confort des man-pages:

• une man-page par logiciel, parfois plusieurs dans quelques rares cas (zsh),
• dont le nom est même auto-complété (avec zsh, du moins),
• mémoire musculaire :)