C'est vrai et regrettable, maintenant il y a quand même moyen d'améliorer notablement les choses:
-Choix d'une uSD classe A1 ou A2 (norme crée pour extension stockage smartphone, donc adaptées à un use-case 24/7 et permettant un wear-levelling statique avec ses opérations en arrière plan et donc des perfs plus constantes, ce que les bons modèles font et les rapproche de la gestion d'un SSD au TRIM près) de bonne factures.
-Monter la fréquence de l'interface, par défaut à 50MHz, plus proche du max de 100 (je suis depuis des années à 83 sans souci sur un PI3B).
-Aller voir côté sysfs les réglages vmm (virtual memory management): On peut régler la bufferisation, les temps de commit… tout ce qu'il faut pour permettre de mieux grouper les écritures par le FS: Gros gains de perf et longévité accrue, minimisant les écritures et donc les cycles d'effacement, surtout si on a conservé les logs sur la uSD et pas mis cela dans un tmpfs (au risque de plus les avoir pour un debug post-mortem). Si on a une alimentation à travers une batterie tampon évitant des pertes en cas de coupure brutale à la mesure des réglages, c'est vraiment une option à tester.
Rien que les cartes Ax, l'actuelle a 3 ans en usage domotique 24/7 et sans perte trop notable de perf qui annonce en général la fin: C'est mieux que les modèles industriels que j'utilisais jusque là et qui en wear-levelling dynamique restaient sujettes aux points chauds et peinaient à tenir 18 mois. Ces indus étaient mieux que les cartes de base (10/12 mois), mais on restait dans des cartes faites pour un usage "j'allume un bidule, il va faire qq accès surtout séquentiels, j'éteins": Pas de possibilité d'opérations d'arrière plan pour se garder un pool de secteurs pré-effacés, gérer des compteurs d'effacement par secteur physique flash et bouger les données vers un autre plus frais au besoin pour éviter les points chauds…
Le gros problème du PI5, c'est en effet son prix. Si encore le M.2 pour enfin sortir des uSD en stockage avait été en standard! Mais non, donc on reste avec le pb du stockage datant des origines qui limite les possibilités de l'ensemble avec peu d'intérêt à y passer vs PI4 ou même 3… et si on veut aller au delà, entre HAT à ajouter et stockage, boitier, alim le tarif total n'est plus du tout compétitif avec un Alder Lake N!
Le pb des SBC tierces c'est le support logiciel. Pb résolu par qq SBC base Intel qui peuvent faire tourner tout ce qu'un PC accepte, avec ajouté de quoi gérer les IO canoniques: A la limite, je dirais que raspberry qui a désormais isolé cela dans un RP1 externe a eux devrait offrir des possibilités vu que les IO chez Intel, faut pas compter sur leur déterminisme (c'est des machines à débiter en PCIe, les IO intégrées au PCH faut pas compter en faire qqchose de précis vu les latences et leur variabilité): Ca prendra 4 lignes PCIe (mais de toutes manières des USB/Eth additionnels ici intégrées feraient de même) mais offrirait des possibilités identiques de ce côté tout en n'ayant plus le problème d'une distro allant de spécifique (raspberry) à jamais mis à jour (chinoiseries).
C'est même à se demander si raspberry ne scie pas la branche avec ce RP1, sauf à avoir une politique de diffusion assez restrictive.
Ton application a juste besoin de dire le runtime auquel il dépend et si plusieurs applications utilisent le même (et c'est souvent bien partagé) tu as peu de redondance pour ces bibliothèques essentielles.
Je ne voit pas comment assurer une cohérence qui peut fonctionner dans un système centralisé de dépôts, non sans déjà causer quelques maux de têtes aux mainteneurs, pourrait être ici viable en pratique… avec chaque développeur des applicatifs aux manettes.
La réalité, c'est que les utilisateurs d'Ubuntu a qui on a fait passer pas mal d'applicatif dans le pendant Snap ont bien vu les temps de chargement/démarrage exploser au changement, surtout s'il ne sont pas passé au SSD NVME voir racheté des barrettes de RAM (car la mémoire virtuelle mappait chaque dépendance partagée dans chaque process sur une seule physiquement présente).
Ici, on s’assoit juste sur toute la pertinence d'un modèle de distribution en sources ouvertes vs binaires fermés: Tout ce qui permets de rendre un Linux plus efficace qu'un Windows et avec quasiment zéro impact performance sur un upgrade à matériel constant.
Ça, c'est la promesse. Java aussi disait «write once, run anywhere».
Et on sait comment cela a (mal) tourné: Chaque applicatif Java traînant avec lui sa JVM et dépendances dans la version testée! Avec le début de la décroissance (certes lente, vu la masse de l'existant) de ce langage à la clef.
Bref, le syndrome windows avec les compilations statiques ou les DLL quasi-doublons venant avec quasiment tout ce qu'on ajoute et s'installe certes d'un clic, en pire…
Franchement, je n'ai pas hâte de voir cela sous Linux car cela ruine toute l'efficience matérielle de gestion de la mémoire virtuelle d'une part et que l'alibi de la gestion fine des droits ne fait à mon sens que souligner le cadre pour lequel les diverses formes de conteneur, s'ajoutant ici aux doublonnages crades de non gestion intelligente des dépendances, ont été crées: Permettre de tester des applicatifs qui ne soient pas de confiance… ou de se faire un environnement d’exécution sur mesure de vieux trucs encore nécessaires à son usage/production mais devenus impossibles à recompiler/faire évoluer, par exemple car on en a perdu les sources créés avant que les systèmes de gestion de conf n'existent!
Puis comme dit par ailleurs, à la base, on peut aussi minimiser les dépendances un peu hétéroclites en les intégrant de manière statique… voir en codant la fonctionnalité soit-même plutôt que de gauler un truc plus ou moins bien fait/stable ajouté en mode quick&dirty pour ensuite le payer en maintenance sur la durée tout en emmerdant l'utilisateur final.
Niveau MAJ, je suis sous Debian depuis ~13 ans après quelques années sous Ubuntu (la LTS 10.04 fut ma dernière, après cette distro se voulant "résoudre le bug Microsoft" a de mon point de vue trop fait de gras, délires de bureau, pour finir par remplacer un "bug" par un autre), jamais eu aucun problème: Zéro, nada, néant. Autant sur des machines perso/famille (8 ou 10 références utilisées sur cette durée) qu'au boulot sur des machines lab auto administrées/hors IT.
Si j'ai eu des merdes, c'est surtout sur qq RH du boulot installées par d'autres "parce que c'est plus pro" et qui, avec des dépots vides comparés à Debian, obligent à bidouiller avec des dépôts tiers/Fedora pour tout ce qui ne se build pas facilement soit-même (option à privilégier pour tout hors-dépots sur ce système, mais pas toujours possible/aisé): Mauvaise distro, changer distro…
En réalité, tout ceci me semble venir du web qui a un développement qu'on pourrait simplement qualifier ainsi: TTM-Driven… Et on s'en fout de la durée à maintenir, on refera tout dans 2 ou 3 ans avec le nouveau framework à la mode.
Sauf que dans le cas qui nous intéresse, la durée on ne s'en fout pas!
L'autre sujet, plus personnel, c'est le bureau choisi: Gnome dans sa version canonique je n'ai jamais accroché. Si j'y suis revenu après quelques années d'errance au passage à Gnome 3 c'est car Cinnamon offre une expérience desktop classique et pas une sorte d'hybride mobile (et avant cela, les tentatives depuis avortées d'Ubuntu sur ce modèle m'avaient rebutées aussi).
A ce sujet on remarquera qu'Apple, qui ne s'est jamais trop planté sur l'ergonomie, n'a jamais tenté ce type de mauvaise fusion de ses interfaces mobiles et desktop! Probable qu'ils aient étudié cela, ayant bouleversé l'expérience mobile et collé une pomme sur la tête de la concurrence endormie sous l'arbre, sans y trouver de pertinence…
D'où cette interrogation pour moi: Vouloir rendre Linux plus accessible… avec ce choix de DE, quelle cohérence?
Le calcul est juste. Pour une conso totale égale il faut une consommation digne d'un boulanger faisant tourner ses fours en nocturne et la vitrine le jour désormais.
EDF, je n'avait pas pigé comment cela fonctionnait au moment du changement.
RTE, c'était assez simple en fait… Il suffit de regarder (F12->Réseau->Recharger la page sous Firefox par exemple) ce qu'appelle la page RTE grand public citée dans mon autre commentaire (en maintenance à l'instant ou j'écris, cependant).
On y voit une URL appelée par cette page front-end avec en paramètre les années de la saison Tempo en cours (on peut récupérer également les saisons passées complètes de manière analogue, d'ailleurs) qui retourne un JSON récapitulant tout le calendrier depuis le 1er septembre du début de saison Tempo avec les couleurs. On en tire la dispo de l'info lendemain et par simple somme les totaux par couleur de l'année en cours.
Ce que j'ai est un peu spécifique niveau langage (Lua), car ma solution domotique a une intégration Lua native (c'est un langage fait spécifiquement pour s'intégrer ainsi à d'autres programmes, même si un interpréteur classique existe, avec tout ce qu'il faut quand le cœur est en C/C++, il est d'ailleurs utilisé dans certains jeux pour scripter des actions). Mais récupérer un JSON ouvert et le parser en Python par exemple c'est simple (possible en Bash aussi, mais c'est moins évident/lisible à mon sens, son avantage est surtout d'être là de base sur presque sur tout Unice).
L'autre avantage est d'avoir 99% du temps l'info dès 6h15 (ça a parfois tardé jusqu'à 9h30 des jours ou cela a semblé hésiter et à chaque fois c'était pas du bleu le lendemain) au lieu de 11h passé chez EDF.
Je l'avais oublié cette news! Faut dire que j'avais proposé un truc écrit un peu rapidement puis reçu des demandes de modifs à un moment ou je n'étais pas chez moi en septembre dernier… puis cela m'était un peu sorti de la tête.
Merci à ceux qui ont édité/complété, cela peut sans doute toujours servir à ceux qui n'auraient pas déjà trouvé une source d'info alternative qui leur convienne. Pour celle-ci, je peux donner un bilan de l'automne/hiver qui est très positif.
Cette API cachée s'est révélée très fiable, avec une (pré-)info couleur du lendemain généralement donnée entre 6h00 et 6h15 (mon script teste à partir de 6h et tous les 1/4 d'heures si info lendemain présente): L'intérêt est d'être informé d'un jour rouge avant même de partir au boulot la veille et de lancer un gros consommateur type machine à laver de manière anticipée, sachant que si on est lundi RTE peut possiblement enquiller la semaine derrière si les prévisions de conso sont élevées et ne s'est pas privé de le faire cette année.
Il y a eu quelques exceptions plus tardives, mais elles sont restées rares et toujours bien plus tôt que les 10h30 spécifiées engager RTE, sans parler de toute autre source qui en dépends.
Je n'ai pas pu clarifier le rôle du champ fallback: Jamais constaté de remise en cause de l'info, classiquement prise dès publication chez moi, après 10h30… Mais il peut aussi y avoir des saisons tempo entières sans que cette possibilité soit utilisée et possiblement plusieurs saisons d'observation requises pour en avoir le coeur net.
Je ne pourrais sans doute pas le faire: Probable que j'abandonne Tempo en novembre prochain avant les premiers jours rouges, car les évolutions tarifaires du kWh se sont un peu foutues de ceux qui font des efforts et la CRE a d'ors et déjà annoncée vouloir persister à rendre Tempo moins intéressant car même sans changer ses habitudes les jours rouges cela restait un abonnement rentable!
OK, mais dans ce cas pourquoi avoir conservé des tarifs kWh bleu/blanc stables et baissé surtout les HP rouges quand les autres offres réglementées on baissées généralement de plus de 15% en février dernier? Ceux qui jouaient le jeu sur ces périodes de tarifs élevés ne verront aucune baisse (ne consommant quasiment rien en HP/rouge) tandis que cela va profiter en réalité à ceux qui ne changeaient rien! Cette évolution tarifaire est donc à 180° du problème soulevé par la CRE: Il eu fallu baisser bleu/blanc quitte à monter fortement les HP/rouge!
Cette année, début février le quota de jours rouges était passé donc aucun intérêt à sortir immédiatement de Tempo. Mais sur la saison suivante je pense partir sur une stratégie inverse: Passer d'un 9kVA Tempo à un 6kVA tarif fixe (car le 9kVA fixe est passé en extinction en février dernier, imposant le HP/HC qui n'est plus jamais rentable à lui seul, cf la suite) et étaler sur 24h ce que je me faisais chier à concentrer sur 8h HC, en particulier les jours rouges.
Je paierais pour le moment plus cher, mais sans la contrainte Tempo qui était forte quand on est tout électrique: Jouer avec son télétravail pour pouvoir approvisionner son insert en quasi continu, se retrouver avec 1 semaine de lessives à passer sur le WE suivant 5j consécutifs (certes, je pourrais lancer des LL en HC rouge de nuit, mais il faudrait me relever au milieu de la nuit pour tout mettre dans le sèche linge inévitable en hiver) etc… En résumé, je veux bien m'emmerder mais il faut que le jeu en vaille clairement la chandelle. Et j'ai en prime horreur qu'on se moque de moi, ce qui est à mon sens ici le cas: On a attiré le chaland en 2022 quand RTE ne pensait pas faire l'hiver sans risquer le black-out, ça va mieux, au revoir et même pas merci!
Niveau évolution, cela a piégé aussi ceux qui étaient resté sur les tarifs EJP en extinction depuis des lustres: Tous les tarifs Tempo étaient passé sous ceux EJP, beaucoup ont donc viré EJP et ne pourront y revenir alors que ce tarif est désormais redevenu plus intéressant que Tempo!
Et l’extinction du tarif fixe en 9kVA est d'ors et déjà prévue pour les 6kVA!
A ce sujet petit calcul de rentabilité HP/HC:
Si F est le tarif kWh fixe et P/C respectivement ceux d'un tarif HP/HC, à considérer les consos équivalentes Nf et Np/Nc nous avons:
Nf.F=Np.P+Nc.C pour l'équilibre tarifaire des 2 types de contrats fixe et HP/HC.
Nf=Np+Nc avec la même conso globale.
La résolution est triviale et donne un équilibre tarifaire pour un ratio de conso HC/HP de:
Nc/Np=(F-C)/(P-F)
C'est à dire que pour rentabiliser un HP/HC au tarif réglementé actuel, il faut désormais consommer à minima presque 2.5 fois plus en HC (1/3 d'une journée, généralement de nuit) qu'en HP (2/3 restants de la journée)!!! Intégrer les différences tarifaires des différents abonnements ne change ce constat qu'à la marge.
Autant dire qu'il est désormais impossible de rentabiliser un HP/HC classique (non Tempo): La mise en extinction des tarifs fixes est donc une augmentation qui ne dit pas son nom et va toucher tous les nouveaux contrats ou les changements…
Il faut en effet voir qu'il y a 25 ans, un tarif HP était équivalent au tarif fixe et les HC n'étaient que du bonus. On est depuis longtemps passé à un malus aux HP hélas jusqu'à en arriver à la situation présente: Se faire flouer! Et passer à Tempo n'est désormais plus forcément une option.
=> Retour au fixe en soignant les délestages car désormais ce sera baisser vers un 6kVA: Ce sera une conso plus plate, non pilotable à la consommation pour les producteurs qui si tout le monde fait pareil vont donc devoir se démerder pour produire! Mais il faut à un moment arrêter de prendre les gens pour des ânes…
Dans tout avion de ligne, je pense que tu trouves un bon vieux "computer" mécanique de calculs typés navigation: En cas de panne avionique tu n'as que cela et point besoin de batterie qui sera HS après l'avoir oublié des années dans un coin d'équipement de secours d'un cockpit.
Les capacités de calcul mental actuelles ont largement déclinées, suffit d'avoir eu des enfants pour le constater. Les enseignants eux-mêmes sont d'accord pour dire qu'il y a un énorme pb avec les maths en France.
C'est pourtant assez connu chez les accrocs au RPN, ce fabricant de clones des HP de la belle époque… Mais bon, pour ma part, la HP28s de prépa/école ingé tourne toujours presque 35 ans après. Et la 48s et 32s récupérées depuis d'occase dans un état collection fonctionnent aussi.
Ce qui est assez incroyable, c'est qu'on ne fasse plus de calculatrices sur ce principe: Rien que pour le simple calcul, ayant aidé mes enfants au collège/lycée avant de devoir arrêter (les souvenirs devenaient plus difficiles!) en cours de 1er cycle universitaire ces derniers étaient étonné de ma rapidité comparé à leurs empilages de parenthèses!
Les gens d'un certain âge te disent bien des choses, en mode "le temps ne fait rien à l'affaire"… pour qui commence tôt.
Pour ma part, j'ai un peu de mal à comprendre des gens qui acceptent de donner des droits illimités/sans rapport pour une appli donnant la météo. Et c'est quasiment tout le monde.
La possibilité de concevoir des sites propres en version mobile existe et pourrait sans doute faire le job de 90% de l'applicatif débilophone existant. Le fait que ce ne soit pas le cas devrait surtout interroger n'importe qui doté d'un cerveau sur les motivations réelles de faire ainsi: L'aspirateur à données personnelles en résumé, en plus de faire tourner la machine à obsolescence des appareils (performances requises, stockage…).
Cette tendance est juste stupide, surtout si on cumule avec le fait de voir que c'est une génération qui chiale sur la planète que les vieux leurs laisseraient qui y pousse: Ils n'ont sans doute plus leurs (arrière?) grands parents pour leur parler de la guerre et des rationnements qui ont perduré quasiment 10 ans ensuite, mais au train ou va le monde il se pourrait qu'un cours de rattrapage à la dure survienne au cours de leur vie.
Sur le principe du décroché/raccroché, cette appli est mieux que le NoPhoneSpam que j'utilise. Hélas, android 10 minimum et mon vieux XCover 4 est en 9, donc sur mobile ça va continuer à polluer la boite vocale mais je suis pour ma part sur mobile loin des niveaux connus sur ma ligne fixe, probable que les appels en gros y conservent un coût significatif limitant le pb (une piste à creuser pour le fixe: En finir avec les vrais illimités côté téléphonie?).
Par contre, utilisant ce principe chez moi via un vieux modem-voix 56k USB (le truc d'avant l'ADSL!) ayant la fonction CallerID et connecté au PI3 qui gère la baraque (mes tél fixes n'utilisent pas le RJ11 de la livebox, qui a une base DECT intégrée, le modem filtreur est dessus), cela n'avait pas suffit à calmer l'affaire: Ça décroche, le numéro est valide pour eux et aucun moyen de savoir si c'est un humain silencieux ou un automate qui fait la manip.
Ce qui a vraiment eu un effet, c'est de balancer les 3 tons du SIT de ligne non attribuée/en dérangement entre le décroché et le raccroché. Wikipédia-SIT
Même pas besoin du message vocal explicatif normalement requis et vu de dehors, dans mon expérience perso, les robots numéroteurs de call center vous retirent direct de leur liste quand ils se prennent un SIT. Je ne voit pas d'autre bonne raison au vu de la baisse rapide des appels bloqués consécutive à cet ajout: Passé de plusieurs dizaines/semaine à 15 sur les 2.5 derniers mois!
Un truc à suggérer à l'auteur de cette appli à mon sens.
L'opérateur qui a accès à toute la signalisation saura toujours attribuer précisément l'origine d'un appel même si le numéro appelant présenté est spoofé. Aucun besoin de mettre un nom sur un titulaire pour cela. Puis on fait comment si c'est un numéro étranger? Une BDD mondiale… ah mince y'aura toujours des états peu coopératifs!
Je ne pense pas que les pré-payé soient un réel problème côté spam téléphonique, c'est plutôt la criminalité ici le sujet.
Déjà qu'il s'est fait offrir un nouveau bracelet et pas vraiment par Rolex, cet attristé membre du gang de nos anciens présidents (mais qui n'aurait eu aucune chance au casting de Point-Break)!
"Il y a des pays où, pour acheter une SIM pré-payée, il faut fournir un numéro de carte d'identité…"
Le problème, c'est que ce n'est pas côté utilisateur/abonné que ce pb se situe mais côté usurpateur qui peut coller n'importe quoi comme numéro d'appelant.
Cf mon log plus loin, on en a un intéressant quand on lit attentivement:
CALL 13, logged at 2025-02-05 11:55:20 ; Score = blacklist
CID info : Date 0205 / Time 1155 / Nmbr 0377193829 / Name
Provider : none ; Prefix 'none'
=> Ici, on en a un qui a forcément utilisé un numéro usurpé, car il est carrément en dehors des plages d'allocation (pas de provider identifié faute que cela tombe sur un préfixe d'allocation atttribué) publiées par l'ARCEP que j'utilise et conserve à jour!
Je me rappelles il y a 2 ou 3 ans avoir eu un appel passé au travers de mes blacklist pourtant bien aiguisées: J'étais pas d'humeur/j'envoie donc bouler plus brutalement que d'habitude l'opératrice casse burnes. Rappel dans les 10s avec un 2nd numéro différent (et cette fois black listé), la même j'imagine… puis re-tente avec un 3ème numéro aussi blacklisté… et un 4ème qui cette fois en 06 passe alors au travers: La nana m'engueule de l'avoir envoyée se faire f….. et me menace carrément! Je lui dit merci, continue débile, ici tout est loggé/enregistré en lui citant les numéros qu'elle vient manifestement d'usurper! Elle raccroche. Cerise sur le gâteau déjà pas bien frais, ce 06 était attribué à un particulier, j'avais vérifié.
Tout ceci pour dire que c'est pas celui qui prends une SIM prépayée qu'il faut emmerder un peu plus. Ou alors pas pour ce motif là.
Si les opérateurs ne sont pas fichus d'éviter de router un appel qui affiche un numéro qui n'a rien à voir avec l'appelant, c'est eux qu'il faut motiver à le faire.
Notez en complément que depuis l'envoi d'un SIT aux appels bloqués au milieu du décroché/raccroché, le nombre a chuté.
A un moment j'avais ce nombre sur une demi semaine voir pire! Pas trouvé mieux, répondre c'est empirer l'affaire.
Tout cette complexité croissante du démarrage lié à la sécurité, obligeant de plus l'OS à s'en servir (via des SMC call et autres runtime services selon qu'on prie pour ne pas se faire poutrer à la chapelle Arm ou x86) via les enclaves sécurisées ayant la main exclusive sur les trucs sensibles… eh bien il ne faut pas avoir beaucoup mis son nez dans les étages de lancement de la fusée pour croire que cela améliore les choses!
C'est pourtant assez simple à comprendre: On est à des étapes du démarrage qui ont toujours été déboguées avec "la bite et le couteau" comparé à la situation bien plus confortable sous OS d'une part. D'autre part, à multiplier les verrouillages et les couches voulues étanches entre elles c'est aussi le support (matériel/drivers hors OS et autres fonctionnalités communes type gestion mémoire, affichage…) logiciel qui est multiplié d'autant.
Alors entre les doublons et la difficulté de debug accrue, inutile de dire que des problèmes à exploiter il y a en bien plus que quand tout ceci était plus simple!
Et tout cela pour quel bénéfice? Bin quand t'es root, comme faut tous les outils d'upgrade/maintenance (donc signature etc) sur la cible pour en faire quelque chose tu reste totalement libre d'y coller ce que tu veux.
Emmerdes maximales, bugs a découvrir à gogo, pour un résultat de nul à négatif.
En attendant, F-DROID doit pouvoir tout rebuilder depuis les sources et cette appli fort pratique (je l'utilise des actions liées ma domotique) a été sans MAJ sur F-D pendant plusieurs mois à cause de son moteur JS tombé à l'abandon, changé pour un autre récemment afin de débloquer F-D: https://github.com/Waboodoo/HTTP-Shortcuts/issues/446
Par contre, avec le Play Store de Gogole ça passait crème… Pour moi, ce requis de F-D c'est quand même la base et que ça passe chez Gogole c'est juste ahurissant.
Si les abus restent limités c'est en effet pas forcément la peine d'ajouter des contraintes mais vu comme d'autres sont obligés de compliquer la souscription pour limiter le problème, netlibre serait l'exception qui confirme la règle?
A mon sens, pour avoir l'utilité d'un domaine il faut avoir également la capacité de gérer ou héberger les services qui y seront liés. Partant de là, ce que j'évoquais ne sera pas forcément un réel souci par rapport au reste mais c'est mon propre sentiment, ajouté au fait que dans le domaine (!!) c'est un peu le requis généralisé en matière de keep-alive.
Le pire serait de devoir se loguer régulièrement à son compte sur le site, selon moi: Ça on finit toujours par l'oublier un jour!
La remarque était à mon sens un peu brutale face à du bénévolat!
Maintenant, si les domaines inactifs sont devenus un problème, peut-être que ce serait l'occasion d'ajouter aux conditions une obligation de rafraîchir ses domaines périodiquement (genre 1x/mois, avec envoi d'un mail de rappel et clôture si pas de réaction à l'échance suivante, ainsi sous 2 mois un domaine inactif est libéré) même si l'on est en IP fixe et que ce n'est pas vraiment nécessaire?
C'est assez commun pour ce type de service et ne surprendra personne je pense, surtout qu'ici la MAJ est vraiment on ne peut plus simple et qu'avoir un cron qui fait cela 1x/semaine (ainsi en cas d'indisponibilité temporaire de l'URL de MAJ on a de la marge) ce n'est pas bcp demander!
J'espère que ca marche avec le ssh -X, qu'on tire le graphique d'une machine toujours X11 ou Wayland? C'est vraiment un cas d'usage qui me manquerait énormément…
Sur les PC d'entreprise sous windows, vu qu'on a encore régulièrement des scripts d'administration qui se lancent dans une bonne vielle boite DOS visible de l'utilisateur, je ne pense pas que grand monde y fasse attention!
Donc le câble qui émule un clavier pour ouvrir un terminal le temps d'y dérouler un truc scripté, cela risque dans ce contexte de ne pas étonner beaucoup de monde… Il serait sans doute même possible de déclencher un "make me admin" sur un poste permettant un peu de liberté et il est même possible que les gens valident une demande d'élévation de privilège (le sudo de windows arrivé avec Vista) si par bonheur on tombe sur un compte administrateur direct.
Jusque là, ces bidules s'intercalaient sur un câble classique ou se branchaient tel une clef USB et restaient donc bien plus visible. Là c'est imparable. on peut même imaginer un dispositif avec un wifi ou plutôt un BT (moins surveillé dans les boites via la recherche régulière d'AP de shadow-IT) intégré pour un truc plus interactif/possible à mettre à jour sans devoir aller s'exposer à y re-toucher… ou exfiltrer des données.
[^] # Re: On peut faire du bureau avec ?
Posté par lym . En réponse à la dépêche Raspberry Pi 5, évolution ou révolution ?. Évalué à 1 (+0/-0).
C'est vrai et regrettable, maintenant il y a quand même moyen d'améliorer notablement les choses:
-Choix d'une uSD classe A1 ou A2 (norme crée pour extension stockage smartphone, donc adaptées à un use-case 24/7 et permettant un wear-levelling statique avec ses opérations en arrière plan et donc des perfs plus constantes, ce que les bons modèles font et les rapproche de la gestion d'un SSD au TRIM près) de bonne factures.
-Monter la fréquence de l'interface, par défaut à 50MHz, plus proche du max de 100 (je suis depuis des années à 83 sans souci sur un PI3B).
-Aller voir côté sysfs les réglages vmm (virtual memory management): On peut régler la bufferisation, les temps de commit… tout ce qu'il faut pour permettre de mieux grouper les écritures par le FS: Gros gains de perf et longévité accrue, minimisant les écritures et donc les cycles d'effacement, surtout si on a conservé les logs sur la uSD et pas mis cela dans un tmpfs (au risque de plus les avoir pour un debug post-mortem). Si on a une alimentation à travers une batterie tampon évitant des pertes en cas de coupure brutale à la mesure des réglages, c'est vraiment une option à tester.
Rien que les cartes Ax, l'actuelle a 3 ans en usage domotique 24/7 et sans perte trop notable de perf qui annonce en général la fin: C'est mieux que les modèles industriels que j'utilisais jusque là et qui en wear-levelling dynamique restaient sujettes aux points chauds et peinaient à tenir 18 mois. Ces indus étaient mieux que les cartes de base (10/12 mois), mais on restait dans des cartes faites pour un usage "j'allume un bidule, il va faire qq accès surtout séquentiels, j'éteins": Pas de possibilité d'opérations d'arrière plan pour se garder un pool de secteurs pré-effacés, gérer des compteurs d'effacement par secteur physique flash et bouger les données vers un autre plus frais au besoin pour éviter les points chauds…
[^] # Re: On peut faire du bureau avec ?
Posté par lym . En réponse à la dépêche Raspberry Pi 5, évolution ou révolution ?. Évalué à 1 (+0/-0).
Le gros problème du PI5, c'est en effet son prix. Si encore le M.2 pour enfin sortir des uSD en stockage avait été en standard! Mais non, donc on reste avec le pb du stockage datant des origines qui limite les possibilités de l'ensemble avec peu d'intérêt à y passer vs PI4 ou même 3… et si on veut aller au delà, entre HAT à ajouter et stockage, boitier, alim le tarif total n'est plus du tout compétitif avec un Alder Lake N!
Le pb des SBC tierces c'est le support logiciel. Pb résolu par qq SBC base Intel qui peuvent faire tourner tout ce qu'un PC accepte, avec ajouté de quoi gérer les IO canoniques: A la limite, je dirais que raspberry qui a désormais isolé cela dans un RP1 externe a eux devrait offrir des possibilités vu que les IO chez Intel, faut pas compter sur leur déterminisme (c'est des machines à débiter en PCIe, les IO intégrées au PCH faut pas compter en faire qqchose de précis vu les latences et leur variabilité): Ca prendra 4 lignes PCIe (mais de toutes manières des USB/Eth additionnels ici intégrées feraient de même) mais offrirait des possibilités identiques de ce côté tout en n'ayant plus le problème d'une distro allant de spécifique (raspberry) à jamais mis à jour (chinoiseries).
C'est même à se demander si raspberry ne scie pas la branche avec ce RP1, sauf à avoir une politique de diffusion assez restrictive.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par lym . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 2 (+2/-1).
Je ne voit pas comment assurer une cohérence qui peut fonctionner dans un système centralisé de dépôts, non sans déjà causer quelques maux de têtes aux mainteneurs, pourrait être ici viable en pratique… avec chaque développeur des applicatifs aux manettes.
La réalité, c'est que les utilisateurs d'Ubuntu a qui on a fait passer pas mal d'applicatif dans le pendant Snap ont bien vu les temps de chargement/démarrage exploser au changement, surtout s'il ne sont pas passé au SSD NVME voir racheté des barrettes de RAM (car la mémoire virtuelle mappait chaque dépendance partagée dans chaque process sur une seule physiquement présente).
Ici, on s’assoit juste sur toute la pertinence d'un modèle de distribution en sources ouvertes vs binaires fermés: Tout ce qui permets de rendre un Linux plus efficace qu'un Windows et avec quasiment zéro impact performance sur un upgrade à matériel constant.
[^] # Re: Je ne comprends pas l’engouement autour de flatpak ou snap
Posté par lym . En réponse à la dépêche GNOME OS comme Linux idéal, partie 1 : la promesse de l'atomique. Évalué à 3 (+3/-1).
Et on sait comment cela a (mal) tourné: Chaque applicatif Java traînant avec lui sa JVM et dépendances dans la version testée! Avec le début de la décroissance (certes lente, vu la masse de l'existant) de ce langage à la clef.
Bref, le syndrome windows avec les compilations statiques ou les DLL quasi-doublons venant avec quasiment tout ce qu'on ajoute et s'installe certes d'un clic, en pire…
Franchement, je n'ai pas hâte de voir cela sous Linux car cela ruine toute l'efficience matérielle de gestion de la mémoire virtuelle d'une part et que l'alibi de la gestion fine des droits ne fait à mon sens que souligner le cadre pour lequel les diverses formes de conteneur, s'ajoutant ici aux doublonnages crades de non gestion intelligente des dépendances, ont été crées: Permettre de tester des applicatifs qui ne soient pas de confiance… ou de se faire un environnement d’exécution sur mesure de vieux trucs encore nécessaires à son usage/production mais devenus impossibles à recompiler/faire évoluer, par exemple car on en a perdu les sources créés avant que les systèmes de gestion de conf n'existent!
Puis comme dit par ailleurs, à la base, on peut aussi minimiser les dépendances un peu hétéroclites en les intégrant de manière statique… voir en codant la fonctionnalité soit-même plutôt que de gauler un truc plus ou moins bien fait/stable ajouté en mode quick&dirty pour ensuite le payer en maintenance sur la durée tout en emmerdant l'utilisateur final.
Niveau MAJ, je suis sous Debian depuis ~13 ans après quelques années sous Ubuntu (la LTS 10.04 fut ma dernière, après cette distro se voulant "résoudre le bug Microsoft" a de mon point de vue trop fait de gras, délires de bureau, pour finir par remplacer un "bug" par un autre), jamais eu aucun problème: Zéro, nada, néant. Autant sur des machines perso/famille (8 ou 10 références utilisées sur cette durée) qu'au boulot sur des machines lab auto administrées/hors IT.
Si j'ai eu des merdes, c'est surtout sur qq RH du boulot installées par d'autres "parce que c'est plus pro" et qui, avec des dépots vides comparés à Debian, obligent à bidouiller avec des dépôts tiers/Fedora pour tout ce qui ne se build pas facilement soit-même (option à privilégier pour tout hors-dépots sur ce système, mais pas toujours possible/aisé): Mauvaise distro, changer distro…
En réalité, tout ceci me semble venir du web qui a un développement qu'on pourrait simplement qualifier ainsi: TTM-Driven… Et on s'en fout de la durée à maintenir, on refera tout dans 2 ou 3 ans avec le nouveau framework à la mode.
Sauf que dans le cas qui nous intéresse, la durée on ne s'en fout pas!
L'autre sujet, plus personnel, c'est le bureau choisi: Gnome dans sa version canonique je n'ai jamais accroché. Si j'y suis revenu après quelques années d'errance au passage à Gnome 3 c'est car Cinnamon offre une expérience desktop classique et pas une sorte d'hybride mobile (et avant cela, les tentatives depuis avortées d'Ubuntu sur ce modèle m'avaient rebutées aussi).
A ce sujet on remarquera qu'Apple, qui ne s'est jamais trop planté sur l'ergonomie, n'a jamais tenté ce type de mauvaise fusion de ses interfaces mobiles et desktop! Probable qu'ils aient étudié cela, ayant bouleversé l'expérience mobile et collé une pomme sur la tête de la concurrence endormie sous l'arbre, sans y trouver de pertinence…
D'où cette interrogation pour moi: Vouloir rendre Linux plus accessible… avec ce choix de DE, quelle cohérence?
[^] # Re: Ouf!
Posté par lym . En réponse à la dépêche Information couleur du jour pour contrats électricité Tempo. Évalué à 0 (+0/-1).
Le calcul est juste. Pour une conso totale égale il faut une consommation digne d'un boulanger faisant tourner ses fours en nocturne et la vitrine le jour désormais.
[^] # Re: La couleur du jour dans son terminal
Posté par lym . En réponse à la dépêche Information couleur du jour pour contrats électricité Tempo. Évalué à 1 (+0/-0).
EDF, je n'avait pas pigé comment cela fonctionnait au moment du changement.
RTE, c'était assez simple en fait… Il suffit de regarder (F12->Réseau->Recharger la page sous Firefox par exemple) ce qu'appelle la page RTE grand public citée dans mon autre commentaire (en maintenance à l'instant ou j'écris, cependant).
On y voit une URL appelée par cette page front-end avec en paramètre les années de la saison Tempo en cours (on peut récupérer également les saisons passées complètes de manière analogue, d'ailleurs) qui retourne un JSON récapitulant tout le calendrier depuis le 1er septembre du début de saison Tempo avec les couleurs. On en tire la dispo de l'info lendemain et par simple somme les totaux par couleur de l'année en cours.
Ce que j'ai est un peu spécifique niveau langage (Lua), car ma solution domotique a une intégration Lua native (c'est un langage fait spécifiquement pour s'intégrer ainsi à d'autres programmes, même si un interpréteur classique existe, avec tout ce qu'il faut quand le cœur est en C/C++, il est d'ailleurs utilisé dans certains jeux pour scripter des actions). Mais récupérer un JSON ouvert et le parser en Python par exemple c'est simple (possible en Bash aussi, mais c'est moins évident/lisible à mon sens, son avantage est surtout d'être là de base sur presque sur tout Unice).
L'autre avantage est d'avoir 99% du temps l'info dès 6h15 (ça a parfois tardé jusqu'à 9h30 des jours ou cela a semblé hésiter et à chaque fois c'était pas du bleu le lendemain) au lieu de 11h passé chez EDF.
[^] # Re: Une autre alternative libre
Posté par lym . En réponse à la dépêche La liberté des calculatrices graphiques ?. Évalué à 3 (+2/-0).
Sinon, cette 16C de programmeur il y a moyen de l'avoir toujours sur soi quand on a un smartphone Android: JRPN 16C (une 15C existe aussi)!
Dispo à la fois sur Gogole store et F-Droid. Il y a même une version tournant dans le navigateur ici:
https://jrpn.jovial.com/
# Ouf!
Posté par lym . En réponse à la dépêche Information couleur du jour pour contrats électricité Tempo. Évalué à 4 (+5/-2).
Je l'avais oublié cette news! Faut dire que j'avais proposé un truc écrit un peu rapidement puis reçu des demandes de modifs à un moment ou je n'étais pas chez moi en septembre dernier… puis cela m'était un peu sorti de la tête.
Merci à ceux qui ont édité/complété, cela peut sans doute toujours servir à ceux qui n'auraient pas déjà trouvé une source d'info alternative qui leur convienne. Pour celle-ci, je peux donner un bilan de l'automne/hiver qui est très positif.
Cette API cachée s'est révélée très fiable, avec une (pré-)info couleur du lendemain généralement donnée entre 6h00 et 6h15 (mon script teste à partir de 6h et tous les 1/4 d'heures si info lendemain présente): L'intérêt est d'être informé d'un jour rouge avant même de partir au boulot la veille et de lancer un gros consommateur type machine à laver de manière anticipée, sachant que si on est lundi RTE peut possiblement enquiller la semaine derrière si les prévisions de conso sont élevées et ne s'est pas privé de le faire cette année.
Il y a eu quelques exceptions plus tardives, mais elles sont restées rares et toujours bien plus tôt que les 10h30 spécifiées engager RTE, sans parler de toute autre source qui en dépends.
Je n'ai pas pu clarifier le rôle du champ fallback: Jamais constaté de remise en cause de l'info, classiquement prise dès publication chez moi, après 10h30… Mais il peut aussi y avoir des saisons tempo entières sans que cette possibilité soit utilisée et possiblement plusieurs saisons d'observation requises pour en avoir le coeur net.
Je ne pourrais sans doute pas le faire: Probable que j'abandonne Tempo en novembre prochain avant les premiers jours rouges, car les évolutions tarifaires du kWh se sont un peu foutues de ceux qui font des efforts et la CRE a d'ors et déjà annoncée vouloir persister à rendre Tempo moins intéressant car même sans changer ses habitudes les jours rouges cela restait un abonnement rentable!
OK, mais dans ce cas pourquoi avoir conservé des tarifs kWh bleu/blanc stables et baissé surtout les HP rouges quand les autres offres réglementées on baissées généralement de plus de 15% en février dernier? Ceux qui jouaient le jeu sur ces périodes de tarifs élevés ne verront aucune baisse (ne consommant quasiment rien en HP/rouge) tandis que cela va profiter en réalité à ceux qui ne changeaient rien! Cette évolution tarifaire est donc à 180° du problème soulevé par la CRE: Il eu fallu baisser bleu/blanc quitte à monter fortement les HP/rouge!
Cette année, début février le quota de jours rouges était passé donc aucun intérêt à sortir immédiatement de Tempo. Mais sur la saison suivante je pense partir sur une stratégie inverse: Passer d'un 9kVA Tempo à un 6kVA tarif fixe (car le 9kVA fixe est passé en extinction en février dernier, imposant le HP/HC qui n'est plus jamais rentable à lui seul, cf la suite) et étaler sur 24h ce que je me faisais chier à concentrer sur 8h HC, en particulier les jours rouges.
Je paierais pour le moment plus cher, mais sans la contrainte Tempo qui était forte quand on est tout électrique: Jouer avec son télétravail pour pouvoir approvisionner son insert en quasi continu, se retrouver avec 1 semaine de lessives à passer sur le WE suivant 5j consécutifs (certes, je pourrais lancer des LL en HC rouge de nuit, mais il faudrait me relever au milieu de la nuit pour tout mettre dans le sèche linge inévitable en hiver) etc… En résumé, je veux bien m'emmerder mais il faut que le jeu en vaille clairement la chandelle. Et j'ai en prime horreur qu'on se moque de moi, ce qui est à mon sens ici le cas: On a attiré le chaland en 2022 quand RTE ne pensait pas faire l'hiver sans risquer le black-out, ça va mieux, au revoir et même pas merci!
Niveau évolution, cela a piégé aussi ceux qui étaient resté sur les tarifs EJP en extinction depuis des lustres: Tous les tarifs Tempo étaient passé sous ceux EJP, beaucoup ont donc viré EJP et ne pourront y revenir alors que ce tarif est désormais redevenu plus intéressant que Tempo!
Et l’extinction du tarif fixe en 9kVA est d'ors et déjà prévue pour les 6kVA!
A ce sujet petit calcul de rentabilité HP/HC:
Si F est le tarif kWh fixe et P/C respectivement ceux d'un tarif HP/HC, à considérer les consos équivalentes Nf et Np/Nc nous avons:
Nf.F=Np.P+Nc.C pour l'équilibre tarifaire des 2 types de contrats fixe et HP/HC.
Nf=Np+Nc avec la même conso globale.
La résolution est triviale et donne un équilibre tarifaire pour un ratio de conso HC/HP de:
Nc/Np=(F-C)/(P-F)
Avec les tarifs actuels donnés ici:
https://particulier.edf.fr/content/dam/2-Actifs/Documents/Offres/Grille_prix_Tarif_Bleu.pdf
Nc/Np=(20.16-16.96)/(21.46-20.16)=2.46
C'est à dire que pour rentabiliser un HP/HC au tarif réglementé actuel, il faut désormais consommer à minima presque 2.5 fois plus en HC (1/3 d'une journée, généralement de nuit) qu'en HP (2/3 restants de la journée)!!! Intégrer les différences tarifaires des différents abonnements ne change ce constat qu'à la marge.
Autant dire qu'il est désormais impossible de rentabiliser un HP/HC classique (non Tempo): La mise en extinction des tarifs fixes est donc une augmentation qui ne dit pas son nom et va toucher tous les nouveaux contrats ou les changements…
Il faut en effet voir qu'il y a 25 ans, un tarif HP était équivalent au tarif fixe et les HC n'étaient que du bonus. On est depuis longtemps passé à un malus aux HP hélas jusqu'à en arriver à la situation présente: Se faire flouer! Et passer à Tempo n'est désormais plus forcément une option.
=> Retour au fixe en soignant les délestages car désormais ce sera baisser vers un 6kVA: Ce sera une conso plus plate, non pilotable à la consommation pour les producteurs qui si tout le monde fait pareil vont donc devoir se démerder pour produire! Mais il faut à un moment arrêter de prendre les gens pour des ânes…
[^] # Re: Catalogue API RTE
Posté par lym . En réponse à la dépêche Information couleur du jour pour contrats électricité Tempo. Évalué à 1 (+0/-0).
Hello,
En effet, c'est la possibilité toute fléchée!
Maintenant, la question, c'est pourquoi imposer un compte pour obtenir une info ouverte?
Si on regarde un site très utilisé en domotique et faisant indirection (https://www.api-couleur-tempo.fr/) il utilise aussi en source l'URL libre d'accès de RTE et à regarder ses sources sur Github, un commentaire évoque qu'en plus de demander un compte ces API seraient moins stables que l'URL sans prise de tête qui alimente le site donnant l'info mise en forme (https://www.services-rte.com/fr/visualisez-les-donnees-publiees-par-rte/calendrier-des-offres-de-fourniture-de-type-tempo.html)!
[^] # Re: La limite de la liberté... pour le mode examen. Normal.
Posté par lym . En réponse à la dépêche La liberté des calculatrices graphiques ?. Évalué à 1 (+1/-1).
Dans tout avion de ligne, je pense que tu trouves un bon vieux "computer" mécanique de calculs typés navigation: En cas de panne avionique tu n'as que cela et point besoin de batterie qui sera HS après l'avoir oublié des années dans un coin d'équipement de secours d'un cockpit.
Les capacités de calcul mental actuelles ont largement déclinées, suffit d'avoir eu des enfants pour le constater. Les enseignants eux-mêmes sont d'accord pour dire qu'il y a un énorme pb avec les maths en France.
[^] # Re: Une autre alternative libre
Posté par lym . En réponse à la dépêche La liberté des calculatrices graphiques ?. Évalué à 3 (+2/-0).
C'est pourtant assez connu chez les accrocs au RPN, ce fabricant de clones des HP de la belle époque… Mais bon, pour ma part, la HP28s de prépa/école ingé tourne toujours presque 35 ans après. Et la 48s et 32s récupérées depuis d'occase dans un état collection fonctionnent aussi.
Ce qui est assez incroyable, c'est qu'on ne fasse plus de calculatrices sur ce principe: Rien que pour le simple calcul, ayant aidé mes enfants au collège/lycée avant de devoir arrêter (les souvenirs devenaient plus difficiles!) en cours de 1er cycle universitaire ces derniers étaient étonné de ma rapidité comparé à leurs empilages de parenthèses!
[^] # Re: Nous sommes des êtres corruptibles...
Posté par lym . En réponse au journal Après la boutique des JO, c'est au tour de la banque, et d'ici dix ans..de tout le reste?. Évalué à 1 (+0/-0).
Les gens d'un certain âge te disent bien des choses, en mode "le temps ne fait rien à l'affaire"… pour qui commence tôt.
Pour ma part, j'ai un peu de mal à comprendre des gens qui acceptent de donner des droits illimités/sans rapport pour une appli donnant la météo. Et c'est quasiment tout le monde.
La possibilité de concevoir des sites propres en version mobile existe et pourrait sans doute faire le job de 90% de l'applicatif débilophone existant. Le fait que ce ne soit pas le cas devrait surtout interroger n'importe qui doté d'un cerveau sur les motivations réelles de faire ainsi: L'aspirateur à données personnelles en résumé, en plus de faire tourner la machine à obsolescence des appareils (performances requises, stockage…).
Cette tendance est juste stupide, surtout si on cumule avec le fait de voir que c'est une génération qui chiale sur la planète que les vieux leurs laisseraient qui y pousse: Ils n'ont sans doute plus leurs (arrière?) grands parents pour leur parler de la guerre et des rationnements qui ont perduré quasiment 10 ans ensuite, mais au train ou va le monde il se pourrait qu'un cours de rattrapage à la dure survienne au cours de leur vie.
[^] # Re: Mode balek ? Pas si sûr
Posté par lym . En réponse au journal Vers l'interdiction du démarchage téléphonique en France !. Évalué à 2 (+1/-0).
Sur le principe du décroché/raccroché, cette appli est mieux que le NoPhoneSpam que j'utilise. Hélas, android 10 minimum et mon vieux XCover 4 est en 9, donc sur mobile ça va continuer à polluer la boite vocale mais je suis pour ma part sur mobile loin des niveaux connus sur ma ligne fixe, probable que les appels en gros y conservent un coût significatif limitant le pb (une piste à creuser pour le fixe: En finir avec les vrais illimités côté téléphonie?).
Par contre, utilisant ce principe chez moi via un vieux modem-voix 56k USB (le truc d'avant l'ADSL!) ayant la fonction CallerID et connecté au PI3 qui gère la baraque (mes tél fixes n'utilisent pas le RJ11 de la livebox, qui a une base DECT intégrée, le modem filtreur est dessus), cela n'avait pas suffit à calmer l'affaire: Ça décroche, le numéro est valide pour eux et aucun moyen de savoir si c'est un humain silencieux ou un automate qui fait la manip.
Ce qui a vraiment eu un effet, c'est de balancer les 3 tons du SIT de ligne non attribuée/en dérangement entre le décroché et le raccroché. Wikipédia-SIT
Même pas besoin du message vocal explicatif normalement requis et vu de dehors, dans mon expérience perso, les robots numéroteurs de call center vous retirent direct de leur liste quand ils se prennent un SIT. Je ne voit pas d'autre bonne raison au vu de la baisse rapide des appels bloqués consécutive à cet ajout: Passé de plusieurs dizaines/semaine à 15 sur les 2.5 derniers mois!
Un truc à suggérer à l'auteur de cette appli à mon sens.
[^] # Re: Tant qu'il n'y aura pas la validation du n° c'est voué l'échec
Posté par lym . En réponse au journal Vers l'interdiction du démarchage téléphonique en France !. Évalué à 2 (+1/-0).
L'opérateur qui a accès à toute la signalisation saura toujours attribuer précisément l'origine d'un appel même si le numéro appelant présenté est spoofé. Aucun besoin de mettre un nom sur un titulaire pour cela. Puis on fait comment si c'est un numéro étranger? Une BDD mondiale… ah mince y'aura toujours des états peu coopératifs!
Je ne pense pas que les pré-payé soient un réel problème côté spam téléphonique, c'est plutôt la criminalité ici le sujet.
[^] # Re: Tant qu'il n'y aura pas la validation du n° c'est voué l'échec
Posté par lym . En réponse au journal Vers l'interdiction du démarchage téléphonique en France !. Évalué à 1 (+0/-0).
Et Paul Bismuth, il va faire comment alors?
Déjà qu'il s'est fait offrir un nouveau bracelet et pas vraiment par Rolex, cet attristé membre du gang de nos anciens présidents (mais qui n'aurait eu aucune chance au casting de Point-Break)!
[^] # Re: Tant qu'il n'y aura pas la validation du n° c'est voué l'échec
Posté par lym . En réponse au journal Vers l'interdiction du démarchage téléphonique en France !. Évalué à 2 (+1/-0).
"Il y a des pays où, pour acheter une SIM pré-payée, il faut fournir un numéro de carte d'identité…"
Le problème, c'est que ce n'est pas côté utilisateur/abonné que ce pb se situe mais côté usurpateur qui peut coller n'importe quoi comme numéro d'appelant.
Cf mon log plus loin, on en a un intéressant quand on lit attentivement:
=> Ici, on en a un qui a forcément utilisé un numéro usurpé, car il est carrément en dehors des plages d'allocation (pas de provider identifié faute que cela tombe sur un préfixe d'allocation atttribué) publiées par l'ARCEP que j'utilise et conserve à jour!
Je me rappelles il y a 2 ou 3 ans avoir eu un appel passé au travers de mes blacklist pourtant bien aiguisées: J'étais pas d'humeur/j'envoie donc bouler plus brutalement que d'habitude l'opératrice casse burnes. Rappel dans les 10s avec un 2nd numéro différent (et cette fois black listé), la même j'imagine… puis re-tente avec un 3ème numéro aussi blacklisté… et un 4ème qui cette fois en 06 passe alors au travers: La nana m'engueule de l'avoir envoyée se faire f….. et me menace carrément! Je lui dit merci, continue débile, ici tout est loggé/enregistré en lui citant les numéros qu'elle vient manifestement d'usurper! Elle raccroche. Cerise sur le gâteau déjà pas bien frais, ce 06 était attribué à un particulier, j'avais vérifié.
Tout ceci pour dire que c'est pas celui qui prends une SIM prépayée qu'il faut emmerder un peu plus. Ou alors pas pour ce motif là.
Si les opérateurs ne sont pas fichus d'éviter de router un appel qui affiche un numéro qui n'a rien à voir avec l'appelant, c'est eux qu'il faut motiver à le faire.
[^] # Re: Mode balek...
Posté par lym . En réponse au journal Vers l'interdiction du démarchage téléphonique en France !. Évalué à 2 (+1/-0).
Notez en complément que depuis l'envoi d'un SIT aux appels bloqués au milieu du décroché/raccroché, le nombre a chuté.
A un moment j'avais ce nombre sur une demi semaine voir pire! Pas trouvé mieux, répondre c'est empirer l'affaire.
# Mode balek...
Posté par lym . En réponse au journal Vers l'interdiction du démarchage téléphonique en France !. Évalué à 1 (+0/-0).
Liste des bloqués depuis fin novembre chez moi:
Caller list (since 2024-11-30 15:52:18) :
- CALL 1, logged at 2024-12-02 10:16:41 ; Score = blacklist
CID info : Date 1202 / Time 1016 / Nmbr 0188440244 / Name
Provider : DVSC ; Prefix '0188440'
- CALL 2, logged at 2024-12-02 17:00:01 ; Score = blacklist
CID info : Date 1202 / Time 1659 / Nmbr 0162000926 / Name
Provider : LGC ; Prefix '016200'
- CALL 3, logged at 2024-12-06 12:02:47 ; Score = blacklist
CID info : Date 1206 / Time 1202 / Nmbr 0162081193 / Name
Provider : IAGI ; Prefix '0162081'
- CALL 4, logged at 2024-12-20 12:08:53 ; Score = blacklist
CID info : Date 1220 / Time 1208 / Nmbr 0948380339 / Name
Provider : IAGI ; Prefix '094838'
- CALL 5, logged at 2025-01-02 13:03:35 ; Score = blacklist
CID info : Date 0102 / Time 1303 / Nmbr 0270491130 / Name
Provider : LGC ; Prefix '027049'
- CALL 6, logged at 2025-01-09 13:46:02 ; Score = blacklist
CID info : Date 0109 / Time 1345 / Nmbr 0424501192 / Name
Provider : LGC ; Prefix '042450'
- CALL 7, logged at 2025-01-13 14:57:46 ; Score = blacklist
CID info : Date 0113 / Time 1457 / Nmbr 0162543553 / Name
Provider : OXIL ; Prefix '0162543'
- CALL 8, logged at 2025-01-20 11:48:54 ; Score = blacklist
CID info : Date 0120 / Time 1148 / Nmbr 0162000922 / Name
Provider : LGC ; Prefix '016200'
- CALL 9, logged at 2025-01-23 12:15:23 ; Score = blacklist
CID info : Date 0123 / Time 1215 / Nmbr 0162081602 / Name
Provider : IAGI ; Prefix '0162081'
- CALL 10, logged at 2025-01-23 17:57:15 ; Score = blacklist
CID info : Date 0123 / Time 1757 / Nmbr 0162081604 / Name
Provider : IAGI ; Prefix '0162081'
- CALL 11, logged at 2025-01-24 19:24:53 ; Score = blacklist
CID info : Date 0124 / Time 1924 / Nmbr 0162081602 / Name
Provider : IAGI ; Prefix '0162081'
- CALL 12, logged at 2025-01-31 14:08:04 ; Score = blacklist
CID info : Date 0131 / Time 1407 / Nmbr 0568233008 / Name
Provider : DVSC ; Prefix '056823'
- CALL 13, logged at 2025-02-05 11:55:20 ; Score = blacklist
CID info : Date 0205 / Time 1155 / Nmbr 0377193829 / Name
Provider : none ; Prefix 'none'
- CALL 14, logged at 2025-02-05 12:35:32 ; Score = blacklist
CID info : Date 0205 / Time 1235 / Nmbr 0424458928 / Name
Provider : LNCT ; Prefix '0424458'
- CALL 15, logged at 2025-02-06 12:21:49 ; Score = neutral
CID info : Date 0206 / Time 1221 / Nmbr 0634894341 / Name
Provider : SFR0 ; Prefix '06348'
[^] # Re: Custom rom bloquée
Posté par lym . En réponse au sondage Quel âge a votre smartphone ?. Évalué à 0 (+0/-1).
Pas grave, si tu ne comprends pas c'est que tu n'es pas vraiment concerné!
Allez: https://github.com/ARM-software/arm-trusted-firmware
[^] # Re: Custom rom bloquée
Posté par lym . En réponse au sondage Quel âge a votre smartphone ?. Évalué à 2 (+1/-0).
Tout cette complexité croissante du démarrage lié à la sécurité, obligeant de plus l'OS à s'en servir (via des SMC call et autres runtime services selon qu'on prie pour ne pas se faire poutrer à la chapelle Arm ou x86) via les enclaves sécurisées ayant la main exclusive sur les trucs sensibles… eh bien il ne faut pas avoir beaucoup mis son nez dans les étages de lancement de la fusée pour croire que cela améliore les choses!
C'est pourtant assez simple à comprendre: On est à des étapes du démarrage qui ont toujours été déboguées avec "la bite et le couteau" comparé à la situation bien plus confortable sous OS d'une part. D'autre part, à multiplier les verrouillages et les couches voulues étanches entre elles c'est aussi le support (matériel/drivers hors OS et autres fonctionnalités communes type gestion mémoire, affichage…) logiciel qui est multiplié d'autant.
Alors entre les doublons et la difficulté de debug accrue, inutile de dire que des problèmes à exploiter il y a en bien plus que quand tout ceci était plus simple!
Et tout cela pour quel bénéfice? Bin quand t'es root, comme faut tous les outils d'upgrade/maintenance (donc signature etc) sur la cible pour en faire quelque chose tu reste totalement libre d'y coller ce que tu veux.
Emmerdes maximales, bugs a découvrir à gogo, pour un résultat de nul à négatif.
[^] # Re: Custom rom bloquée
Posté par lym . En réponse au sondage Quel âge a votre smartphone ?. Évalué à 5 (+4/-0).
En attendant, F-DROID doit pouvoir tout rebuilder depuis les sources et cette appli fort pratique (je l'utilise des actions liées ma domotique) a été sans MAJ sur F-D pendant plusieurs mois à cause de son moteur JS tombé à l'abandon, changé pour un autre récemment afin de débloquer F-D:
https://github.com/Waboodoo/HTTP-Shortcuts/issues/446
Par contre, avec le Play Store de Gogole ça passait crème… Pour moi, ce requis de F-D c'est quand même la base et que ça passe chez Gogole c'est juste ahurissant.
Alors maintenant, on peut disserter sur le reste mais on en revient au grand cirque de la sécurité qui in-fine, maintient une accidentologie digne de feu le Continental-Circus… pour parodier Linus qui parlait il y a une dizaine d'années déjà d'un "cirque" et de "singes branleurs"!
https://www.reseaux-telecoms.net/actualites/lire-linus-torvalds-en-a-assez-de-tout-ce--cirque-sur-la-securite-18643.html
[^] # Re: délai de six mois seulement ?!
Posté par lym . En réponse à la dépêche Netlibre, un service libre et un nom de domaine gratuit. Évalué à 2.
Si les abus restent limités c'est en effet pas forcément la peine d'ajouter des contraintes mais vu comme d'autres sont obligés de compliquer la souscription pour limiter le problème, netlibre serait l'exception qui confirme la règle?
A mon sens, pour avoir l'utilité d'un domaine il faut avoir également la capacité de gérer ou héberger les services qui y seront liés. Partant de là, ce que j'évoquais ne sera pas forcément un réel souci par rapport au reste mais c'est mon propre sentiment, ajouté au fait que dans le domaine (!!) c'est un peu le requis généralisé en matière de keep-alive.
Le pire serait de devoir se loguer régulièrement à son compte sur le site, selon moi: Ça on finit toujours par l'oublier un jour!
[^] # Re: délai de six mois seulement ?!
Posté par lym . En réponse à la dépêche Netlibre, un service libre et un nom de domaine gratuit. Évalué à 2.
La remarque était à mon sens un peu brutale face à du bénévolat!
Maintenant, si les domaines inactifs sont devenus un problème, peut-être que ce serait l'occasion d'ajouter aux conditions une obligation de rafraîchir ses domaines périodiquement (genre 1x/mois, avec envoi d'un mail de rappel et clôture si pas de réaction à l'échance suivante, ainsi sous 2 mois un domaine inactif est libéré) même si l'on est en IP fixe et que ce n'est pas vraiment nécessaire?
C'est assez commun pour ce type de service et ne surprendra personne je pense, surtout qu'ici la MAJ est vraiment on ne peut plus simple et qu'avoir un cron qui fait cela 1x/semaine (ainsi en cas d'indisponibilité temporaire de l'URL de MAJ on a de la marge) ce n'est pas bcp demander!
[^] # Re: Attentes / contributions préalables pour Debian Trixie
Posté par lym . En réponse au journal Debian 13 (Trixie) : à quand le gel ?. Évalué à 2.
"Xwayland assure la transition"
J'espère que ca marche avec le ssh -X, qu'on tire le graphique d'une machine toujours X11 ou Wayland? C'est vraiment un cas d'usage qui me manquerait énormément…
[^] # Re: Intéressant mais ça manque de détail technique
Posté par lym . En réponse au journal Un câble USB qui permet de pirater un ordinateur.. Évalué à 2.
Sur les PC d'entreprise sous windows, vu qu'on a encore régulièrement des scripts d'administration qui se lancent dans une bonne vielle boite DOS visible de l'utilisateur, je ne pense pas que grand monde y fasse attention!
Donc le câble qui émule un clavier pour ouvrir un terminal le temps d'y dérouler un truc scripté, cela risque dans ce contexte de ne pas étonner beaucoup de monde… Il serait sans doute même possible de déclencher un "make me admin" sur un poste permettant un peu de liberté et il est même possible que les gens valident une demande d'élévation de privilège (le sudo de windows arrivé avec Vista) si par bonheur on tombe sur un compte administrateur direct.
Plus finement, exploiter une faille sur n'importe quoi qui peut passer par de l'USB (cad désormais à peu près tout!), surtout ce qui n'est pas si communément utilisé et auquel pas grand monde ne pense d'un point de vue sécurité. On a ainsi vu le MIDI exploité il y a qq années sous Linux:
https://i.blackhat.com/EU-21/Thursday/EU-21-Bogaard-Geist-Achieving-Linux-Kernel-Code-Execution-Through-A-Malicious-USB-Device.pdf
Jusque là, ces bidules s'intercalaient sur un câble classique ou se branchaient tel une clef USB et restaient donc bien plus visible. Là c'est imparable. on peut même imaginer un dispositif avec un wifi ou plutôt un BT (moins surveillé dans les boites via la recherche régulière d'AP de shadow-IT) intégré pour un truc plus interactif/possible à mettre à jour sans devoir aller s'exposer à y re-toucher… ou exfiltrer des données.