paulez a écrit 387 commentaires

Je ne répondrai pas à la question du courriel, mais dans ton billet tu sembles hésiter entre apprendre Emacs et rester sur Vim.
J'avais un peu le même problème, et j'ai trouvé le meilleur des deux mondes avec Spacemacs, qui est une configuration pour Emacs qui permet de l'utiliser comme Vim.
C'est super agréable à utiliser avec toute la mnémonique des opérations Vim, et la puissance d'Emacs.

La moitié de tes problèmes sont liés à l'hébergement à la maison. Gestion du hardware qui pète, FAI peu accommodant sur ce cas d'usage, Internet qui lâche, etc.
Entre le serveur qui plante toujours pendant les vacances, l'alim qui pète et les soucis d'ADSL, j'ai laissé tomber. Quelques déménagements plus tard je suis aussi bien content de ne pas avoir à me trimballer mon serveur de mail en plus.

J'héberge mon mail moi-même, mais dans une infra cloud. Depuis, j'ai 0 problème d'infra, et un ou deux problème de spam/non réception à gérer par an.

Bonne nouvelle donc ! C'était bien le blacklisting d'IP qui m'inquiétait, je pensais qu'il y avait plus qu'une base de données d'où retirer son IP.
Surtout avec des acteurs pas très coopératifs comme Microsoft qui ont leur propre liste d'IPs.
SPF, DKIM, DMARC and co sont tout autant nécessaires quand on utilise un hébergeur.

Je suis tout à faire d'accord que CentOS Streams est une très belle idée, et permet d'ouvrir le développement de RHEL. En effet, actuellement un utilisateur de CentOS 7 rencontrant un bogue n'a aucun moyen de contribuer à sa résolution. Avec CentOS Streams, il peut contribuer au stream pour proposer un correctif qui un jour pourrait arriver dans CentOS.

Donc CentOS Streams c'est une super idée. Mais ça n'est pas CentOS. RH essaie de nous faire passer la mort de CentOS par un "voyez c'est mieux qu'avant !" mais clairement, ils annoncent la fin de CentOS, sachant que CentOS Streams avait déjà été annoncée.

Est-ce que tu penses qu'il y aura plus de gens prêts à contribuer gratuitement au développement de RHEL sans pouvoir l'utiliser gratuitement, que d'utilisateurs actuels de CentOS ?

On peut aussi discuter de la moindre importance aujourd'hui d'une distribution à très longue durée de vie avec la containérisation, mais si c'était vraiment ça le problème, RedHat arrêterait le support longue durée de RHEL, pas CentOS. Clairement donc l'objectif de RedHat est de forcer les utilisateurs de CentOS à passer sur RHEL.

Bien sûr que si, n'importe qui peut faire un CentOS like en partant des sources de Red Hat. Il y en a quelques uns dans la nature, et peut être qu'un autre reviendra. Là dessus rien ne change.

C'est un peu fallacieux de dire ça, CentOS faisait un assez gros travail pour rendre ça possible, c'est d'ailleurs pour ça que beaucoup de projets sont basés sur CentOS.

RedHat ne fait que balancer les srpm dans ses repos. CentOS faisait tout le boulot de les extraire, versionner ça dans un git, suivre les mises à jours de sécurité, etc.

Plus le boulot initial pour boostraper la distro (arriver à compiler from scratch) ce qui n'est pas du tout trivial (et probablement cassé avec les dernières versions des srpms, il faut avoir l'historique pour avoir une chance).

Tuer CentOS telle qu'elle l'était, ça monte vraiment une volonté de fermeture de la part de RedHat.

J'héberge mon mail moi même et je ne suis pas blacklisté par les grands fournisseurs (j'ai du batailler un peu avec le support Microsoft quand même) et le spam reçu est raisonnable.

Par contre ce n'est pas chez moi, je pense qu'en effet avec une IP de FAI c'est peine perdue.

Le client ne propose que le cipher RC4 que tu n'autorises pas, donc la transaction échoue.
Autoriser RC4 pourrait être un compromis moins risqué que la désactivation de TLS, par contre ça peut être impossible en fonction de la distro. RC4 a été assez récemment désactivé un peu partout car considéré comme non sûr.

Ce qui est bizarre c'est que le client ne réessaie pas en clair. Quel était la valeur précédente de smtpd_tls_security_level ? Chez moi c'est configuré à may comme recommandé par la doc Postfix pour autoriser les clients qui ne veulent pas faire du TLS.

la probabilité moyenne

Déjà ça commence fort.

pour un individu lambda (sans distinction d’âge ou de comorbidité) de ne pas être hospitalisé est de 99,5% et celle de ne pas être admis en réanimation est de 99,91%

99,91% de la population française pas en réanimation ça en fait quand même 60 000 (soixante mille) en réa. On a combien de lits déjà ?

Ces lignes nécessitent l'utilisation du driver Xorg intel. Par défaut c'est le driver modeset qui est utilisé maintenant pour les cartes Intel.
Si tu n'arrivais pas à démarrer avec cette configuration, c'est peut-être parce que le driver Intel n'est pas installé. Est-ce que le paquet xserver-xorg-video-intel qui le fournit est installé ?

J'utilise Tiny Tiny RSS auto-hébergé depuis de nombreuses années, super pratique. Il y a un client Android pour synchroniser ses lectures, Liferea a aussi un backend pour ça.

C'est lié aux accès aléatoires et au NCQ.

Dans le pire des cas chaque accès prend un maximum de temps à cause de sa position sur le disque (par exemple si tu lis un bloc juste avant).

Le principe du NCQ est de ré-ordonnancer les accès dans la file d'attente, pour minimiser le parcours du disque à effectuer.

Donc par exemple si tu demandes à lire quelque chose comme ça et que les blocs sont stockés dans l'ordre sur le disque (je mets les numéros de blocs):

5 - 4 - 3 - 2

À chaque fois tu dois attendre un tour complet du disque vu que le bloc à lire suivant est situé avant celui qui vient d'être lu.

Avec NCQ, le contrôleur du disque va réordonnancer la liste des requêtes à effectuer afin de minimiser la distance à parcourir sur le disque:

2 - 3 - 4 - 5

Au final le temps de réponse pour la première requête est plus important, mais le débit global est augmenté.

NCQ ne peut agir que sur les requêtes envoyées au disque (donc fonction de la taille de la file d'attente).

Donc plus tu augmentes la taille de la file de requête plus potentiellement NCQ peut augmenter le débit en réordonnançant des requêtes, au détriment de la latence des requêtes situées au début de la file.

Tu satures tes disques en IOPS (environ 75 i/o par seconde en moyenne pour des disques magnétiques 7200 tours/minute) car tu fais des accès aléatoires (non séquentiels). Les accès aléatoires sont vraiment l'énorme différence de perf entre les SSD et les disques magnétiques.
hdparm -tT c'est un test en accès séquentiel donc pas représentatif si tu fais de l'aléatoire.
En effet si tu peux augmenter la taille des blocs de données accédés à chaque i/o, tu devrais pouvoir augmenter ton débit.

• Une partie de la Bretagne ne se retrouve pas complètement immergée.

La Bretagne est assez vallonnée, donc il y a moyen de trouver des endroits sans risque à ce niveau. C'est bien plus problématique pour les régions plates au bord de la mer (comme le Médoc et la Vendée).

J'ai l'impression que ça dépend pas mal du contexte, par exemple les déploiements, est-ce que le déploiement de conteneur n'est pas plus simple au final que de déployer des tonnes de RPMs à l'ancienne ?
Aussi il y a un gros besoin au niveau sécurité. Il y a régulièrement des problèmes de sécurités liées à la nature du C (accès mémoire non sûr), donc une partie de ce qui motive de réécrire des bouts de système en Rust est d'éviter ce genre de problème.

Globalement les systèmes sont certes beaucoup plus complexes, mais on a aussi des besoins de simplicités accrus. En effet c'est trop compliqué de gérer un système complexe si ses composants sont aussi complexes à maintenir, donc certaines couches doivent êtres simplifiées. D'où par exemple le gain de popularité d'Alpine Linux pour construire des conteneurs, des binaires self-exécutables, etc.

J'ai récemment acheté un Smartbook chez Evi pré-installé avec Ubuntu. Ils assemblent sur une base Clevo, et proposent diverses distributions Linux à la pré-installation.
Le processus d'achat s'est bien passé même si c'est un peu artisanal, en gros j'ai envoyé un mail avec la commande.
Ils n'ont pas l'air d'avoir beaucoup de choix en AMD, donc pas sûr qu'ils puissent répondre à tes critères.
Le châssis Clevo est pas trop mal, les touches du clavier sont un peu dures. Par contre le son des enceintes est vraiment mauvais…

Il ne me semble pas que les version de Windows impactées par des failles de sécurités soient bloquée par les UEFI.

C'est un problème différent, tout comme UEFI avec Grub permet de booter des kernels Linux qui ont été impactés par des failles de sécurité.

Le principe de secure boot est de ne pouvoir démarrer qu'un boot loader et noyau signés par un vendeur et donc considérés comme sûr. De fait un attaquant ne peux pas modifier le noyau pour y ajouter un rootkit qui serait actif au prochain redémarrage, le démarrage du noyau compromis échouerait.

Cette faille contourne cette protection, rendant le secure boot à peu près caduc.

Soyons réalistes, oui il y a régulièrement des failles affectant des systèmes Linux standards et permettant d'exécuter du code avec des privilèges suffisant pour exploiter cette vulnérabilité, par exemple une liste de CVE affectant Debian (en effet, les logiciels couverts sont larges du fait de la taille de la distribution Debian, mais un attaquant se fera un plaisir d'utiliser n'importe quel vecteur d'attaque disponible).

Difficile de dire que ça n'est pas si grave. Oui la faille est difficile à exploiter, mais elle rend complètement caduque les protections secure boots pour de nombreux mois, voire années, et ce pour tout le monde.
En effet, les versions signées de Grub qui sont affectées vont devoir être bloquée au niveau d'UEFI, ce qui va nécessiter d'attendre que la majorité des utilisateurs aient mis à jour leur système. Même après ça, ça risque de rendre non bootable un très grand nombre de système (car la version compromise ne sera plus acceptée par l'UEFI).
Ça affecte tous les systèmes, en effet un attaquant peut attaquer un système Windows (ou autre) pour y installer un Grub compromis et signé, qui sera accepté pour l'UEFI.
Donc ça pose un sacré problème de confiance en grub pour être fiable dans le futur.

De plus, après la découverte de la faille, les équipes de securité de Canonical et autres ont passé grub à la moulinette d'analyse statique, et ont trouvé beaucoup d'autres vulnérabilités, pour s'en convaincre la liste se trouve dans l'alerte de sécurité de RedHat.

Si sur un composant aussi critique pour la sécurité que grub on trouve autant de code non sûr, quid des autres composants qui disposent d'encore moins de moyens pour faire ce type d'analyse ?

Et que trouves-tu que Ubuntu a mais pas Fedora ? Pour comprendre ta logique car je ne vois pas à quels éléments tu fais référence.

Une LTS. Et on ne peut pas dire que CentOS soit la LTS de Fedora.

Pareil au taf, KDE sur Debian Buster, ça tourne absolument nickel.

J'ai longtemps été sous Stretch KDE à la maison, le seul truc plus stable que ça est un PC éteint.

Quelques alternatives que je connais, par contre je ne sais pas si elles sont disponibles à Marseille.

• OSMand: l’application Android fournit depuis peu le calcul d’itinéraire en transport en communs. C’est open source et basé sur OpenStreeMap.
• HERE WeGo: fonctionne dans beaucoup de villes. Fonctionne hors-ligne ce qui est appréciable.
• Citymapper: assez efficace et beaucoup de fonctionnalités (par exemple combiner vélo et transports en commun, par contre supporte un nombre limité de villes, je ne sais pas si Marseille en fait partie.

Une seconde multipliée par des millions de lancements, ça devient non négligeable pour l’opérateur du cloud.

Sans même aller dans le cas de Lamdda, l’utilisation du cloud fait qu’on passe son temps à lancer et arrêter des machines virtuelles, donc économiser du temps de démarrage du système est super important.
Par exemple pas mal de gens relancent toutes leurs machines virtuelles pour déployer une mise à jour, plutôt que de faire la mise à jour sur les machines existantes. Réduire le temps de démarrage réduit le temps de déploiement dans ce cas, surtout si on déploie par vagues.

Pour limiter le débit descendant tu pourrais utiliser un cgroup. À priori peux limiter le débit par cgroup (je n’ai pas essayé).

D'après le lien ci-dessus pour l'instant Firefox ne supporte pas simulcast donc les flux doivent vidéos être envoyés à tout le monde si un participant utilise Firefox, ce qui peut sérieusement dégrader le résultat (si la bande passante ou le CPU ne sont pas suffisants je suppose).

Clonezilla semble en effet une très bonne option que je n'ai pas essayée, par contre est-ce qu'il gère la configuration du boot manager ? Dans le cas d'un système EFI, il faut configurer le boot manager (copier le bootloader sur le disque ne suffit pas), et donc si Clonezilla ne le fait pas, il faut toujours effectuer les étapes chroot et installation de grub (qui configure le boot manager).