Yth a écrit 2671 commentaires

Et si les données sont sur ton téléphone uniquement, je pense aussi que le 5eme amendement s'applique (eg, le droit de ne pas s'auto incriminer).

Et en l'occurrence, l'appli à laquelle je pensais, que j'ai retrouvé, s'appelle Periodical, et est hors connexion, aucun serveur, que pouick, tu la vires et il n'y a plus de traces.

• Yth.

Mais cette question a déjà une réponse !

Dans la loi : avortement possible jusqu'à 14 semaines de grossesses, l'amas de cellules n'a pas son absence de mots à ne pas pouvoir communiquer.
Au delà de 14 semaines, IVG impossible (on peut entrer dans le cadre de la médecine : sauver la mère en perdant le fœtus, etc, mais ce n'est pas un IVG : le V étant pour Volontaire).

Voilà, t'as ta réponse.
Et elle peut évoluer, on peut - et on doit - continuer à se poser des questions éthiques, morales, philosophiques, médicales, sociétales, etc. Ça a d'ailleurs évolué récemment puisqu'on est passé de 12 à 14 semaines.
Mais ces considérations ne doivent pas remettre en cause ce droit à l'IVG, simplement ses modalités.

• Yth.

Les applis se financent avec la pub, l'arrivée d'un enfant entraîne des dépenses, c'est un marché spécialisé, donc il y a de la demande.

Et comme d'hab, il existe au moins une alternative libre sur f-droid !
Sans pubs, respect de la vie privée, bref, vous connaissez la chanson.

• Yth.

Oui, même si Margaret Atwood en a été la première surprise, mais pas tant que ça.
Un peu comme Georges Orwell.

Faut arrêter avec ces romans dystopiques, ça donne des idées aux fâcheux en fait…

• Yth.

Ah non, pas philosophique du tout.
Le droit à l'avortement, ce n'est pas la porte ouvert à tomber enceinte toute les trois semaines, se faire avorter, et faire portnawak !

Alors oui, assez souvent de jeunes femmes, ou filles, tombent enceinte sans l'avoir prévu parce qu'elles ne font pas gaffe, jeunesse tout ça.
Mais aussi, la contraception peut foirer, et on peut avoir de vraies bonnes raisons légitimes de l'utiliser et de ne pas vouloir d'enfants (ou pas plus d'enfants).
Et puis il y a le cas du viol.
Et le cas où la grossesse peut médicalement être fatale à la mère pour tout un tas de raisons.

Bref, plein de situations où la question de l'avortement se pose, en termes médicaux, sociétaux, éthiques, financiers, mais pas spécialement philosophique.
Il n'y a pas d'obligation de l'avortement, jamais, mais simplement la possibilité de se poser la question et d'agir en conséquence. La philosophie, les croyances, les principes, etc. n'interviennent que là, au moment du choix.

L'IVG a toujours été encadré, assez clairement.
Il n'est pas, n'a jamais été, et ne sera jamais question d'avorter toutes les femmes, il s'agit juste de leur laisser le choix, et de leur donner la possibilité, le cas échéant, de le faire dans de bonnes conditions.

C'est un problème de société, et de santé publique, bien plus qu'une question de philosophie.

Retirer ce choix c'est imposer une vision du monde à la moitié de l'humanité.
Juste à la moitié : les femmes.

C'est donc indubitablement une restriction des libertés des femmes par rapport aux hommes, une perte d'égalité entre les hommes et les femmes.
Et ça sert entre autre aux principales religions monothéistes (dogmatiques), à persister à donner une place inférieure à la femme.
Entre autre à persister dans un monde patriarcal ou les femmes sont moins égales que les hommes.

Et déjà qu'on est encore loin de l'égalité entre les sexes (quels qu'ils soient), si on creuse l'écart, ben on n'est pas rendu. Et le passé a prouvé qu'il est facile et rapide de revenir en arrière sur des acquis peut-être pas si acquis que ça, et que de fait il ne faut jamais rien lâcher.

Cela étant dit, mon opinion - toujours très optimiste, je suis comme ça - est qu'il s'agit des soubresauts d'un mode de pensée à l'agonie, une reculade qui finira par disparaître et entrer dans l'Histoire.
Tout comme la Restauration et le second Empire n'ont été que des soubresauts d'un monde révolu, face à l'irrémédiable progression de la République, qui est aujourd'hui une simple évidence (jusqu'à ce qu'on trouve vraiment mieux).
Tout comme la manif pour tous n'est que le reflet d'idées passées et ne peut rien contre le fait que ces idées sont effectivement passées. Je ne fais pas beaucoup de différence entre ces gens qui voudraient me dire que je ne peux pas vivre en couple (ou non) avec qui je veux, qu'avec d'autres gens qui me conchient parce que je cuisine végétarien dans ma maison, ou d'hypothétiques personnes qui penseraient que je devrais manger mes œufs par le petit bout plutôt que le gros bout. C'est pareil : ça les regarde pas, faites comme vous voulez chez vous les gens, je continuerai de faire comme je veux chez moi !
C'est quoi cette idée de vouloir dicter comment vivent des autres qu'on ne rencontrera jamais et qu'on ne verra jamais, et à qui on ne parlera jamais ?

Un enfant vivra plus heureux s'il est voulu, quels que soient les sexes de ses parents (ou de son parent tout seul hein), qu'un enfant non voulu, voire - pire - imposé parce que le droit à l'IVG a été flingué par des imbéciles réacs.
Si vraiment c'est le bonheur des enfants et l'avenir de la société qui les motive, alors ils devraient plutôt lutter pour le droit à l'IVG.

• Yth.

Un peu comme l'« intelligence artificielle ».
En anglais ils sont tellement second degré sur la notion d'intelligence qu'ils ont carrément de la « military intelligence » !

C'est dire s'ils ont de l'humour.

• Yth.

Je trouve ça spoilant ces discussions.

• Y.

Si la grossesse a été démarrée dans un état anti-avortement, ils peuvent dire que la femme a enfreint la loi en allant se faire avorter ailleurs, et l'interpeller au retour.
Ou dans la logique du pro-life, dire que le fœtus étant d'ores et déjà résident légal de l'état et qu'il a été assassiné dans celui d'à côté…

Et en fait le problème n'est même pas que le procès aboutisse, soit gagné par une partie ou par l'autre. C'est surtout ce que ça fait subir à l'accusée, qui fera peut-être de la préventive plusieurs années en attendant le procès qui traînera forcément, bref la vie brisée, même en cas de victoire.
Et donc la plus grande difficulté pour d'autres femmes de faire pareil, puisqu'on va largement au delà de la difficulté première de voyager à temps.

C'est un pays très légaliste, où les procès sont lancés pour un oui ou pour un non.
Le service législatif là-bas, ça fonctionne comme une assurance : tu évalues les pertes et profits probables, et au final ce genre de procès sont une forme d'investissement pour par exemple rendre l'accès à l'avortement plus difficile.

Le respect de la loi est très secondaire : est-il plus rentable de l'enfreindre et d'en profiter à mort tant qu'on s'est pas fait chopper, et de payer la taxe à l'arrivée, ou de rester dans les clous ?

• Yth.

Ce projet est au niveau fédéral.
Aujourd'hui, le droit à l'avortement est constitutionnel au niveau fédéral, donc les états n'ont pas leur mot à dire.

Demain, si le projet actuel abouti, l'état fédéral ne contraindra plus les états.
Chaque état pourra alors choisir de construire une législation anti-avortement.
Ou de conserver les choses comme elles sont aujourd'hui.

Et il y a déjà une douzaine d'états qui ont adopté ce genre de lois aujourd'hui, même si elles sont inapplicables puisque tout procès serait forcément perdu, vu que ces lois enfreignent les décisions fédérales, ce qui risquerait de rendre la loi caduque. Autant attendre que la loi puisse être appliquée pour ne pas avoir de précédent judiciaire, et ne pas avoir à tout recommencer.
Cela dit ça n'est déjà pas sans conséquences au quotidien, avec des dénonciations publiques et autres saloperies. Oui, il fait assez mal vivre en femme moderne (et pas riche, les riches ont tous les droits aux USA) au Texas en ce moment.

En pratique, ça n'empêchera pas les femmes d'aller avorter dans l'état d'à côté - si elles en ont les moyens, ou si de manière générale elles peuvent se permettre de s'en aller - par contre selon les cas il n'est pas impossible qu'elles puissent encourir des poursuites pénales si elles reviennent.
Ça pourrait vouloir dire un exil permanent hors de son état d'origine, et potentiellement hors des états qui auront adopté une telle loi.
Et il n'est pas dit que ça empêche des poursuites d'un état à un autre, sous tout un tas de prétexte du genre la grossesse a été entamée ici, c'est la loi d'ici qui prévaut, etc.
Ici aussi, pas dit que ces poursuites aboutissent, mais ça peut briser des vies, et rendre la démarche mentalement plus difficile : aller à côté pour avorter-et-se-tanner-des-années-de-procès ?
Le package complet est un peu brutal.

Bref, ça serait une authentique et sérieuse régression du droit des femmes dans « la plus grande démocratie du monde ».

• Yth.

Ouais, cliquer partout, par période, ou indiquer pour tout que cette publicité ne nous intéresse pas, par période.
Mais on gagne du temps à juste s'en aller et penser à arroser son adblock :)

• Yth.

Ça fait 18 ans que je traîne mes gros doigts ici.
Je poste des commentaires.
Je pertinente, j'inutilise, parfois.
Je trolle, j'anti-trolle, je corrige, je répond, je me méprend, j'agace, et parfois on aime ce que j'écris.
Et si je m'engueule avec un pseudo, la semaine d'après j'ai oublié avec qui, et on peut discuter de pseudo à pseudo sans arrière-pensée, et être d'accord ce coup-ci (ou pas, si c'est un pseudo-con, on va jamais s'entendre, vu que je suis un vrai con).

Fondamentalement je ne connais personne sur LinuxFR.
Je n'ai pas spécialement d'amis ou de contacts sur LinuxFR.
Je n'y cultive aucun réseau.
J'y trouve des projets, des idées, de la veille, des discussions intéressantes, d'autres moins.
J'y trouve des choses.

Mon compte Facebook a duré quelques années - trois peut-être quatre - et il m'a apporté la possibilité de mettre à jour ma liste de date d'anniversaire des copains, chose que j'aurais pu faire plus simplement. Et le plaisir de flinguer les outils de pubs ciblés en faisant n'importe quoi, sans jamais cliquer sur le moindre truc qui pouvait m'attirer.
Ça ne dure jamais qu'un temps de faire le con avec une machine qui s'en fout royalement, j'avais mieux à faire.
Jamais je n'ai ajouté comme contact quelqu'un que je n'avais pas rencontré en vrai, mais franchement, c'est plus pratique de ne pas avoir Facebook pour cesser de voir certaines personnes, qui sans ça resteraient là dans une liste d'« amis » poussiéreuse, et nous rappelleraient indéfiniment de nos mauvaises rencontres… Oui, je sais, on peut les virer, mais c'était moins d'effort de fermer le site et ne plus jamais le rouvrir, du jour au lendemain.
Aussi facile que de garer la voiture aux confinements et de l'oublier plusieurs mois.
Et ça me serait le même déchirement d'y retourner que j'en ai à redémarrer le moteur pour aller faire des réunions Teams dans un open-space à la con, plutôt qu'avec mon chat sur les genoux.

Franchement, ça n'a rien à voir, il n'y a aucun élément de comparaison entre LinuxFR et Facebook, outre le fait qu'on puisse écrire du texte sur les deux (mais je peux faire ça sur les murs de mon village aussi).

• Yth.

Ben de mon point de vue, aujourd'hui, j'ai rigoureusement zéro arguments pour convaincre qui que ce soit de passer à du XMPP propre, libre et respectueux.
En gros mon argumentaire c'est « si tu veux causer avec moi, ajoute une énième appli, sachant que de toute façon j'ai déjà cédé et j'ai Signal comme toi. »
Autant dire que ça ne risque pas d'aboutir.

Alors qu'il y a 20 ans, quand j'étais déjà sur jabber.org, et que j'avais des contacts sur MSN, gtalk, facebook messenger, et que je pouvais causer à tout le monde en direct, ou via des passerelles (pour MSN), bah j'avais convaincu des gens d'utiliser des clients moins pourris et mieux foutus, libres et tout.

Et puis les réseaux se sont séparés, et je n'ai presque plus de contacts sur XMPP.

Avec l'interopérabilité, je vend mon âme sur un compte spécifique connecté aux réseaux vampires, mais je peux convaincre des gens d'utiliser d'autres applications, je vire mon Signal et conserve mon Conversation/Psi/Xabber/Movim/etc. et sans perdre mes contacts.
Et j'ai des arguments :
- mon appli est moins lourde et fonctionne mieux ;
- en plus elle respecte ta vie privée, (même si tu resteras connecté au mal) ;
- c'est du logiciel libre ;
- etc. on peut en trouver après selon les personnes, ce qui va (ou pas) faire mouche.

Et franchement, le coup de la connexions aux réseaux vampires se pose déjà avec le mail.
Tu fais quoi, tu filtres les mails @gmail, @yahoo, @live, @etc. pour être déconnecté de ces réseaux ?
En général, non.

• Yth.

Un mail coûte plus qu'un ticket de caisse ?
Bigre…
Dans quel monde ?

Donne des preuves crédibles, des ordres de grandeurs au minimum, parce que là, sérieux, j'ai juste envie de pointer la faille dans l'éventuel raisonnement…

• Yth.

Voyons, puisqu'on vous dit qu'il s'agit d'un séminaire corporate pour renforcer l'esprit d'équipe et la camaraderie, les valeurs communes, la culture d'entreprise étatique, voir du pays, rencontrer des gens qui ont plein de choses à partager, les tuer, etc.

Rien à voir avec une guerre, allez, circulez.
Et comme dit Vlad : « Si tu m'embêtes, je te balance mes nukes dans le fion, lol ! », tu vois : lol, c'est bon enfant, non ?

Et ça, les organisateurs de séminaires corportate de culture d'entreprise et d'esprit d'équipe de chez Alphabet l'ont bien compris, c'est leur B-A BA d'ailleurs chez Alphabet : « Don't do evil things not related to more brouzoufs. » (dont on a parfois omis la fin de la phrase par commodité éthique, taille d'un twit, tout ça, toussa).

• Y.

Dans mon exemple il n'y a pas de Jinja2, non.
Mais remplacer des bidouilles Jinja2 par du python rend les choses plus claires : moins de mélange de genre entre descriptif et impératif.
Et dans les cas simples, ça ne change pas grand chose non plus, comme montré dans mon exemple : il faut quand même avoir une documentation des différents modules et de leurs paramètres, de la syntaxe générale, etc.

Mais bon, mon questionnement ne tient pas tellement de comment il convient d'utiliser l'outil, mais plutôt d'une tentative de divination : comment ça va évoluer, au vu de comment c'est utilisé aujourd'hui ?

• Yth.

Trop simple, trop compliqué…
Ton exemple est trop simple pour représenter un cas réel.
La réalité te confronte rapidement à des structures de données un poil plus complexe qu'un dictionnaire de deux listes de trois éléments, avec deux clé/valeur au bout.

Et là… Là ça devient très vite illisible.
Mais en vrai, du Python avec de forts degrés d'indentations et sans découpage du code, c'est insupportable aussi. En fait n'importe quel langage.
Et pour le coup une syntaxe ouvrante/fermante est plus lisible (même si parfois marginalement).

Sauf que, pour des états, des structures de données, la complexité peut être normale, alors que dans du code source, la normalité est de faire des fonctions, de la factorisation, pour garder des ensembles cohérent de code assez petits, et sans trop de niveaux d'imbrication.

Et un include task bidule en yaml ansible, qui exploite des variables héritées sans prendre de paramètres, te donne rapidement un sac de fichiers imbitables à dérouler.
Donc tu fais quoi ? Tu essaies d'être plus explicite, de passer des paramètres à tes sub-tasks, de faire de boucles, … de programmer ta description d'état…

Et tu sors du templating descriptif pour entrer dans le templating crados.
Et là parfois tu te demandes bien pourquoi tu n'es pas en train de coder directement en Python.
La différence entre :

tasks:
- name: "install Apache server"
yum:
name: "httpd"
state: latest

Et :

tasks(name="install Apache server").yum(name="httpd", state="latest")

Est moins évidente, mais permettrait d'éviter la « programmation en Jinja2 ».

Mais bref, je trouve que c'est une dérive qu'on retrouve un peu trop dans Ansible, un peu sur le principe de quand on a un marteau, tous les problèmes ressemblent à des clous, si on a déjà une infra Ansible en place, on a envie de tout faire en Ansible.
Et cette dérive me fait penser au PHP des années 2000.
Le PHP des années 2000 a abouti au PHP 8 d'aujourd'hui, qui est efficace et fonctionnel, rien à dire de ce côté là, donc ce n'était pas forcément un mal en soi, juste une phase d'adolescence brouillonne et qui a laissé des traumatismes.

Mais quelle adolescence aujourd'hui dans Ansible, qui a clairement dépassé le stade de la prime jeunesse ?
Quelle stabilité sera conquise dans le futur, quelle évolution attendre ?
Puisque le côté outil simple et descriptif d'un état clairement énoncé ne suffit pas (sinon on n'aurait pas les dérives que je décris, et décrie), quelle est la réponse ?

Ansible doit-il se contenter d'être un outil de description d'état désiré, ou doit-il évoluer vers un outil de programmation distante comme on peut le voir de plus en plus ?
Et s'il évolue vers un outil de programmation distante, quelle évolution du couple yaml/Jinja2 ? Un autre format plus adapté à côté, ou des hacks imbitable qui finiront par donner un langage de programmation originellement pensé pour faire du templating, et qui deviendra utilisable dans 10 ans ?

Le parallèle avec PHP 3 se fait exactement ici, on est dans la période brouillonne et crados, et on est en train de construire les traumatismes futurs.
Mais quel futur est souhaitable ? Quel futur sera construit ?

• Yth.

Ah mais Yaml, couplé avec Jinja2, c'est le PHP des années 2000 all-over-again.
PHP c'est - à l'origine - un préprocesseur de HTML.
Sauf que c'est incidemment un langage turing-complet.

Et on est passé du templating sympa au templating crados pour dépasser le templating, puis à l'application web mal foutue bourrée de trous et impossible à maintenir, et enfin aux applications PHP modernes qui sont quand même mieux faites, mais n'ont rigoureusement plus rien à voir avec le pré-processing des origines.

Et là, quand on fait du Ansible avancé, on se retrouve à voir des trucs qui ressemblent au passage du templating sympa, au templating crados.
Par pur chance on a les modules, généralement en Python, qui permettent de ralentir le passage à l'application ansible mal foutue fondée sur un langage de templating descriptif…

Et franchement, faire de la programmation en Yaml/Jinja2 c'est du pur masochisme, sadique pour le reste de l'équipe.
Sauf qu'il faut trouver le bon curseur entre complexificatifier son module pour gérer plein de cas, et traiter des cas différents depuis un bout de programmation Yaml/Jinja2, ce qui n'est pas toujours d'une complète évidence.

Au bout du compte, dès qu'on commence à vraiment gérer des choses compliquées en Ansible, c'est terriblement difficile à lire et à maintenir :(
Alors passer des arguments depuis un Job Jenkins à un playbook Ansible, qui appelle des rôles, et eux-mêmes des modules internes, c'est un champs de mine terrifiant à débugger pour savoir pourquoi cette p$£*% de variable a pas la bonne valeur là, bigre !

En plus j'ai une question subsidiaire :
La syntaxe du Python est basée sur l'indentation, et ça rend presque forcément le code lisible, qu'on aime ou pas, le code Python se ressemble et avec de l'habitude on arrive même à lire le code de Pierre T.
La syntaxe de Yaml est basée sur l'indentation, et ça rend presque forcément le résultat illisible, qu'on aime ou pas, le code Yaml se ressemble, et même avec de l'habitude il faut s'y reprendre à plusieurs fois pour bien savoir quelle est la structure représentée.
Pourquoi ?
Ou plutôt : Comment avoir autant raté son design ?
Comment réussir au final à être moins lisible que du bête JSON qui n'impose rien en terme de présentation du code ?

Bref, Ansible, si je pouvais m'en passer, ça serait volontiers.
cela dit, le journal est clair et bien présenté, j'approuve totalement, merci JulienG !

• Yth.

Alors pour ça, je profite de mon avantage indu d'être né avec un pénis entre les jambes.
Le salon est à 5 minutes à pieds et c'est 16€ la coupe Homme.
C'est franchement pas rentable, vu la différence de qualité du résultat, de le faire moi-même !

Je trouve ça abominablement sexiste que, par principe juste comme ça, ça soit plus cher pour les femmes que pour les hommes, et j'en profite sans vergogne aucune, alors que j'ai une sacrée toison et pas un soupçon de calvitie naissante…

Et moi non plus je ne vois pas pourquoi mon absence de seins change le tarif, de toute façon rien de tout ça ne pousse sur le haut du crâne.

• Yth.

Désolé, je ne sais pas, j'utilise depuis 15 ans un outil bash maison pas super user-friendly, mais que je fais évoluer selon mon bon plaisir.
J'essaie de terminer la V3 en mode propre, en python parce que la maintenance des bonnes idées en bash est parfois cauchemardesque, et compatible avec certains formats de fichiers utilisés par d'autres outils d'admin slackware comme hoorex, mais ça n'avance pas vite…

Bref, je n'utilise pas certains outils dont je vante les mérites ^{^}

• Yth.

Mon avis sur la question des résolutions de dépendances est que je ne m'embête plus trop :
J'installe une Slackware complète - éventuellement sans les catégories kde ou xfce, voire xap et x pour un serveur - et hop, la résolution de dépendances est terminée : ça fonctionne.
Pour gérer le multilib (sur les machines où ça sert, en général c'est pour jouer), c'est le dépôt d'AlienBob, ajouté à slackpkg grâce à slackpkg+.

Ensuite pour les slackbuilds, je n'utilise pas de dépôt tiers comme Slacky ou AlienBob (sauf son excellent ungoogled-chromium pour les trois fois dans l'année où j'ai besoin d'un chrome-like), mais je compile moi-même, avec un outil comme sbopkg, pour gérer la file d'attente de construction, et les dépendances.

Cela dit slpkg est créé par un contributeur très actif du projet slackbuilds.org, et fait partie des divers outils recommandés pour gérer sa Slackware si on ne se contente pas de slackpkg.

• Yth.

Glossaire :
pkgtools : le gestionnaire de paquets bas-niveau de Slackware, celui qui permet d'installer, mettre à jour, supprimer, et lister les paquets Slackware.
slackpkg : gestionnaire de mise à jour automatique, qui va chercher les infos du dépôt Slackware sur internet, te liste les nouveaux paquets, les mises à jour etc, et permet de tout mettre à jour en une seule commande.
Slackbuilds : un fichier .SlackBuild est un script permettant à partir des sources d'un paquet de compiler et générer un paquet Slackware. Le projet slackbuilds.org maintient près de 8000 slackbuilds pour étendre sa Slackware dans tous les sens. La Slackware elle-même crée ses paquets à partir de SlackBuilds gérés par l'équipe. Slackbuilds.org part du principe que tu as une installation complète et à jour d'une Slackware stable : là-dessus tout le dépôt s'installe, et la gestion de dépendance ne prend pas en compte les paquets considérés comme présent via Slackware.
slackpkg+ : un plugin pour slackpkg permettant de gérer plusieurs dépôts de paquets, en plus du dépôt Slackware principal, comme par exemple multilib, alienbob, slacky, ou un répertoire personnel de slackbuilds produit soi-même, il permet aussi de lister les slackbuilds correspondant à une recherche par nom par exemple, mais sans gérer leur construction.
sbopkg, sbotools : Outils permettant d'automatiser la construction de paquets Slackware (avec dépendances) à partir du projet slackbuilds.org.

Quelle idée aussi d'être une femme qui invente des choses utiles aux femmes, alors qu'elle est afro-américaine durant la période des Lois_Jim_Crow aussi…

• Yth, qui vient de se vider une belle rasade de cynisme, heureusement le monde a un peu évolué depuis, un peu.

Oui, je l'ai raté, j'ai pris le train fin 1999, à la sortie de la 7.0.
Sachant que j'ai eu mon premier ordinateur a moi en août 1999, et ma première connexion internet stable et régulière en septembre de la même année, je n'avais pas spécialement eu l'occasion de découvrir l'univers Linux avant…

Mais ça m'avait bien fait rigoler à l'époque :)

• Yth.

J'approuve :)

Et il faut plus lutter pour les standards ouverts, les normes claires etc.

Plus haut dans ce fil, il y a un débat entre applis webs et applis natives.
J'ai un exemple à donner : le mail.
Tant qu'il est basé sur des protocoles ouverts, documentés, libres etc. alors il n'y a pas à choisir et on peut faire cohabiter les deux, on peut aussi bien avoir des applis webs et natives, et conserver le choix.

Dès que c'est fermé, comme Exchange par exemple (qui n'est pas du mail), on perd ce choix, le navigateur devient incontournable, ou alors l'application proposée par microsoft (et bourrée de saloperie, pas libre, mal foutue, etc.)

C'est valable pour le RSS aussi : format ouvert, on peut avoir une appli native ou un outil web. Du libre ou du propriétaire, et chacun choisit, sans empêcher les autres de faire un choix différent.
Et il y a plein d'exemples dans les deux sens…

Les formats, les protocoles, c'est le plus important.

• Yth.

Ça me casserait vraiment les pieds en tout petits morceaux si je devais redémarrer mon serveur X tous les trois jours plutôt qu'exclusivement lors des mises à jour d'icelui, ou du noyau (qui impliquent un reboot, mais si je pouvais rebooter le noyau sans rebooter X, je serais content !).

Donc la métrique n'est pas inintéressante : il y pléthores d'addons pour rendre plus facile le reboot du navigateur web.
La fonctionnalité qui tue et n'est pas dans un addon et ne sera pas supprimée de sitôt, c'est de restaurer la session précédente au redémarrage.
Bref, il y a énormément d'efforts faits dans les navigateurs (FF, mais Chrome c'est pas mieux), pour que le reboot du bouzin soit transparent, parce que le bouzin en question est condamné a une courte existence…

La métrique n'est pas si absurde : elle conditionne ta façon d'utiliser l'outil.

• Yth.

Je suis partagé sur cette évaluation, mais bon, je n'ai pas l'habitude de lire les trucs sur distrowatch…

The distribution is a slow moving project, often with several years between releases.

Cette distribution évolue lentement, avec souvent plusieurs années entre deux versions.

Cette distribution a deux versions : une stable qui sort quand elle est prête (un peu comme Debian), et une rolling-release très active.
En 27 années et demi il y a eu 13 versions stables de Debian et 36 versions stables de Slackware.
On voit clairement un changement de rythme depuis la 14.1 (2,5 années) et la 14.2 (5,5 années), mais souvent il y a entre six mois et un an entre deux versions, pas « several years ».

Bon, c'est un brin agaçant quand on commence par des âneries, j'aurais pu lire un truc comme « on croyait que ça n'avançait plus vu que le rythme habituel a été dépassé de 5 ans, ce qui est très long en informatique », mais en vrai, jusqu'à la 14.1, c'était un projet plutôt rapide est dynamique.
Je ne peux qu'espérer que ça redevienne le cas.

Slackware has a well deserved reputation for stability
and for having a simple technical design.
A design which frequently ignores modern approaches to system management.
Slackware still uses a text-based system installer,
has 90s-era approaches to package management,
and prefers editing text files over graphical tools when it comes time to adjust most configuration settings.

Slackware a une réputation mérité de stabilité
et d'avoir un design simple/épuré.
Un design qui ignore généralement les approches modernes de l'administration système.
Slackware continue d'utiliser un installateur en mode texte.
a une approche très années 90 de la gestion de paquets,
et choisit l'édition textuelles de fichiers plutôt que des outils graphiques pour la configuration plus fine.

J'ai encore une fois le sentiment que « ignorer les approches modernes de l'administration système » est juste une façon de dire qu'il n'y a pas systemd. On en pense ce qu'on veut, mais je ne vois toujours pas systemd comme un passage obligé, ni un truc si révolutionnaire que ça. Bref, passons…

Concernant l'installateur en mode texte, fichtre, mais et alors ?
C'est l'outil pour installer le système, le truc que tu vois une fois par nouvel ordinateur, le reste se fait en mise à jour, et on ne revoit plus jamais cet installateur.
Comme si, pour être « moderne », il fallait absolument avoir un outil à l'utilité marginale en version graphique ?
Alors que le seul intérêt d'un tel outil est de faire bonne impression pour un public de néophytes.
Que de préjugés alors…

Le gestionnaire de paquets de Slackware date des années 90.
Mais bon, dpkg date de 1994, RPM de 1997 (1995 en interne chez Redhat), ce sont aussi des gestionnaires de paquets datant des années 90.
Tous les trois ont évolués depuis, il y a eu des versions pour chacun d'entre eux, et il existe des outils plus haut niveau pour l'administration des paquets, pour les trois, y compris des interfaces graphiques (oui oui, même pour Slackware !).
Donc : critique ou gage de qualité ? Ou rien à voir avec la choucroute ?

Et la dernière phrase est juste, sous Slackware l'approche éditeur de texte dans un terminal est préférée à l'approche cliquesque, c'est à dire la façon de faire pour la majorité des serveurs : on n'accède pas à un outil graphique pour administrer un serveur, mais on le fait avec un vi/nano/joe quelconque à travers SSH.
Et même en 2021 on continue de faire des erreurs de copié-collé liés à des sauts de ligne probablement liés à l'utilisation de ce genre d'outils en ligne de commande via SSH… Je doute que Facebook utilise beaucoup de Slackware.
Encore une fois on n'a pas ici affaire à des outils très orientés néophytes.
Cela dit je ne critiquerait pas un outil de configuration graphique, mais sous Slackware il y a ce genre d'outils en ncurses, donc en terminal, mais graphique, dans la lignée de l'installeur, ils fonctionnent très bien via SSH.

Bref, à retenir : Slackware ne subit pas les hypes, suit sa propre voie, et privilégie l'apprentissage des fichiers de configuration à l'utilisation d'un outil graphique qui essaierait de centraliser tout, ce qui fait qu'on a une impression d'austérité et un franc manque de bling-bling.

Il y a pas mal de choses à l'avenant : si Slackware utilise un logiciel qui fait le taf, mais que d'autres plus grosses distribs ont remplacées par une alternative, qui fait le taf aussi, Slackware est considérée comme « en retard » plutôt que différente.
C'est très marquant avec l'opposition Calligra/LibreOffice.
Il y a des tas de gens qui se font chier à coder un logiciel efficace, léger, rapide, et parfaitement intégré à l'environnement KDE, j'ai nommé Calligra, mais comme le logiciel phare de bureautique c'est LibreOffice, point de salut, Slackware est à la ramasse de proposer le premier plutôt que le second !
Alors : il est très simple d'installer LibreOffice sous Slackware, et comme l'environnement de bureau par défaut est KDE (ou XFCE), Calligra est un choix par défaut assez évident : ça s'intègre bien, ça se lance vite, et ça fait l'essentiel du boulot, en odt/ods/od* comme LibreOffice, et c'est capable d'ouvrir des fichiers .docx comme LibreOffice.
Il faut vraiment avoir un usage un peu avancé de la suite bureautique pour trouver des différences fortes, ou des manquements, et dans ce cas là, tous les gens que j'ai rencontré avec ce genre de besoins, décrient LibreOffice est se tourne vers MS Office, à mon grand dam…

De la même manière, je n'ai rien contre VLC, mais critiquer son absence c'est un brin orienté…
Je n'aime pas spécialement utiliser VLC, réfractaire à l'interface, je préfère largement smplayer.
Historiquement, mplayer a toujours été le lecteur vidéo qui permettait de lire tout et n'importe quoi, avant le début du projet VLC, c'est toujours actif, toujours fonctionnel, ça marche au poil, encore une question de choix ici ? VLC ou la déshérence ?

The distribution ships with so many applications it's difficult to find anything in the menus because each category in the twin-pane menu holds pages of launchers. Many of these programs I haven't used before, or have not used in a long time.

La distribution embarque tellement de logiciels qu'il est difficile de s'y retrouver, chaque catégorie de menu a plusieurs pages de lanceurs. Avec beaucoup de programmes que je n'ai jamais utilisé, ou pas depuis longtemps.

Mouais, bref, il n'y a pas exactement les outils dont il a l'habitude et il est tout perturbé ?
Il y a du choix.
Autant pour la soi-disant austérité de la distribution : en full-install elle n'est pas minimaliste, et offre du choix pour un peu tout. En vrai, je trouve ça absolument génial pour un néophyte (que j'ai été), pour tout essayer, découvrir, apprendre, expérimenter.

I find it too much effort to get common tasks done with this distribution. There is a lot of manual work involved and very little, if any, benefit to being forced to do this extra work.

Je trouve qu'il faut trop d'efforts pour accomplir la moindre tâche avec cette distribution. Il faut beaucoup d'huile de coude pour très peu, voire pas, de valeur ajoutée.

C'est un peu ce que je ressens quand je dois me faire ch… avec une VM CentOS, pourquoi tant d'efforts pour des tâches simples ? pourquoi tant de commandes à retenir par cœur (ou à avoir dans sa cheat sheet) ?

Mais qui est le problème ? Moi, l'amateur d'une distribution fidèle, moderne et conservatrice à la fois, qui « fait les choses comme il y a 25 ans » qui suit campé sur mes habitudes, ou plutôt l'auteur de l'article qui a une vision des « bons logiciels à utiliser », des façons de faire, et ne comprends pas que Slackware puisse penser les choses différemment ?

Bref, je trouve cet article triste, très monoculturel, je trouve que l'auteur pousse à rejeter la Slackware non pas sur ses défauts, mais sur des choix qui ne sont pas jugés assez mainstream…

Un dernier point concernant la communauté, qui serait stagnante depuis 20 ans.
Ce n'est pas ce que je ressens dans le projet Slackbuilds, ça tourne, des gens vont, d'autres viennent, il y a plusieurs dizaines de contributeurs assidus et réguliers, et il n'est pas si commun de trouver un logiciel libre pour lequel c'est le cas.
Je le déplore mais il y a beaucoup plus de contributeurs au simple projet Slackbuilds.org qu'à Gimp, qui a, à mon avis, une importance nettement supérieure pour le monde des logiciels libres.
J'en suis ravi pour la Slackware, et les Slackbuilds, bien sûr, et je ne jetterai pas la vieille bique avec l'eau du temps, cette distribution a un avenir, et continuera de proposer une alternative fiable aux projets équivalents et plus mainstream que je trouve souvent trop pressés d'intégrer les dernières hypes du moment, au détriment d'autres projets tout aussi valables mais moins bien marketés.

• Yth.