Posté par lym .
En réponse à la dépêche Memtest86+ v6.00 est sorti.
Évalué à 2.
Dernière modification le 03 novembre 2022 à 12:34.
Rassurant, peut-être, mais pour ma part j'ai vu trop de problèmes passer à travers des tests. A tel point que sur des cartes télécom/industrielles, ils ne sont plus guère passés qu'en prod et plutôt pour déceler des problèmes de fabrication que des boitiers DDR eux-mêmes.
De toutes manières, les problèmes n'ont plus guère de chance de passer à travers le nombre croissant de calibrations avec les générations de DDR. Donc cela va coincer dès l'init dun contrôleur DDR avec aucune chance de pouvoir lancer un memtest.
Et si l'init passe quand même, il y a plus de chance que le démarrage d'un OS complet stresse plus la DDR que dérouler un memtest. Avec soit des erreurs captées par l'ECC si présent… ou le florilège d'exceptions/comportement indéterminé pouvant résulter de problèmes de RAM.
De toutes manières, les temps de tests deviennent désormais prohibitifs avec les tailles de RAM installées. Le dernier test systématique (fait à chaque boot) que j'ai eu à écrire se contentait, de u-boot et exceptions ECC masquées, de faire une passe de lecture du pattern d'init du contrôleur DDR: Donc une passe de simple lecture ASM optimisée pour l'architecture (PowerPC et ses instructions avec incrément de l'adresse automatique) et les tailles de burst/ligne de cache. Pas de comparaison, rien, juste une lecture finale des compteurs d'erreurs ECC pour vérifier qu'il n'y en avait pas eu!
Si IBM avait sélectionné les deux zozos proposant le pire OS (DOS: non multitâche/multi-utilisateur…) possible pour l'architecture ouverte de son PC originel en 1981, peut-être étais-ce aussi pour ne pas tuer trop vite leur (B de) business de stations Unix (traversé depuis l'origine, plus de 10 ans avant et une éternité pour l'informatique à l'époque, par la pile réseau) dès qu'Intel sortirait un processeur avec une MMU (ce qui est mieux pour le multitâche) et que qqun se dirait que les slots d'extension pourraient héberger une carte réseau!
Le premier windows avec support réseau (3.11 for workgroups) a sonné l'arrivée de la carte réseau accessible et les débuts de Linux. Le temps que cela prenne vraiment de l'envergure (au tournant de ce siècle), IBM avait gagné 20 ans et les zozos fournisseur du tas de merde étaient faits milliardaires!
Pour des besoins très très simples (notification d'évènements…) d'IPC, ne pas oublier les signaux utilisateur (SIGUSR1 et 2)!
Quand dans ma domotique j'ai voulu faire en sorte que le système d'alarme perso scripté dessus fasse sonner une liste de téléphones mobiles, ayant par ailleurs codé un service (en python) faisant du filtrage d'appel (recyclant un vieux modem 56k usb branché sur le RJ11 de la Livebox alors inutilisé, tous les téléphones utilisant sa base DECT intégrée), j'avais commencé à vouloir utiliser des tubes nommés et même codé un prototype en python.
Puis n'étant pas un programmeur système (mais plutôt très bas niveau en C/ASM) et n'ayant pas anticipé que ce serait un peu "too much", surtout que le côté alarme/domotique était scripté en Lua et la gestion du modem/filtre appel ou serait ajouté le côté liste de numéro à appeler en cas d'alarme était de son côté écrite en Python… En relisant ce dernier je passe sur l'accrochage d'un handler SIGINT tout ce qu'il y a de plus commun… et eurêka, j'ai alors repensé aux signaux utilisateur et tout est devenu bien plus simple!
Côté Lua, un os.execute de 'pkill -10 -f "python.*phoneFilter.py"&'
Côté service Python (nommé phoneFilter.py), juste accrocher le handler gérant la liste d'appels si alarme (sigusr1_handler) sur le SIGUSR1 (signal 10): signal.signal(signal.SIGUSR1, sigusr1_handler)
Et mon machin à filtrer les pubeux (d'un décroché/raccroché immédiat via le modem, sur blacklist de numéros individuels, préfixes d'allocation ARCEP, voir toute plage de numéros alloués à des opérateurs de VoIP s'étant révélés au fil des mois 100% chiants… et si pas en blacklist locale ni connu dans l'annuaire DECT de la Livebox, qui a alors le bon goût de remplir un nom dans le Caller ID, beautifulsoup interroge 2 services en ligne pour récupérer une classification… et l'ajouter a une blacklist locale pour le coup suivant) s'est vu ajouter simplement très simplement une fonctionnalité.
0km/h, plus de mouvement, plus de chocs possibles. Le CQFD de notre "sécurité" routière… qui a commencé à taper sérieusement sur les vitesses à la fin des années 90, alors que les mortalités remontaient.
A cette époque, qu'est-ce qui arrivait de nouveau dans toutes les poches mais aussi derrière bien des volants? Le GSM…
Désormais c'est plus simplement des communications vocales (~0.8g/l d'alcoolémie selon des études d'alors, mais pas faites en France: Canada de mémoire. Soit un niveau délictuel côté bibine mais resté contraventionnel niveau "smart"-phone) mais internet et réseaux sociaux au volant (=> 1g dans chaque poche?), mais on va en remettre un coup sur les vitesses en cumulant avec prétexte de sobriété énergétique, comme en 1973?
Tout ce qui peut justifier la politique facile du radar et sa rentabilité est bienvenu. Les morts, au fond, l'état s'en fout!
"Sous prétexte que l'inscription est quasi-gratuite en fac de droit, de médecine, en prépa ou école d'ingé…"
C'est en effet pire que la situation présente en temps qu'employé, je dirais. On n'est même pas fichu de défalquer quelques trimestres obligatoires pour compenser des études supérieures niveau retraite, alors qu'on ne s'est pas vraiment roulé les pouces.
Il ne faut pas s'étonner que les études supérieures longues attirent moins un de ces jours. Surtout que niveau salaire, le rapport Q/P n'est globalement pas là. Sauf à aller faire x3 de l'autre côté de l'atlantique…
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).
[^] # Re: Ma gratitude
Posté par lym . En réponse à la dépêche Memtest86+ v6.00 est sorti. Évalué à 2. Dernière modification le 03 novembre 2022 à 12:34.
Rassurant, peut-être, mais pour ma part j'ai vu trop de problèmes passer à travers des tests. A tel point que sur des cartes télécom/industrielles, ils ne sont plus guère passés qu'en prod et plutôt pour déceler des problèmes de fabrication que des boitiers DDR eux-mêmes.
De toutes manières, les problèmes n'ont plus guère de chance de passer à travers le nombre croissant de calibrations avec les générations de DDR. Donc cela va coincer dès l'init dun contrôleur DDR avec aucune chance de pouvoir lancer un memtest.
Et si l'init passe quand même, il y a plus de chance que le démarrage d'un OS complet stresse plus la DDR que dérouler un memtest. Avec soit des erreurs captées par l'ECC si présent… ou le florilège d'exceptions/comportement indéterminé pouvant résulter de problèmes de RAM.
De toutes manières, les temps de tests deviennent désormais prohibitifs avec les tailles de RAM installées. Le dernier test systématique (fait à chaque boot) que j'ai eu à écrire se contentait, de u-boot et exceptions ECC masquées, de faire une passe de lecture du pattern d'init du contrôleur DDR: Donc une passe de simple lecture ASM optimisée pour l'architecture (PowerPC et ses instructions avec incrément de l'adresse automatique) et les tailles de burst/ligne de cache. Pas de comparaison, rien, juste une lecture finale des compteurs d'erreurs ECC pour vérifier qu'il n'y en avait pas eu!
[^] # Re: Bon chasseur et mauvais chasseur
Posté par lym . En réponse au journal CISSP, sécurité, il faut que je vous raconte un truc.... Évalué à 2.
Et ça commencerait à se voir:
https://www.usinenouvelle.com/editorial/alerte-generale-sur-les-penuries-d-ingenieurs.N2043747
[^] # Re: Si je puis me permettre ...
Posté par lym . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 1.
Si IBM avait sélectionné les deux zozos proposant le pire OS (DOS: non multitâche/multi-utilisateur…) possible pour l'architecture ouverte de son PC originel en 1981, peut-être étais-ce aussi pour ne pas tuer trop vite leur (B de) business de stations Unix (traversé depuis l'origine, plus de 10 ans avant et une éternité pour l'informatique à l'époque, par la pile réseau) dès qu'Intel sortirait un processeur avec une MMU (ce qui est mieux pour le multitâche) et que qqun se dirait que les slots d'extension pourraient héberger une carte réseau!
Le premier windows avec support réseau (3.11 for workgroups) a sonné l'arrivée de la carte réseau accessible et les débuts de Linux. Le temps que cela prenne vraiment de l'envergure (au tournant de ce siècle), IBM avait gagné 20 ans et les zozos fournisseur du tas de merde étaient faits milliardaires!
[^] # Re: Si je puis me permettre ...
Posté par lym . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 4.
Pour des besoins très très simples (notification d'évènements…) d'IPC, ne pas oublier les signaux utilisateur (SIGUSR1 et 2)!
Quand dans ma domotique j'ai voulu faire en sorte que le système d'alarme perso scripté dessus fasse sonner une liste de téléphones mobiles, ayant par ailleurs codé un service (en python) faisant du filtrage d'appel (recyclant un vieux modem 56k usb branché sur le RJ11 de la Livebox alors inutilisé, tous les téléphones utilisant sa base DECT intégrée), j'avais commencé à vouloir utiliser des tubes nommés et même codé un prototype en python.
Puis n'étant pas un programmeur système (mais plutôt très bas niveau en C/ASM) et n'ayant pas anticipé que ce serait un peu "too much", surtout que le côté alarme/domotique était scripté en Lua et la gestion du modem/filtre appel ou serait ajouté le côté liste de numéro à appeler en cas d'alarme était de son côté écrite en Python… En relisant ce dernier je passe sur l'accrochage d'un handler SIGINT tout ce qu'il y a de plus commun… et eurêka, j'ai alors repensé aux signaux utilisateur et tout est devenu bien plus simple!
Côté Lua, un os.execute de 'pkill -10 -f "python.*phoneFilter.py"&'
Côté service Python (nommé phoneFilter.py), juste accrocher le handler gérant la liste d'appels si alarme (sigusr1_handler) sur le SIGUSR1 (signal 10): signal.signal(signal.SIGUSR1, sigusr1_handler)
Et mon machin à filtrer les pubeux (d'un décroché/raccroché immédiat via le modem, sur blacklist de numéros individuels, préfixes d'allocation ARCEP, voir toute plage de numéros alloués à des opérateurs de VoIP s'étant révélés au fil des mois 100% chiants… et si pas en blacklist locale ni connu dans l'annuaire DECT de la Livebox, qui a alors le bon goût de remplir un nom dans le Caller ID, beautifulsoup interroge 2 services en ligne pour récupérer une classification… et l'ajouter a une blacklist locale pour le coup suivant) s'est vu ajouter simplement très simplement une fonctionnalité.
[^] # Re: Et surtout...
Posté par lym . En réponse au journal Hypocrisie d'énergie . Évalué à -3.
0km/h, plus de mouvement, plus de chocs possibles. Le CQFD de notre "sécurité" routière… qui a commencé à taper sérieusement sur les vitesses à la fin des années 90, alors que les mortalités remontaient.
A cette époque, qu'est-ce qui arrivait de nouveau dans toutes les poches mais aussi derrière bien des volants? Le GSM…
Désormais c'est plus simplement des communications vocales (~0.8g/l d'alcoolémie selon des études d'alors, mais pas faites en France: Canada de mémoire. Soit un niveau délictuel côté bibine mais resté contraventionnel niveau "smart"-phone) mais internet et réseaux sociaux au volant (=> 1g dans chaque poche?), mais on va en remettre un coup sur les vitesses en cumulant avec prétexte de sobriété énergétique, comme en 1973?
Tout ce qui peut justifier la politique facile du radar et sa rentabilité est bienvenu. Les morts, au fond, l'état s'en fout!
[^] # Re: Bon chasseur et mauvais chasseur
Posté par lym . En réponse au journal CISSP, sécurité, il faut que je vous raconte un truc.... Évalué à 1.
"Sous prétexte que l'inscription est quasi-gratuite en fac de droit, de médecine, en prépa ou école d'ingé…"
C'est en effet pire que la situation présente en temps qu'employé, je dirais. On n'est même pas fichu de défalquer quelques trimestres obligatoires pour compenser des études supérieures niveau retraite, alors qu'on ne s'est pas vraiment roulé les pouces.
Il ne faut pas s'étonner que les études supérieures longues attirent moins un de ces jours. Surtout que niveau salaire, le rapport Q/P n'est globalement pas là. Sauf à aller faire x3 de l'autre côté de l'atlantique…
[^] # 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…