A 100% non, car comme dit par ailleurs tu auras toujours des FW non libres qui seront présents dans un matériel ou nécessaires au démarrage du processeur.
Tu peux toujours les considérer comme liés au matériel et laisser la version résidente qu'ils embarquent en majorité en refusant d'installer un paquet firmware-XXX non libre.
Mais c'est s'exposer à des problèmes, car ces firmwares peuvent avoir des bugs!
Exemple perso: Il y a quelques mois, un problème de raspbian bloquait le chargement du firmware bluetooth des raspberry PI 3.
Pas de bol, je l'utilise pour ma domotique afin de savoir qui est à la maison (via les smartphones) et adapter sa gestion (+activation/désactivation alarme).
Je me suis rendu compte du souci car au bout de qq heures, le bluetooth du PI plantait totalement… et arrivait même parfois à planter le bluetooth du smartphone Android en face!
Le firmware résident avait visiblement un bon gros bug corrigé par la version chargée au démarrage.
Il y a un niveau ou placer le curseur, car avant même ce qui peut être chargé par l'OS il y a ce qui démarre bien avant qu'il ait la main sous forme de processeurs de service et/ou de sécurité. Sachant que tous fournissent des services à l'OS ensuite. Un mal qui s'est bien généralisé depuis Intel et son ME. Arm devient d'une certaine manière presque pire niveau étages de la fusée au démarrage!
C'est un problème non seulement pour le SW, mais aussi le HW: Intel est ainsi en position d'imposer sa façon de faire en refusant la mise à disposition des firmwares non signés par exemple, ce qui interdit de fait de faire son propre boot loader si on ne veut pas passer par un éditeur de BIOS (qui lui y aura accès grace à une relation "privilégiée", ainsi qu'aux reference code/RC, dont celui très complexe d'init du controleur DDR/MRC, alors que coreboot ne se voit proposer à reculons que des blobs binaire, version compilée des RC/MRC).
Les derniers processeurs modernes sur lesquels j'ai bossé ou l'on pouvait tout faire sans que le fondeur n'interfère trop (voir pas du tout si pas de besoin des accélérateurs réseau) étaient des PowerPC Freescale dédiés à l'embarqué (utilisés surtout en infra Télécom jusqu'à la 4G/LTE, puis une fois bien débogués par cet usage, en avionique).
Mais le PowerPC, lâché par les télécoms, ne vit plus guère que chez IBM côté serveurs. Et il y a probablement subi les mêmes dérives depuis le schisme d'avec Motorola semiconducteurs (devenu Freescale puis NXP).
Il ne doit pas être évident contre un mur d'éviter qu'elles ne puissent passer puis grimper. Pour ma part, suite à une infestation de puces localisée au fond du jardin en juillet, après avoir hébergé une portée de hérissons dans une cabane faite pour eux, à la fin du printemps (ne pas croire ce qu'on lit, qu'elles sont propres aux hérissons et ne vont pas ailleurs: Conneries!), j'ai découvert la terre de diatomée.
Au départ, j'ai cramé le secteur le plus touché avec le brûleur de mauvaise herbe à gaz puis ne voulant utiliser d'insecticide (j'apprécie également l'aide des cox et puis mon chat est souvent dans le coin même si là, il évitait), j'ai cherché autre chose: Les qq jours pour que les oeufs passés à travers le brûlage ne repeuplent le secteur laissaient le temps d'une recherche/commande…
En fait, ca a été très efficace sur les pucerons mais aussi sur les fourmis (j'ai eu un nb de fourmilières conséquent cette année). Niveau application, le mieux que j'ai trouvé est une boite à café expresso moulu métal à couvercle plastique (pour pouvoir fermer/secouer après remplissage) dont le fond est percé d'une constellation de coups de tournevis.
On remplit dans le seau de terre de diatomée (on trouve des formats "poulailler" de 5 ou 10l économiques), ferme la boite et on secoue/distribue aisément aux lieux de passage/pieds d'arbres ou de mur.
Le mode d'action est purement mécanique: Ça leur grippe/détruit littéralement les rouages de l'exosquelette et ces insectes se vident/meurent. Sans produit chimique. Les cox n'allant pas au sol, aucun souci pour elles.
Cela résiste à quelques épisodes pluvieux si pas trop de ruissellement: Pas pire qu'un insecticide qui sera lessivé, voir même mieux.
J'avais suivi le même chemin quand Gnome 3 est arrivé. Désormais, c'est la machine qui décide:
-Potable : Cinnamon.
-Vieux clou/netbook en sursis: Mate, ce dernier était quand même meilleur niveau fonctionnalités qu'un XFCE ou autre bureau réputé léger… sans forcément être notablement plus lourd à l'usage.
Ce qui m'inquiète, c'est le futur de Cinnamon sous Debian vu que le mainteneur est passé à KDE.
Pas envie de revenir à Mint et une base Ubuntu lâchée depuis 2010 en raison de l'accumulation de mauvaise graisse (je suis passé à cette époque de plus facile de rajouter ce qui manque à une Debian minimale que de retirer ce qui est en trop d'une Ubuntu ayant grossi) et aussi, de leur côté, d'un délire sur les DE que ne renierait pas Gnome depuis sa funeste version 3.
Arghhh, le truc qui m'agace: Tu veux coller une fenêtre qqpart et on te la retouche… et il faut aller chercher les obscurs réglages pour signifier au DE "touche à ton c.."!
J'en serais étonné: Orange n'a jamais eu un SIP standard contrairement à d'autres.
Alors certes on a un réseau correct et quand il y a un problème ils s'en occupent, mais pour pouvoir utiliser librement ce a quoi son abonnement donne pourtant droit (téléphoner en SIP de son PC, une API pour envoyer des SMS autrement que via leur site et le navigateur), on part chez eux de très loin.
Ce type de réglementation déclinée chez nous les obligerait à évoluer, au moins sur la partie téléphonie.
L'envoi de SMS m'aurait rendu service pour mes notif domotique par exemple: No way…
Le SIP, même pas forcément pour téléphoner d'un PC en plus du fixe DECT, permettrait de récupérer l'identifiant appelant sans matériel supplémentaire de de filtrer les appels de pubeux d'un décroché/raccroché par exemple.
Pour cette dernière fonction filtrage, n'utilisant pas le RJ11 de la livebox pour le fixe (tout en DECT utilisant la base intégrée à la box), j'ai dû recycler un vieux modem 56k USB ayant la fonction caller ID…
Une alternative possible pour les notif vocales de ma domotique/alarme sur PI3, même si pour le moment ce bon vieil espeak, avec un peu de configuration et quelques libertés d'écriture pour obtenir une prononciation plus réaliste, fait l'affaire?
A priori toujours pas, vu que la config reste graphique et que mon système est installé sans support graphique (headless, l'interaction se faisant via un site ouèbe embarqué et l'administration via ssh)…
Pour les activités gravité et comprendre intuitivement comment cela fonctionne, je ne saurais trop recommander de s'inspirer d'un petit jeu qui avait pour ma part eu un succès très réel avec mes enfants, hélas peu voir plus maintenu (même si de vieux paquets peuvent encore s'installer sur une Debian actuelle): Slingshot!
Comme précisé, je ne suis pas allé très loin dans l'examen car j'apprécie vraiment la liberté laissée par le C. Et là je n'ai d'entrée pas trouvé mon compte pour du soft plateforme/bas niveau: La rapport bénéfice/emmerdement ne me parait pas positif.
Maintenant, pour de l'applicatif actuel (surtout en frontal avec l'extérieur) ou des ajouts du langage seront utiles (apports thread/reseau) autant que, par construction, limiter les erreurs possibles quasiment aux seules fautes de logique du programmeur, au bénéfice de la sécurité/fiabilité: OK, d'ailleurs Mozilla n'a-t'il pas crée ce langage exactement pour cela?
Je ne crois pas avoir dit le contraire… mais l'UEFI ne va pas gérer la mémoire virtuelle de l'OS, ses IT, sa configuration cache et les finasseries pour maintenir sa cohérence très dépendantes de l'architecture.
Je dirais même que l'UEFI est une saloperie codé cochon, qui crée des dépendances évitables entre le boot loader et l'OS… avec pour résultat un code de démarrage en 3 phases quasi étanches (SEC/PEI/DXE), faisant intervenir jusque 3 origines de sources (RC/MRC, les réference code Intel source clos fournis uniquement aux éditeurs de BIOS/UEFI ; EDK2, implémentation de référence tirée encore par Intel ; Code glue/menu/log/selection boot device… historique de l'éditeur de BIOS).
Cad que le code commun se retrouve souvent avec 3(SEC/PEI/DXE)x3(sources code RC/EDK2/Editeur intégrant le patchwork)=9 duplicats…
Tout ce qu'on essaie d'ordinaire d'éviter. Avec au final un tas de m…. de l'ordre de grandeur du kernel linux en nb de lignes de code juste pour booter la machine, fournir qq services à l'OS (car microsoft n'a jamais su s'en passer, cf les ancêtres "interruptions" BIOS des boot services UEFI actuels), après avoir fait l'énumération PCI.
Et un truc plus long en temps (chargé d'une flash SPI) d'execution que le démarrage de l'OS complet derrière.
Pour fournir quoi d'utile? Un menu de config assez basique et un shell pas sans rappeler la boite DOS (en particulier les scripts, on revient au temps du .BAT): Un u-boot qu'on a longtemps fait tenir sur un secteur de 512k de flash NOR sur du powerPC est de ce point de vue mieux foutu que ces BIOS qui réclament une flash de 16MB (avec les firmwares en pagaille, autre spécificité Intel).
Ces messages peuvent être vus comme un progrès pour ceux qui n'utilisent pas un mode de navigation privée, voir avaient depuis la nuit des temps configuré leur navigateur (proposant ces options, tel FF) pour vider la benne à ordure des pubeux de tout ordre à extinction.
On peut aussi vider la benne en cours de session à des moments opportuns, par exemple avant de se connecter à leur banque/site de commerce avec une intention d'achat, d'un Ctrl+Shift+Suppr.
=> Ceux là, soucieux des traces laissées chez eux depuis longtemps, sont au final ceux qui sont emmerdés par ces dispositions législatives très mal pensées car ils vont devoir refaire la manip (en général au plus rapide proposé, accepter tout, sachant que finasser est conçu pour être dissuasif) à chaque re-connexion.
Pour réconcilier tout le monde, ce type de disposition aurait dû être faite sur le mode du "do not track", voir en rendant ce dernier (pré-existant) équivalent à un "ne rien accepter" exclusif de tout questionnement et indépendant du vidage de la benne à cookie et données de sites diverses et avariées.
Comme avec bloctel (il eu mieux valu faire une chose très simple: Redonner un coût obligatoire aux appels vers fixe en faisant un illimité en mode mobile: Peu probable d'y arriver en usage individuel, par contre pas vraiment pour un centre d'appel) qui semble vous ramener plus d'appels qu'en éviter, nous sommes dans un pays qui aime faire des usines à gaz finissant à l'inverse du but visé.
Pour éviter les bidouilles!
On pourrait ajouter les variables static (là aussi, on peut bidouiller), facilitant l'utilisation purement procédurale du langage…
Les outils d'analyse de code C permettent en effet de compenser les avantages de conception de Rust, en évitant en prime de devoir cumuler (au niveau logiciel de base) la complexité de la machine (un processeur/SoC actuel) avec celle du langage (devoir en particulier en permanence s'embêter avec les problèmes d'appartenance).
Je n'ai pas étudié l'affaire de très près, ceci dit, mais vu de haut je vois plus Rust utile côté applicatif que pour coder un système d'exploitation voir ses modules/drivers.
Ce ne serait pas le 1er challenger du C de l'histoire à échouer!
Il y a des tas de choses à bas niveau qui sont propres à chaque architecture et qui n'ont pas leur place dans des langages de haut niveau, même ceux qui permettent déjà beaucoup de choses comme le C.
Sans même parler du strict démarrage (va appeler du C sans avoir initialisé une pile, donc une RAM qui est souvent un bout de mémoire cache plateforme dévoyé le temps de la complexe initialisation DDR!), niveau OS, toutes les primitives bas niveau touchant à la mémoire cache justement, la mémoire virtuelle, préfixes/postfixes d'interruptions, opérations atomiques (test&set)…
Cela ne représente plus grand chose (on n'écrit donc pas vraiment un OS en asm), même s'il y en a quand même de planqué ailleurs (sous forme d'asm inline) que dans des fichiers complets, mais c'est la portion inévitable.
En effet, mes 2 dernières installations:
-Un laptop perso acheté d'occase livré avec un Win10 home refurb sur un BIOS reconfiguré en legacy… mais qui repassé en UEFI, avait encore la clef 10 pro de la version constructeur bien au chaud… avant de lui mettre un double boot Debian.
-Puis une machine labo au taf, avec la clef de licence win7 pro OEM de l'étiquette (bouffée sans pb par l'installeur de 10: Ils ne veulent vraiment plus le vendre!), pour des softs d'analyseur logique, l'horreur Visual eBios d'AMI qui n'avait aucune chance de me réconcilier avec le patchwork Eclipse etc… dont les versions Linux ne sont hélas pas stables (Salae, si tu m'entends…).
Et franchement même réflexion: Zéro problème, fini la litanie d'une demi journée de reboot d'application séquentielle de tous les patchs mensuels depuis la sortie de la dernière ISO. Juste à ruser pour éviter le compte en ligne microsoft et se taper le moins de traceurs (télémétrie en novlangue microsoft) possible.
Au final, on arrive à avoir un système (certes moins complet on n'a pas une suite bureautique etc) qu'un Linux dans un temps à peine 2x supérieur à mon top chrono: La Debian Netinstall, qui charge direct tout un système à jour.
Franchement, cela me semble devenu très correct même si je n'apprécie pas win10 et ne l'utilise que dans des cas contraints (et toujours avec un Cygwin pour le rendre supportable).
Il faut dire qu'utiliser un clone Red-Hat ne se justifie vraiment que pour avoir une version d'OS homogène sur un parc matériel qui va forcément diverger sur les 10 ans de support assuré: Là, avoir Red-Hat qui se tape le boulot de backport du support du nouveau matériel arrivant en flux continu sur un kernel antédiluvien peut avoir une utilité.
Mais la contrepartie, c'est quand même des dépôts qui sont un vide absolu comparé à la richesse côté Debian. Les premiers mois/années, on peut au moins recompiler de manière a peu près fiable ce qui manque soit-même (pour éviter les acrobaties avec les dépôts de la Fée-Dora, sport de masse sous RH) mais cela se gâte très vite.
Pour ma part, entre la gestion de paquets inférieure (en disponibilité et à l'usage) et le cycle AMHA trop long, j'ai toujours trouvé que Debian offrait un meilleur compromis stabilité/nouveauté.
Scientific-Linux devenu un CentOS, après que RH ait déjà savonné la planche aux coucous d'Oracle, les jours de la "RH du pauvre" semblaient comptés. Car le débouché entre Fée-Dora et RH semble pour le moins limité.
Posté par lym .
En réponse à la dépêche Sortie de TIC‑80 version 0.80 .
Évalué à 1.
Dernière modification le 05 novembre 2020 à 16:52.
J'ai toujours mon EeePC901 avec son Atom 1er du nom si "poussif", actuellement avec une Debian 10 et bureau Mate qui n'est pas le plus léger qui soit. Ca reste utilisable. La seule modif avait été de lui payer une barrette de 2GB à la place de celle d'1GB d'origine (+, sans impact ici, carte wifi Ubiquity plus sensible que l'originale et pouvant cracher très au dessus des 100mW autorisés, import US oblige, qui accrochait sans problème des points d'accès à 500m, malgré les antennes internes, en vacances avant la baisse des forfaits data mobiles).
Pour le jeu, pas mal de jeux Linux un peu anciens tournent sans problème… d'encore plus anciens portages, type Doom, également: C'est pas neuf, mais ça reste d'un autre niveau qu'animer des sprites comme sur un Amstrad ou Commodore des années 80 tout de même.
Là si c'est un problème, c'est pas l'Atom qu'il faut blâmer!
Le plus incroyable avec cette petite machine comme on n'en fait hélas plus: Son autonomie, avec une batterie d'origine chargeant encore à 85% de sa capacité théorique. Du Asus de la décennie 2000, en résumé, même pour ce modèle alors low-cost.
Quand on voit qu'un A400M tout frais sorti de l'assemblage a été perdu (tuant l'équipage d'essai) car le FADEC (contrôle moteur), si des calibrations hélice manquaient, était capable d'accepter la puissance maximale au décollage mais qu'ensuite chaque réduction ne permettrait pas de remettre plus de puissance ultérieurement, on ne peut pas trop moquer Boeing hélas.
Et là, on n'a pas l'excuse de pousser à bout un design des années 60 pour économiser sur les requis d'issues de secours actuels, entre autres…
Le pire, c'est que c'était spécifié ainsi! Quel est l'âne qui a pu faire cela? Là ou cela se situe, il doit se faire tout petit outre rhin…
Pour le planeur vs avion de ligne, c'est pas si loin selon le planeur. Si les modèles de compétition sont vers les 60 de finesse, les bois et toile classiques pour l'instruction sont plutôt dans les de 25 à 30. Un avion léger d'aéroclub sera dans les 10/15.
Et puis quand on a un pilote de ligne vélivole à ses heures perdues aux commandes, la finesse d'un avion de ligne (dans les 20) peut vous sauver la vie: https://fr.wikipedia.org/wiki/Planeur_de_Gimli
Pourtant, il y a 25 ans, une personne faisait très bien ce travail seule en plus de pas mal de TP d'enseignement: http://patrick.ducrot.free.fr
Et pour la sécurité, je me souviens encore de ses images "Wanted" balancées régulièrement sur tout le réseau de machines Unix (servant à l'enseignement) visant avec humour le seul élève ayant réussi (pas bien longtemps, juste le temps de repérer un process inconnu rapidement décortiqué) à lui piquer son login. Le petit malin avait exploité (de mémoire) une faille liée au lecteur de disquettes 5"1/4 mis à dispo des élèves pour transférer leurs sources/fichiers de leurs PC perso, pour ceux qui en avaient…
Moi je n'avais pas fait si bonne pêche, avec mon chalut lancé à la même époque côté réseau PC (sous windows 3, de mémoire, à l'époque? Ils servaient alors à la bureautique) qui avait eu a peu près tous les élèves mais pas lui: Trop prudent déjà vis à vis des produits Microsoft, je pense qu'il ne se connectait que de son bureau avec sa machine, ce qui le rendait insensible à mon exploitation de l'ancêtre des services runtime UEFI: Les interruptions BIOS qui permettaient de mettre des hooks (tel un virus de secteur de boot, capacités de réplication en moins) sur les frappes clavier (permettant de récupérer tout ce qui suivait un mot clef type "login", "telnet"…) et accès disque (pour sauver cela, à des fins de glanage ultérieur, sur des zones de HDD inutilisées/cachées à l'OS). Un article cocasse dans le canard de l'école dont je dois toujours avoir copie quelque part avait cloturé ma 3ème année, exposant les mots de passe simplistes ou tout simplement drôles.
C'est triste de voir un Microsoft pourtant en perte de vitesse (hors bureautique et cloud) noyauter ainsi l'enseignement et la recherche. Mais dans le privé c'est pareil, y compris chez LE concurrent de Boeing: S'ils veulent refaire leur retard, au moins, ils n'auront pas à faire comme les Chinois qui avaient acheté un A320 qui ne s'est ensuite jamais montré dans aucun aéroport et n'a pas été revu en vol après sa livraison.
Pourtant, tous les produits et services de Microsoft sont plus que jamais évitables.
Pour avoir un avantage concurrentiel avec des machines qui démarrent beaucoup plus vite, peut-être!
En arriver à passer plus de temps dans le BIOS qu'au démarrage d'un OS complet, c'est quand même un peu le miracle de l'UEFI: 3 phases étanches (SEC, et surtout PEI/DXE), un agglomérat du RC/MRC Intel, EDK2, auxquelles on ajoute le propre code du fournisseur de BIOS (configuration, son code legacy, son système de build mal fichu qui colle plus ou moins bien les morceaux).
On a donc bien souvent des choses écrites quasiment à l'identique dans ces 3 phases et pour les 3 origines possibles (avec de bonnes raisons à cela, le fournisseur de BIOS pouvant utiliser une chaîne de compil microsoft, Intel la sienne et EDK2 GCC).
Forcément, ce n'est pas très efficient. Surtout quand on charge cela (et tous les firmwares obscurs dont Intel raffole) d'une flash SPI.
J'espère de tout coeur que vous réussirez, revenu sur Intel en me bouchant le nez (avec un niveau de support très bas sur ces sujets) après plus de 2 décennies sur le PowerPC dans l'industrie télécoms.
Maintenant, sur des machines destinées à faire tourner Linux, il serait bon de commencer à faire du lourd passé Intel table rase. Le PowerPC crève de la politique d'IBM hélas, mais RiscV progresse…
Le point qui m’intéressait, c'était que ça tourne sur un PI3, je dois dire.
Ce qui m'embêtait, c'est que c'est le serveur qui centralise, son rôle ne se limitant visiblement pas à la gestion des utilisateurs et leur "mise en relation". Ce qui fait que la visio n'est pas là, elle coincerait de toute façons sur une petite config avec un fonctionnement non pair à pair.
Mais si en prime la config est lourde c'est mort pour sortir famille/amis de zoom et autres machins troués… mais qu'un proche de 80 ans arrive à utiliser avec quelques directives simples.
Ce qui manque en fait toujours, c'est vraiment un Skype libre avec un fonctionnement d'avant son sabordage par Microsoft qui l'a tué, comme à peu près tout ce qu'ils rachètent, en le centralisant…
Pour le -fpatchable-function, on verrait une version plus générique du -finstrument-functions de gcc mais à y réfléchir un peu ça semble difficilement utilisable en comparaison, surtout dans un contexte visant plusieurs architectures avec des tailles d'instruction "nop" potentiellement différentes…
Unix est traversé par la pile réseau depuis qu'il existe. Le reste a suivi cette philo et X aussi qui fait le job nativement. Un remplaçant qui retire des fonctionnalités pareilles ça n'aide pas à son adoption et d'ailleurs ça traîne depuis presque 10 ans (je m'étais d'ailleurs fait rembarrer en exposant ce gros manque aux développeurs il y a fort fort longtemps…). Maintenant que ca arrive enfin (pour les installations, pas les upgrades) avec même Debian qui s'y risque, ce qui manque et qui avait pu échapper a des utilisateurs pas forcément branchés sur le dessous du capot de l'affichage graphique va se voir. Et visiblement, certains commencent à y pallier.
Wayland et Gnome (3): Des projets un peu dogmatiques à mon goût et qui n'écoutent qu'eux mêmes… Au final, d'autres ayant des compétences sur les sujets qui fâchent font Cinnamon et waypipe, certes, mais ces attitudes n'aident pas le libre. Tout comme conchier X: Je préfère un truc qui marche à travers le réseau que gagner des FPS au jeu, même si les deux ce serait l'idéal.
Puis la sécurité, c'est un peu l'alibi du siècle. J'attends toujours les ennuis personnellement.
… bien plus réel que l'auteur ne le laisse supposer, à titre personnel je vivrais très mal sans cela:
-En télétravail, je suis habituellement connecté à minimum une machine windows (en RDP) et 2 machines Linux (une saloperie dans le cloud et une physique en lab). Et qu'est-ce qui est le plus chiant: Ce RDP obligeant sous windows à tirer un foutu bureau complet (sans pouvoir avoir le même utilisateur utilisant le bureau en distant et local, + avec un win10 distant des polices généralement floues en distant si la définition de l'écran distant n'est pas identique au local) et d'en avoir au final 2 à gérer au lieu de fenêtres applicatives qui s'y intègrent en organisant ça par bureau virtuel.
Tirer un bureau complet distant, c'est au final de mon point de vue pas très pro, voir carrément très "tata Janine":
-A la maison, même un PI qui gère la baraque avec une raspbian minimale (sans bureau graphique complet, inutile, il est headless) fait du X11 forwarding via SSH, le combo idéal, avec juste le paquet xvfb (X11 frame-buffer) installé dessus: Si on évite les applicatifs issus de gnome/kde tirant des tétrachiées de dépendances, genre des terminaux light comme urxvt et éditeurs graphiques genre nedit, ca permet quand même de travailler dessus de manière bien plus confortable qu'avec des consoles. Avec wayland, je ne sais pas si le même genre de choses sera possible…
De ce point de vue, wayland était une regrettable régression sur l’ancêtre X11 qui fait que tant que X11 sera là, il restera sur mes machines… mais comme ça ne sera sans doute possible qu'un temps, tout ce qui va dans le sens de combler ce foutu manque va dans le bon sens, surtout si on gagne un support de l'accélération graphique au passage.
Le plus incroyable, c'est que cela n'ait pas été fait nativement. Il ne s'agit quand même pas de windows-clicodrome, mais d'un Unice construit depuis les débuts autour de la pile réseau, affichage compris.
Je pense que c'est lié au fait que la génération qui code cela, ne sachant pas vivre sans une IDE Eclipse (personnellement, je fuie), trouve que X11 via le réseau ne fonctionne pas forcément très bien avec des trucs trop complexes graphiquement (mais déjà un peu moins mal en activant la compression à la volée de SSH en plus du X11 forwarding : "ssh -XC toto@machineDistante") et non utilisatrice n'a même pas pensé à essayer de faire mieux de ce point de vue.
Merci en tout cas d'avoir fait connaître cet ajout, surtout en n'en éprouvant pas personnellement le besoin!
[^] # Re: Firmwares privateurs
Posté par lym . En réponse à la dépêche La distribution GNU/Linux Trisquel 10.0 « Nabia » est là !. Évalué à 1.
A 100% non, car comme dit par ailleurs tu auras toujours des FW non libres qui seront présents dans un matériel ou nécessaires au démarrage du processeur.
Tu peux toujours les considérer comme liés au matériel et laisser la version résidente qu'ils embarquent en majorité en refusant d'installer un paquet firmware-XXX non libre.
Mais c'est s'exposer à des problèmes, car ces firmwares peuvent avoir des bugs!
Exemple perso: Il y a quelques mois, un problème de raspbian bloquait le chargement du firmware bluetooth des raspberry PI 3.
Pas de bol, je l'utilise pour ma domotique afin de savoir qui est à la maison (via les smartphones) et adapter sa gestion (+activation/désactivation alarme).
Je me suis rendu compte du souci car au bout de qq heures, le bluetooth du PI plantait totalement… et arrivait même parfois à planter le bluetooth du smartphone Android en face!
Le firmware résident avait visiblement un bon gros bug corrigé par la version chargée au démarrage.
[^] # Re: Firmwares privateurs
Posté par lym . En réponse à la dépêche La distribution GNU/Linux Trisquel 10.0 « Nabia » est là !. Évalué à 2.
Il y a un niveau ou placer le curseur, car avant même ce qui peut être chargé par l'OS il y a ce qui démarre bien avant qu'il ait la main sous forme de processeurs de service et/ou de sécurité. Sachant que tous fournissent des services à l'OS ensuite. Un mal qui s'est bien généralisé depuis Intel et son ME. Arm devient d'une certaine manière presque pire niveau étages de la fusée au démarrage!
C'est un problème non seulement pour le SW, mais aussi le HW: Intel est ainsi en position d'imposer sa façon de faire en refusant la mise à disposition des firmwares non signés par exemple, ce qui interdit de fait de faire son propre boot loader si on ne veut pas passer par un éditeur de BIOS (qui lui y aura accès grace à une relation "privilégiée", ainsi qu'aux reference code/RC, dont celui très complexe d'init du controleur DDR/MRC, alors que coreboot ne se voit proposer à reculons que des blobs binaire, version compilée des RC/MRC).
Les derniers processeurs modernes sur lesquels j'ai bossé ou l'on pouvait tout faire sans que le fondeur n'interfère trop (voir pas du tout si pas de besoin des accélérateurs réseau) étaient des PowerPC Freescale dédiés à l'embarqué (utilisés surtout en infra Télécom jusqu'à la 4G/LTE, puis une fois bien débogués par cet usage, en avionique).
Mais le PowerPC, lâché par les télécoms, ne vit plus guère que chez IBM côté serveurs. Et il y a probablement subi les mêmes dérives depuis le schisme d'avec Motorola semiconducteurs (devenu Freescale puis NXP).
# Pour les fourmis...
Posté par lym . En réponse au journal J'ai mangé une pomme. Évalué à 1.
Il ne doit pas être évident contre un mur d'éviter qu'elles ne puissent passer puis grimper. Pour ma part, suite à une infestation de puces localisée au fond du jardin en juillet, après avoir hébergé une portée de hérissons dans une cabane faite pour eux, à la fin du printemps (ne pas croire ce qu'on lit, qu'elles sont propres aux hérissons et ne vont pas ailleurs: Conneries!), j'ai découvert la terre de diatomée.
Au départ, j'ai cramé le secteur le plus touché avec le brûleur de mauvaise herbe à gaz puis ne voulant utiliser d'insecticide (j'apprécie également l'aide des cox et puis mon chat est souvent dans le coin même si là, il évitait), j'ai cherché autre chose: Les qq jours pour que les oeufs passés à travers le brûlage ne repeuplent le secteur laissaient le temps d'une recherche/commande…
En fait, ca a été très efficace sur les pucerons mais aussi sur les fourmis (j'ai eu un nb de fourmilières conséquent cette année). Niveau application, le mieux que j'ai trouvé est une boite à café expresso moulu métal à couvercle plastique (pour pouvoir fermer/secouer après remplissage) dont le fond est percé d'une constellation de coups de tournevis.
On remplit dans le seau de terre de diatomée (on trouve des formats "poulailler" de 5 ou 10l économiques), ferme la boite et on secoue/distribue aisément aux lieux de passage/pieds d'arbres ou de mur.
Le mode d'action est purement mécanique: Ça leur grippe/détruit littéralement les rouages de l'exosquelette et ces insectes se vident/meurent. Sans produit chimique. Les cox n'allant pas au sol, aucun souci pour elles.
Cela résiste à quelques épisodes pluvieux si pas trop de ruissellement: Pas pire qu'un insecticide qui sera lessivé, voir même mieux.
[^] # Re: positionnement avec cinnamon
Posté par lym . En réponse à la dépêche Sortie de MATE 1.26. Évalué à 1.
J'avais suivi le même chemin quand Gnome 3 est arrivé. Désormais, c'est la machine qui décide:
-Potable : Cinnamon.
-Vieux clou/netbook en sursis: Mate, ce dernier était quand même meilleur niveau fonctionnalités qu'un XFCE ou autre bureau réputé léger… sans forcément être notablement plus lourd à l'usage.
Ce qui m'inquiète, c'est le futur de Cinnamon sous Debian vu que le mainteneur est passé à KDE.
Pas envie de revenir à Mint et une base Ubuntu lâchée depuis 2010 en raison de l'accumulation de mauvaise graisse (je suis passé à cette époque de plus facile de rajouter ce qui manque à une Debian minimale que de retirer ce qui est en trop d'une Ubuntu ayant grossi) et aussi, de leur côté, d'un délire sur les DE que ne renierait pas Gnome depuis sa funeste version 3.
[^] # Re: À essayer
Posté par lym . En réponse à la dépêche Sortie de MATE 1.26. Évalué à 1.
Arghhh, le truc qui m'agace: Tu veux coller une fenêtre qqpart et on te la retouche… et il faut aller chercher les obscurs réglages pour signifier au DE "touche à ton c.."!
[^] # Re: Pauvre support technique
Posté par lym . En réponse à la dépêche Les Néerlandais peuvent choisir leurs modems et routeurs. Évalué à 4. Dernière modification le 15 septembre 2021 à 11:39.
J'en serais étonné: Orange n'a jamais eu un SIP standard contrairement à d'autres.
Alors certes on a un réseau correct et quand il y a un problème ils s'en occupent, mais pour pouvoir utiliser librement ce a quoi son abonnement donne pourtant droit (téléphoner en SIP de son PC, une API pour envoyer des SMS autrement que via leur site et le navigateur), on part chez eux de très loin.
Ce type de réglementation déclinée chez nous les obligerait à évoluer, au moins sur la partie téléphonie.
L'envoi de SMS m'aurait rendu service pour mes notif domotique par exemple: No way…
Le SIP, même pas forcément pour téléphoner d'un PC en plus du fixe DECT, permettrait de récupérer l'identifiant appelant sans matériel supplémentaire de de filtrer les appels de pubeux d'un décroché/raccroché par exemple.
Pour cette dernière fonction filtrage, n'utilisant pas le RJ11 de la livebox pour le fixe (tout en DECT utilisant la base intégrée à la box), j'ai dû recycler un vieux modem 56k USB ayant la fonction caller ID…
C'est quand même dommage de devoir en arriver là.
[^] # Re: paquet AUR
Posté par lym . En réponse à la dépêche gSpeech passe en 0.10. Évalué à 1.
Une alternative possible pour les notif vocales de ma domotique/alarme sur PI3, même si pour le moment ce bon vieil espeak, avec un peu de configuration et quelques libertés d'écriture pour obtenir une prononciation plus réaliste, fait l'affaire?
A priori toujours pas, vu que la config reste graphique et que mon système est installé sans support graphique (headless, l'interaction se faisant via un site ouèbe embarqué et l'administration via ssh)…
# Cela semble avoir bien progressé...
Posté par lym . En réponse à la dépêche Sortie de GCompris 1.0 (et joyeux anniversaire !). Évalué à 2.
… depuis 7/8 ans que mes enfants ont passé l'age.
Pour les activités gravité et comprendre intuitivement comment cela fonctionne, je ne saurais trop recommander de s'inspirer d'un petit jeu qui avait pour ma part eu un succès très réel avec mes enfants, hélas peu voir plus maintenu (même si de vieux paquets peuvent encore s'installer sur une Debian actuelle): Slingshot!
https://download.tuxfamily.org/sdtraces/BottinHTML/Bottin_R-S_files/Slingshot-12831.html
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par lym . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 1.
Comme précisé, je ne suis pas allé très loin dans l'examen car j'apprécie vraiment la liberté laissée par le C. Et là je n'ai d'entrée pas trouvé mon compte pour du soft plateforme/bas niveau: La rapport bénéfice/emmerdement ne me parait pas positif.
Maintenant, pour de l'applicatif actuel (surtout en frontal avec l'extérieur) ou des ajouts du langage seront utiles (apports thread/reseau) autant que, par construction, limiter les erreurs possibles quasiment aux seules fautes de logique du programmeur, au bénéfice de la sécurité/fiabilité: OK, d'ailleurs Mozilla n'a-t'il pas crée ce langage exactement pour cela?
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par lym . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 5.
Je ne crois pas avoir dit le contraire… mais l'UEFI ne va pas gérer la mémoire virtuelle de l'OS, ses IT, sa configuration cache et les finasseries pour maintenir sa cohérence très dépendantes de l'architecture.
Je dirais même que l'UEFI est une saloperie codé cochon, qui crée des dépendances évitables entre le boot loader et l'OS… avec pour résultat un code de démarrage en 3 phases quasi étanches (SEC/PEI/DXE), faisant intervenir jusque 3 origines de sources (RC/MRC, les réference code Intel source clos fournis uniquement aux éditeurs de BIOS/UEFI ; EDK2, implémentation de référence tirée encore par Intel ; Code glue/menu/log/selection boot device… historique de l'éditeur de BIOS).
Cad que le code commun se retrouve souvent avec 3(SEC/PEI/DXE)x3(sources code RC/EDK2/Editeur intégrant le patchwork)=9 duplicats…
Tout ce qu'on essaie d'ordinaire d'éviter. Avec au final un tas de m…. de l'ordre de grandeur du kernel linux en nb de lignes de code juste pour booter la machine, fournir qq services à l'OS (car microsoft n'a jamais su s'en passer, cf les ancêtres "interruptions" BIOS des boot services UEFI actuels), après avoir fait l'énumération PCI.
Et un truc plus long en temps (chargé d'une flash SPI) d'execution que le démarrage de l'OS complet derrière.
Pour fournir quoi d'utile? Un menu de config assez basique et un shell pas sans rappeler la boite DOS (en particulier les scripts, on revient au temps du .BAT): Un u-boot qu'on a longtemps fait tenir sur un secteur de 512k de flash NOR sur du powerPC est de ce point de vue mieux foutu que ces BIOS qui réclament une flash de 16MB (avec les firmwares en pagaille, autre spécificité Intel).
Stp, ne me parles plus d'UEFI…
# Plus un problème qu'une solution...
Posté par lym . En réponse au journal Je viens de déposer plainte à la CNIL : mon retour d'expérience.. Évalué à 1. Dernière modification le 10 décembre 2020 à 13:28.
Ces messages peuvent être vus comme un progrès pour ceux qui n'utilisent pas un mode de navigation privée, voir avaient depuis la nuit des temps configuré leur navigateur (proposant ces options, tel FF) pour vider la benne à ordure des pubeux de tout ordre à extinction.
On peut aussi vider la benne en cours de session à des moments opportuns, par exemple avant de se connecter à leur banque/site de commerce avec une intention d'achat, d'un Ctrl+Shift+Suppr.
=> Ceux là, soucieux des traces laissées chez eux depuis longtemps, sont au final ceux qui sont emmerdés par ces dispositions législatives très mal pensées car ils vont devoir refaire la manip (en général au plus rapide proposé, accepter tout, sachant que finasser est conçu pour être dissuasif) à chaque re-connexion.
Pour réconcilier tout le monde, ce type de disposition aurait dû être faite sur le mode du "do not track", voir en rendant ce dernier (pré-existant) équivalent à un "ne rien accepter" exclusif de tout questionnement et indépendant du vidage de la benne à cookie et données de sites diverses et avariées.
Comme avec bloctel (il eu mieux valu faire une chose très simple: Redonner un coût obligatoire aux appels vers fixe en faisant un illimité en mode mobile: Peu probable d'y arriver en usage individuel, par contre pas vraiment pour un centre d'appel) qui semble vous ramener plus d'appels qu'en éviter, nous sommes dans un pays qui aime faire des usines à gaz finissant à l'inverse du but visé.
# Et enfin un vrai switch/case...
Posté par lym . En réponse à la dépêche Python 3.9 est disponible. Évalué à 0.
Pour éviter les bidouilles!
On pourrait ajouter les variables static (là aussi, on peut bidouiller), facilitant l'utilisation purement procédurale du langage…
Bin non? Pour le 4.0 peut-être?!
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par lym . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 1.
Les outils d'analyse de code C permettent en effet de compenser les avantages de conception de Rust, en évitant en prime de devoir cumuler (au niveau logiciel de base) la complexité de la machine (un processeur/SoC actuel) avec celle du langage (devoir en particulier en permanence s'embêter avec les problèmes d'appartenance).
Je n'ai pas étudié l'affaire de très près, ceci dit, mais vu de haut je vois plus Rust utile côté applicatif que pour coder un système d'exploitation voir ses modules/drivers.
Ce ne serait pas le 1er challenger du C de l'histoire à échouer!
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par lym . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 3.
Il y a des tas de choses à bas niveau qui sont propres à chaque architecture et qui n'ont pas leur place dans des langages de haut niveau, même ceux qui permettent déjà beaucoup de choses comme le C.
Sans même parler du strict démarrage (va appeler du C sans avoir initialisé une pile, donc une RAM qui est souvent un bout de mémoire cache plateforme dévoyé le temps de la complexe initialisation DDR!), niveau OS, toutes les primitives bas niveau touchant à la mémoire cache justement, la mémoire virtuelle, préfixes/postfixes d'interruptions, opérations atomiques (test&set)…
Cela ne représente plus grand chose (on n'écrit donc pas vraiment un OS en asm), même s'il y en a quand même de planqué ailleurs (sous forme d'asm inline) que dans des fichiers complets, mais c'est la portion inévitable.
[^] # Re: Tu n'as vraiment pas de chance
Posté par lym . En réponse au journal Ivre, il tente de réinstaller Windows, ça tourne mal. Évalué à 0.
En effet, mes 2 dernières installations:
-Un laptop perso acheté d'occase livré avec un Win10 home refurb sur un BIOS reconfiguré en legacy… mais qui repassé en UEFI, avait encore la clef 10 pro de la version constructeur bien au chaud… avant de lui mettre un double boot Debian.
-Puis une machine labo au taf, avec la clef de licence win7 pro OEM de l'étiquette (bouffée sans pb par l'installeur de 10: Ils ne veulent vraiment plus le vendre!), pour des softs d'analyseur logique, l'horreur Visual eBios d'AMI qui n'avait aucune chance de me réconcilier avec le patchwork Eclipse etc… dont les versions Linux ne sont hélas pas stables (Salae, si tu m'entends…).
Et franchement même réflexion: Zéro problème, fini la litanie d'une demi journée de reboot d'application séquentielle de tous les patchs mensuels depuis la sortie de la dernière ISO. Juste à ruser pour éviter le compte en ligne microsoft et se taper le moins de traceurs (télémétrie en novlangue microsoft) possible.
Au final, on arrive à avoir un système (certes moins complet on n'a pas une suite bureautique etc) qu'un Linux dans un temps à peine 2x supérieur à mon top chrono: La Debian Netinstall, qui charge direct tout un système à jour.
Franchement, cela me semble devenu très correct même si je n'apprécie pas win10 et ne l'utilise que dans des cas contraints (et toujours avec un Cygwin pour le rendre supportable).
[^] # Re: À voir en vrai
Posté par lym . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à 5.
Il faut dire qu'utiliser un clone Red-Hat ne se justifie vraiment que pour avoir une version d'OS homogène sur un parc matériel qui va forcément diverger sur les 10 ans de support assuré: Là, avoir Red-Hat qui se tape le boulot de backport du support du nouveau matériel arrivant en flux continu sur un kernel antédiluvien peut avoir une utilité.
Mais la contrepartie, c'est quand même des dépôts qui sont un vide absolu comparé à la richesse côté Debian. Les premiers mois/années, on peut au moins recompiler de manière a peu près fiable ce qui manque soit-même (pour éviter les acrobaties avec les dépôts de la Fée-Dora, sport de masse sous RH) mais cela se gâte très vite.
Pour ma part, entre la gestion de paquets inférieure (en disponibilité et à l'usage) et le cycle AMHA trop long, j'ai toujours trouvé que Debian offrait un meilleur compromis stabilité/nouveauté.
Scientific-Linux devenu un CentOS, après que RH ait déjà savonné la planche aux coucous d'Oracle, les jours de la "RH du pauvre" semblaient comptés. Car le débouché entre Fée-Dora et RH semble pour le moins limité.
[^] # Re: Config
Posté par lym . En réponse à la dépêche Sortie de TIC‑80 version 0.80 . Évalué à 1. Dernière modification le 05 novembre 2020 à 16:52.
J'ai toujours mon EeePC901 avec son Atom 1er du nom si "poussif", actuellement avec une Debian 10 et bureau Mate qui n'est pas le plus léger qui soit. Ca reste utilisable. La seule modif avait été de lui payer une barrette de 2GB à la place de celle d'1GB d'origine (+, sans impact ici, carte wifi Ubiquity plus sensible que l'originale et pouvant cracher très au dessus des 100mW autorisés, import US oblige, qui accrochait sans problème des points d'accès à 500m, malgré les antennes internes, en vacances avant la baisse des forfaits data mobiles).
Pour le jeu, pas mal de jeux Linux un peu anciens tournent sans problème… d'encore plus anciens portages, type Doom, également: C'est pas neuf, mais ça reste d'un autre niveau qu'animer des sprites comme sur un Amstrad ou Commodore des années 80 tout de même.
Là si c'est un problème, c'est pas l'Atom qu'il faut blâmer!
Le plus incroyable avec cette petite machine comme on n'en fait hélas plus: Son autonomie, avec une batterie d'origine chargeant encore à 85% de sa capacité théorique. Du Asus de la décennie 2000, en résumé, même pour ce modèle alors low-cost.
# Autre exemple...
Posté par lym . En réponse à la dépêche Bogues de logiciel et bogues de management : 737 Max et autres catastrophes. Évalué à 5.
Quand on voit qu'un A400M tout frais sorti de l'assemblage a été perdu (tuant l'équipage d'essai) car le FADEC (contrôle moteur), si des calibrations hélice manquaient, était capable d'accepter la puissance maximale au décollage mais qu'ensuite chaque réduction ne permettrait pas de remettre plus de puissance ultérieurement, on ne peut pas trop moquer Boeing hélas.
Et là, on n'a pas l'excuse de pousser à bout un design des années 60 pour économiser sur les requis d'issues de secours actuels, entre autres…
Le pire, c'est que c'était spécifié ainsi! Quel est l'âne qui a pu faire cela? Là ou cela se situe, il doit se faire tout petit outre rhin…
[^] # Re: A propos du Boeing 737.
Posté par lym . En réponse à la dépêche Bogues de logiciel et bogues de management : 737 Max et autres catastrophes. Évalué à 6.
Pour le planeur vs avion de ligne, c'est pas si loin selon le planeur. Si les modèles de compétition sont vers les 60 de finesse, les bois et toile classiques pour l'instruction sont plutôt dans les de 25 à 30. Un avion léger d'aéroclub sera dans les 10/15.
Et puis quand on a un pilote de ligne vélivole à ses heures perdues aux commandes, la finesse d'un avion de ligne (dans les 20) peut vous sauver la vie:
https://fr.wikipedia.org/wiki/Planeur_de_Gimli
[^] # Re: Un exemple du quotidien
Posté par lym . En réponse à la dépêche Bogues de logiciel et bogues de management : 737 Max et autres catastrophes. Évalué à 9.
Pourtant, il y a 25 ans, une personne faisait très bien ce travail seule en plus de pas mal de TP d'enseignement:
http://patrick.ducrot.free.fr
Et pour la sécurité, je me souviens encore de ses images "Wanted" balancées régulièrement sur tout le réseau de machines Unix (servant à l'enseignement) visant avec humour le seul élève ayant réussi (pas bien longtemps, juste le temps de repérer un process inconnu rapidement décortiqué) à lui piquer son login. Le petit malin avait exploité (de mémoire) une faille liée au lecteur de disquettes 5"1/4 mis à dispo des élèves pour transférer leurs sources/fichiers de leurs PC perso, pour ceux qui en avaient…
Moi je n'avais pas fait si bonne pêche, avec mon chalut lancé à la même époque côté réseau PC (sous windows 3, de mémoire, à l'époque? Ils servaient alors à la bureautique) qui avait eu a peu près tous les élèves mais pas lui: Trop prudent déjà vis à vis des produits Microsoft, je pense qu'il ne se connectait que de son bureau avec sa machine, ce qui le rendait insensible à mon exploitation de l'ancêtre des services runtime UEFI: Les interruptions BIOS qui permettaient de mettre des hooks (tel un virus de secteur de boot, capacités de réplication en moins) sur les frappes clavier (permettant de récupérer tout ce qui suivait un mot clef type "login", "telnet"…) et accès disque (pour sauver cela, à des fins de glanage ultérieur, sur des zones de HDD inutilisées/cachées à l'OS). Un article cocasse dans le canard de l'école dont je dois toujours avoir copie quelque part avait cloturé ma 3ème année, exposant les mots de passe simplistes ou tout simplement drôles.
C'est triste de voir un Microsoft pourtant en perte de vitesse (hors bureautique et cloud) noyauter ainsi l'enseignement et la recherche. Mais dans le privé c'est pareil, y compris chez LE concurrent de Boeing: S'ils veulent refaire leur retard, au moins, ils n'auront pas à faire comme les Chinois qui avaient acheté un A320 qui ne s'est ensuite jamais montré dans aucun aéroport et n'a pas été revu en vol après sa livraison.
Pourtant, tous les produits et services de Microsoft sont plus que jamais évitables.
[^] # Re: Congrats
Posté par lym . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 0.
Pour avoir un avantage concurrentiel avec des machines qui démarrent beaucoup plus vite, peut-être!
En arriver à passer plus de temps dans le BIOS qu'au démarrage d'un OS complet, c'est quand même un peu le miracle de l'UEFI: 3 phases étanches (SEC, et surtout PEI/DXE), un agglomérat du RC/MRC Intel, EDK2, auxquelles on ajoute le propre code du fournisseur de BIOS (configuration, son code legacy, son système de build mal fichu qui colle plus ou moins bien les morceaux).
On a donc bien souvent des choses écrites quasiment à l'identique dans ces 3 phases et pour les 3 origines possibles (avec de bonnes raisons à cela, le fournisseur de BIOS pouvant utiliser une chaîne de compil microsoft, Intel la sienne et EDK2 GCC).
Forcément, ce n'est pas très efficient. Surtout quand on charge cela (et tous les firmwares obscurs dont Intel raffole) d'une flash SPI.
J'espère de tout coeur que vous réussirez, revenu sur Intel en me bouchant le nez (avec un niveau de support très bas sur ces sujets) après plus de 2 décennies sur le PowerPC dans l'industrie télécoms.
Maintenant, sur des machines destinées à faire tourner Linux, il serait bon de commencer à faire du lourd passé Intel table rase. Le PowerPC crève de la politique d'IBM hélas, mais RiscV progresse…
[^] # Re: Accessibilité
Posté par lym . En réponse à la dépêche Audio‑conférences en ligne avec Mumble. Évalué à -1.
Le point qui m’intéressait, c'était que ça tourne sur un PI3, je dois dire.
Ce qui m'embêtait, c'est que c'est le serveur qui centralise, son rôle ne se limitant visiblement pas à la gestion des utilisateurs et leur "mise en relation". Ce qui fait que la visio n'est pas là, elle coincerait de toute façons sur une petite config avec un fonctionnement non pair à pair.
Mais si en prime la config est lourde c'est mort pour sortir famille/amis de zoom et autres machins troués… mais qu'un proche de 80 ans arrive à utiliser avec quelques directives simples.
Ce qui manque en fait toujours, c'est vraiment un Skype libre avec un fonctionnement d'avant son sabordage par Microsoft qui l'a tué, comme à peu près tout ce qu'ils rachètent, en le centralisant…
# Patch
Posté par lym . En réponse au journal Sortie de LLVM 10.0.0. Évalué à 0.
Pour le -fpatchable-function, on verrait une version plus générique du -finstrument-functions de gcc mais à y réfléchir un peu ça semble difficilement utilisable en comparaison, surtout dans un contexte visant plusieurs architectures avec des tailles d'instruction "nop" potentiellement différentes…
[^] # Re: Comble un manque...
Posté par lym . En réponse au journal waypipe, affichage distant natif pour Wayland. Évalué à 0.
Unix est traversé par la pile réseau depuis qu'il existe. Le reste a suivi cette philo et X aussi qui fait le job nativement. Un remplaçant qui retire des fonctionnalités pareilles ça n'aide pas à son adoption et d'ailleurs ça traîne depuis presque 10 ans (je m'étais d'ailleurs fait rembarrer en exposant ce gros manque aux développeurs il y a fort fort longtemps…). Maintenant que ca arrive enfin (pour les installations, pas les upgrades) avec même Debian qui s'y risque, ce qui manque et qui avait pu échapper a des utilisateurs pas forcément branchés sur le dessous du capot de l'affichage graphique va se voir. Et visiblement, certains commencent à y pallier.
Wayland et Gnome (3): Des projets un peu dogmatiques à mon goût et qui n'écoutent qu'eux mêmes… Au final, d'autres ayant des compétences sur les sujets qui fâchent font Cinnamon et waypipe, certes, mais ces attitudes n'aident pas le libre. Tout comme conchier X: Je préfère un truc qui marche à travers le réseau que gagner des FPS au jeu, même si les deux ce serait l'idéal.
Puis la sécurité, c'est un peu l'alibi du siècle. J'attends toujours les ennuis personnellement.
# Comble un manque...
Posté par lym . En réponse au journal waypipe, affichage distant natif pour Wayland. Évalué à 0.
… bien plus réel que l'auteur ne le laisse supposer, à titre personnel je vivrais très mal sans cela:
-En télétravail, je suis habituellement connecté à minimum une machine windows (en RDP) et 2 machines Linux (une saloperie dans le cloud et une physique en lab). Et qu'est-ce qui est le plus chiant: Ce RDP obligeant sous windows à tirer un foutu bureau complet (sans pouvoir avoir le même utilisateur utilisant le bureau en distant et local, + avec un win10 distant des polices généralement floues en distant si la définition de l'écran distant n'est pas identique au local) et d'en avoir au final 2 à gérer au lieu de fenêtres applicatives qui s'y intègrent en organisant ça par bureau virtuel.
Tirer un bureau complet distant, c'est au final de mon point de vue pas très pro, voir carrément très "tata Janine":
-A la maison, même un PI qui gère la baraque avec une raspbian minimale (sans bureau graphique complet, inutile, il est headless) fait du X11 forwarding via SSH, le combo idéal, avec juste le paquet xvfb (X11 frame-buffer) installé dessus: Si on évite les applicatifs issus de gnome/kde tirant des tétrachiées de dépendances, genre des terminaux light comme urxvt et éditeurs graphiques genre nedit, ca permet quand même de travailler dessus de manière bien plus confortable qu'avec des consoles. Avec wayland, je ne sais pas si le même genre de choses sera possible…
De ce point de vue, wayland était une regrettable régression sur l’ancêtre X11 qui fait que tant que X11 sera là, il restera sur mes machines… mais comme ça ne sera sans doute possible qu'un temps, tout ce qui va dans le sens de combler ce foutu manque va dans le bon sens, surtout si on gagne un support de l'accélération graphique au passage.
Le plus incroyable, c'est que cela n'ait pas été fait nativement. Il ne s'agit quand même pas de windows-clicodrome, mais d'un Unice construit depuis les débuts autour de la pile réseau, affichage compris.
Je pense que c'est lié au fait que la génération qui code cela, ne sachant pas vivre sans une IDE Eclipse (personnellement, je fuie), trouve que X11 via le réseau ne fonctionne pas forcément très bien avec des trucs trop complexes graphiquement (mais déjà un peu moins mal en activant la compression à la volée de SSH en plus du X11 forwarding : "ssh -XC toto@machineDistante") et non utilisatrice n'a même pas pensé à essayer de faire mieux de ce point de vue.
Merci en tout cas d'avoir fait connaître cet ajout, surtout en n'en éprouvant pas personnellement le besoin!