On remarque que la controverse tourne toujours autour de Gnome3 et sa customisation… Une litanie depuis 10 ans. Heureusement qu'il y a eu Cinnamon (ou MATE qui tourne encore sur un EeePC901, enfin en Debian n'ayant pas fait de mauvaise graisse et abusé du SchNAPs et installée via NetInstall qui permet de conserver l'essentiel, restons réaliste!).
A lire les news de sortie Ubuntu, je me félicite d'être passé de la copie de plus en plus raturée à l'originale depuis 10 ans. La 10.04 avait été ma dernière Ubuntu…
Copier Windows avec un applicatif embarquant toutes ses dépendances pour éviter d'avoir à gérer proprement les versions n'est clairement pas un bon modèle: Gâchis côté disque, mémoire virtuelle, sont alors inévitables. Parler de Bug N°1 et finir dans les mêmes travers (jusque là logiquement évité dans un modèle de sources ouverts vs compatibilité binaire ou c'est forcément moins simple), ce n'est pas sans ironie.
Le seul cas ou je voie un intérêt à snap et autres, c'est quand la distribution retire un truc: VLC sur la dernière Debian est désormais compilé sans le support RTSP par exemple. Un problème de licence vu par le mainteneur Debian qui ne semble guère poser de pb au projet VLC. Ce protocole étant quasiment généralisé sur les cam IP, difficile de s'en passer.
Mais cela permet aussi de constater que la version snap n'est pas très stable dès qu'on essaie d'ouvrir plusieurs flux en parallèle. Visiblement, VLC n'est sur ce point pas vraiment un cas isolé.
Hors de question de partir sur une distro se basant de manière croissante sur ce genre de modèle pour ma part.
Apple a toujours tout fait pour être un écosystème captif pour l'utilisateur qui y mets le petit doigt. A une époque, on ne pouvait même pas mettre une barrette mémoire de PC pourtant physiquement identique dans un MAC sans se faire jeter au boot! La différence? Juste un format de SPD EEPROM non standard.
Crucial avait fini par en sortir avec des SPD flashées au format Apple pour que les clients arrêtent de se faire prendre pour des pommes à les payer plus du double chez Apple… Mais bon, à un moment, à cumuler sur ce type d'emmerdements on en est rendu à se dire qu'il y a quelques centaines de millions de couillons friqués changeant de débilophone tous les 1 ou 2 ans pour expliquer ce milliard.
Au final, ces quelques centaines de millions vs 8 milliards d'individus sur la planète sont bien un marché de niche :o)
En espérant que ce post-mortem soit au final donné, c'est toujours intéressant et ce serait la moindre des choses vu le temps que tu y a passé: Le bug d'un équipement/FW tombé en marche après un upgrade d'équipement ne m'étonnerait guère chez Orange. Ils semblent avoir vraiment des gros pb de ce côté, il n'y a qu'a avoir tenté d'utiliser leurs SMTP en direct (sans passer par un client lourd codé pour s'adapter à tout!) pour constater combien au hasard des load-balancing on se retrouve sur des trucs qui font tousser les configs lib ssl/tls par défaut de moins de 5 ans.
Pour ma part, avec une LB Play chez Sosh (celle utilisée auparavant en ADSL, qui n'avait jamais posé pb), c'est l'ONT qui coince après les coupures secteur: Il semble y avoir un pb assez fréquent qui fait que cela ne monte alors pas correctement si les deux démarrent ensemble quand l'alimentation est restaurée. Si la LB est démarrée avant l'ONT, cela semble OK à tous les coups (mais je n'ai pas fait une tétra-chiée d'essai non plus), sinon cela merde au moins 3 fois sur 4. Aucune possibilité d'accès à l'interface d'administration LB "pour voir" car le switch côté LAN ne semble en prime pas monter tant que le côté WAN ne monte pas (au démarrage, si on débranche l'ONT après un démarrage OK c'est bon).
C'est un peu emmerdant pour la domotique/alarme qui se retrouve à la merci d'une panne secteur en vacances, si celle-ci dépasse la durée permise par la batterie tampon (double voltage en sortie) alimentant box+ont (en 20V) et PI3/Domoticz (5V USB).
C'est au final très pénible, cet ONT. Prévoir une cage SFP sur les box pas trop anciennes aurait permis une meilleure intégration tant niveau matériel (place prise/esthétique, double alim…) que logicielle (la box a le contrôle du démarrage/configuration du SFP).
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é.
[^] # Re: autossh
Posté par lym . En réponse à la dépêche Moniteur de tunnels SSH Tunnelmon en version 1.1 . Évalué à 2.
Si cela suffit, c'est que personne n'a encore pensé à descendre tout ce qui démarre en exposant la bannière, qui passe en clair:
~$ telnet localhost 22
Trying ::1…
Connected to localhost.
Escape character is ']'.
SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1
Oups! Même sur un 443 au lieu du 22, chez moi ils sont hélas plus malins.
# Controverses...
Posté par lym . En réponse à la dépêche Sortie de la version Ubuntu LTS 22.04. Évalué à 7.
On remarque que la controverse tourne toujours autour de Gnome3 et sa customisation… Une litanie depuis 10 ans. Heureusement qu'il y a eu Cinnamon (ou MATE qui tourne encore sur un EeePC901, enfin en Debian n'ayant pas fait de mauvaise graisse et abusé du SchNAPs et installée via NetInstall qui permet de conserver l'essentiel, restons réaliste!).
A lire les news de sortie Ubuntu, je me félicite d'être passé de la copie de plus en plus raturée à l'originale depuis 10 ans. La 10.04 avait été ma dernière Ubuntu…
Copier Windows avec un applicatif embarquant toutes ses dépendances pour éviter d'avoir à gérer proprement les versions n'est clairement pas un bon modèle: Gâchis côté disque, mémoire virtuelle, sont alors inévitables. Parler de Bug N°1 et finir dans les mêmes travers (jusque là logiquement évité dans un modèle de sources ouverts vs compatibilité binaire ou c'est forcément moins simple), ce n'est pas sans ironie.
Le seul cas ou je voie un intérêt à snap et autres, c'est quand la distribution retire un truc: VLC sur la dernière Debian est désormais compilé sans le support RTSP par exemple. Un problème de licence vu par le mainteneur Debian qui ne semble guère poser de pb au projet VLC. Ce protocole étant quasiment généralisé sur les cam IP, difficile de s'en passer.
Mais cela permet aussi de constater que la version snap n'est pas très stable dès qu'on essaie d'ouvrir plusieurs flux en parallèle. Visiblement, VLC n'est sur ce point pas vraiment un cas isolé.
Hors de question de partir sur une distro se basant de manière croissante sur ce genre de modèle pour ma part.
[^] # Re: Encore des remarques
Posté par lym . En réponse au journal L'Union européenne va imposer l'USB-C !. Évalué à 0.
Apple a toujours tout fait pour être un écosystème captif pour l'utilisateur qui y mets le petit doigt. A une époque, on ne pouvait même pas mettre une barrette mémoire de PC pourtant physiquement identique dans un MAC sans se faire jeter au boot! La différence? Juste un format de SPD EEPROM non standard.
Crucial avait fini par en sortir avec des SPD flashées au format Apple pour que les clients arrêtent de se faire prendre pour des pommes à les payer plus du double chez Apple… Mais bon, à un moment, à cumuler sur ce type d'emmerdements on en est rendu à se dire qu'il y a quelques centaines de millions de couillons friqués changeant de débilophone tous les 1 ou 2 ans pour expliquer ce milliard.
Au final, ces quelques centaines de millions vs 8 milliards d'individus sur la planète sont bien un marché de niche :o)
[^] # Re: Suite ?
Posté par lym . En réponse au journal La fibre orange hoquette ... ou comment devenir fou.. Évalué à 1.
En espérant que ce post-mortem soit au final donné, c'est toujours intéressant et ce serait la moindre des choses vu le temps que tu y a passé: Le bug d'un équipement/FW tombé en marche après un upgrade d'équipement ne m'étonnerait guère chez Orange. Ils semblent avoir vraiment des gros pb de ce côté, il n'y a qu'a avoir tenté d'utiliser leurs SMTP en direct (sans passer par un client lourd codé pour s'adapter à tout!) pour constater combien au hasard des load-balancing on se retrouve sur des trucs qui font tousser les configs lib ssl/tls par défaut de moins de 5 ans.
Pour ma part, avec une LB Play chez Sosh (celle utilisée auparavant en ADSL, qui n'avait jamais posé pb), c'est l'ONT qui coince après les coupures secteur: Il semble y avoir un pb assez fréquent qui fait que cela ne monte alors pas correctement si les deux démarrent ensemble quand l'alimentation est restaurée. Si la LB est démarrée avant l'ONT, cela semble OK à tous les coups (mais je n'ai pas fait une tétra-chiée d'essai non plus), sinon cela merde au moins 3 fois sur 4. Aucune possibilité d'accès à l'interface d'administration LB "pour voir" car le switch côté LAN ne semble en prime pas monter tant que le côté WAN ne monte pas (au démarrage, si on débranche l'ONT après un démarrage OK c'est bon).
C'est un peu emmerdant pour la domotique/alarme qui se retrouve à la merci d'une panne secteur en vacances, si celle-ci dépasse la durée permise par la batterie tampon (double voltage en sortie) alimentant box+ont (en 20V) et PI3/Domoticz (5V USB).
C'est au final très pénible, cet ONT. Prévoir une cage SFP sur les box pas trop anciennes aurait permis une meilleure intégration tant niveau matériel (place prise/esthétique, double alim…) que logicielle (la box a le contrôle du démarrage/configuration du SFP).
# 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é.