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.
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.
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…
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).
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.
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?
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.
Et comme j'utilise moi même gcc et python3 (par exemple pour mes cours), je crois que je n'ai jamais eu de machine où ils n'étaient pas installés !
Python est assez omniprésent oui, je ne dis pas le contraire.
J'essaie d'avoir un système python-free pour des raisons bien à moi, qui ne sont pas pertinentes ici, mais ça ne m'empêche pas de rester pragmatique et de l'utiliser quand même: je ne me vois pas me passer d'outils tels que zim, zenmap, gparted… tant que je ne leur trouve pas un remplaçant qui tienne la route, python me sera nécessaire.
Je sais faire la différence entre l'idéal (le mien, pour mes raisons à moi) vers lequel je tend et le présent ou j'ai besoin de mes outils même s'ils ne cochent pas toutes les cases :)
Le point de mon message était uniquement d'apporter des précisions.
A ce jour, j'utilise encore DIA pour avoir un qqch de potable visuellement
Dia… j'aimais bien aussi, et je l'utilise encore de temps en temps, mais j'en suis largement insatisfait, tout en n'ayant rien trouvé de mieux…
Énormément de place est gâchée par les barres d'outils et règles, qu'il faut virer à chaque démarrage de l'application.
L'édition de chaque table demande une utilisation trop importante de la souris, c'est long, très, très long pour juste modifier un champ (d'un autre côté, c'est un éditeur de diagramme, pas d'UML ni de merise. M'enfin quand même, le dialogue de modif pourrait être moins pire…).
Les relations sont… bon, c'est soit se les tapper et les maintenir à la main (genre, chaque angle, et refaire au moindre déplacement) soit avoir un truc difficilement lisible.
De même, impossible de savoir quand 2 relations se croise s'il s'agit d'une fourche (plusieurs relations qui avant avaient le même trajet se séparent) ou si l'une "passe au-dessus" de l'autre.
Bref, je l'utilise à défaut de mieux, mais j'aimerai trouver mieux. Par contre, j'insiste pour que l'outil soit installable facilement en off-line, parce que le réseau quand il lâche, c'est bien de pouvoir accéder aux graphes qui le documentent, ou le modifier :)
Il y a longtemps j'utilisais Bouml, mais ça ne sert que pour l'uml d'une part, et d'autre part, c'est trop compliqué pour 90% des usages que j'en aurai, l'interface se mets également dans les pattes de l'utilisateur je trouve. J'imagine que pour un gros, gros logiciel ça peut servir, cependant.
Sinon, je serais curieux de savoir ce que les gens qui gèrent des réseaux (LAN/WAN) utilisent, pour documenter liens physiques, emplacements des services, ce genre de choses? Dia peut faire le boulot en partie, mais c'est assez limite je trouve.
Oui. Mais quand on veut évincer quelqu'un d'une organisation pour la défense des logiciels libre, le minimum, c'est d'utiliser des outils libres quand le choix existe. Et il existe, je connais, comme tout le monde ici, au moins 1 forge dont a minima le coeur est libre.
Notes bien que je parle bien du coeur, parce que gitlab est loin d'être idéal, mais ça serait toujours mieux et crédible que github. Ici, il faut utiliser un logiciel non-libre pour signer la pétition qui à pour but d'évincer le père du libre et tous les dirigeants d'une association qui défend le logiciel libre.
En terme de crédibilité, c'est plus que douteux.
Par problèmes de sécurité, tu entends juste pénétration de système, ou tu inclues la possibilité de se faire passer pour un site tiers? Qu'appelles-tu récent?
Pour moi, 10 ans et moins, c'est acceptable sous l'étiquette de "récent", donc ce qui est mentionné ici est valide. Ce n'est pas une liste exhaustive, mais j'ai la flemme de chercher.
Alors, bien sûr, ça date de 2015 (je n'ai pas cherché trop longtemps) ça a été corrigé depuis, etc, etc.
Mais il n'empêche que la méthode simple pour certbot, celle que quelqu'un qui veut héberger un blog sans trop se prendre la tête appliquera, c'est: un serveur http qui supporte CGI, et certbot qui tourne en tant que root.
On peut faire autrement, je sais, en n'utilisant pas le challenge http, mais les autres nécessitent clairement plus de compétences.
Tout ça pour un blog ou un site perso?
Je trouve clairement que c'est overkill, que ça augmente drastiquement la surface d'attaque de la machine, et j'ai également cité des liens montrant des problèmes de sécurité avérés, et liés au web au trust.
Personnellement, je penseque la chaîne de confiance c'est bien: pour les applications web qui impliquent un login et qui manipulent des données sensibles, comme ma banque.
Mais pour aller lire un blog? Je n'en vois clairement pas l'intérêt. Tu dis que le maillon est pété d'office, mais le truc c'est qu'il n'y a pas de maillon, justement.
Tiens d'ailleurs, tu considères que le modèle de sécurité d'OpenSSH est pété par défaut? Parce que c'est le même par défaut.
killall et fuser ne servent pas, mais on utilise pstree dans la mission 25.
C'est dans psmisc, tout ça, pas dans x11-utils.
Je ne suis pas sûr que gcc et python3 soient présents sur une installation minimale.
Ils ne le sont pas.
D'ailleurs, je n'ai que quelques applications qui me tirent python, dans la pratique je peux très bien le virer et conserver mon système avec mon player musical (mpd), mon lecteur video (mpv), mes navigateurs (vivaldi, firefox), mon MUA (claws) tout ce qu'il y a de plus fonctionnel.
Bon, je triche: j'ai recompilé mpv et mpd pour virer le support de samba, qui dépend de python.
En gros, j'ai besoin de python pour: scons, meson (qui sont utilisés pour compiler des jeux), zenmap, blender, zim et… c'est tout, en fait. Le seul outil qui me soit réellement utile fréquemment dans cette liste, c'est zim (que d'ailleurs je ne serais pas contre de remplacer, parce que python2+gtk2… et tant qu'a faire, remplacer pour un soft qui n'utilise ni gtk (et surtout pas gtk3!), ni python).
Pour ce qui est de gcc, il n'est même pas installé dans une installation par défaut de Debian il me semble, même pas besoin d'être minimaliste.
Désolé, mais des gens qui mettent une pétition sur GitHub pour virer toutes les têtes dirigeantes de la FSF, pour moi, ce sont des gens qui n'en ont rien à foutre du libre, et je ne vois donc aucune raison de les écouter quand ils parlent de modifier la gestion d'une organisation dont le combat principal (voire unique?) est la défense du logiciel libre.
RMS et les autres peuvent avoir leurs opinions et comportements, qui peuvent ne pas plaire à certains individus à la morale chatouilleuse, pourquoi pas.
Mais qu'au moins ces gens fassent preuve de cohérence: s'ils pensent que RMS fait du mal au libre, s'ils veulent faire une pétition pour le virer ainsi que tout "le bureau" de la FSF, soit, mais au moins qu'ils le fassent avec une solution qui ait un semblant de LL!.
S'ils veulent utiliser une forge pour ça, soit. Mais pourquoi utiliser celle qui est le plus loin d'être compatible avec le libre? Même sourceforge est mieux placé de ce point de vue, si ma mémoire est bonne, vu qu'ils se basent ou se sont basés sur un fork d'un LL.
[^] # Re: Second degrés
Posté par freem . En réponse au journal Systemd à la maison. Évalué à 10.
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:
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.
[^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...
Posté par freem . En réponse au journal Jouer à distance avec du logiciel libre. Évalué à 2.
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:
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:
puis:
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é"?
[^] # Re: Inspiration
Posté par freem . En réponse à la dépêche GNOME annonce la nouvelle bibliothèque libadwaita. Évalué à 4.
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).
[^] # Re: pas tout seul
Posté par freem . En réponse au journal Nostalgie d'Internet des années 2000.. Évalué à 6.
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.
[^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...
Posté par freem . En réponse au journal Jouer à distance avec du logiciel libre. Évalué à 2.
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…
[^] # Re: clé sous la porte??
Posté par freem . En réponse au journal Oracle vs Google. Évalué à 6. Dernière modification le 09 avril 2021 à 10:09.
OU alors ils ont autant d'actions chez l'un que chez l'autre, du coup peu importe :)
[^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...
Posté par freem . En réponse au journal Jouer à distance avec du logiciel libre. Évalué à 1.
C'est vrai.
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).
[^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...
Posté par freem . En réponse au journal Jouer à distance avec du logiciel libre. Évalué à 2.
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:
ainsi que:
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.
# Faire le rendu à distance sans problèmes de performance? Compliqué...
Posté par freem . En réponse au journal Jouer à distance avec du logiciel libre. Évalué à 2.
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.
[^] # Re: M'ouaif
Posté par freem . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 3.
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:
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…
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).
[^] # Re: Le billet original
Posté par freem . En réponse au lien TenFourFox, le cousin de Firefox, va dire adieu aux vieux Mac. Évalué à 2.
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.
# Lié au bloat?
Posté par freem . En réponse au journal Un mois avec Clear Linux. Évalué à 5.
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.
[^] # Re: putty & linux-tkg
Posté par freem . En réponse au journal Un mois avec Clear Linux. Évalué à 3.
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
[^] # Re: Le billet original
Posté par freem . En réponse au lien TenFourFox, le cousin de Firefox, va dire adieu aux vieux Mac. Évalué à 4.
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:
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?
[^] # Re: Ça pue c'est pas libre.
Posté par freem . En réponse au journal RMS et la FSF. Évalué à 1.
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.
[^] # Re: Memory leak et warnings
Posté par freem . En réponse au journal 723, +5736, -5696… un mois de travail de résurrection d'un projet libre…. Évalué à 2. Dernière modification le 31 mars 2021 à 11:07.
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:
[^] # Re: dépendances
Posté par freem . En réponse à la dépêche GameShell, apprendre les rudiments du shell en s'amusant. Évalué à 2.
Python est assez omniprésent oui, je ne dis pas le contraire.
J'essaie d'avoir un système python-free pour des raisons bien à moi, qui ne sont pas pertinentes ici, mais ça ne m'empêche pas de rester pragmatique et de l'utiliser quand même: je ne me vois pas me passer d'outils tels que zim, zenmap, gparted… tant que je ne leur trouve pas un remplaçant qui tienne la route, python me sera nécessaire.
Je sais faire la différence entre l'idéal (le mien, pour mes raisons à moi) vers lequel je tend et le présent ou j'ai besoin de mes outils même s'ils ne cochent pas toutes les cases :)
Le point de mon message était uniquement d'apporter des précisions.
[^] # Re: Créer un MDP sexy avec quel outil ?
Posté par freem . En réponse au journal Graph my database. Évalué à 4.
Dia… j'aimais bien aussi, et je l'utilise encore de temps en temps, mais j'en suis largement insatisfait, tout en n'ayant rien trouvé de mieux…
Énormément de place est gâchée par les barres d'outils et règles, qu'il faut virer à chaque démarrage de l'application.
L'édition de chaque table demande une utilisation trop importante de la souris, c'est long, très, très long pour juste modifier un champ (d'un autre côté, c'est un éditeur de diagramme, pas d'UML ni de merise. M'enfin quand même, le dialogue de modif pourrait être moins pire…).
Les relations sont… bon, c'est soit se les tapper et les maintenir à la main (genre, chaque angle, et refaire au moindre déplacement) soit avoir un truc difficilement lisible.
De même, impossible de savoir quand 2 relations se croise s'il s'agit d'une fourche (plusieurs relations qui avant avaient le même trajet se séparent) ou si l'une "passe au-dessus" de l'autre.
Bref, je l'utilise à défaut de mieux, mais j'aimerai trouver mieux. Par contre, j'insiste pour que l'outil soit installable facilement en off-line, parce que le réseau quand il lâche, c'est bien de pouvoir accéder aux graphes qui le documentent, ou le modifier :)
Il y a longtemps j'utilisais Bouml, mais ça ne sert que pour l'uml d'une part, et d'autre part, c'est trop compliqué pour 90% des usages que j'en aurai, l'interface se mets également dans les pattes de l'utilisateur je trouve. J'imagine que pour un gros, gros logiciel ça peut servir, cependant.
Sinon, je serais curieux de savoir ce que les gens qui gèrent des réseaux (LAN/WAN) utilisent, pour documenter liens physiques, emplacements des services, ce genre de choses? Dia peut faire le boulot en partie, mais c'est assez limite je trouve.
[^] # Re: Ça pue c'est pas libre.
Posté par freem . En réponse au journal RMS et la FSF. Évalué à 2.
Oui. Mais quand on veut évincer quelqu'un d'une organisation pour la défense des logiciels libre, le minimum, c'est d'utiliser des outils libres quand le choix existe. Et il existe, je connais, comme tout le monde ici, au moins 1 forge dont a minima le coeur est libre.
Notes bien que je parle bien du coeur, parce que gitlab est loin d'être idéal, mais ça serait toujours mieux et crédible que github. Ici, il faut utiliser un logiciel non-libre pour signer la pétition qui à pour but d'évincer le père du libre et tous les dirigeants d'une association qui défend le logiciel libre.
En terme de crédibilité, c'est plus que douteux.
[^] # Re: M'ouaif
Posté par freem . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 2.
Par problèmes de sécurité, tu entends juste pénétration de système, ou tu inclues la possibilité de se faire passer pour un site tiers? Qu'appelles-tu récent?
Pour moi, 10 ans et moins, c'est acceptable sous l'étiquette de "récent", donc ce qui est mentionné ici est valide. Ce n'est pas une liste exhaustive, mais j'ai la flemme de chercher.
Sinon, plus récent, pas lié en soit au modèle en chaîne, mais lié à let's encrypt: https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf-4Yc/
Alors, bien sûr, ça date de 2015 (je n'ai pas cherché trop longtemps) ça a été corrigé depuis, etc, etc.
Mais il n'empêche que la méthode simple pour certbot, celle que quelqu'un qui veut héberger un blog sans trop se prendre la tête appliquera, c'est: un serveur http qui supporte CGI, et certbot qui tourne en tant que root.
On peut faire autrement, je sais, en n'utilisant pas le challenge http, mais les autres nécessitent clairement plus de compétences.
Tout ça pour un blog ou un site perso?
Je trouve clairement que c'est overkill, que ça augmente drastiquement la surface d'attaque de la machine, et j'ai également cité des liens montrant des problèmes de sécurité avérés, et liés au web au trust.
[^] # Re: M'ouaif
Posté par freem . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 2. Dernière modification le 28 mars 2021 à 16:00.
En quoi c'est pété d'office, en fait?
Personnellement, je penseque la chaîne de confiance c'est bien: pour les applications web qui impliquent un login et qui manipulent des données sensibles, comme ma banque.
Mais pour aller lire un blog? Je n'en vois clairement pas l'intérêt. Tu dis que le maillon est pété d'office, mais le truc c'est qu'il n'y a pas de maillon, justement.
Tiens d'ailleurs, tu considères que le modèle de sécurité d'OpenSSH est pété par défaut? Parce que c'est le même par défaut.
[^] # Re: Memory leak et warnings
Posté par freem . En réponse au journal 723, +5736, -5696… un mois de travail de résurrection d'un projet libre…. Évalué à 3.
Merci bien. Le fait que gcc (et clang, d'ailleurs) n'ait pas de man-pages est bien pénible, et je n'arrive jamais à utiliser info.
[^] # Re: dépendances
Posté par freem . En réponse à la dépêche GameShell, apprendre les rudiments du shell en s'amusant. Évalué à 2.
C'est dans psmisc, tout ça, pas dans x11-utils.
Ils ne le sont pas.
D'ailleurs, je n'ai que quelques applications qui me tirent python, dans la pratique je peux très bien le virer et conserver mon système avec mon player musical (mpd), mon lecteur video (mpv), mes navigateurs (vivaldi, firefox), mon MUA (claws) tout ce qu'il y a de plus fonctionnel.
Bon, je triche: j'ai recompilé mpv et mpd pour virer le support de samba, qui dépend de python.
En gros, j'ai besoin de python pour: scons, meson (qui sont utilisés pour compiler des jeux), zenmap, blender, zim et… c'est tout, en fait. Le seul outil qui me soit réellement utile fréquemment dans cette liste, c'est zim (que d'ailleurs je ne serais pas contre de remplacer, parce que python2+gtk2… et tant qu'a faire, remplacer pour un soft qui n'utilise ni gtk (et surtout pas gtk3!), ni python).
Pour ce qui est de gcc, il n'est même pas installé dans une installation par défaut de Debian il me semble, même pas besoin d'être minimaliste.
# Ça pue c'est pas libre.
Posté par freem . En réponse au journal RMS et la FSF. Évalué à 1.
Désolé, mais des gens qui mettent une pétition sur GitHub pour virer toutes les têtes dirigeantes de la FSF, pour moi, ce sont des gens qui n'en ont rien à foutre du libre, et je ne vois donc aucune raison de les écouter quand ils parlent de modifier la gestion d'une organisation dont le combat principal (voire unique?) est la défense du logiciel libre.
RMS et les autres peuvent avoir leurs opinions et comportements, qui peuvent ne pas plaire à certains individus à la morale chatouilleuse, pourquoi pas.
Mais qu'au moins ces gens fassent preuve de cohérence: s'ils pensent que RMS fait du mal au libre, s'ils veulent faire une pétition pour le virer ainsi que tout "le bureau" de la FSF, soit, mais au moins qu'ils le fassent avec une solution qui ait un semblant de LL!.
S'ils veulent utiliser une forge pour ça, soit. Mais pourquoi utiliser celle qui est le plus loin d'être compatible avec le libre? Même sourceforge est mieux placé de ce point de vue, si ma mémoire est bonne, vu qu'ils se basent ou se sont basés sur un fork d'un LL.
Bref: qu'ils aillent balayer devant leur porte.
[^] # Re: M'ouaif
Posté par freem . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 2.
On reparle de la chaîne de vulnérabilitéW confiance du web, et de ce qu'il se passe quand un maillon pète?