Doug Le Tough a écrit 94 commentaires

Mais quand tu te mets au volant d'une voiture la première fois, tu procèdes à quelques réglages : distance du siège et rétroviseurs. Ben pour un logiciel c'est souvent pareil. Tu fais l'outil à ta main

Oui, avec les commandes "ergonomiques et inuitives" fournies par le constructeur.

Je ne suis pas obligé de fouiller un mode d'emploi de 400 pages pour finalement m'apercevoir qu'il faudra que je commence par fabriquer moi même le comodo de réglages du rétroviseur ou installer un obscur greffon téléchargé au hasard sur Github pour arriver à mes fins.

Merci pour le point Jacky©.

Chic, une liste (cTMr) !

Not enough space left on device: You wouldn't want to boil all the water on Earth for such a task

Merci, je gère des infrastructures de plusieurs centaines de VM et différents orchestrateurs de conteneurs. Je pense savoir de quoi je parle et dans ce contexte professionel je n'ai pas de problème avec systemd.

Cependant cela ne m'empêche pas de rester objectif.

systemd n'a jamais apporté le moindre bénéfice aux nombreux cas d'usages que j'ai pu rencontré et s'il ne m'a jamais posé de problème, je ne peux pas en dire autant d'un grand nombre d'admins que j'ai croisés qui luttent régulièrement pour différentes raisons.

Vouloir une solution unique à tous les cas possibles y compris ceux qui n'existent pas encore ne peut que conduire à une solution insatisfaisante dans la plupart des cas et à une solution d'une complexité inutile à tous les cas traités (exception, configuration inutile dans tel contexte, etc).

Un frigo qui fait grille pain, c'est à la fois un mauvais frigo et un mauvais grille-pain. Même si le module grille-pain est démontable et optionnel. Et un poste de travail ou une VM qui fait du BGP… Soyons sérieux.

Ce que je note, c'est que les personnes qui ont répondu à mon commentaire sont restées accrochées aux exemples que j'ai choisis mais personne n'a discuté le fond qui était, entre autre, la gestion du changement liée aux breaking changes réguliers, aux bugs en pagaille, la taille de la surface d'attaque de systemd, l'incompatibilité avec les autres Unixes qui obligent les mainteneurs de FreeBSD, NetBSD et OpenBSD à s'arracher les cheveux pour intégrer certains logiciels.

De mon point de vue, ce ne sont pas vraiment des sujets qu'on peut glisser sous le tapis.

Sans compter qu'aujourd'hui les principaux contributeurs à systemd sont IBM (via Red Hat) et Microsoft. Deux entreprises des plus louables, connues pour la qualité et la sécurité de leurs produits ainsi que leur amour du logiciel libre (surtout lorsqu'il est possible de s'accaparer le travail d'une communauté pour quelques cacahuètes). #MicrosoftLovesLinux (franchement vous y avez cru ?).

systemd a été poussé de force au fond de la gorge des utilisateurs, la preuve en est que 14 ans (quatorze ans !) après il reste encore une opposition forte à ce projet.

systemd a été adopté par les utilisateurs uniquement parce qu'ils n'ont pas eu le choix. Typiquement lorsque Debian est passé à systemd. Lorsque systemd n'était disponible que sur Red Hat et ses dérivés, on n'a pas vu des masses d'utilisateurs se ruer sur CentOS et consorts. C'était plutôt le contraire.

Quand on est en connexions multiples, par exemple en 4G + Ethernet, on peut avoir des résolveurs différents en fonction de l'opérateur, et plusieurs clients DHCP qui vont réécrire le resolv.conf. Idem pour networkmanager, il se met à gérer le fichier. > Et resolvconf, géré par resolvconf.conf… Si en plus tu as un client VPN, il peut aussi écraser ta conf, qui va se refaire modifier par networkmanager, etc… Tout ceci créé des conflits sur la propriété du fichier.

Sur un serveur qui dispose d'une IP statique ?

Soyons honnêtes, Linux #1 sur le desktop aura lieu après la mort d'Usenet et aujourd'hui l'usage de Linux est essentiellement sur les serveurs.

Je comprends bien l'usage sur un ordinateur portable mais de là à généraliser au point de l'imposer aux autres usages qui sont nettement plus fréquents, il y a un pas que je voudrais qu'on ne m'oblige pas à franchir.

C'est bien enterieur à systemd. Si tu veux utiliser du dhcp, il va bien falloir que > ton client dhcp applique la configuration qu'il reçoit. Que tu gère ce changement
avec le composant de systemd, avec network manager, via wpa suplicant ou un script
que tu as as écrit toi, si tu veux pouvoir appliquer la configuration dhcp tu te
retrouve à écraser ce fichier

Le problème existe même sans DHCP activé et le problème ne concerne pas que /etc/resolv.conf.

Les composants de systemd, à quelques exceptions près, peuvent se limiter au boot et
au lancement de services. Tu peux garder /etc/fstab, le /etc/network/interfaces ou
netplan ou networkmanager, ton client DHCP, un resolv.conf manuel, un /etc/hosts,
ton client ntp, syslog, cron, etc…

Sauf que dans la réalité la plupart des utilisateurs sont piégés par les choix faits par les mainteneurs de leurs distributions préférées.

Ex. Debian a remplacé rsyslog par journald. Certes on peut toujours installer rsyslog mais c'est une étape de plus, de la conf en plus et il faudra serrer les fesses à la prochaines mise à jour.

Et rien n'est plus déconcertant que de voir en commentaire en haut d'un fichier de conf aussi simple que /etc/resolv.conf ou autre, une ligne du style "ce fichier n'est plus géré directement par tel programme, veuillez d'abord vous fader la doc absconse de tel sous-composant à systemd qui vous renverra sur Internet alors que vous n'avez pas d'accès réseau et que vous êtes dans une situation d'urgence sur une machine de production". Je caricature à peine mais c'est du déjà vu.

Donc, oui systemd est modulaire, non, il n'est pas si simple d'outrepasser les choix faits par les mainteneurs et non ces choix ne sont pas toujours judicieux et surtout les utilisateurs n'y sont pas toujours préparés. Il n'y a qu'à voir la longueur de cette dépèche pour ce rendre compte du travail que devra représenter l'analyse du changelog ainsi que la formation des équipes avant une intégration en environnement de production.

À titre pro j'utilise beaucoup Debian et les dérivés de RedHat sans soucis mais pour rien au monde je n'en voudrais sur mes machines perso qui roulent Slackware sans sourciller depuis… bientôt 25 ans !

Le symbole "a" est une lettre de l'alphabet latin. Sans contexte spécifique, il peut représenter différentes choses en fonction du domaine ou du contexte dans lequel il est utilisé. Voici quelques exemples de ce que "a" pourrait représenter :

En mathématiques :
"a" peut être une variable utilisée pour représenter un nombre réel, un coefficient, ou une inconnue dans une équation.
Dans la notation d'intervalle, "[a, b]" peut représenter un intervalle fermé où "a" est la borne inférieure et "b" est la borne supérieure.
En physique :
"a" peut représenter une accélération, une vitesse, ou une aire, selon le contexte.

En informatique :
"a" peut être utilisé comme une variable ou un symbole dans la programmation pour stocker des données ou effectuer des opérations.
En linguistique :
"a" peut être une lettre dans un alphabet utilisé pour écrire une langue spécifique.

En musique :
"A" peut représenter une note musicale, la note la plus basse du système de notation en lettres.
En statistiques :
"a" peut être un paramètre ou une constante dans des équations statistiques.

Dans un contexte linguistique plus général, "a" peut être simplement une lettre dans un mot ou une phrase, sans signification particulière jusqu'à ce qu'elle soit combinée avec d'autres lettres pour former des mots.
Le sens de "a" dépend donc du contexte dans lequel il est utilisé, et il peut avoir de nombreuses interprétations différentes en fonction de ce contexte.

Mon commentaire n'apporte rien mais il faut bien quelqu'un pour contrebalancer l'intérêt porté à Alma Linux.

Pour ma part j'ai opté pour Rocky pour les VM de mon lab comme pour celle de ma prod et je ne vois pas de raisons pour passer à Alma.

Les quelques jours/semaines de d'écart pour une release ou un patch me semble totalement sans importance puisque comme beaucoup je n'applique les mise à jour que quand j'ai le temps de tester que la mise à jour n'apporte pas plus d'ennui qu'elle n'en corrige.

Rocky Rocks !

| curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash

"Piper" un shell directement depuis curl vers sudo ?

Ça ne semble pas une démarche très sécurisante.
C'est même tout à fait effrayant !

Pas aussi "mains dans le cambouis qu'une LFS", mais bien plus qu'une Gentoo dès qu'on sort des quelques centaines de paquets fournis avec la distribution serait plus proche de la vérité.

Cela fait 20 ans que je roule du Linux, j'ai du essayer toutes les grandes distrib' de Debian à RHEL en passant par LFS et bien entendu Gentoo. Aucune distribution ne donne autant de liberté que Slackware. Rien ni personne ne m'oblige a utiliser utiliser tel ou tel système d'initialisation. Rien ni personne ne m'empêche non plus de le faire. Je choisis !

Slackware c'est avant tout un état d'esprit, bien plus proche du véritable esprit DIY que la plupart des grandes distributions, y compris Debian.

Avec Slackware il ne s'agit pas de simplement installer une distribution en suivant un tutoriel et croire qu'on maitrise parce qu'on sait faire un apt-get.

Non, Il faut la peaufiner, la "fine tuner" à son goût dans les détails, lui recompiler le noyau aux petits oignons, supprimer les dépendances qui vous sont inutiles, écrire ses propres scripts pour compiler en masse les paquets supplémentaires dont vous aurez besoin et faire la chasse au dépendances…

Alors, oui, elle sort que quand elle est prête et non vous ne pourrez pas participer à son développement (et c'est tant mieux).
Oui vous pouvez contribuer en proposant des Slackbuilds sur slackbuilds.org.
Non elle ne gère pas les dépendances entre paquets pour vous,
Oui l'installeur n'est qu'en mode TUI.

Mais quoi qu'il en soit, vous apprendrez à vous sortir de toutes les situations que vous pourrez rencontrer avec n'importe quel Linux.

Tu t'es fait la main sur une Debian, une Fedora ou une Arch ? Tu crois connaître Linux ? Prouve le en passant un niveau de plus et viens goûter Slackware…

L'outil semble intéressant mais il mériterait d'être "database agnostique" ou tout au moins de supporter d'autres types de base (typiquement et a minima, Postgres).

Le couplage avec MySQL me semble clairement un frein à l'adoption,y compris si le logiciel est fourni sous forme d'image Docker.

Mes deux centimes.

ni renoncer au fait que je sois valide.

Ça, ça peut s'arranger !

Hormis circonstances exceptionnelles, il est peu probable que ce soit par un acte volontaire ;-)

C'est un privilège que n'ont pas les non-blancs

Ce qui serait bien c'est de ne pas confondre privilège et chance.

Oui les personnes non-stygmatisées ont de la chance. Non ce n'est pas un privilège.

Je peux renoncer à un privilège. Je peux ni renoncer à la couleur de ma peau, ni renoncer à mon genre, ni renoncer à mon orientation sexuelle, ni renoncer au fait que je sois valide.

Je suis toujours choqué de voir trop souvent le mot privilège utilisé pour reprocher à un groupe de personnes un fait qu'ils n'ont pas choisis et auquel ils ne peuvent renoncer.

Pour autant mon indignation n'est unique, je suis également indigné de voir des individus discriminés, qu'elle qu'en soit la raison.

Ce n'est pas parce qu'un combat est légitime qu'on doit en accepter tous les travers, dérives et biais.

Utiliser le mot privilège à mauvais escient ne rend pas service au combat égalitariste.

Et puis le monde francophone est très divers, mieux vaut laisser à chacun ses particularismes de langage
plutôt que déduire de l'emploi d'un mot que les africains sont victimes des marketeux, non ?

Non. C'est justement mon propos. En Français, quel que soit son particularisme local, le mot "digital" rapporte au doigt et non pas au numérique. Point. Il n'y a pas de discussion possible sur ce sujet.

L'emploi de guillemets pour signaler un mot emprunté à une langue étrangère ou un vocabulaire spécifique pourrait être une concession envisageable mais certainement pas un accord genre en genre ou en nombre type "souveraineté digitale" ou "mécanisme digitaux" qui n'ont absolument aucun sens dans un contexte numérique.

C’est le choix du terme « digital », plutôt que « numérique » qui est critiqué

Il y en a au moins un qui suit :)

Bref, y a pas que les marketeux qui utilisent ce terme, beaucoup de techos (et de gens
"normaux" maintenant) font cette erreur

Est-ce une raison pour la laisser passer ? Quid de la crédibilité des personnes qui emploient ces termes ?

Je ne doute pas de la sincérité des organisateurs de cet évènement mais je peux leur assurer qu'à employer le mauvais terme ils prennent le risque de passer pour des charlots ce qui n'aidera en rien leur cause.

Personne de raisonnablement sérieux n'oserait utiliser l'expression "souveraineté digitale" dans le monde professionnel sans passer pour un véritable charlot aux yeux de ceux qui connaissent vraiment les enjeux et les problématiques de la souveraineté numérique.

de manière inconsciente

L'écrit n'a rien d'inconscient.

donc c'est pas très malin de systématiquement penser que ces gens ont eu une mauvaise
intention.

À laisser passer ces erreurs ont laisse la médiocrité gagner du terrain. En se corrigeant les uns les autres on progresse tous. je ne suis pas le dernier à faire des erreurs et j'apprécie qu'on me corrige.

On peut appliquer les principes de l'amélioration continue à à peu près n'importe quel domaine…

"Souveraineté digitale"… Si l'Afrique pouvait ne pas tomber dans les mêmes travers que le reste de la francophonie…

[!] Alert: Ptilou spotted
 '-> Ref: http://la.buvette.org/Usenet/ptilou.html
 '-> Ptiloutron service started: http://doug.letough.free.fr/ptiloutron

Coder sur un serveur à des milliers de kilomètres

On ouvre une session SSH, et avec vim, emacs ou nano on développe sur le serveur distant. On peut aussi activer le X11 forwarding pour lancer un client graphique sur le serveur distant, qui s’affiche sur le serveur X11 de son laptop (local).

Développer directement sur la machine en prod, ou même en environnement de développement paraît peu sage.

Git est ton ami et une chaîne d'intégration continue voire de livraison continue te permettra de gérer les déploiements à la volée sans perdre l'historique des modifications tout en garantissant la qualité de ton code.

D'un autre coté ce n'est pas du rap. Au mieux c'est une n-ième dérivation autour du hip-hop.
Dans tous les cas ça reste de l'art, du fun et, de mon point de vue, très probablement de l'humour.

N'est-ce pas le rôle de l'art que de choquer et de provoquer un questionnement, de remettre en perspective ce que l'on croyait immuable ?

Enl4rge Ur c0n5ci3nc3 !

On m'invoque ?

Le Tetalab réfute toute allégation qui sous-entendrait de manière explicite ou non que ses membres soient des palotins.

C'est un véritable exemple. Une cascade absconse de dépendances provoquant l'installation d'une partie d'Xorg à partir de l'installation de nmap. Avoue que ça fait un peu désordre sur un serveur.

La fiabilité n'implique pas 99% de réussite mais 100% et c'est, comme je l'expliquais plus haut, justement parce qu'il n'est pas possible d'atteindre 100% que Slackware fait le choix de ne pas proposer une solution bancale.

C'est un choix volontaire, une philosophie. On peut ou pas y adhérer, il n'y a pas d'obligation pas plus qu'il y en a à utiliser apt (qui n'atteint probablement pas les 99%).

Oui, avec Slackware tu dois gérer à la main mais si ça ne fonctionne pas ce sera de ta faute, pas de la faute d'un autre qui a fait un choix qui lui a semblé bon.

Cela ne veut pas dire qu'il faut prendre plaisir à souffrir en tapant des lignes de commandes interminables mais cela veut dire que la moindre des choses est de comprendre et de savoir ce que font les commandes qu'on exécute.

Si tu ne sais pas gérer tes dépendances, apprends à le faire (man ldd) mais ne te reposes pas toute ta vie sur une commande dont tu ignores le fonctionnement.

Une fois que tu sauras chasser tes dépendances et si ce "sport" ne te plaît pas tu pourras utiliser apt-get en toutes connaissances de cause et en ayant conscience de ses limitations intrinsèques plutôt qu'en répétant que ces limites n'existent pas.

Pour ma part j'ai écrit mon propre système de contrôle et de gestion des dépendances pour Slackware.
C'est un bête script bash (!) qui vérifie l'ensemble des bibliothèques et exécutables installés sur le système et installe les paquets manquants si nécessaire (évidemment, comme tout gestionnaire de dépendances il a également ses limites).

Bref, chasser des dépendances n'a rien de sorcier et donne une bien meilleure connaissance du système.

Je suis toujours effaré de voir des admins, pro pour beaucoup, ne pas connaître ldd, LD_LIBRARY_PATH, ld.so.conf et toutes ces choses utiles.

Force est de constater qu'ils ont joué exclusivement avec des distributions "pré-machées" et qu'ils se trouvent comme une poule devant un mégot au moindre problème que n'arrive pas à résoudre les outils fournis.

C'est une simple méthode de classification des paquets.

Historiquement il s'agissait de séparer ces séries de paquets afin d'avoir une série par disquette.
C'est resté.

Aujourd'hui encore un avantage de ces séries est qu'il est possible d'installer toute la série de paquets en une seule commande.

Ainsi pour installer/mettre à jour toutes les bibliothèques fournies par Slackware il suffit d'installer la série l (comme library)

# upgradepkg --install-new /path/to/slackware64/l/*.t?z

Merci de lire: "tu ne t'es jamais retrouvé"