Yth a écrit 2678 commentaires

Le problème c'est que c'est un peu comme de croire que si tu as un couteau à la main, tu vas réussir à te défendre.
Quelle que soit l'arme, de deux choses l'une :
* Soit tu as appris à t'en servir, auquel cas tu es dangereux, et ta posture, ton calme, ton attitude et peut-être aussi tes paroles vont t'aider à désamorcer un conflit.
* Soit pas. Et là ça va se voir, sauf si tu bluffes très bien, et tu risques surtout de te blesser avec ta propre arme. Même (surtout ?) dans le cas d'une arme à feu.

Tu dissuaderas aussi bien avec un bout de bois qu'avec une arme à feu si tu montres que tu sais te servir de ton arme.
Et tu te défendras aussi mal avec un fusil d'assaut qu'avec une petite cuiller si ça se voit que tu ne sais pas t'en servir.

Donc l'aspect dissuasif ne provient pas de l'arme en tant que telle.

Bon, ok, un peu quand même parce que faire n'importe quoi avec une petite cuiller c'est moins risqué que de faire n'importe quoi avec un fusil de chasse, mais c'est plus le côté chaotique de la situation qui peut faire peur que le fait que toi tu aies une arme.

Et si tu te fais agresser par quelqu'un qui a lui même une arme, et que tu en sors une ? Cette personne a de grande chance de tirer le premier, tu prends un risque énorme. Sauf, encore une fois, si tu es prêt à tirer, et un minimum entraîné.
Mais tu penses qu'appuyer sur la gâchette c'est facile ?
Même si ta vie est en danger ?

Tu peux tourner la situation dans tous les sens, imaginer la situation que tu veux.
Ce qui va te protéger c'est de savoir te défendre, même si c'est à main nue avec des techniques d'arts martiaux, de boxe ou que-sais-je.
Ce n'est pas l'arme.
Ce n'est jamais l'arme.

Et donc avec tout ça je n'ai jamais qu'une seule conclusion possible : une arme à feu ne sert pas à se défendre, c'est savoir se défendre qui sert à se défendre.
Une arme à feu ça sert à tuer.

Et « un logiciel », ça peut servir à tout et n'importe quoi.
Ergo : la comparaison ne peut que tomber à l'eau, ça ne marche pas, ce n'est pas comparable.

• Yth.

Est-ce immoral de se défendre lorsqu'on est attaqué ?

Ma seule réponse ici va être de dire qu'on est dans un cas particulier ici et non dans le cas général.
La légitime défense ça ne fonctionne d'ailleurs pas qu'aux états-unis.
Et c'est la raison pour laquelle certaines forces de l'ordre, même en France, sont armées.

Tant qu'on garde en tête qu'une arme à feu ne sert pas à se défendre, mais à contre-attaquer.
Pour se défendre on a le gilet pare-balle par exemple, imparfait mais utile, ou la voiture blindée.

La notion de l'on puisse utiliser une arme à feu pour se défendre est fausse.
Mais ça ne veut pas dire qu'on n'a pas le droit de se défendre et qu'on n'a pas la possibilité de le faire - dans certains cas, selon ta spatio-temporalité - avec une arme à feu.

Le cas général c'est A tue B, en dehors de toute raison.

Allez, j'en rajoute un peu :
Un logiciel d'intrusion pour tester ton système c'est comme de valider la pénétration dans ton gilet pare-balle ou t'entraîner à tirer sur cible.
Sachant que tu peux être dans une situation de conflit armé (à feu ou avec des logiciels), tu peux te préparer à riposter sans te laisser faire, et vérifier que tes contre-mesures (physiques ou logiques) sont efficaces.

À la rigueur, tu pourrais comparer le sous-ensemble des « logiciels d'intrusion, attaque, etc. » avec les armes à feu.
Ou alors l'ensemble des logiciels, avec, je sais pas, un sur-ensemble des armes à feu ? La chimie ? Le feu ? Les outils mécaniques ?

C'est en ça que cette comparaison est invalide, tu as un concept général d'un côté, multi-forme, multi-paradigme, permettant logiquement de tout faire (turing-complet).
Et de l'autre une gamme d'applications particulières avec un objectif précis (tuer, mais ça pourrait être creuser des trous hein).

Ça n'est pas comparable.

• Yth.

Le logiciel libre est né aux États-Unis, pays qui autorise la vente libre d’armes à feu.

Ça ne change rien à la question.
Tuer reste immoral dans le cas général aux états-unis.
Une arme à feu reste un outil conçu pour tuer.

Maintenant les cas d'autorisation d'utiliser une arme à feu sont plus étendus aux états-unis, en particulier, chez toi, tu peux massacrer un intrus à coups de fusil à pompe sans rien risquer, tu peux même tirer sur les forces de l'ordre si elles ne se sont pas correctement présentées comme telles, et si tu survis - par hasard - tu ne pourras pas être condamné pour ça.

En France ce n'est pas le cas.

Il n'empêche, une arme à feu reste un outil conçu pour effectuer une action immorale dans le cas général, alors qu'un logiciel, bah, non.

Et ça change tout.
Il est légitime de réguler la vente d'armes à feu a priori (elle l'est aux états-unis : le matériel militaire n'est pas en vente libre par exemple, les explosifs non plus), il ne l'est pas pour les logiciels. A priori.
Mais en particulier, il y a des lois, et des usages.
Et si la vente d'armes est libres aux USA, tuer quelqu'un dans un lieu public ne l'est pas plus qu'en France.
Et si le reverse engineering est interdit aux états-unis, il ne l'est pas en France par exemple, où on peut donc considérer qu'on a plus de libertés, ce qui est le cas au niveau de l'utilisation des logiciels.

• Yth.

Je suis perturbé.
La première partie de ton message est clairement ironique, mais après tu dis très sérieusement que toutes les comparaisons ont une limite.

Or la comparaison que tu utilises pour ce faire est sans commune mesure avec celle que tu critiques…

Car une arme à feu est effectivement conçue pour tuer. De façon tout à fait neutre, ça sert simplement à tuer. Pas à blesser, ni à se défendre. À tuer.
Et autant dans certains cas ce n'est pas considéré comme immoral (un conflit armé, ou les animaux lors de la chasse), autant dans le cas général, si.

Tuer, par défaut, c'est immoral.
Et les exceptions à ce cas par défaut évoluent selon les âges, et les cultures, en France il n'était pas immoral de guillotiner il y a deux siècles, mais ça l'est aujourd'hui.

Par contre une chaise, ça n'a jamais été immoral. Ni par défaut, ni jamais.
Un couteau non plus.
Une branche d'arbre non plus, même si on peut blesser ou tuer avec.

Un logiciel, dans le cas général, sans autre précision, ça n'a rien d'immoral.
Un algorithme non plus d'ailleurs, qu'il soit informatique ou pas.

Un logiciel conçu pour enfreindre la loi, c'est immoral, mais c'est comme la chaise électrique en France aujourd'hui, ça entre dans la catégorie des chaises, mais celle-ci est spécifiquement conçue pour tuer, ce qui est immoral. En France. Aujourd'hui.
Il n'y a rigoureusement aucune raison de réglementer les chaises en général.
Par contre les chaises électriques, oui !

Il n'y a aucune raison de réglementer les logiciels, mais ceux qui sont conçus pour enfreindre les lois, si (par exemple un logiciel espion utilisé par les services secrets).
Et il y a toute les raisons de réglementer les usages, comme celui de tuer, que ça soit avec un stylo-bille, une chaise, ou un logiciel.

La morale entre donc exclusivement dans la réglementation des usages.
Ou dans le cas spécifique d'un logiciel conçu comme étant immoral.

Un logiciel de partage de fichier n'a rien d'immoral.
Il y a des usages cependant qui sont considérés par une partie de la population, aujourd'hui, en France, comme immoraux.

La réglementation se fait donc sur l'usage, pas sur le logiciel.

Bref, j'ai l'impression de tautologer…

• Yth.

Ou sinon :
ln -s /mon/script/a/lancer/toutes/les/heures.sh /etc/cron.hourly/
Et ça va se lancer toutes les heures.

Tu as aussi /etc/cron.daily/, /etc/cron.weekly/ et /etc/cront.monthly/
En général, ce n'est pas une obligation, bien sûr, que ces répertoires existent, mais c'est souvent le cas.

Après, ça gère quelques cas très généraux, et pas des cas particuliers, où ton script doit être lancé le second dimanche de chaque mois à 13h57 précisément.

• Yth.

En gros, il suffirait de poster un contenu illicite sur Facebook, et hop, on fait appel à la future HADOPARCEPI pour que les FAI bloquent tout facebook ?

…

C'est pourtant le cœur du problème, même si on sait très bien que ça ne s'appliquera jamais aux gros sites, mais uniquement aux petits…

• Yth.

Ah non, rien à voir !
Le M c'est le premier dans la liste, l'original, le plus important, le plus nocif.
Et celui qui essaie de se faire oublier.

Mais l'acronyme devrait être MAGAF plutôt !

En plus c'est mieux.

• Yth.

C'est un type.
Et il a une opinion.

• Y.

C'est vrai, c'est un plaisir coupable, et sa rareté ne le rend que plus appréciable.

• Yth.

Bah, au bout d'un moment, la petite bédé quand on se répond à soi-même, elle fait moins d'effet, il faut savoir se ménager ce plaisir rare, pour le conserver plus longtemps !

• Yth.

Comme je l'ai dis plus haut, là, franchement, on dépasse le cadre de mes connaissances ^{^}

• Yth.

Pour le coup, on parle d'un cas très particulier, et aussi d'un logiciel avec une place assez unique parmi tous les autres.

J'ai commencé à utiliser les binaires officiels pour la version développeurs.
Difficile à packager efficacement dans une distrib, plus simple de laisser Firefox gérer ses propres mises à jour.

• Yth.

Ah oui, la Slackware i586 a les mêmes paquets que la version x86_64.
Donc un noyau récent, une glibc récente, etc.
Enfin, si on parle de la 14.2, ça a 5 ans, donc pas si récent, mais la current en i586 est la même que la version x86_64 (ou arm).
Donc côté libs et compatibilité, ça peut largement foirer sur une vieille version d'une autre distribution.

• Yth.

Pour le coup je ne suis pas très sûr que ça soit plus simple avec flathub.
Le binaire Firefox officiel, tu détares, et tu te fais ton lien pour lancer Firefox, après tu touches plus, la mise à jour est gérée par firefox dans son répertoire où tu l'as dézippé, tu ne retélécharges plus jamais rien à la main, tu ne fais plus rien d'autre que d'accepter les mises à jours et redémarrages qui vont avec.

• Arnaud.

Ah ben oui, un moteur de rendu web, en 2021, c'est l'un des bouts de code les plus complexes qui tournent sur ton ordinateur…

À côté de ça, une synchro de données, même si c'est pas simple, c'est un autre ordre de grandeur.

• Yth.

Les binaires fournis par mozilla fonctionnent très bien sous une slackware 14.2, j'écris sur un FF 86.0 là.
Mais c'est alors décorrélé de la distrib, mon autre FF est installé dans un répertoire, et il gère les mises à jour en interne.

• Yth.

C'est un peu comme de forcer à confirmer la moindre suppression de fichier.
rm truc -> confirmation
rm -r truc/ -> confirmation, confirmation, confirmation… -> ctrl-c -> rm -rf truc/
Et finalement on saute l'étape rm truc pour taper toujours rm -f truc.
Et là on n'a plus de demande de confirmation pour les fichiers un peu protégés mais qu'on peut effacer quand même.

L'idée est bonne et fonctionne cinq minutes, et après on en revient toujours au même point : fais toujours gaffe à ce que tu fais, et tu ne seras jamais à l'abri d'une fausse manip.

• Yth.

La valeur est de 98304 (=3*32k) dans la configuration du noyau Slackware (vu sur un 4.4 et un 5.10, donc ça ne semble pas avoir changé dernièrement):
$ zgrep CONFIG_DEFAULT_MMAP_MIN_ADDR /proc/config.gz
CONFIG_DEFAULT_MMAP_MIN_ADDR=98304
J'ai un kernel Debian arm 4.2 dans un coin (juste le noyau, pas la distrib), qui a 4096 comme valeur.

Pour avoir plus d'infos, il faudrait probablement se plonger dans des archives longues et lointaines…
Mais on est dans l'idée du « something like 64k ».

• Yth.

Ah oui, en l'occurrence, c'est clairement un abus de langage et il faut lire GNU/Linux.

• Yth.

Et aussi la compatibilité Linux, parce que là ils proposent avec un windows 10, mais ça serait bien de proposer nu, et que ça marche sous notre OS préféré.

Le coup des slots d'extension, c'est plutôt efficace pour choisir, et changer, la connectique de la machine, j'aime bien l'idée.
Et aussi pour choisir de quel côté on branche l'écran, ou la souris :)

• Yth.

Ah non, c'est l'inverse !

• Y.

Ben apparemment ça en casse une d'application.
Je t'assure que si ça en cassait des dizaines, ça se saurait, ça se serait vu. Déjà pour une seule, ça s'est vu.
Tu me trouveras une seule distribution qui n'a pas de problèmes de temps en temps avec tel ou tel logiciel…

Maintenant, ce « bug » est-il lié à la Slackware qui paramètre au delà de 64k, au noyau Linux qui permet de mettre une valeur au delà de 64k, ou Unvanquished qui plante si la valeur dépasse 64k ?
La solution la plus simple est de modifier cette valeur sous Slackware, puisque ça peut se faire en une commande (deux pour la persistance).
Mais est-ce une bonne solution de contraindre cette valeur à au maximum 64ko ?
Je n'ai pas la réponse à cette question, je ne comprends pas suffisamment le problème en l'état pour juger ou même donner un avis pertinent.

Mais cette recherche d'information t'en apprend-elle plus sur Slackware, sur le paramétrage du noyau Linux et certaines options Linux dont tu pouvais ne jamais avoir entendu parler, ou sur le code d'Unvanquished ?

À vue de nez, un bout du code d'Unvanquished (ou une lib sous-jacente) a pris un peu au pied de la lettre la doc du noyau : « Setting this value to something like 64k will allow the vast majority of applications to work correctly and provide defense in depth against future potential kernel bugs. » . Et devrait peut-être moins partir du principe que ce paramètre va être à 64k ou en dessous. Sauf qu'il y a peut-être des contraintes fortes pour ça ? Je ne sais pas.
Par contre, la doc qu'on va lire est exclusivement celle du noyau Linux, et on en apprend sur le fonctionnement du noyau, on découvre des attaques potentielles, et la solution choisie pour les mitiger.

Et tout ça nous apprends seulement que la Slackware a fait un choix pour cette valeur au delà de la valeur par défaut de 0 qui est décrite comme : « no protections will be enforced by the security module » soit un gros trou de sécurité potentiel.
Et là on espère qu'aucune distrib n'a laissé cette valeur à 0 par défaut.

Bref, j'en ai plus appris sur le noyau Linux que sur la Slackware (au delà du fait que l'équipe sait paramétrer un noyau Linux, ce qu'on savait déjà).

Mais le même symptôme sur n'importe quelle autre distribution aurait permis exactement le même raisonnement, et permis d'apprendre des choses sur le noyau Linux, et pas tellement sur la distribution en elle-même.

--

En gros, cette histoire de si tu apprends Slackware tu apprends Linux ça veut dire à peu près ça :
Tu commences par installer et paramétrer ton système, après avoir choisi ton clavier dans une liste.
L'installeur est Slackware seul, mais t'obliges à utiliser toi-même un *fdisk, à faire ton partitionnement, décider de ton swap, de tes partitions, voire de tes systèmes de fichiers au préalable, mais ça peut se faire dans l'installeur.
Il prend la main après, et tu choisis quelle partition sert à quoi, quels paquets tu installes - tout sauf kdei en 14.2, tout en 15.0 en gros, mais tu peux choisir très finement paquet par paquet.
Ensuite il y a une passe de configuration, réseau, polices console, bootloader, services démarrés par défaut.
C'est très Slackware-centré comme partie, et ça va le rester : le système d'init est quelque part entre du systemV et du BSD, l'apprendre ne te servira que sous Slackware ou un dérivé (il y en a plein : https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg).

Là tu apprends à paramétrer d'autres trucs, les mains dans le cambouis :
- comment régler ton serveur X comme tu veux (en particulier la langue, et le clavier) ? Ce qui va te servir c'est de piger la structure d'un fichier de configuration X.org.
- comment initialiser ta base mariaDb ? Ici il y a une doc slackware, mais qui va t'indiquer quelques commandes mariaDb à effectuer pour bootstrapper ton serveur, le fonctionnement est certainement assez spécifique à Slackware, mais t'apprends comment utiliser mariaDb, et pourrait te servir n'importe où. Typiquement certaines étapes sont faites automatiquement sur d'autres distribs, pas ici.
- comment lancer le serveur graphique par défaut ? bon faut définir le runlevel 4 dans ton initrd, là ça risque de ne plus te servir sur un OS systemd, on est dans du spécifique.
- comment passer en multilib ? Pour le coup, lire et comprendre la doc Slackware à ce sujet, par AlienBob, est très instructif sur comment ça marche un système multilib. La méthode est spécifique à Slackware (ben oui, tu vas installer des paquets Slack), mais le fonctionnement est totalement générique sur ce que signifie un paquet multilib, comment ça se construit, comment ça marche.

Et puis on arrive un peu au bout de ce qui est spécifique à Slackware.
À partir de là tu es un peu largué, option main dans le cambouis et RTFM, si tu veux apprendre à utiliser un logiciel, lis la doc de ce logiciel, c'est fini, tu n'as plus rien de spécifique à la Slackware.

Tu veux fine-tuner ton noyau Linux ? Tu peux partir de la configuration fournie par Slackware si tu veux, elle est fournie par le noyau dans /proc/config.gz, les sources du noyau - non modifié - sont installées sur ton système, tu peux aller faire des make menuconfig et apprendre à paramétrer Linux. Rien de spécifique Slackware ici.
Tu veux paramétrer Apache ? Bah lis la doc d'Apache… Ça te servira pour un peu n'importe quelle installation d'Apache si tu retrouves les fichiers de confs qui vont bien (ça peut être complexe ailleurs, ou pas, j'ai vu de tout).
Tu veux configurer des cgroups ? Ben va falloir lire la doc du noyau Linux à ce sujet, parce que tu ne trouveras pas grand chose de spécifique à Slackware par là.

Et donc si pour faire fonctionner un logiciel, tu te réfère à la documentation de ce logiciel et non à la documentation Slackware, et bien tu vas apprendre à faire fonctionner ce logiciel de manière générale, pas à le faire fonctionner spécifiquement sous Slackware.

Tu vas me dire que c'est le cas un peu partout, et ce n'est pas faux, mais en fait sous Redhat et Debian tu as une couche d'abstraction du paramétrage des applications pour standardiser au maximum.
L'intérêt c'est que quand tu découvres un nouvel outil, sa configuration va être formatée un peu comme tous les autres logiciels sur ton système, tu vas tout de suite retrouver tes petits, et ça permet d'avoir des outils de configuration génériques, des interfaces de configuration qui vont permettre de cliquer sans rien savoir des fichiers de conf, ou de comment ça fonctionne en dessous.
C'est génial hein ce genre d'outils, je ne vais certainement pas dire le contraire !
Mais ça ne t'apprends pas le paramétrage spécifique de tel ou tel outil, ça t'apprends juste où cliquer sur ton OS spécifique.
Tu gagnes plein de temps, et pour tous les gens qui n'ont pas envie de se prendre le choux, et préfèrent juste utiliser sans chercher trop profondément, c'est super !

Et tu apprends à utiliser ta distribution, mais pas spécifiquement chaque outil, pas Linux en général, mais ce que ta distribution te présente.
Et si ça ne te convient pas, il faudra mettre les mains dans le cambouis, et ça sera moins simple que sous Slackware (ou au mieux aussi compliqué) parce que tu vas devoir comprendre la configuration de cet outil spécifique, mais aussi comment cette configuration est adaptée et formatée dans ton système à toi.

--

J'espère que ces explications éclaireront mon propos, et surtout permettront aux gens de comprendre qu'il n'y a aucun jugement ici entre si telle ou telle vision est meilleure qu'une autre.
Ce sont des choix, des philosophies, différentes.
Pas très conciliables dans le sens où un outil graphique d'administration Debian n'a a peu près aucune chance de fonctionner sous Slackware.
Et c'est aussi dans ce sens où je pense (je pense) que systemd ne suis pas la philosophie Slackware, puisque ça centralise et formatte les configurations des logiciels, pour permettre de les gérer tous de la même manière avec des outils automatisés par dessus.
Je ne crois pas qu'on y gagne en simplicité au bout du compte, je crois même que c'est le contraire.
Je crois
Mais peut-être est-ce pur conservatisme de ma part.
En tout cas je passe mon énergie à faire complètement autre chose que de savoir comment administrer mes Slackwares, c'est un problème résolu depuis longtemps et qui fonctionne suffisamment bien pour que je ne voies pas du tout pourquoi j'irais tout casser.
Et de toute évidence, Patrick Volkerdig et les autres membres de l'équipe Slackware sont du même avis que moi.
Alors je suis content :)

• Yth.

Vous vous en foutez, mais il y a 6 fois "systemd" dans votre post. C'est très cohérent. Hein?

Aaah, les chiffres !
3 lignes sur 73 avec ce mot, ça fait pas bien lourd quand même…
Dans un paragraphe qui dit deux choses :
- la version stable n'introduit pas de changement dans son mode de fonctionnement comme le serait celui de passer à systemd, qui force - personne ne me contrediras là-dessus quand même ? - à changer complètement ses habitudes d'administration de la machine - idem pour PAM par exemple.
- la prochaine version sera aussi sans systemd parce que en gros on s'en fout, c'est une non-question, et le côté conservateur de la Slackware fait qu'un changement aussi radical et non nécessaire n'est pas intervenu - mais la prochaine sera avec PAM.

Là dessus, des gens s'emballent en croyant que je critique systemd en disant que c'est de la merde. Bigre, j'en sais rien, je l'utilise pas ! Mais je suis plutôt content de me préoccuper d'autres choses que de cet appeau à trolls lors de mes migrations vers la 15.0.
Je n'ai pas envie de changer ces habitudes là, je préfère continuer à construire sur la même base toujours aussi solide qu'est celle de la Slackware.

Franchement, la configuration déclarative, j'en bouffe des kilomètres au boulot avec des yaml, mustache, jinja2, et cie, je ne suis pas bien convaincu qu'on y gagne majoritairement en efficacité, en maintenabilité, ou même en lisibilité.
C'est aussi un gros effet de mode, et quand il sera décanté, on verra où ce paradigme est pertinent et où il n'apporte rien, voire pire.

Mais c'est exactement comme la mode du XHTML à l'époque, tu te faisais insulter si t'étais pas XHTML strict, quel soulagement d'avoir vu arriver HTML5…

Unicode n'est toujours pas par défaut.

Ah ouais, parce que l'équipe ne s'engage pas sur le fait que tu n'aies pas certaines man-page qui déconne si t'es en UTF-8 dans la console, y'aurait pas d'UTF-8 dans la Slack ?
J'ai toujours activé l'unicode dans la Slack, depuis 20 ans locale=fr_FR.UTF8, ça ne m'a jamais vraiment posé de soucis (fut un temps, xterm déconnait passablement beaucoup, mais bon, xterm quoi, y'a d'autres alternatives).
Mais lis mieux l'article en question, qui indique que la Slack est English-centrée, tout ce que ça veut dire c'est qu'aucun effort particulier n'est fait pour localiser la Slack en autre chose que l'anglais.
Et après tu as plein d'explications sur comment en fait c'est pas vrai, et que tout est là, mais bon, mets un peu tes mains dans le cambouis, on t'a prévenu, c'est la Slackware, va falloir retrousser un peu tes manches (et éditer environ 3 fichiers texte, et télécharger toi-même ton dictionnaire français pour libreoffice et ton grammalecte pour firefox).
En plus, c'est de la doc générique qui ne bouge pas, je ne sais pas quand cette page a été modifiée la dernière fois, ou si quelqu'un s'est posé deux minutes la question de savoir si cet avertissement antédiluvien était toujours pertinent.

Ceci dit, je m'en fous, j'utilise pas Slack.

Bah tout va bien alors :)
C'est pour ça qu'il y a des centaines de distribution !
Et tu me reliras : je n'incite personne à quitter sa distrib préférée pour venir sous Slackware, je présente ma vie avec cette ditrib.
Ma vie avec UTF-8, clairement, à 100%, pour tous mes logiciels hein, et sans effort particulier (1 fichier de conf pour tout passer en français UTF-8 par défaut, je n'appelle pas ça un effort particulier).

Donc, systemd, on s'en fout en vrai, c'est un non-problème, un logiciel comme un autre, un choix comme un autre.

Donc arrête d'en parler.

Passif-agressif ?
Détends-toi, zen, on peut parler aussi de choses sans conséquences, on peut expliquer calmement aussi qu'un choix ou un autre n'est qu'un choix.
Ce n'est pas :

Il y a des conservateurs qui ne veulent pas suivre le "progrès" (<= guillemets), parfois ils ont raison, parfois tort.

Et souvent : on s'en fout, il s'agit juste d'un choix.
Ce n'est pas parce que postgreSQL est plus puissant que mariaDB que tout le monde doit obligatoirement passer du second au premier, sous peine de ne pas suivre le « progrès ».
Ce n'est pas parce que NginX est plus récent, et peut dans certains cas être significativement plus véloce qu'Apache, que de rester sous Apache est refuser le « progrès ».
Ce n'est pas parce que git que mercurial == refuser le « progrès ».

Il faut la comprendre la notion de choix hein…
La travailler pour bien l'intégrer.
Le choix, c'est que si mon voisin fait pas le même que le mien, bah je m'en fous, c'est son choix. Et en général il y en a rarement un qui est résolument meilleur que l'autre (sauf quitter Windows/Mac pour passer à Linux, mais bon :p ).

Bises,

• Yth.

Comme le dit Barmix juste avant moi : cgroup v2 c'est une API Linux.
Pas une API systemd, qui - doit-on le rappeler ? - n'est au final qu'un système d'initialisation d'un OS GNU/Linux…

Pour autant que je sache, systemd s'appuie sur Dbus, qui fonctionne sans, ou avec, systemd.

Un firewall applicatif ou autre n'a pas besoin de systemd pour fonctionner et exploiter pleinement le potentiel du noyau Linux.
La possibilité d'un userID dynamique est forcément une possibilité offerte par le noyau Linux, et peut obligatoirement se faire sans passer par systemd.

Si on fait du spécifique Linux, c'est en général pour faire des interfaces envers les possibilités offertes par le noyau Linux spécifiquement. Le firewall entre exactement dans cette catégorie, car les flux réseaux sont gérés au niveau du noyau Linux, et tout firewall n'est qu'une interface vers ce que le noyau propose pour gérer, filtrer, modérer, ou limiter ces flux réseaux.
Si tu construits une couche d'abstraction Linux, BSD, ou autre, tu peux avoir un firewall qui va fonctionner sous plusieurs noyaux différents, s'appuyant sur chaque API noyau spécifique.

Et dans tout ça, systemd, le truc pour initialiser ton système, ben on s'en fout.
Quelle importance que ce soit lui ou un script shell à la con qui lance le logiciel, tant qu'il est lancé ?
systemd c'est pas de la fonctionnalité, c'est de l'administration !
Ça peut - ou non - simplifier l'administration de ton OS, ou la standardiser d'une certaine manière, mais ça n'enlarge pas ton Linux qui peut tout faire avec ou sans systemd.

Donc : on s'en fout !
systemd c'est un choix, si tu veux tu peux, si tu veux pas tu peux ne pas.

• Yth, j'ai le sentiment vertigineux de me répéter…

Et ce que je dis en disant qu'on s'en fout un peu du système d'init c'est aussi exactement le fait que ça impacte assez peu, et en général pas du tout, les logiciels…

Barmic me fait dire précisément l'inverse de ce que j'ai écris.

Mais bon, dès qu'on parle de systemd, les gens cessent de se lire les uns les autres et se clivent immédiatement.

Passons…

• Yth.