Merci de prendre la peine de témoigner de cet entreprenariat laborieux (à la fois au sens mélioratif et au sens déprimant)… Je me dis que vous seriez dans la Silicon Valley, vous auriez trouvé en 2 semaines un pack 1M$ pour la 1ère année + gens passionnés super formés + fournisseurs + encadrement. La pauvreté du financement industriel en France est déprimante :(
Rholala, +1. Et les broches étaient trop longues et souples, pas mal de connecteurs étaient de mauvaise qualité et leurs broches finissaient par rentrer complètement dans le carter de la prise. Et la grande masse fendue, pour avoir du jeu et faciliter l'insertion je suppose, se déformait rapidement et rendait l'insertion acrobatique. Ca faisit toujours un bruit horrible de craquement de plastique et de mauvais glissement de métal à chaque insertion/retrait. C'était immonde. Clairement un des pires connecteurs audio/vidéo.
C'est une grande leçon d'humilité. Etant programmeur, je lis le document de confection en sentant la rigueur, la concision et l'élégance du code et … je n'y comprends rien :).
Et je suis jaloux parce que le résultat est concret et objectivement séduisant, ce que je ne peux pas faire dans ma pratique de programmeur. Je vais peut être me mettre au Jacquard tiens.
Et merci pour l'humour à la fois au 1er et second degré, et vive les strings !
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.
# Mauvais hyperliens ?
Posté par zerodeux (site web personnel) . En réponse au journal Des faits saillants pour une plus que centenaire. Évalué à 0.
La plupart des noms de femmes dans ce billet ont des hyperliens vers https://numericoach.net/blabla - c'est très bizarre …
# Superbe initiative, bon courage !
Posté par zerodeux (site web personnel) . En réponse à la dépêche L’ordinateur portable modulaire : La lumière au bout du tunnel. Évalué à 4.
Merci de prendre la peine de témoigner de cet entreprenariat laborieux (à la fois au sens mélioratif et au sens déprimant)… Je me dis que vous seriez dans la Silicon Valley, vous auriez trouvé en 2 semaines un pack 1M$ pour la 1ère année + gens passionnés super formés + fournisseurs + encadrement. La pauvreté du financement industriel en France est déprimante :(
# Merci
Posté par zerodeux (site web personnel) . En réponse au journal Moins d’un an pour un vaccin, est-ce surprenant ?. Évalué à 1.
Un article posé, clair, sourcé, facile à lire. Sur ce sujet en ce moment c'est un peu une gageure. De l'or en barre, merci.
[^] # Re: La prise péritel (SCART)
Posté par zerodeux (site web personnel) . En réponse au journal Des concepteurs qui ont éteint trop tôt leur cerveau. Évalué à 4.
Rholala, +1. Et les broches étaient trop longues et souples, pas mal de connecteurs étaient de mauvaise qualité et leurs broches finissaient par rentrer complètement dans le carter de la prise. Et la grande masse fendue, pour avoir du jeu et faciliter l'insertion je suppose, se déformait rapidement et rendait l'insertion acrobatique. Ca faisit toujours un bruit horrible de craquement de plastique et de mauvais glissement de métal à chaque insertion/retrait. C'était immonde. Clairement un des pires connecteurs audio/vidéo.
# Le code tricot ...
Posté par zerodeux (site web personnel) . En réponse au journal Les strings d’Ada. Évalué à 4.
C'est une grande leçon d'humilité. Etant programmeur, je lis le document de confection en sentant la rigueur, la concision et l'élégance du code et … je n'y comprends rien :).
Et je suis jaloux parce que le résultat est concret et objectivement séduisant, ce que je ne peux pas faire dans ma pratique de programmeur. Je vais peut être me mettre au Jacquard tiens.
Et merci pour l'humour à la fois au 1er et second degré, et vive les strings !
# Super journal
Posté par zerodeux (site web personnel) . En réponse au journal Unknown Pleasures : un pulsar iconique. Évalué à 2. Dernière modification le 06 décembre 2021 à 20:58.
Merci pour cette bonne tranche de (cross-over de) culture !
# 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.