Mais oui bien sûr! Puis je dois me faire vieux, mais je ne comprends pas la moitié des acronymes utilisés de "technologies déjà bien connues" au milieu d'un article globalement "quickie", l'envie avant puis la décontraction après en moins…
La dérive du développement vers les technos web, c'est quand même une jolie plaie. Des débilophones plus puissants et avec au moins 2x la mémoire de PC d'il y a 10 ans pour faire tourner des jeux assez basiques ne semble néanmoins plus faire tilter grand monde sur le gâchis de ce foutoir. L'impression de vivre une époque formidable!
Le plus important semble être de se mettre au niveau, avé le cul-cul-r-code!
C'est vrai qu'en domotique, MQTT fait une percée remarquée: On passe en fait de solutions bien intégrées (Domoticz en était un bon exemple) via des bibliothèques gérant des protocoles différents avec toute la configuration au même endroit, des bugs faciles à tracer, zéro problème de versions vu le monolithisme… a un truc éclaté, plus difficile à installer/configurer (pour ce dernier point, la découverte automatique entends le solutionner mais se révèle en pratique peu fiable): Broker MQTT (dans la bonne version), plugins s'y interfaçant (souvent en python, un langage en train de très mal tourner et pot de pus croissant à chaque changement de sous-version) côté applicatif domotique ET gestion d'un protocole domotique particulier (zwave, zigbee…) de l'autre côté du broker MQTT, idéalement écrits dans des langages absolument pas faits pour contrôler du matériel et rajoutant une couche d'interpréteur (JS pour ce qui remplace openzwave lâché par son unique mainteneur il y a 1 an 1/2 par exemple). Youpiii, c'est beau le progrès!
Bref, on rajoute 3 étages de machins et leurs dépendances avec souvent des pb de versions qui tournent au cauchemar quand on doit unifier sous la bannière mqtt plusieurs protocoles différents: Au final on duplique tout dans les versions qui "tombent en marche" dans des docker que l'on doit faire causer ensemble…
De quoi donner envie de tout bazarder!
Pour ne pas niquer sa distro sans tomber dans les travers bien connus du genre depuis Java (chaque applicatif traînant sa JVM pour ne pas avoir d'incompatibilités), être homogène à ce niveau et n'utiliser que ce qui est dans les dépôts en 1ère sélection tout en bannissant ce qui est manifestement codé en mode agile (mon crédo: "Les post-it s'envolent, les spec restent") en seconde lame du rasoir.
Si on veut être vraiment portable, se limiter à des implémentations minimalistes de python pour l'embarqué.
Certes, cela peut limiter les usages de python à un bash++, mais n'est-ce pas l'avoir fait sortir de ce cadre qui cause les problèmes?
Les processeurs de service ayant la main en premier en sortie de reset se généralisent.
Certes, sur ARM c'est en général basé sur une implémentation de référence open source mais rien n'assure que les patch d'un fondeur de SoC soient présents vu la licence BSD: De fait, les sources d'un SCP ou autre ATF fournies par un fondeur diffèrent de celles du github de ARM (https://github.com/ARM-software) par exemple, seules les évolutions non spécifiques semblant assez systématiquement remontées. Chacun peut donc ici conserver ses petites subtilités, ceux qui développent des produits basés sur un SoC précis ont accès aux sources et n'ont pas à jouer aux devinettes sur les problèmes voir peuvent remonter les patch au fondeur sur des pb qu'il ne peut pas forcément reproduire: Tout les acteurs industriels sont contents, sauf en fait le client final qui achète le matos s'il est bidouilleur.
Se passer de ces firmwares, quand c'est possible, doit par ailleurs avoir certains impacts niveau design (afin de ne pas devoir compter sur les protections thermiques et autres): Un ME chez Intel ne sera par exemple à ma connaissance jamais totalement inactif mais dans un mode dégradé (recovery): Il y en a de toutes manières un morceau gravé en dur (non upgradable) dans le PCH, en plus de ce qui est dans la boot flash (dans une section upgradable, avec ou séparément du reste du bios). Pour moi cette partie PCH n'est pas évitable, en premier lieu car c'est elle qui fait la découverte de la boot flash SPI (RSFDP, c'est d'ailleurs une dépendance implicite entre ME et BIOS assez dégueulasse et source de problèmes tordus!): C'est la première commande qu'on voit passer après le reset quand on mets un Salae en espion sur l'interface SPI boot… et un bios ne repasse pas sur les configurations faites à ce moment (adressage 3 ou 4 bytes en particulier) et attends même un certain comportement derrière en fonction du type/taille de flash (>16Mbyte ou pas, en particulier). D’où des plantages possibles dès que le driver SPI du bios va prendre la main, assez tôt dans l’exécution du BIOS (pour écrire/lire de l'environnement par exemple, le MRC Intel y mets plein de valeurs de calibration DDR par exemple => Si l'adressage utilisé par le bios ne match pas avec ce que le ME est censé avoir initialisé, on ne passe même pas l'init DDR!).
Comme dit par ailleurs, 45mn de chargement on n'en était heureusement pas là! La mémoire joue des tours et celle d'un CPC464 n'aurait pas encaissé.
La K7, j'avais connu sur le Tandy mc10 rebadgé Alice par Matra qui le distribuait en France (repeint du blanc au rouge)… Ça m'avait incité, avec mes Hebdogiciel pour tuer le temps avec Alice, à attendre le CPC6128 (et ses disquettes 3", format jamais vu ailleurs) alors que bien des potes avaient sauté sur le 464 à K7.
Ensuite, il est vrai que ces machines démarraient vite. Il n'y avait il est vrai pas grand chose à démarrer mais tout de même, le PC est depuis l'origine une brouette à ce niveau.
Il est désormais courant de voir un PC récent avec SSD bien plus lent sur la partie démarrage initial (BIOS/UEFI) qu'a démarrer l'OS complet derrière. C'est dire.
Si on compare avec une architecture plus récente mais bien plus élégante et qu'on voyait bien, à la fin du siècle dernier, faire la nique au x86: Le PowerPC… on voit bien qu'il n'y a pas que la complexité d'un processeur moderne, ce qu'il y a autour et de l'OS derrière pour expliquer la différence. Le Betamax n'avait pas gagné lui non plus!
Un pré-OS de 2M de lignes de code lourd comme une Cadillac tournant sur sur un cylindre… forcément: D'un côté on avait le prompt d'un Linux embarqué (succédant à un u-boot bien plus simple et n'utilisant même pas systemd) en moins 15s tandis que de l'autre on est encore dans le bios.
Même ARM rejoint de plus en plus le PC à ce niveau, principalement en raison des firmwares (SCP/EBF/ATF) passant avant u-boot et passés loin devant le pendant ME d'Intel niveau temps d’exécution (ils font aussi plus de choses, dont l'init DDR), avant même de passer la main resp. à u-boot ou bios.
Le progrès n'est pas toujours bon à prendre… même si le suspend-to-ram évite désormais de devoir se taper trop de lancements de la fusée et ses multiples étages!
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.
# JS=natif!!!
Posté par lym . En réponse à la dépêche Meetup - découvrir l’initiative Quick Apps (Paris 2022/07/01). Évalué à 5. Dernière modification le 29 juin 2022 à 08:46.
Mais oui bien sûr! Puis je dois me faire vieux, mais je ne comprends pas la moitié des acronymes utilisés de "technologies déjà bien connues" au milieu d'un article globalement "quickie", l'envie avant puis la décontraction après en moins…
La dérive du développement vers les technos web, c'est quand même une jolie plaie. Des débilophones plus puissants et avec au moins 2x la mémoire de PC d'il y a 10 ans pour faire tourner des jeux assez basiques ne semble néanmoins plus faire tilter grand monde sur le gâchis de ce foutoir. L'impression de vivre une époque formidable!
Le plus important semble être de se mettre au niveau, avé le cul-cul-r-code!
# Un peu sceptique...
Posté par lym . En réponse à la dépêche Transmission de données de capteurs via internet. Évalué à 2.
C'est vrai qu'en domotique, MQTT fait une percée remarquée: On passe en fait de solutions bien intégrées (Domoticz en était un bon exemple) via des bibliothèques gérant des protocoles différents avec toute la configuration au même endroit, des bugs faciles à tracer, zéro problème de versions vu le monolithisme… a un truc éclaté, plus difficile à installer/configurer (pour ce dernier point, la découverte automatique entends le solutionner mais se révèle en pratique peu fiable): Broker MQTT (dans la bonne version), plugins s'y interfaçant (souvent en python, un langage en train de très mal tourner et pot de pus croissant à chaque changement de sous-version) côté applicatif domotique ET gestion d'un protocole domotique particulier (zwave, zigbee…) de l'autre côté du broker MQTT, idéalement écrits dans des langages absolument pas faits pour contrôler du matériel et rajoutant une couche d'interpréteur (JS pour ce qui remplace openzwave lâché par son unique mainteneur il y a 1 an 1/2 par exemple). Youpiii, c'est beau le progrès!
Bref, on rajoute 3 étages de machins et leurs dépendances avec souvent des pb de versions qui tournent au cauchemar quand on doit unifier sous la bannière mqtt plusieurs protocoles différents: Au final on duplique tout dans les versions qui "tombent en marche" dans des docker que l'on doit faire causer ensemble…
De quoi donner envie de tout bazarder!
# Prenons le problème à l'envers...
Posté par lym . En réponse à la dépêche Environnement moderne de travail Python. Évalué à 1. Dernière modification le 03 juin 2022 à 12:54.
Pour ne pas niquer sa distro sans tomber dans les travers bien connus du genre depuis Java (chaque applicatif traînant sa JVM pour ne pas avoir d'incompatibilités), être homogène à ce niveau et n'utiliser que ce qui est dans les dépôts en 1ère sélection tout en bannissant ce qui est manifestement codé en mode agile (mon crédo: "Les post-it s'envolent, les spec restent") en seconde lame du rasoir.
Si on veut être vraiment portable, se limiter à des implémentations minimalistes de python pour l'embarqué.
Certes, cela peut limiter les usages de python à un bash++, mais n'est-ce pas l'avoir fait sortir de ce cadre qui cause les problèmes?
[^] # Re: Matériel backdoor inside et vidéo disponible ?
Posté par lym . En réponse à la dépêche Conférence « Les libertés du logiciel et du matériel » avec Richard Stallman. Évalué à 1.
Les processeurs de service ayant la main en premier en sortie de reset se généralisent.
Certes, sur ARM c'est en général basé sur une implémentation de référence open source mais rien n'assure que les patch d'un fondeur de SoC soient présents vu la licence BSD: De fait, les sources d'un SCP ou autre ATF fournies par un fondeur diffèrent de celles du github de ARM (https://github.com/ARM-software) par exemple, seules les évolutions non spécifiques semblant assez systématiquement remontées. Chacun peut donc ici conserver ses petites subtilités, ceux qui développent des produits basés sur un SoC précis ont accès aux sources et n'ont pas à jouer aux devinettes sur les problèmes voir peuvent remonter les patch au fondeur sur des pb qu'il ne peut pas forcément reproduire: Tout les acteurs industriels sont contents, sauf en fait le client final qui achète le matos s'il est bidouilleur.
Se passer de ces firmwares, quand c'est possible, doit par ailleurs avoir certains impacts niveau design (afin de ne pas devoir compter sur les protections thermiques et autres): Un ME chez Intel ne sera par exemple à ma connaissance jamais totalement inactif mais dans un mode dégradé (recovery): Il y en a de toutes manières un morceau gravé en dur (non upgradable) dans le PCH, en plus de ce qui est dans la boot flash (dans une section upgradable, avec ou séparément du reste du bios). Pour moi cette partie PCH n'est pas évitable, en premier lieu car c'est elle qui fait la découverte de la boot flash SPI (RSFDP, c'est d'ailleurs une dépendance implicite entre ME et BIOS assez dégueulasse et source de problèmes tordus!): C'est la première commande qu'on voit passer après le reset quand on mets un Salae en espion sur l'interface SPI boot… et un bios ne repasse pas sur les configurations faites à ce moment (adressage 3 ou 4 bytes en particulier) et attends même un certain comportement derrière en fonction du type/taille de flash (>16Mbyte ou pas, en particulier). D’où des plantages possibles dès que le driver SPI du bios va prendre la main, assez tôt dans l’exécution du BIOS (pour écrire/lire de l'environnement par exemple, le MRC Intel y mets plein de valeurs de calibration DDR par exemple => Si l'adressage utilisé par le bios ne match pas avec ce que le ME est censé avoir initialisé, on ne passe même pas l'init DDR!).
[^] # Re: Évolutions techniques
Posté par lym . En réponse à la dépêche Marion Créhange, l’informatique au service des sciences humaines. Évalué à 1. Dernière modification le 11 mai 2022 à 17:08.
Comme dit par ailleurs, 45mn de chargement on n'en était heureusement pas là! La mémoire joue des tours et celle d'un CPC464 n'aurait pas encaissé.
La K7, j'avais connu sur le Tandy mc10 rebadgé Alice par Matra qui le distribuait en France (repeint du blanc au rouge)… Ça m'avait incité, avec mes Hebdogiciel pour tuer le temps avec Alice, à attendre le CPC6128 (et ses disquettes 3", format jamais vu ailleurs) alors que bien des potes avaient sauté sur le 464 à K7.
Ensuite, il est vrai que ces machines démarraient vite. Il n'y avait il est vrai pas grand chose à démarrer mais tout de même, le PC est depuis l'origine une brouette à ce niveau.
Il est désormais courant de voir un PC récent avec SSD bien plus lent sur la partie démarrage initial (BIOS/UEFI) qu'a démarrer l'OS complet derrière. C'est dire.
Si on compare avec une architecture plus récente mais bien plus élégante et qu'on voyait bien, à la fin du siècle dernier, faire la nique au x86: Le PowerPC… on voit bien qu'il n'y a pas que la complexité d'un processeur moderne, ce qu'il y a autour et de l'OS derrière pour expliquer la différence. Le Betamax n'avait pas gagné lui non plus!
Un pré-OS de 2M de lignes de code lourd comme une Cadillac tournant sur sur un cylindre… forcément: D'un côté on avait le prompt d'un Linux embarqué (succédant à un u-boot bien plus simple et n'utilisant même pas systemd) en moins 15s tandis que de l'autre on est encore dans le bios.
Même ARM rejoint de plus en plus le PC à ce niveau, principalement en raison des firmwares (SCP/EBF/ATF) passant avant u-boot et passés loin devant le pendant ME d'Intel niveau temps d’exécution (ils font aussi plus de choses, dont l'init DDR), avant même de passer la main resp. à u-boot ou bios.
Le progrès n'est pas toujours bon à prendre… même si le suspend-to-ram évite désormais de devoir se taper trop de lancements de la fusée et ses multiples étages!
[^] # 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.