il n'y a que deux boutons -/+ et tu dois sélectionner au préalable sur lequel des 4 feux tu veux régler le niveau de puissance.
Je me suis retenu de faire déborder le troll vers les bouton +/- mais c'est clairement le corolaire. Je peste violemment contre cette incongruité à chaque fois que j'en rencontre (locations, etc).
Je suis au gaz, les boutons sont arrangés exactement comme les brûleurs, ça réagit instantanément, et qu'on tourne violemmente à droite où à gauche ça résoud le problème (un côté c'est "mini", l'autre c'est "off"). On peut régler par pas infinitésimaux. Bref ça c'est de l'UX bordel.
Pour répondre précisément au problème du lait qui déborde : c'est beaucoup plus safe de couper/baisser le gaz d'un coup plutôt que de tenter de soulever une casserole bouillante en panique (cas vécu au hasard : oublie de la tendinite qui 2sec après avoir soulevé la casserole te fait tout lâcher, etc).
Et je trolle pas au point d'avoir le gros bouton rouge de coupure urgente, juste des contrôles intuitifs, raisonnables et efficaces. Je pense que la roue codée ne l'est que dans 1% des cas (et là on s'esbaudit, certes).
Et surtout : le problème est le même avec un potard asservi
Je ne pense pas. Le potard asservi ne peut pas sauter instantanément à un volume démentiel, et même s'il peut atteindre une valeur indécente, ce n'est pas du tout le même effet psychologique sur l'organisme. Et surtout le réflexe de sauter sur le bouton et de le tourner fissa vers 0 est effectif.
Ça, ça ne devrait pas arriver non plus et ce n'est pas vraiment le problème de la roue, mais de ce qui va derrière.
On est d'accord, le soft qui interprète le signal de la roue représente 90% du problème. Mais ça rejoint mon troll : impossible de se planter niveau UX avec un potard analogique. Alors qu'avec une roue codée (ou des boutons +/-) toutes les erreurs sont possibles, et je dirai même que les implémentations bien foutues (=ergonomiques) sont rarissimes.
Y a de l'aérosol spécial potard ? Bon à savoir… Effectivement sur les gros amplis ce sont souvent des potards à plusieurs axes imbriqués, je reconnais que c'est pas trivial à sourcer.
Je vais tenter le coup, mais en général on trouve un bloc en plastique sellé et j'avais supposé que c'était toujours optique à l'intérieur - donc problablement lié à un problème de déformation/désalignement.
Ce n'est pas le contexte territorial qui explique le bordel côté logiciel, du moins pas tout à fait … Les collectivités territoriales ne s'occupent que du matériel. Parfois d'achats groupés dans le logiciel, mais c'est plus par opportunité que par stratégie.
Les collèges et lycées peuvent choisir leurs logiciels, ils n'ont pas d'appel d'offres à faire, "juste" à obtenir le budget adéquat pour les acheter. Ils n'ont quasi pas de contraintes, ils peuvent acheter du full MS 365 et des tablettes Apple "enrôlées" par 100aines, c'est même courant :(.
Enfin les DSDEN (direction des services départementaux, sorte de "bras armé" administratif de chaque académie) peuvent proposer des services. Ils sont obligés d'au moins gérer la messagerie @ac-.fr (et le site qui va avec), avec chacun leur soluce et moyens du bord. Ils n'ont qu'une petite poignée de gens sous-formés pour gérer plus d'une 100aine d'apps pour 5000 à 50,000 personnes (de la voix à la visio, en passant par le provisionning, d'Unix à Windows en passant par Appleries, etc).
Je lis ce journal, je baisse le regard, et je crois voir pour la 1ère fois ce bitoniau rouge sur le X1 que j'ai depuis 18 mois …
Je suis sous Thinkpad depuis 12 ans, j'ai complètement occulté l'existence de cet engin. Je me rappelle avoir essayé avec enthousiasme au début ("s'ils l'ont mis à une place aussi évidente sur tous les modèles c'est que ça doit être bien"), mais je ne m'y suis jamais fait.
Fondamentalement je suis du genre intégral et je veux pointer en désignant une position, et pas mentalement dériver en donnant une vitesse. C'est particulièrement frustrant pour faire des petits ajustements (d'où l'approche spiralaire dont plusieurs utilisateurs parlent). Gros blocage conceptuel et pratique pour moi.
Et comme 95% de mon boulot peut se faire au clavier, je n'ai aucun pb à aller faire 5% de détours par une souris, qui est clairement plus ergonomique qu'un trackpad. Par contre je fais tous mes scrolls à 2 doigts sur le trackpad. Du coup un trackpad 1D me conviendrait bien…
Je transmet une réponse de Loïc, auteur de la solution Awk originelle :
ts "%s" donne une seconde de résolution. Cela ne suffit pas.
Heureusement, ts accepte aussi "%.s" pour une partie fractionnaire (un caractère de plus). Et pas besoin des guillemets : deux caractères de moins. Aussi, avec des secondes plutôt que des nanosecondes, le facteur 6e10 dans le programme AWK devient 60 : encore deux caractères de moins.
La solution prend alors 72 caractères :
$ ts %.s|awk '{t[++k]=$0}k>5{r=k-5}k>1{printf"%i",60*(k-r-1)/($0-t[r+1])}'
Si 100 caractères est la limite, on peut se permettre d'ajouter la remise à zéro après 5 secondes sans taper, comme dans le projet initial de mzf, et utiliser son format de sortie ("Tempo : %i bpm") :
ts %.s|awk '$0-t[k]>5{k=r=0}{t[++k]=$0}k>5{r=k-5}k>1{printf"Tempo : %i bpm",60*(k-r-1)/($0-t[r+1])}' 100 caractères. Pile poil. Quelqu'un trouvera-t-il mieux ?
l'efficacité énergétique (flops/W) a été multiplié par 20.
Oui mais ce qu'on fait tourner sur ces mêmes CPUs plus efficients est vastement moins efficient. Je n'ai pas de chiffre et sources précises, mais depuis 20 ans que je vois passer des blogs et CMS PHP (que j'héberge), je ne les vois que systématiquement ralentir (mesure du TTBF avec l'app neuve sans plugins) et réclamer de plus en plus de CPUs et de RAM dans leur pré-requis. Commentaire certes trollesque, mais c'est mon observation constante et répétée sur de très longues années.
Autre grand sujet occulté : il faudrait comparer les dépenses énergétiques à fonctions comparables. Par ex. quelle est l'évolution du bilan énergétique du transport de la voix en passant du POTS à la VoIP ? Quelle évolution de la conso en passant de la télé+vidéoclub à Youtube+Netflix par heure regardée ? Comme ces critères n'ont jamais été pris en compte, je m'attend à ce qu'on constate globalement qu'on est de plus en plus inefficients à fonction constante (et SUPER inefficients vu que le matériel a lui-même eu une croissance d'efficience impressionnnante).
Il y a pas mal de facteurs qui font qu'estimer la consommation de "son" projet est particulièrement casse-gueule. Je clarifie tout de suite : je n'ai aucun problème avec l'idée, mais il faudrait être honnête en précisant qu'il ne s'agit que d'une tentative d'évaluation, et par exemple être prudent en donnant des chiffres en "pseudo-watts", et bien rappeler le périmètre de ce qui est mesurée qui est très restreint.
1/ RAPL ne mesure qu'une toute petite partie de la conso d'un serveur, lui échappe les circuits d'alimentation (efficients à 90% max), toutes les IOs, la RAM, la ventilation, etc. Si tu as accès à un serveur avec un BMC récent, tente de comparer les mesures RAPL avec ce que le BMC mesure directement depuis des capteurs sur la ou les alims du serveur. Perso j'utilise les BMCs pour partir de la conso réelle (que je peux aussi rapprocher à leur somme et ce que je peux lire sur les onduleurs), mais je me suis pas encore aventuré à distribuer ça "soft" par "soft" (prochaine étape : la VM).
2/ Sur un serveur pour maximiser les performances il y a très peu de mécanismes de consommation d'énergie variable en jeu (comme dans les laptops), de ce fait un serveur qui ne fait rien consomme pas mal, et cette conso n'appartient à personne (je relève régulièrement 100 à 150W sur un serveur qui "dort")
3/ Il faut aussi rajouter la conso des équipements réseaux impliqués, c'est certes souvent un ou deux ordres de grandeur inférieur aux serveurs car on peut mutualiser et être très efficient sur la partie switch et routage, mais toute de même … En tout cas je n'irai pas jusqu'à décompter la partie FAI et le terminal, c'est intéressant mais c'est un autre sujet (certes connexe).
4/ Toutes ces données varient énormément d'un DC à l'autre, et la plupart des clouds sont complètement opaques à ce sujet. Au mieux on a le PUE, souvent vers 1,1 ces jours-ci donc penser à s'imputer +10% mini. Vous n'aurez pas le tonnage de batteries au plomb et le tonnage de fuel pour les alternateurs de secours, les pertes en ligne dans le DC, etc. Ni la nature de l'énergie électrique, qui change quand même pas mal la donne si on en fait un projet d'étude écologique. Ce serait facile de dire qu'on n'en paie pas sa part.
5/ La durée de vie des équipements a un gros impact, je mettrais donc un gros malus aux gros cloud qui courrent toujours après le derniers CPU/GPU les plus voraces et donc décomissionnent des anciens équipements parfaitement fonctionnels (donc tous ?). Il semble difficile de trouver du CPU de plus de 5 ans sur le marché, pourtant je peux témoigner qu'un serveur de bonne facture choyé dans l'environnement d'un DC peut tourner 10ans sans soucis, et convient à des foules d'applications qui n'en ressentent aucun grief.
Enfin et c'est ce qui me chiffonne le plus, cette approche part du concept qu'on ne consomme que ce que le programme utilise. C'est à peu près vrai pour du "batch", mais pour faire tourner de l'interactif ça me semble très incorrect, on réserve de la capacité et ce n'est pas gratuit : d'une part parce que des serveurs qui tournent à vide ça consomme (cf. plus haut) et d'autre part parce que ça pousse la demande du cloud vers le haut - et in fine le problème principal aujourd'hui c'est la croissance folle du nombre et de la conso des DCs.
Je pourrais ajouter qu'aujourd'hui une app est rarement isolée à une VM mais va consommer foules de services (storage S3, logs, métriques, etc.) et tout ceci compte; j'ai vu pas mal de 'stacks' où clairement la quantité de logiciels et de ressources consommées n'étaient pas dans l'app, mais ailleurs (CI/CD, régie pub, monitoring, indexation déportée, etc). On pourra facilement publier des chiffres de conso totalement tartuffiens sur la page de son app en oubliant 90% de son écosystème. Perso en amont je forcerai un projet à lister ces ressources et à s'imposer un malus (coef multiplicateur ?) pour chaque ressource supplémentaire. Si ça peut faire réfléchir ceux qui déploient 99 micro-services sur 42 VM autoscalées avec invocation de la moitié des services AWS pour un pauvre blog, ça serait toujours ça de pris.
Bref tout ça pour dire : attention à ne pas confondre la mesure du détail avec la mesure du problème global.
Je dois avoir du bol … Réfractaire, j'ai cédé en 2016 au smartphone mais à condition de pouvoir mettre un OS libre. Un copain m'a conseillé le Moto E2 et bingo : alors que je ne connaissais rien aux smartphones (découverte uboot, fastboot et tout le toutim), je suis allé bêtement sur le site de Lineageos, j'ai suivi la procédure et 30min plus tard ça juste marchait. Heureusement d'ailleurs car j'avais oublié de sauvegarder la ROM fournie…
Je l'ai toujours, et il est toujours à jour - jamais réinstallé, j'accepte juste les updates et ça se débrouille tout seul (17.1 aka Android 10) : https://wiki.lineageos.org/devices/surnia
Cerises sur le gâteau :
* je ne l'ai payé que 100€ neuf à l'époque (et je crois qu'il n'existait rien moins cher)
* je lui ai pété 2 fois l'écran, je l'ai remplacé moi-même pour 15€ à chaque fois (pièces faciles à trouver, tutoriels vidéos clairs)
* je ne le recharge qu'1 fois par semaine (oui, 4 ans après), mais ça me sert juste de tél, GPS ponctuel et 10/15min web par jour
Comme vous vous en doutez, je n'utilise que F-Droid et je dois installer 1 app par an à tout casser. Mais bon, j'ai zéro problème avec ma vie privée (je crois). Les grands méchants GAFAM n'ont vraiment que ce qu'on leur donne.
Sur "Recovery & Death rate" il y a deux problèmes de lisibilité (aussi considéré faute-peine-de-mort pour un statisticien) :
l'ordonnée ne démarre pas à 0
les deux courbes qui ont bien la même unité (taux) ne partagent pas la même échelle alors que leur superposition encourage à les comparer (et les axes distincts nous en empêchent)
Oui je sais ça applatit les courbes et c'est moins "sexy", mais des fois la vérité c'est que les courbes sont assez plates et c'est une information importante.
Je met du Dell partout, ça juste marche mais les BIOS mettent maintenant minimum 3min à POSTer, les BMC sont des usines à gaz qui ne font pas l'essentiel de façon sécurisé et fiable, ne sont pas automatisables, ni upgradables sans s'arracher les cheveux, etc. Si HP sort des serveurs linuxboot et des BMC utilisables (en virant en particulier ce protocole immonde qu'est IPMI, merci u-bmc), je deviens HP 100% direct.
J'ai utilisé des Sun RaQ début des années 2000, le BIOS de ces bestiaux était … Linux. Je me rappelle que 48h après avoir découvert le bestiau je pouvais recompiler le boot kernel et le hacker sans aucun souci, au boot on avait direct (en 2sec) une console Linux extensible/hackable à souhait, etc. J'ai donc vu la lumière il y a presque 20 ans, et à ce jour je vois juste des UEFI et autres empilements de ROMs écrites avec les pieds (contrôleurs RAID, PXE, etc), bref c'est de plus en plus obscur, insecure et inefficace.
PS: je fais du cloud (infra) et je me moque des "trusted boot" & co. En fait le seul modèle de sécurité ou je pourrai parler de confiance sera celui d'un serveur dont je choisis et comprend le modèle de sécurité, pas celui qui m'impose sa conception du monde et ses blobs magiques.
Merci de faire avancer le "boot world", il en a tellement besoin…
Flux entrants (vu du serveur, donc émis par les caméras) : environ 2 MB/s et il y avait 5 caméras allumées. C'est ok pour les chanceux (par ex. j'ai 20 Mbps d'upload et iptraf-ng a mesuré que ma session webrtc uploadait à 3 Mbps comme prévu par le design : https://github.com/jitsi/jitsi-meet/issues/1313). Par contre pour les participants avec < 1 Mbps d'upload c'était la peine capitale avec un envoi de 2 images/sec de qualité abyssale (tous les récepteurs ont confirmé).
Flux sortants (vu du serveur) : jusqu'à 7 MB/s, WTF! Oui, environ 60 Mbps ! Pour 5 flux 'miniaturisés' vers 10 participants !
Après il y a peut être une nette différence entre le client natif et le WebRTC mais l'article ne semble pas préciser ce qui a été utilisé pour tester. Dans mon cas le client WebRTC a des performances très médiocres (ne s'adapte pas à la BP, ne respecte pas le réglage LowDef, expérience utilisateur niveau "inutilisable").
Avec les mêmes utilisateurs et dans les mêmes conditions on a testé https://openvidu.io/demos avec succès : 10 participants, 7 flux vidéo et tout le monde se voyait avec une qualité satisfaisante (résolution et fluidité). C'était le jour et la nuit. Très bon backend donc, mais il n'y a pas de client abouti…
Je pense que technologiquement Jitsi est trop simpliste et ne marche que dans des conditions optimales. Donc rarement.
CA FAIT DU BRUIT, les serveurs rackables sont conçus pour un environnement sans humains, truffés de ventilateurs qui n'ont aucune retenue en terme de vrombissements et sifflements. C'est impossible de les laisser allumés plusieurs heures dans la pièce où tu travailles (à moins que tu ne travailles qu'avec du heavy metal dans le casque).
Je ne savais pas qu'avec -M on pouvait passer les args à l'importeur, du coup je l'avais zappé, mais bon sang c'est bien sûr !
Je ne connaissais pas l'alias de push en $t[@t]=, j'adopte (pour les oneliners…). Et le += qui force un contexte scalaire ET promet une valeur indéfinie en 0 en mode non-strict, c'est bien recherché :).
J'évite $#t qui a un facteur brainfuck très élevé (le rapport gain de compression vs. perte de lisibilité me semble très défavorable), mais évidemment c'est valide et plus court.
merci beaucoup pour ces journaux et votre travail sur le boot.
En ces temps où il est déjà difficile d'expliquer et responsabiliser des dev(ops) qui piochent n'importe quelle image cloud ou Docker et ne se posent aucune question de sécurité et de chaîne de confiance, aller jusqu'au boot et expliquer qu'il faudrait aussi s'inquiéter du firmware n°1 est une tâche super ardue… Ca me semble pourtant en effet essentiel.
Je vois aussi d'autres avantages : par ex. concernant Meltdown, les maj de microcodes restent étroitement liées aux constructeurs et à leurs BIOS (je peux les faire moi-même depuis Linux, mais le vendeur peut me garantir la couverture de test pour un hard particulier). Avec un LinuxBios je pourrais court-circuiter le vendeur et faire mes tests beaucoup plus facilement…
Et oui, le temps de boot des serveurs c'est un sujet, chez Dell on en arrive à des POSTs délirant de 2 à 3min pour le moindre serveur. Quand on debug un automate ou une panne ça rend le processus extrêmement inefficace. Quand on veut minimiser un downtime sur un service non redondé ou cloudé (et il en reste des tonnes dans la nature), c'est souvent ce qui plombe le SLA. Et objectivement on sait que c'est un indécent par rapport aux réels besoins que la physique impose (stabilisation des alims, allumage en cascade des éléments, etc). Tout POST > 10s devrait pouvoir être considéré comme un défaut de construction :(.
Note historique : j'ai bossé au début des années 2000 sur des Cobalt/Raq (projet Sun) qui utilisaient Linux comme firmware, et c'était tellement bien conçu et ouvert que je pouvais moi-même recompiler des Linux/firmwares sans soucis (sans être dév kernel). Le support Cobalt/Raq était d'ailleurs mainstream dans Linux (au moins pour les 2.2 et 2.4). J'ai ainsi maintenu des firmwares de ces Raq pendant plus de 5 ans après la fin de vie de ces produits. Ces machines étaient triviales à administrer à distance, provisionner, debugger. Elles postaient en 1 à 2s (!). Tous les autres équipements (serveurs, routeurs) me semblent d'une hostilité incroyable depuis cette expérience.
Sur vos questions sur le contexte de boot idéal, je ne sais pas trop ce qu'il pourrait être mais j'ai une bonne idée sur ce qu'il ne pourrait pas être :
oublier tout ce qui est vidéo/VGA; ou plus exactement le laisser hors-scope, ceux qui veulent aller de ce côté le feront s'ils le souhaitent
oublier les interfaces pseudo-vidéo à la ncurses : souvent inutilisables via des consoles séries, n'ont en général pas la moindre notion de termcap, sont inscriptables, etc; pareil, devrait être hors-scope, si des gens veulent faire ça, qu'ils n'embêtent pas les autres avec ça
oublier les firmwares pluggables avec chacun leur propre vision du monde (et interface, et idiomes, etc), mais ça je crois que c'est déjà fait vu que c'est dans le design de NERF :)
oublier IPMI dont l'intention est bonne mais dont le protocole est ridicule (personne ne l'implémente correctement, du moins de façon interopérable, et je parie qu'il est truffé de trous de sécu)
Dans le cahier des charges, il me vient à l'esprit :
être trivial à prendre en main par un opérateur; le fait que ce soit une forme de shell autodocumenté semble assez attendue
faciliter l'automatisation; sans aller jusqu'à vouloir définir une API, ce qui serait trop rigide et trop de travail. Ca peut très bien marcher en laissant les acteurs se synchroniser sur des formats 'machine readable' des commandes usuelles, le pragmatisme faisant souvent des merveilles; en tout cas les admins sont rompus à assurer la glue avec ce genre d'outils et n'auraient aucune objection a maintenir un jeu d'automate par vendeur (rien que pouvoir le faire serait une avancée énorme, regardez la complexité et la fragilité de FAI)
avoir des opinions fortes pour limiter la configurabilité et faire disparaître plein de problèmes de déploiement et de développement; par ex. les Cobalt/Raq avaient un port série en 115200n8, c'était comme ça et pas autrement (et, malins, un second port série pour un usage libre, rendant tout le monde content). Evacuation de moults questions et inconnues, s'il n'y a pas de raison que ça soit configurable, alors ça ne doit pas l'être.
s'il doit y avoir de l'auth, utiliser/imposer SSH; la hostkey pourrait être générée pour chaque build et signée par le builder (sur un site public), ce qui permettrait de vérifier trivialement qu'on s'adresse bien à la première connection au firmware fourni par le tiers prévu
d'un autre côté je dois dire que j'utilise des LAN dédiés pour l'ILO et si je pouvais juste avoir des telnets triviaux, ce serait aussi simple; mais SSH est tellement universel, trivial, et surtout beaucoup plus utilisable que telnet (notion de canal, pty oui/non, keepalive, tunnel, etc) que je ne vois aucune excuse de s'en passer
Et c'est peut être hors sujet, mais si on pouvait obliger la présence d'un support Flash librement utilisable d'environ 512 MB, ça ne coûterait quasiment rien à l'intégrateur, et ça pourrait révolutionner le déploiement de pas mal de serveurs où l'OS est très simple (hyperviseur, filers, routeurs soft, loadbalancers soft, etc.) quand on veut être plus résilient qu'une infra de netboot (qui de plus est pénible à maintenir et scaler).
# Mais ...
Posté par zerodeux (site web personnel) . En réponse au journal Nouvelle : systemd-society.service. Évalué à 0.
trop systemd-lol !
# Chapeau
Posté par zerodeux (site web personnel) . En réponse au journal Sortie de mon premier album de musique libre : Flammes. Évalué à 1.
C'est super bien produit et tu sais écrire et chanter, respect.
[^] # Re: Taquinage d'audiophile :p
Posté par zerodeux (site web personnel) . En réponse au journal Manifeste contre la roue codeuse. Évalué à 2.
Uhuh, on glisse le mot "potard" et y a un article complet d'audiogeeks qui se construit dans les commentaires. On vous adore :).
[^] # Re: Vive la low-tech !
Posté par zerodeux (site web personnel) . En réponse au journal Manifeste contre la roue codeuse. Évalué à 1.
Validay (x100 [W]).
[^] # Re: Il y a pire
Posté par zerodeux (site web personnel) . En réponse au journal Manifeste contre la roue codeuse. Évalué à 3.
Je me suis retenu de faire déborder le troll vers les bouton +/- mais c'est clairement le corolaire. Je peste violemment contre cette incongruité à chaque fois que j'en rencontre (locations, etc).
Je suis au gaz, les boutons sont arrangés exactement comme les brûleurs, ça réagit instantanément, et qu'on tourne violemmente à droite où à gauche ça résoud le problème (un côté c'est "mini", l'autre c'est "off"). On peut régler par pas infinitésimaux. Bref ça c'est de l'UX bordel.
Pour répondre précisément au problème du lait qui déborde : c'est beaucoup plus safe de couper/baisser le gaz d'un coup plutôt que de tenter de soulever une casserole bouillante en panique (cas vécu au hasard : oublie de la tendinite qui 2sec après avoir soulevé la casserole te fait tout lâcher, etc).
Et je trolle pas au point d'avoir le gros bouton rouge de coupure urgente, juste des contrôles intuitifs, raisonnables et efficaces. Je pense que la roue codée ne l'est que dans 1% des cas (et là on s'esbaudit, certes).
[^] # Re: Code Gray
Posté par zerodeux (site web personnel) . En réponse au journal Manifeste contre la roue codeuse. Évalué à 5.
Je ne pense pas. Le potard asservi ne peut pas sauter instantanément à un volume démentiel, et même s'il peut atteindre une valeur indécente, ce n'est pas du tout le même effet psychologique sur l'organisme. Et surtout le réflexe de sauter sur le bouton et de le tourner fissa vers 0 est effectif.
On est d'accord, le soft qui interprète le signal de la roue représente 90% du problème. Mais ça rejoint mon troll : impossible de se planter niveau UX avec un potard analogique. Alors qu'avec une roue codée (ou des boutons +/-) toutes les erreurs sont possibles, et je dirai même que les implémentations bien foutues (=ergonomiques) sont rarissimes.
[^] # Re: Entretenir son matos
Posté par zerodeux (site web personnel) . En réponse au journal Manifeste contre la roue codeuse. Évalué à 3.
Y a de l'aérosol spécial potard ? Bon à savoir… Effectivement sur les gros amplis ce sont souvent des potards à plusieurs axes imbriqués, je reconnais que c'est pas trivial à sourcer.
[^] # Re: Ca se nettoye
Posté par zerodeux (site web personnel) . En réponse au journal Manifeste contre la roue codeuse. Évalué à 2.
Je vais tenter le coup, mais en général on trouve un bloc en plastique sellé et j'avais supposé que c'était toujours optique à l'intérieur - donc problablement lié à un problème de déformation/désalignement.
[^] # Re: lapin compris
Posté par zerodeux (site web personnel) . En réponse au journal Les enseignants, poussés vers GMail. Évalué à 2.
Ben … Gratuit et qui va pas lire tes mails et/ou revendre tes données ?
Laposte.net ? Ah non même pas. Il faut un pedigree complet pour créer un compte et slalomer entre 4 coches "je veux vendre mon corps au marché" : https://compte.laposte.net/inscription/index.do?srv_gestion=lapostefr
Non je vois pas.
Du coup parmis tous ces requins, tu prends le plus connu qui se trouve aussi être le meilleur techniquement (enfin je crois, je n'utilise pas).
[^] # Re: et pourtant les solutions ne sont pas compliquées…
Posté par zerodeux (site web personnel) . En réponse au journal Les enseignants, poussés vers GMail. Évalué à 4.
Ce n'est pas le contexte territorial qui explique le bordel côté logiciel, du moins pas tout à fait … Les collectivités territoriales ne s'occupent que du matériel. Parfois d'achats groupés dans le logiciel, mais c'est plus par opportunité que par stratégie.
Les collèges et lycées peuvent choisir leurs logiciels, ils n'ont pas d'appel d'offres à faire, "juste" à obtenir le budget adéquat pour les acheter. Ils n'ont quasi pas de contraintes, ils peuvent acheter du full MS 365 et des tablettes Apple "enrôlées" par 100aines, c'est même courant :(.
Enfin les DSDEN (direction des services départementaux, sorte de "bras armé" administratif de chaque académie) peuvent proposer des services. Ils sont obligés d'au moins gérer la messagerie @ac-.fr (et le site qui va avec), avec chacun leur soluce et moyens du bord. Ils n'ont qu'une petite poignée de gens sous-formés pour gérer plus d'une 100aine d'apps pour 5000 à 50,000 personnes (de la voix à la visio, en passant par le provisionning, d'Unix à Windows en passant par Appleries, etc).
# Oh tiens ...
Posté par zerodeux (site web personnel) . En réponse au journal Le trackpoint sur les thinkpad…. Évalué à 4.
Je lis ce journal, je baisse le regard, et je crois voir pour la 1ère fois ce bitoniau rouge sur le X1 que j'ai depuis 18 mois …
Je suis sous Thinkpad depuis 12 ans, j'ai complètement occulté l'existence de cet engin. Je me rappelle avoir essayé avec enthousiasme au début ("s'ils l'ont mis à une place aussi évidente sur tous les modèles c'est que ça doit être bien"), mais je ne m'y suis jamais fait.
Fondamentalement je suis du genre intégral et je veux pointer en désignant une position, et pas mentalement dériver en donnant une vitesse. C'est particulièrement frustrant pour faire des petits ajustements (d'où l'approche spiralaire dont plusieurs utilisateurs parlent). Gros blocage conceptuel et pratique pour moi.
Et comme 95% de mon boulot peut se faire au clavier, je n'ai aucun pb à aller faire 5% de détours par une souris, qui est clairement plus ergonomique qu'un trackpad. Par contre je fais tous mes scrolls à 2 doigts sur le trackpad. Du coup un trackpad 1D me conviendrait bien…
[^] # Re: awk '{system("date +%s%N")}' c'est long
Posté par zerodeux (site web personnel) . En réponse au journal TapTempo contest : un peu moins d'octets en Awk. Évalué à 1.
Je transmet une réponse de Loïc, auteur de la solution Awk originelle :
ts "%s" donne une seconde de résolution. Cela ne suffit pas.
Heureusement, ts accepte aussi "%.s" pour une partie fractionnaire (un caractère de plus). Et pas besoin des guillemets : deux caractères de moins. Aussi, avec des secondes plutôt que des nanosecondes, le facteur 6e10 dans le programme AWK devient 60 : encore deux caractères de moins.
La solution prend alors 72 caractères :
$ ts %.s|awk '{t[++k]=$0}k>5{r=k-5}k>1{printf"%i",60*(k-r-1)/($0-t[r+1])}'
Si 100 caractères est la limite, on peut se permettre d'ajouter la remise à zéro après 5 secondes sans taper, comme dans le projet initial de mzf, et utiliser son format de sortie ("Tempo : %i bpm") :
ts %.s|awk '$0-t[k]>5{k=r=0}{t[++k]=$0}k>5{r=k-5}k>1{printf"Tempo : %i bpm",60*(k-r-1)/($0-t[r+1])}'
[^] # Re: Dubitatif
Posté par zerodeux (site web personnel) . En réponse à la dépêche Mesurer la consommation d'énergie des projets informatique, depuis les serveurs, avec scaphandre. Évalué à 8.
Oui mais ce qu'on fait tourner sur ces mêmes CPUs plus efficients est vastement moins efficient. Je n'ai pas de chiffre et sources précises, mais depuis 20 ans que je vois passer des blogs et CMS PHP (que j'héberge), je ne les vois que systématiquement ralentir (mesure du TTBF avec l'app neuve sans plugins) et réclamer de plus en plus de CPUs et de RAM dans leur pré-requis. Commentaire certes trollesque, mais c'est mon observation constante et répétée sur de très longues années.
Autre grand sujet occulté : il faudrait comparer les dépenses énergétiques à fonctions comparables. Par ex. quelle est l'évolution du bilan énergétique du transport de la voix en passant du POTS à la VoIP ? Quelle évolution de la conso en passant de la télé+vidéoclub à Youtube+Netflix par heure regardée ? Comme ces critères n'ont jamais été pris en compte, je m'attend à ce qu'on constate globalement qu'on est de plus en plus inefficients à fonction constante (et SUPER inefficients vu que le matériel a lui-même eu une croissance d'efficience impressionnnante).
# Dubitatif
Posté par zerodeux (site web personnel) . En réponse à la dépêche Mesurer la consommation d'énergie des projets informatique, depuis les serveurs, avec scaphandre. Évalué à 10.
Il y a pas mal de facteurs qui font qu'estimer la consommation de "son" projet est particulièrement casse-gueule. Je clarifie tout de suite : je n'ai aucun problème avec l'idée, mais il faudrait être honnête en précisant qu'il ne s'agit que d'une tentative d'évaluation, et par exemple être prudent en donnant des chiffres en "pseudo-watts", et bien rappeler le périmètre de ce qui est mesurée qui est très restreint.
1/ RAPL ne mesure qu'une toute petite partie de la conso d'un serveur, lui échappe les circuits d'alimentation (efficients à 90% max), toutes les IOs, la RAM, la ventilation, etc. Si tu as accès à un serveur avec un BMC récent, tente de comparer les mesures RAPL avec ce que le BMC mesure directement depuis des capteurs sur la ou les alims du serveur. Perso j'utilise les BMCs pour partir de la conso réelle (que je peux aussi rapprocher à leur somme et ce que je peux lire sur les onduleurs), mais je me suis pas encore aventuré à distribuer ça "soft" par "soft" (prochaine étape : la VM).
2/ Sur un serveur pour maximiser les performances il y a très peu de mécanismes de consommation d'énergie variable en jeu (comme dans les laptops), de ce fait un serveur qui ne fait rien consomme pas mal, et cette conso n'appartient à personne (je relève régulièrement 100 à 150W sur un serveur qui "dort")
3/ Il faut aussi rajouter la conso des équipements réseaux impliqués, c'est certes souvent un ou deux ordres de grandeur inférieur aux serveurs car on peut mutualiser et être très efficient sur la partie switch et routage, mais toute de même … En tout cas je n'irai pas jusqu'à décompter la partie FAI et le terminal, c'est intéressant mais c'est un autre sujet (certes connexe).
4/ Toutes ces données varient énormément d'un DC à l'autre, et la plupart des clouds sont complètement opaques à ce sujet. Au mieux on a le PUE, souvent vers 1,1 ces jours-ci donc penser à s'imputer +10% mini. Vous n'aurez pas le tonnage de batteries au plomb et le tonnage de fuel pour les alternateurs de secours, les pertes en ligne dans le DC, etc. Ni la nature de l'énergie électrique, qui change quand même pas mal la donne si on en fait un projet d'étude écologique. Ce serait facile de dire qu'on n'en paie pas sa part.
5/ La durée de vie des équipements a un gros impact, je mettrais donc un gros malus aux gros cloud qui courrent toujours après le derniers CPU/GPU les plus voraces et donc décomissionnent des anciens équipements parfaitement fonctionnels (donc tous ?). Il semble difficile de trouver du CPU de plus de 5 ans sur le marché, pourtant je peux témoigner qu'un serveur de bonne facture choyé dans l'environnement d'un DC peut tourner 10ans sans soucis, et convient à des foules d'applications qui n'en ressentent aucun grief.
Enfin et c'est ce qui me chiffonne le plus, cette approche part du concept qu'on ne consomme que ce que le programme utilise. C'est à peu près vrai pour du "batch", mais pour faire tourner de l'interactif ça me semble très incorrect, on réserve de la capacité et ce n'est pas gratuit : d'une part parce que des serveurs qui tournent à vide ça consomme (cf. plus haut) et d'autre part parce que ça pousse la demande du cloud vers le haut - et in fine le problème principal aujourd'hui c'est la croissance folle du nombre et de la conso des DCs.
Je pourrais ajouter qu'aujourd'hui une app est rarement isolée à une VM mais va consommer foules de services (storage S3, logs, métriques, etc.) et tout ceci compte; j'ai vu pas mal de 'stacks' où clairement la quantité de logiciels et de ressources consommées n'étaient pas dans l'app, mais ailleurs (CI/CD, régie pub, monitoring, indexation déportée, etc). On pourra facilement publier des chiffres de conso totalement tartuffiens sur la page de son app en oubliant 90% de son écosystème. Perso en amont je forcerai un projet à lister ces ressources et à s'imposer un malus (coef multiplicateur ?) pour chaque ressource supplémentaire. Si ça peut faire réfléchir ceux qui déploient 99 micro-services sur 42 VM autoscalées avec invocation de la moitié des services AWS pour un pauvre blog, ça serait toujours ça de pris.
Bref tout ça pour dire : attention à ne pas confondre la mesure du détail avec la mesure du problème global.
[^] # Re: Changer de téléphone / l'OS du téléphone ?
Posté par zerodeux (site web personnel) . En réponse au journal Nous avons un super‑pouvoir pour faire déguerpir les automobilistes 📱 => ⛔ 🚗. Évalué à 0.
Je dois avoir du bol … Réfractaire, j'ai cédé en 2016 au smartphone mais à condition de pouvoir mettre un OS libre. Un copain m'a conseillé le Moto E2 et bingo : alors que je ne connaissais rien aux smartphones (découverte uboot, fastboot et tout le toutim), je suis allé bêtement sur le site de Lineageos, j'ai suivi la procédure et 30min plus tard ça juste marchait. Heureusement d'ailleurs car j'avais oublié de sauvegarder la ROM fournie…
Je l'ai toujours, et il est toujours à jour - jamais réinstallé, j'accepte juste les updates et ça se débrouille tout seul (17.1 aka Android 10) : https://wiki.lineageos.org/devices/surnia
Cerises sur le gâteau :
* je ne l'ai payé que 100€ neuf à l'époque (et je crois qu'il n'existait rien moins cher)
* je lui ai pété 2 fois l'écran, je l'ai remplacé moi-même pour 15€ à chaque fois (pièces faciles à trouver, tutoriels vidéos clairs)
* je ne le recharge qu'1 fois par semaine (oui, 4 ans après), mais ça me sert juste de tél, GPS ponctuel et 10/15min web par jour
Comme vous vous en doutez, je n'utilise que F-Droid et je dois installer 1 app par an à tout casser. Mais bon, j'ai zéro problème avec ma vie privée (je crois). Les grands méchants GAFAM n'ont vraiment que ce qu'on leur donne.
# Merci
Posté par zerodeux (site web personnel) . En réponse à la dépêche Sortie de Perl 5.32.0. Évalué à 10.
Pour le boulot dantesque qu'a du être la rédaction de cette news. Un perl lover.
# Attention aux échelles
Posté par zerodeux (site web personnel) . En réponse au journal Graphiques et cartes Grafana de l'évolution du COVID-19. Évalué à 3.
Sur "Recovery & Death rate" il y a deux problèmes de lisibilité (aussi considéré faute-peine-de-mort pour un statisticien) :
Oui je sais ça applatit les courbes et c'est moins "sexy", mais des fois la vérité c'est que les courbes sont assez plates et c'est une information importante.
# A mort les BIOS et BMC pourris
Posté par zerodeux (site web personnel) . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 4.
Je met du Dell partout, ça juste marche mais les BIOS mettent maintenant minimum 3min à POSTer, les BMC sont des usines à gaz qui ne font pas l'essentiel de façon sécurisé et fiable, ne sont pas automatisables, ni upgradables sans s'arracher les cheveux, etc. Si HP sort des serveurs linuxboot et des BMC utilisables (en virant en particulier ce protocole immonde qu'est IPMI, merci u-bmc), je deviens HP 100% direct.
J'ai utilisé des Sun RaQ début des années 2000, le BIOS de ces bestiaux était … Linux. Je me rappelle que 48h après avoir découvert le bestiau je pouvais recompiler le boot kernel et le hacker sans aucun souci, au boot on avait direct (en 2sec) une console Linux extensible/hackable à souhait, etc. J'ai donc vu la lumière il y a presque 20 ans, et à ce jour je vois juste des UEFI et autres empilements de ROMs écrites avec les pieds (contrôleurs RAID, PXE, etc), bref c'est de plus en plus obscur, insecure et inefficace.
PS: je fais du cloud (infra) et je me moque des "trusted boot" & co. En fait le seul modèle de sécurité ou je pourrai parler de confiance sera celui d'un serveur dont je choisis et comprend le modèle de sécurité, pas celui qui m'impose sa conception du monde et ses blobs magiques.
Merci de faire avancer le "boot world", il en a tellement besoin…
# Ca ne marche pas pour moi...
Posté par zerodeux (site web personnel) . En réponse à la dépêche Organiser des visioconférences de haute qualité (avec le logiciel libre Jitsi Meet). Évalué à 3.
Je n'ai pas du tout ce retour d'expérience.
J'ai installé un serveur tout neuf avec le dernier Jitsi, on a testé jusqu'à 10 participants (via WebRTC) sur une B2-7 OVH : http://zerodeux.net/misc/meet-ovh-test-1.png
Jusqu'à 1 CPU (10 flux) : OK. Mais bien en deça de ce qui est prétendu : https://jitsi.org/jitsi-videobridge-performance-evaluation/ (1000 flux utilisant 20% de 4x4 cores ~= 300 flux/core).
Flux entrants (vu du serveur, donc émis par les caméras) : environ 2 MB/s et il y avait 5 caméras allumées. C'est ok pour les chanceux (par ex. j'ai 20 Mbps d'upload et iptraf-ng a mesuré que ma session webrtc uploadait à 3 Mbps comme prévu par le design : https://github.com/jitsi/jitsi-meet/issues/1313). Par contre pour les participants avec < 1 Mbps d'upload c'était la peine capitale avec un envoi de 2 images/sec de qualité abyssale (tous les récepteurs ont confirmé).
Flux sortants (vu du serveur) : jusqu'à 7 MB/s, WTF! Oui, environ 60 Mbps ! Pour 5 flux 'miniaturisés' vers 10 participants !
Le problème de gestion de qualité/BP est connu mais upstream considère que c'est une feature, pas un bug : https://github.com/jitsi/jitsi-meet/issues/3120
Après il y a peut être une nette différence entre le client natif et le WebRTC mais l'article ne semble pas préciser ce qui a été utilisé pour tester. Dans mon cas le client WebRTC a des performances très médiocres (ne s'adapte pas à la BP, ne respecte pas le réglage LowDef, expérience utilisateur niveau "inutilisable").
Avec les mêmes utilisateurs et dans les mêmes conditions on a testé https://openvidu.io/demos avec succès : 10 participants, 7 flux vidéo et tout le monde se voyait avec une qualité satisfaisante (résolution et fluidité). C'était le jour et la nuit. Très bon backend donc, mais il n'y a pas de client abouti…
Je pense que technologiquement Jitsi est trop simpliste et ne marche que dans des conditions optimales. Donc rarement.
# Serveur rack : pas pour le bureau
Posté par zerodeux (site web personnel) . En réponse au journal Intel = 14 nm, AMD = 7 nm, ARM = 7 nm… et mon serveur ?. Évalué à 3.
CA FAIT DU BRUIT, les serveurs rackables sont conçus pour un environnement sans humains, truffés de ventilateurs qui n'ont aucune retenue en terme de vrombissements et sifflements. C'est impossible de les laisser allumés plusieurs heures dans la pièce où tu travailles (à moins que tu ne travailles qu'avec du heavy metal dans le casque).
[^] # Re: NSI
Posté par zerodeux (site web personnel) . En réponse à la dépêche Apprentissage de la programmation dans les lycées (SNT/NSI) — la création d’exercices. Évalué à 2.
Un bouquin réalisé par des chercheurs d'un labo publique, diffusé sous licence propriétaire et par un biais lucratif, je tique.
Un lien Amazon, je tique.
Tic-tic.
[^] # Re: Et la version code golfé en brainfuck?
Posté par zerodeux (site web personnel) . En réponse au journal TapTempo en une ligne. Évalué à 1.
Ah oui, c'est quasi l'univers dual du one-liner Perl …
[^] # Re: .
Posté par zerodeux (site web personnel) . En réponse au journal TapTempo en une ligne. Évalué à 0.
Si je dis ruby-esque ça te va ? :)
[^] # Re: Suggestions
Posté par zerodeux (site web personnel) . En réponse au journal TapTempo en une ligne. Évalué à 2.
Belle optim' !
Je ne savais pas qu'avec -M on pouvait passer les args à l'importeur, du coup je l'avais zappé, mais bon sang c'est bien sûr !
Je ne connaissais pas l'alias de push en
$t[@t]=, j'adopte (pour les oneliners…). Et le+=qui force un contexte scalaire ET promet une valeur indéfinie en 0 en mode non-strict, c'est bien recherché :).J'évite
$#tqui a un facteur brainfuck très élevé (le rapport gain de compression vs. perte de lisibilité me semble très défavorable), mais évidemment c'est valide et plus court.# Suggestions/expérience sur le boot de serveur
Posté par zerodeux (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). Évalué à 3.
Bonjour,
merci beaucoup pour ces journaux et votre travail sur le boot.
En ces temps où il est déjà difficile d'expliquer et responsabiliser des dev(ops) qui piochent n'importe quelle image cloud ou Docker et ne se posent aucune question de sécurité et de chaîne de confiance, aller jusqu'au boot et expliquer qu'il faudrait aussi s'inquiéter du firmware n°1 est une tâche super ardue… Ca me semble pourtant en effet essentiel.
Je vois aussi d'autres avantages : par ex. concernant Meltdown, les maj de microcodes restent étroitement liées aux constructeurs et à leurs BIOS (je peux les faire moi-même depuis Linux, mais le vendeur peut me garantir la couverture de test pour un hard particulier). Avec un LinuxBios je pourrais court-circuiter le vendeur et faire mes tests beaucoup plus facilement…
Et oui, le temps de boot des serveurs c'est un sujet, chez Dell on en arrive à des POSTs délirant de 2 à 3min pour le moindre serveur. Quand on debug un automate ou une panne ça rend le processus extrêmement inefficace. Quand on veut minimiser un downtime sur un service non redondé ou cloudé (et il en reste des tonnes dans la nature), c'est souvent ce qui plombe le SLA. Et objectivement on sait que c'est un indécent par rapport aux réels besoins que la physique impose (stabilisation des alims, allumage en cascade des éléments, etc). Tout POST > 10s devrait pouvoir être considéré comme un défaut de construction :(.
Note historique : j'ai bossé au début des années 2000 sur des Cobalt/Raq (projet Sun) qui utilisaient Linux comme firmware, et c'était tellement bien conçu et ouvert que je pouvais moi-même recompiler des Linux/firmwares sans soucis (sans être dév kernel). Le support Cobalt/Raq était d'ailleurs mainstream dans Linux (au moins pour les 2.2 et 2.4). J'ai ainsi maintenu des firmwares de ces Raq pendant plus de 5 ans après la fin de vie de ces produits. Ces machines étaient triviales à administrer à distance, provisionner, debugger. Elles postaient en 1 à 2s (!). Tous les autres équipements (serveurs, routeurs) me semblent d'une hostilité incroyable depuis cette expérience.
Sur vos questions sur le contexte de boot idéal, je ne sais pas trop ce qu'il pourrait être mais j'ai une bonne idée sur ce qu'il ne pourrait pas être :
Dans le cahier des charges, il me vient à l'esprit :
Et c'est peut être hors sujet, mais si on pouvait obliger la présence d'un support Flash librement utilisable d'environ 512 MB, ça ne coûterait quasiment rien à l'intégrateur, et ça pourrait révolutionner le déploiement de pas mal de serveurs où l'OS est très simple (hyperviseur, filers, routeurs soft, loadbalancers soft, etc.) quand on veut être plus résilient qu'une infra de netboot (qui de plus est pénible à maintenir et scaler).