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.
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.
Le système d'init n'impacte pas le logiciel aussi profondément que tu le sous-entends. Tous ses logiciels n'ont pas cessé de fonctionné avec l'arrivé de systemd. Que ce soit l'utilisation d'une couche de compatibilité ou en natif cela montre bien qu'il n'y a pas d'impact aussi profond.
D'où ma conclusion : en fait on s'en fout de systemd !
On s'en fout qu'il y soit ou pas.
Ce n'est pas ça qui est important.
En fait, ça n'a même presque aucune importance.
Pas plus que d'utiliser elvis plutôt que vim comme éditeur texte par défaut…
Pas plus que de booter avec grub ou avec lilo !
Mon seul - et unique - propos était de dire qu'un changement fondamental d'habitudes comme de passer à systemd n'arriverait pas durant la période de maintient d'une version stable de la Slackware.
PAM arrive dans slackware 15.0, mais ne serait jamais entré dans la 14.2, malgré 5 années de maintenance.
Erreur de compréhension ?
Slackware introduit des changements d'une version à l'autre, mais pas sur la durée de vie d'une version stable.
C'est à dire que si pas de systemd, à la sortie de la 14.2, pas plus de systemd dans les patchs de la 14.2 le jour de la sortie de la 15.0.
C'est une version stable : elle est stable et ne te forcera pas à changer la moindre habitude durant toute sa durée de vie. Il n'y a rien d'autre à comprendre dans ce que j'ai expliqué plus haut.
Après, si tu veux troller sur systemd, il s'agit d'un système d'init parmi plein d'autre.
Et je suis personnellement très attaché au choix, parce que sinon je serais peut-être sous Mac, quitte à ne plus avoir de choix, autant le faire bien et à fond.
Systemd ? Bah on s'en fout, comme on se fout que tu préfères utiliser Lyx, Abiword, Calligra, OpenOffice, Libreoffice, ou que-sais-je.
Comme on se fout que tu préfères git, ou mercurial, ou subversion, ou pijul, ou fossil ou que-sais-je.
Comme on se fout que tu utilises vim, emacs, geany, textadept, joe, ou que-sais-je.
Ce dont on ne se fout pas, c'est simple : si tu veux tu peux, si tu ne veux pas tu peux ne pas.
Tu veux une slack avec systemd ? Facile, tu as un dépôt avec des slackbuilds pour passer ta slack à systemd et voilà.
Tu veux retirer pulseaudio ? Trivial, tu supprimes le paquet et tu installes apulse à la place, tout est indiqué dans la doc slackware.
Tu ne veux pas passer à PAM en passant à la slackware 15.0 ? Facile, ya une doc aussi, je l'ai vue passer (mais je m'en fous en vrai :p).
Et… tous les auteurs de logiciels qui ne font pas leurs logiciels exclusivement pour Linux ne font pas leurs logiciels exclusivement pour systemd.
Je vois mal des trucs genre apache, nginx, mariadb, redis, postgresql, opensmtpd, dovecot, prosody, postfix, dnsmasq, bind, haproxy, squid, ejabberd, ou que-sais-je, se dire que ça serait une bonne idée de ne fonctionner qu'avec exclusivement systemd en tête.
Parce qu'il n'y a pas que Linux dans la vie…
Il y a le choix, toujours lui qui vient nous casser les pieds tous les trois pas !
Donc, systemd, on s'en fout en vrai, c'est un non-problème, un logiciel comme un autre, un choix comme un autre.
En tout cas ça ne devrait pas décider du choix de ta distrib, ça serait comme rejeter Ubuntu parce que c'est sous Gnome par défaut et que tu préfères KDE.
Je vais répondre simplement que le noyau Linux est conçu et voulu par l'ensemble de sa communauté de développeurs et d'utilisateurs comme un outil qui doit être configuré.
(Un peu comme apache quoi, ou mariadb, ou je sais pas…)
Et la notion de valeur par défaut dans la configuration du noyau Linux, c'est juste histoire qu'il n'y ait pas rien, c'est surtout informatif. Même si en général c'est en mode « ça devrait marcher si tu touches à rien ».
Pendant longtemps je compilais moi-même mon noyau, mes paramètres étaient les miens.
Aujourd'hui je fais le choix conscient de déléguer cette tâche à la Slackware, par manque de temps, et un peu de perte d'intérêt, mais ça changera le jour où ça n'ira plus.
Et donc oui, la Slackware propose des noyaux Linux paramétrés, ce qui - je pense - ne surprendra personne…
Pour Unvanquished, je ne vois pas bien en quoi cette contrainte du jeu fait qu'il a une configuration particulière, ou qu'on a changé quelque chose à l'Unvanquished « vanilla » fournit par les développeurs ?
Il y a une contrainte de paramétrage du noyau, ok.
J'en rajoute des paramétrages maison du noyau, selon mes besoins…
Bah de mon côté ça fait environ 20 ans que je me suis plus fais chier à installer autre chose qu'une Slackware.
En fait tu as deux vision du Slacker : le stable et le current.
Le Slacker stable il pense un peu comme ça :
J'installe ma Slackware stable (14.2 aujourd'hui, bientôt 15.0), c'est toujours pareil, aucune surprise, une passe de mises à jour pour mettre tous les patchs de sécurité (142 paquets hors kernel, là ça commence à faire pas mal après cinq ans), le paramétrage de base (clavier pour X, langue du système…).
Et là, tu commences à personnaliser, les mains dans le cambouis (configure && make && make install) ou pas (sbo install), tu en fais ce que tu veux.
Par rapport à une gentoo, tu as ton système 100% utilisable en 30 minutes, sans efforts, et après tu joues avec des scripts de build pour tes paquets supplémentaires. Tu connais la base qui ne va pas changer sous tes pieds, c'est d'une très grande stabilité, ta seule préoccupation c'est ce que tu mets au dessus, ce qui t'intéresse personnellement, ce qui n'est pas générique.
Générique ce sont les 1500 paquets de base, sachant que Slackware ne découpe pas MySQL en un paquet client, server, devel, etc. Il y a un seul paquet MariaDB, donc 1500 paquets Slackware peuvent valoir un truc comme 2000 à 2500 paquets Debian, au pifomètre.
Tu ne te poses à peu près jamais la question de savoir si une mise à jour va péter ton système, la réponse est non. Mais tu ne restes pas non plus avec par exemple un firefox d'il y a cinq ans (FF 45.2) : la Slackware 14.2 le met à jour avec la dernière version ESR (68.12 aujourd'hui). Le kernel est sur une version avec support à long terme (ESR), passé de 4.4.14 à 4.4.240 en 5 ans.
Le maître-mot : la stabilité.
Le Slacker current lui, il a une distribution en rolling-release, avec des mises à jour très régulières, qui peuvent péter des trucs parfois, en particulier les paquets supplémentaires que tu as compilé aux petits oignons avec tes slackbuilds. Mais il est super à jour, il va voir arriver des nouveautés très tôt. Et avec toujours cette base réduite (mais assez large quand même), ça reste très stable.
Ça demande plus de travail, mais c'est toujours le cas avec une rolling-release !
La sortie d'une nouvelle version stable, ce sont les astres qui sont alignés, et tous les Slackers au même endroit !
Mais bon, à part ça - la stabilité et la simplicité de la Slackware de base - pourquoi Slackware ?
Pourquoi pas une pure compilée à la Gentoo, ou LFS, ou une autre avec vraiment plein de paquets comme Debian ?
Pour moi, c'est l'équilibre et la liberté.
La Slackware ne fait pas de choix pour toi : un paquet Slackware s'installe et se paramètre de la façon dont les auteurs du logiciels l'ont prévus. Pour avoir de la doc sur Apache/Slackware, il suffit de lire la doc Apache, pour la doc MariaDB/Slackware ? C'est MariaDB.
Ça fait une différence avec l'univers Debian qui essaie d'avoir une harmonie dans la façon de gérer tous les logiciels, et où le paramétrage de tel ou tel logiciel doit se faire à-la-Debian. Il faut paramétrer le logiciel pour Debian.
C'est la raison pour laquelle on a tendance à dire que quand tu apprends Debian, tu connais Debian, mais quand tu apprends Slackware, tu connais Linux.
Comparée à une LFS, tu as cette étape de 30 minutes pour installer la base de ton système, 1500 paquets, et un OS stable et parfaitement utilisable. En général bien plus complet que beaucoup d'autres distributions qui vont installer une base encore plus réduite, mais te donner accès à un magasin de paquets plus large: après l'installation, il faudra réinstaller les trucs dont tu as l'habitude, rechercher dans la liste, tout remettre d'aplomb.
Sous Slackware, tu as cette base qui te fait gagner plein de temps.
Et les paquets supplémentaires alors ?
Là il y a deux choix : les dépôts annexes, comme ceux d'AlienBob, en particulier le multilib, qui permet de basculer ta Slackware64 en une distribution multilib capable de faire tourner des logiciels 32 bits.
Ou alors Slackbuilds.org.
C'est un dépôt d'environ 8000 scripts, permettant de construire un paquet Slackware à partir des sources officielles d'un projet.
Alors sur les 8000, on n'en a pas 8000 parfaitement maintenus et à jours, la qualité moyenne n'est pas forcément celle d'une Archlinux ou d'une Debian. Mais en triant les paquets obsolètes ou non maintenus, ça fait quand même un gros tas de logiciels, dans lequel on va trouver facilement les trucs les plus courants auxquels on peut penser.
0ad, Wesnoth, Freeciv, Warzone2100, Unvanquished, Tremulous ? Tu peux avoir les dernières versions une semaine après leur sortie, ou immédiatement si tu modifie toi-même le Slackbuild (par exemple VERSION=2.6.4 ./freeciv.Slackbuild, et hop tu crées le paquet Freeciv en version 2.6.4 à la minute où tu vois l'info comme quoi elle est sortie ! Bon jeu :) )
Et c'est stable aussi Slackbuilds.org, puisque les scripts sont conçus pour tourner sur une Slackware stable, ça veut dire qu'on s'appuie sur cette base stable pour construire des trucs en général très à jour, en mode rolling-release, et qui vont fonctionner partout, puisque la base est la même partout chez les Slackers Stables.
Et donc tu construits tes paquets et tu les installes, il te suffit de conserver tes fichiers de paquets pour réinstaller une machine à l'identique avec tes propres choix logiciels, en une ligne de commande (upgradepkg --install-new *.txz).
Et pour les Slackers Current, il y a le dépôt de Ponce : des modifications des slackbuilds qui ne fonctionnent pas sur -current, pour que ça marche aussi, mais là il ne faut pas avoir peur de mettre les mains dans le cambouis.
Typiquement, j'ai toujours avec moi une clé USB bootable avec une Slackware 14.2, et une partition à côté avec les mises à jours des patchs stables, et mes paquets persos.
Une installation passe donc par l'installation de base, la mise à jour des patchs et logiciels supplémentaires, le paramétrage de slackpkg (l'apt-get de slackware) pour aller chercher les dernières mises à jour en ligne.
L'équilibre ?
Ben oui, entre conservatisme et bleeding-edge.
Typiquement, lors de la sortie de la 14.2, systemd c'était pas encore le truc à la mode.
Donc même patchée jusqu'au bout, la Slackware stable elle est systemd-free.
Un bien, un mal ?
Personne ne t'a forcé la main en tout cas, et tu n'as pas eu à changer tes habitudes en 5 ans.
Des changements majeurs comme ça, il y en a, entre les versions stables, dans la current, qui va péter des trucs quand il va y avoir des expérimentations sur tel ou tel composant central qu'on envisage de modifier.
Spoiler : la 15.0 sera aussi sans systemd, parce que tout le monde s'en fout de systemd, si tu veux systemd il y a deux-cent-cinquante autres distribs qui le proposent, et systemd casse le principe fondamental de dire qu'un paquet Slackware s'installe et se paramètre comme les auteurs du logiciel l'ont prévu.
Et… ça n'a aucune importance en vrai.
Par contre la 15.0 va être super à jour, avec un KDE et un XFCE dernière version, un gimp 2.10.22, python 3.9, gcc 10, bref, tout très à jour.
Équilibre aussi entre simplicité et cambouis.
Rester sur une -14.2, utiliser sbotools pour maintenir ses slackbuilds supplémentaires, ou se contenter d'un dépôt binaire d'une autre personne, c'est deux outils à connaître : slackpkg et sbotools, voilà pour l'administration, simple.
Mais les Slackbuilds ce sont des scripts, on peut les modifier pour changer le comportement, les options, tout ce qu'on veut, en maintenir soi-même : la marche à l'entrée n'est pas très haute pour devenir mainteneur de Slackbuilds. Et on peut vivre dangereusement en -current aussi.
Là le fossé est assez important, parce que 5 ans, c'est du jamais vu dans l'histoire de la Slackware. On avait plutôt une version tous les six mois ou un an avant ça.
Donc elle est très attendue la 15.0.
Mais les Slackers Current y sont déjà.
Et environ un mois après sa sortie (parce que là il y a du boulot), les 8000 Slackbuilds compileront dessus.
Mes propres Slackbuilds (j'en ai une soixantaine) sont déjà quasiment prêts, compatibles 14.2 et 15.0, ou prêts à être mis à jour.
Voilà un peu mon univers Slackware, sa position, et pourquoi je m'y plais !
In its first beta release, Ceres software and hardware requirements are fairly restrictive (Windows operating system, processors with AVX, and NVIDIA GPUs).
Disons en l'occurrence que peut-être que comme ça ne tourne que sur du matos NVidia, ils ou elles n'ont pas été chercher très loin dans leur exception.
Le projet est en bêta, on peut leur laisser le bénéfice du doute.
Pour un projet mûr, en version 1+, et déjà bien installé, j'aurais poussé un peu les mêmes cris d'orfraie que toi. Là on peut se dire que se sont présentés d'autres chats artificiels à fouetter que de gérer un autre type de matériel que ce qu'il y avait sous la main.
Bah LineageOS sans gapps, ça tourne bien.
Tu peux sauter le pas, tu n'en souffriras pas beaucoup, voire pas du tout si déjà les applis gafamisées ne te bottent pas.
J'admets…
Ça dépend de comment tu l'as codé.
Mais pour sortir d'un projet où on a dû faire une migration python 2.4 vers 3.6, avec 150k lignes de code, avec douze ans de passif (oui le projet a été lancé en python 2.4 quand python 3.0 venait de sortir en gros, me demandez pas, j'y étais pas).
Et ben ce n'est pas si compliqué que ça, les modifs de code ne sont pas légions du tout.
Faut être rigoureux, et avoir des batteries de tests déjà prêtes aide beaucoup (tests unitaire, fonctionnels, ou de non régression).
Ok, donc les PSX et XBOX sont juste un pc de gamer avec un enrobage vintage à la con que tout le monde pouvait faire dans un fablab avec une imprimante 3d, mais avec en plus de blobs pour fermer le bouzin, et vendues à pertes.
Mais fondamentalement, mis à part l'ouverture ou la fermeture, c'est pareil, une console de salon c'est un pc de gamer tout bien emballé.
Donc la critique d'au-dessus vis-à-vis de la console Atari n'a pas tellement lieu d'être, non ?
Tout ce qui compte derrière c'est la quantité de jeux qu'on peut faire tourner dessus, et si on peut avoir des jeux parmi les plus récents.
En quoi ça distingue fondamentalement cette console d'Atari des autres consoles du marché ?
Ne sont-ce point aussi des ordinateurs assez classiques, avec un GPU, des périphériques, etc ?
Si tu cherches à envisager le web dans son ensemble, alors oui, c'est super complexe.
Mais si tu cherches juste à faire un site web, voire une application web, non, c'est pas spécialement plus compliqué qu'avant, c'est même plus simple si tu arrives à ne pas te compliquer la vie.
Ton HTML/CSS/JS/(PHP/Python/CGI (bash/perl/…)/…) d'il y a 20 ans fonctionne encore sans quasiment rien changer, mais chacun des ces langages a évolué et permet souvent de faire pareil en plus clair, plus concis, plus lisible, et plus aisé à maintenir.
Par contre on a une sort d'infinité de fois plus de possibilité de faire de la merde imbitable, impossible à maintenir, lourdinque, bourrée de traqueurs, de pubs, et d'autres saloperies, ça oui, mais personne ne t'y oblige :)
Yth — nan, j'ai pas lu l'article, donc oui, c'est normal si je répond - un peu - à côté de la plaque, m'en fous, je suis un dinosaure et j'ai survécu au covid, alors j'fais c'que j'veux, na !
Ben LineageOS, quand on est enfin dessus et qu'on a quitté l'Android classique, version bloaté google+fabriquant+opérateur, on ne revient pas en arrière.
Grosso-modo, c'est Android comme ça devrait être.
Parce que la majorité des formations étant majoritairement masculine - dans les faits - elles perpétuent cet état de fait sur le principe simple de « on ne change pas ce qui marche », et ce qui marche pour la formation, c'est de sortir des gens suffisamment formés.
Il y a deux solutions : faire évoluer doucement mais inexorablement vers une équité, et causer une rupture.
Et aucune des deux ne fonctionne… seule.
Il faut donc un élément de rupture : des formations entièrement féminine pour s'attaquer au problème final et actuel : les femmes sont moins représentées dans le métier parce que elles sont moins représentées dans les formations.
Ceci provoque des discussions, et aussi plus de femmes dans le métier, et donc plus de femmes qui se disent qu'elles peuvent faire des formations tout court, et pas des formations à destination des femmes.
Et au fur et à mesure les choses devraient évoluer dans les formations classiques vers une meilleure parité.
Mais c'est comme quand on fait du sport : on casse la fibre musculaire pour la reconstruire plus souple, plus puissante, etc. Bah là faut casser le modèle pour le reconstruire meilleur. Sauf que comme dans le sport : on ne casse pas tout d'un coup : si on arrache le muscle on peut toujours espérer qu'il repousse, ça va rater.
Dans tous les combats féministes, il y a toujours ces deux approches, caricaturées en : faire changer doucement les choses et foncer dans le tas.
Et les deux sont complémentaires et indispensables.
Donc ce n'est pas sexiste de faire des formations 100% féminines, c'est un impératif d'équité, qui disparaîtra avec le temps, si les choses évoluent dans le bon sens, mais qui augmentera sinon.
Ça fait partie des fonctionnalités communes entre Sylpheed et Claws-Mail : on peut utiliser un éditeur de texte externe pour composer les mails.
D'ailleurs on peut choisir en cours de rédaction de basculer sur l'éditeur de texte externe, puis de revenir sur l'éditeur de mail interne !
Et oui, il y a ce défaut de freeze de l'UI lors de l'incorporation des mails reçus.
Plus précisément :
- Sylpheed récupère une boîte en IMAP, tout va bien ;
- Il a terminé et incorpore les mails reçus : l'UI est gelée ;
- Sylpheed récupère une boîte en POP, et on voit apparaître les mails au fur et à mesure et on peut commencer à les lire pendant qu'ils arrivent.
Ce fut pire par le passé, il y a eu des améliorations ces dernières années à ce sujet.
On peut aussi ne pas faire de récupération automatique, et le faire exclusivement manuellement, un clic et il travaille.
Ou tout désactiver temporairement : il y a un mode hors-ligne, un simple clic et il ne communique plus, on ne risque donc pas d'être dérangé, et on bosse uniquement avec les données locales.
On a aussi l'impossibilité d'envoyer un mail directement pendant qu'une opération de réception est en cours, mais on peut mettre dans la boîte d'envoi et le laisser envoyer plus tard.
Il y a aussi un système de plugin dans Sylpheed, mais je ne sais pas du tout ce qui existe.
Mon plugin pour ouvrir tout type de pièce jointe c'est simplement de l'envoyer vers le système qui utilisera l'application configurée (xpdf, LOo, firefox, etc.)
Mais il affiche quand même les images en interne.
Oh, et bien sûr, lorsqu'on rédige un mail, on peut choisir en cours de route quel compte va envoyer le mail, et en changer autant qu'on veut, ce n'est pas bloqué au moment où on a cliqué sur « répondre » !
En fait, sous Linux, les options sont plus que limitées : Thunderbird, principalement, sinon Geary, qui est très buggué et Kmail, qui dépend de toute la stack KDE (que je n'utilise pas).
J'interviens juste pour faire remarquer qu'il existe toujours Sylpheed, en bien plus léger qu'un Thunderbird, et sans grosse stack graphique. Et aussi Claws-mail, mais je ne l'utilise pas alors je n'en parlerai pas, mais pour ceux qui ne connaissent pas Claws-mail est un fork d'assez longue date de Sylpheed, et je ne connais pas les réelles différences.
J'apprécie Sylpheed depuis longtemps parce que c'est facile de gérer des tas de comptes, y compris temporaires, de garder un compte inactif dans un coin, de ranger et archiver ses mails, aussi bien localement que via IMAP.
Par exemple ma boîte d'archives est auto-hébergée, et j'y archive automatiquement avec des règles de filtrages des mails qui proviennent de toutes les autres boîtes.
On choisit très facilement quelles boîtes sont récupérées quand on clique sur « tout relever », et pour récupérer une autre boîte spécifique non-automatique il suffit de cliquer dessus (et faire relever manuellement si c'est du POP, mais l'IMAP est mis à jour à la volée).
Et tout ça en mails textuels : Sylpheed n'affiche pas les mails en HTML, mais présente la pièce-jointe HTML sur laquelle on peut cliquer pour l'ouvrir dans le navigateur, qui ouvre alors la copie locale hors-ligne de la partie HTML du mail.
J'ai un truc comme 100k mails dans mon Sylpheed, entre de l'IMAP et du local, ça n'a absolument aucun sens, et à part repartir de zéro je ne vois pas comment gérer ça aujourd'hui. Mais Sylpheed n'est pas perturbé par la quantité, ça va vite, ça ne plante pas. J'utilise le même Sylpheed depuis l'an 2000, en mettant à jour, sans jamais avoir rien eu de cassé, sans jamais avoir eu à faire de migration.
Avec tout ce bazar, il pompe 80Mo de RAM alors qu'il tourne depuis 15 jours (changé la batterie de portable fait tomber l'uptime, mais ça pourrait être 300 jours - et ça l'a déjà été - ça serait pareil).
Bref, je ne sais pas si Sylpheed peut répondre à ton besoin, parce qu'il ne s'utilise pas en mode texte, et ne s'interface pas avec org-mode, mais il n'a pas les inconvénients des trois que tu as cités.
Les mails étant stockés localement dans des fichiers individuels - y compris pour le cache local des boîtes en IMAP -, on peut même faire des recherches avec du grep, du find et des trucs comme ça.
Et si la boîte IMAP est définitivement inaccessible, ben tout ce qui est en cache localement est disponible, on peut même en déplaçant simplement le répertoire du cache dans un nouveau répertoire de la boîte locale les intégrer et y accéder comme s'ils avaient toujours été là.
On peut - noter le verbe utilisé qui n'oblige à rien - l'interfacer avec des outils de filtre antispam de façon très simple, il y a un préréglage pour bogofilter, sylfilter et bsfilter, mais comme tout ça se fait par l'invocation de lignes de commandes configurées dans Sylpheed, on peut interfacer un peu ce qu'on veut en bricolant.
On peut re-traiter tous les mails d'une boîte à travers le filtre anti-spam, ou les règles de filtrage, pour organiser après-coup des mails déjà reçus en fonction de nouvelles règles qu'on vient de créer.
Bref, avec un outil comme ça je n'ai jamais ressenti le besoin de subir Thunderbird ou Kmail…
Et sinon je serais probablement resté sous Alpine…
Mais en fait, pour faire un DoS, en pratique il faut exploiter une faille, et le symptôme est un déni de service.
Comment tu fais tomber un service avec une attaque simple si tu n'exploite pas une faille dans le service ?
Alors qu'un DDoS c'est autre chose : tu satures le service rendant impossible d'y accéder pour les gens. C'est 2500 personnes qui font la queue à la gendarmerie pour porter plainte contre une vache, et toi qui veut signaler le vandalisme sur ta voiture, ben tu peux pas.
Bref, on joue sur les mots un peu, mais je classifierait plutôt les (D)DoS comme des types d'attaques plutôt que des failles…
Ce qui n'empêche pas de chercher des solutions pour s'en prémunir, mais ces solutions ne sont pas liés à la sécurité intrinsèque de tes outils, ou à la présence ou non de failles logicielles.
Plutôt à l'organisation de ton réseau. Et c'est relativement indépendant des OS sous-jacents.
Bon, inutile de pinailler plus, ça ne fait pas tellement avancer le schmilblick…
Mais tout ça ne fait pas du (D)DoS une faille de sécurité en tant que telle.
Ça en fait une attaque, et une attaque affaiblit toujours un peu sa cible, permettant parfois à une autre attaque d'atteindre sa cible.
Une faille c'est un moyen d'atteindre ta cible sans avoir à profiter d'un affaiblissement lié à une attaque massive.
Le gros bouton ON/OFF accessible est une fonctionnalité, pas une faille, si il a été mis là c'est probablement pour une bonne raison. Sinon c'est qu'on a affaire à des bras cassés, et des failles il y en a probablement des douzaines encore plus faciles à exploiter…
Un système sans failles peut quand même tomber, être spoofé, être l'objet de phishing, ou d'arnaques en tout genre.
Ça n'en fait pas des failles de sécurité, même si ça reste des problèmes graves pour lesquels on peut mettre en place des mesures.
Le déni de service n'est pas une faille de sécurité.
C'est un blocus de camionneurs sur l'autoroute, une grève pas l'occupation des locaux, installer des tentes sur la voie ferrée pour empêcher les trains de partir, etc.
Le service n'est plus rendu, mais il n'y a pas eu de faille de sécurité, l'intégrité du service et de ses données n'est pas engagée.
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 6.
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.
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 7.
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…
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 9.
D'où ma conclusion : en fait on s'en fout de systemd !
On s'en fout qu'il y soit ou pas.
Ce n'est pas ça qui est important.
En fait, ça n'a même presque aucune importance.
Pas plus que d'utiliser elvis plutôt que vim comme éditeur texte par défaut…
Pas plus que de booter avec grub ou avec lilo !
Mon seul - et unique - propos était de dire qu'un changement fondamental d'habitudes comme de passer à systemd n'arriverait pas durant la période de maintient d'une version stable de la Slackware.
PAM arrive dans slackware 15.0, mais ne serait jamais entré dans la 14.2, malgré 5 années de maintenance.
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 8.
Erreur de compréhension ?
Slackware introduit des changements d'une version à l'autre, mais pas sur la durée de vie d'une version stable.
C'est à dire que si pas de systemd, à la sortie de la 14.2, pas plus de systemd dans les patchs de la 14.2 le jour de la sortie de la 15.0.
C'est une version stable : elle est stable et ne te forcera pas à changer la moindre habitude durant toute sa durée de vie. Il n'y a rien d'autre à comprendre dans ce que j'ai expliqué plus haut.
Après, si tu veux troller sur systemd, il s'agit d'un système d'init parmi plein d'autre.
Et je suis personnellement très attaché au choix, parce que sinon je serais peut-être sous Mac, quitte à ne plus avoir de choix, autant le faire bien et à fond.
Systemd ? Bah on s'en fout, comme on se fout que tu préfères utiliser Lyx, Abiword, Calligra, OpenOffice, Libreoffice, ou que-sais-je.
Comme on se fout que tu préfères git, ou mercurial, ou subversion, ou pijul, ou fossil ou que-sais-je.
Comme on se fout que tu utilises vim, emacs, geany, textadept, joe, ou que-sais-je.
Ce dont on ne se fout pas, c'est simple : si tu veux tu peux, si tu ne veux pas tu peux ne pas.
Tu veux une slack avec systemd ? Facile, tu as un dépôt avec des slackbuilds pour passer ta slack à systemd et voilà.
Tu veux retirer pulseaudio ? Trivial, tu supprimes le paquet et tu installes apulse à la place, tout est indiqué dans la doc slackware.
Tu ne veux pas passer à PAM en passant à la slackware 15.0 ? Facile, ya une doc aussi, je l'ai vue passer (mais je m'en fous en vrai :p).
Et… tous les auteurs de logiciels qui ne font pas leurs logiciels exclusivement pour Linux ne font pas leurs logiciels exclusivement pour systemd.
Je vois mal des trucs genre apache, nginx, mariadb, redis, postgresql, opensmtpd, dovecot, prosody, postfix, dnsmasq, bind, haproxy, squid, ejabberd, ou que-sais-je, se dire que ça serait une bonne idée de ne fonctionner qu'avec exclusivement systemd en tête.
Parce qu'il n'y a pas que Linux dans la vie…
Il y a le choix, toujours lui qui vient nous casser les pieds tous les trois pas !
Donc, systemd, on s'en fout en vrai, c'est un non-problème, un logiciel comme un autre, un choix comme un autre.
En tout cas ça ne devrait pas décider du choix de ta distrib, ça serait comme rejeter Ubuntu parce que c'est sous Gnome par défaut et que tu préfères KDE.
PS : le troll sur UTF8, j'ai pas pigé…
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 5.
Je vais répondre simplement que le noyau Linux est conçu et voulu par l'ensemble de sa communauté de développeurs et d'utilisateurs comme un outil qui doit être configuré.
(Un peu comme apache quoi, ou mariadb, ou je sais pas…)
Et la notion de valeur par défaut dans la configuration du noyau Linux, c'est juste histoire qu'il n'y ait pas rien, c'est surtout informatif. Même si en général c'est en mode « ça devrait marcher si tu touches à rien ».
Pendant longtemps je compilais moi-même mon noyau, mes paramètres étaient les miens.
Aujourd'hui je fais le choix conscient de déléguer cette tâche à la Slackware, par manque de temps, et un peu de perte d'intérêt, mais ça changera le jour où ça n'ira plus.
Et donc oui, la Slackware propose des noyaux Linux paramétrés, ce qui - je pense - ne surprendra personne…
Pour Unvanquished, je ne vois pas bien en quoi cette contrainte du jeu fait qu'il a une configuration particulière, ou qu'on a changé quelque chose à l'Unvanquished « vanilla » fournit par les développeurs ?
Il y a une contrainte de paramétrage du noyau, ok.
J'en rajoute des paramétrages maison du noyau, selon mes besoins…
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 10.
Bah de mon côté ça fait environ 20 ans que je me suis plus fais chier à installer autre chose qu'une Slackware.
En fait tu as deux vision du Slacker : le stable et le current.
Le Slacker stable il pense un peu comme ça :
J'installe ma Slackware stable (14.2 aujourd'hui, bientôt 15.0), c'est toujours pareil, aucune surprise, une passe de mises à jour pour mettre tous les patchs de sécurité (142 paquets hors kernel, là ça commence à faire pas mal après cinq ans), le paramétrage de base (clavier pour X, langue du système…).
Et là, tu commences à personnaliser, les mains dans le cambouis (configure && make && make install) ou pas (sbo install), tu en fais ce que tu veux.
Par rapport à une gentoo, tu as ton système 100% utilisable en 30 minutes, sans efforts, et après tu joues avec des scripts de build pour tes paquets supplémentaires. Tu connais la base qui ne va pas changer sous tes pieds, c'est d'une très grande stabilité, ta seule préoccupation c'est ce que tu mets au dessus, ce qui t'intéresse personnellement, ce qui n'est pas générique.
Générique ce sont les 1500 paquets de base, sachant que Slackware ne découpe pas MySQL en un paquet client, server, devel, etc. Il y a un seul paquet MariaDB, donc 1500 paquets Slackware peuvent valoir un truc comme 2000 à 2500 paquets Debian, au pifomètre.
Tu ne te poses à peu près jamais la question de savoir si une mise à jour va péter ton système, la réponse est non. Mais tu ne restes pas non plus avec par exemple un firefox d'il y a cinq ans (FF 45.2) : la Slackware 14.2 le met à jour avec la dernière version ESR (68.12 aujourd'hui). Le kernel est sur une version avec support à long terme (ESR), passé de 4.4.14 à 4.4.240 en 5 ans.
Le maître-mot : la stabilité.
Le Slacker current lui, il a une distribution en rolling-release, avec des mises à jour très régulières, qui peuvent péter des trucs parfois, en particulier les paquets supplémentaires que tu as compilé aux petits oignons avec tes slackbuilds. Mais il est super à jour, il va voir arriver des nouveautés très tôt. Et avec toujours cette base réduite (mais assez large quand même), ça reste très stable.
Ça demande plus de travail, mais c'est toujours le cas avec une rolling-release !
La sortie d'une nouvelle version stable, ce sont les astres qui sont alignés, et tous les Slackers au même endroit !
Mais bon, à part ça - la stabilité et la simplicité de la Slackware de base - pourquoi Slackware ?
Pourquoi pas une pure compilée à la Gentoo, ou LFS, ou une autre avec vraiment plein de paquets comme Debian ?
Pour moi, c'est l'équilibre et la liberté.
La Slackware ne fait pas de choix pour toi : un paquet Slackware s'installe et se paramètre de la façon dont les auteurs du logiciels l'ont prévus. Pour avoir de la doc sur Apache/Slackware, il suffit de lire la doc Apache, pour la doc MariaDB/Slackware ? C'est MariaDB.
Ça fait une différence avec l'univers Debian qui essaie d'avoir une harmonie dans la façon de gérer tous les logiciels, et où le paramétrage de tel ou tel logiciel doit se faire à-la-Debian. Il faut paramétrer le logiciel pour Debian.
C'est la raison pour laquelle on a tendance à dire que quand tu apprends Debian, tu connais Debian, mais quand tu apprends Slackware, tu connais Linux.
Comparée à une LFS, tu as cette étape de 30 minutes pour installer la base de ton système, 1500 paquets, et un OS stable et parfaitement utilisable. En général bien plus complet que beaucoup d'autres distributions qui vont installer une base encore plus réduite, mais te donner accès à un magasin de paquets plus large: après l'installation, il faudra réinstaller les trucs dont tu as l'habitude, rechercher dans la liste, tout remettre d'aplomb.
Sous Slackware, tu as cette base qui te fait gagner plein de temps.
Et les paquets supplémentaires alors ?
Là il y a deux choix : les dépôts annexes, comme ceux d'AlienBob, en particulier le multilib, qui permet de basculer ta Slackware64 en une distribution multilib capable de faire tourner des logiciels 32 bits.
Ou alors Slackbuilds.org.
C'est un dépôt d'environ 8000 scripts, permettant de construire un paquet Slackware à partir des sources officielles d'un projet.
Alors sur les 8000, on n'en a pas 8000 parfaitement maintenus et à jours, la qualité moyenne n'est pas forcément celle d'une Archlinux ou d'une Debian. Mais en triant les paquets obsolètes ou non maintenus, ça fait quand même un gros tas de logiciels, dans lequel on va trouver facilement les trucs les plus courants auxquels on peut penser.
0ad, Wesnoth, Freeciv, Warzone2100, Unvanquished, Tremulous ? Tu peux avoir les dernières versions une semaine après leur sortie, ou immédiatement si tu modifie toi-même le Slackbuild (par exemple VERSION=2.6.4 ./freeciv.Slackbuild, et hop tu crées le paquet Freeciv en version 2.6.4 à la minute où tu vois l'info comme quoi elle est sortie ! Bon jeu :) )
Et c'est stable aussi Slackbuilds.org, puisque les scripts sont conçus pour tourner sur une Slackware stable, ça veut dire qu'on s'appuie sur cette base stable pour construire des trucs en général très à jour, en mode rolling-release, et qui vont fonctionner partout, puisque la base est la même partout chez les Slackers Stables.
Et donc tu construits tes paquets et tu les installes, il te suffit de conserver tes fichiers de paquets pour réinstaller une machine à l'identique avec tes propres choix logiciels, en une ligne de commande (upgradepkg --install-new *.txz).
Et pour les Slackers Current, il y a le dépôt de Ponce : des modifications des slackbuilds qui ne fonctionnent pas sur -current, pour que ça marche aussi, mais là il ne faut pas avoir peur de mettre les mains dans le cambouis.
Typiquement, j'ai toujours avec moi une clé USB bootable avec une Slackware 14.2, et une partition à côté avec les mises à jours des patchs stables, et mes paquets persos.
Une installation passe donc par l'installation de base, la mise à jour des patchs et logiciels supplémentaires, le paramétrage de slackpkg (l'apt-get de slackware) pour aller chercher les dernières mises à jour en ligne.
L'équilibre ?
Ben oui, entre conservatisme et bleeding-edge.
Typiquement, lors de la sortie de la 14.2, systemd c'était pas encore le truc à la mode.
Donc même patchée jusqu'au bout, la Slackware stable elle est systemd-free.
Un bien, un mal ?
Personne ne t'a forcé la main en tout cas, et tu n'as pas eu à changer tes habitudes en 5 ans.
Des changements majeurs comme ça, il y en a, entre les versions stables, dans la current, qui va péter des trucs quand il va y avoir des expérimentations sur tel ou tel composant central qu'on envisage de modifier.
Spoiler : la 15.0 sera aussi sans systemd, parce que tout le monde s'en fout de systemd, si tu veux systemd il y a deux-cent-cinquante autres distribs qui le proposent, et systemd casse le principe fondamental de dire qu'un paquet Slackware s'installe et se paramètre comme les auteurs du logiciel l'ont prévu.
Et… ça n'a aucune importance en vrai.
Par contre la 15.0 va être super à jour, avec un KDE et un XFCE dernière version, un gimp 2.10.22, python 3.9, gcc 10, bref, tout très à jour.
Équilibre aussi entre simplicité et cambouis.
Rester sur une -14.2, utiliser sbotools pour maintenir ses slackbuilds supplémentaires, ou se contenter d'un dépôt binaire d'une autre personne, c'est deux outils à connaître : slackpkg et sbotools, voilà pour l'administration, simple.
Mais les Slackbuilds ce sont des scripts, on peut les modifier pour changer le comportement, les options, tout ce qu'on veut, en maintenir soi-même : la marche à l'entrée n'est pas très haute pour devenir mainteneur de Slackbuilds. Et on peut vivre dangereusement en -current aussi.
Là le fossé est assez important, parce que 5 ans, c'est du jamais vu dans l'histoire de la Slackware. On avait plutôt une version tous les six mois ou un an avant ça.
Donc elle est très attendue la 15.0.
Mais les Slackers Current y sont déjà.
Et environ un mois après sa sortie (parce que là il y a du boulot), les 8000 Slackbuilds compileront dessus.
Mes propres Slackbuilds (j'en ai une soixantaine) sont déjà quasiment prêts, compatibles 14.2 et 15.0, ou prêts à être mis à jour.
Voilà un peu mon univers Slackware, sa position, et pourquoi je m'y plais !
[^] # Re: Ton droit c'est surtout ...
Posté par Yth (Mastodon) . En réponse au journal WhatsApp et Facebook, quels sont mes droits?. Évalué à 6.
Je ne suis pas gauchiste, je suis anarchiste.
Je ne suis pas fragile. non, vraiment pas…
Je ne suis pas communiste, je te l'ai dis, je suis anarchiste, et humaniste aussi si tu veux.
Je n'ai jamais commandé chez Über, eat ou autre.
Ma dernière commande Amazon date de… Bigre, je sais pas, longtemps, dix ans ? Plus peut-être ?
Je t'ai dis que j'étais anarchiste : ni dieu, ni maître !
Non, c'est un site d'information communautaire, sans engagement.
Mais non, A-nar-chiste merde ! Faut te le dire en quelle langue ?
Euh… Je sais pas quoi répondre à ça, j'avoue, les mots me manquent…
En tant qu'anarchiste, ma voix aux élections n'ira pas pour les fascistes, c'est sûr.
Développe ? Tu entends quoi par là ?
[^] # Re: Question : "éthique" des libristes qui n'aiment pas l'open source
Posté par Yth (Mastodon) . En réponse au lien Ceres, le moteur d'échecs basé sur Leela Chess Zero, flashé à pleine vitesse. Évalué à 4.
Disons en l'occurrence que peut-être que comme ça ne tourne que sur du matos NVidia, ils ou elles n'ont pas été chercher très loin dans leur exception.
Le projet est en bêta, on peut leur laisser le bénéfice du doute.
Pour un projet mûr, en version 1+, et déjà bien installé, j'aurais poussé un peu les mêmes cris d'orfraie que toi. Là on peut se dire que se sont présentés d'autres chats artificiels à fouetter que de gérer un autre type de matériel que ce qu'il y avait sous la main.
[^] # Re: Signal ou Telegram
Posté par Yth (Mastodon) . En réponse au journal WhatsApp et Facebook, quels sont mes droits?. Évalué à 6.
Bah LineageOS sans gapps, ça tourne bien.
Tu peux sauter le pas, tu n'en souffriras pas beaucoup, voire pas du tout si déjà les applis gafamisées ne te bottent pas.
[^] # Re: Signal ou Telegram
Posté par Yth (Mastodon) . En réponse au journal WhatsApp et Facebook, quels sont mes droits?. Évalué à 7.
Sinon, pour mettre à jour les applis, tu peux utiliser Aurora Store en anonyme.
[^] # Re: Nope.
Posté par Yth (Mastodon) . En réponse au lien Le Web est-il devenu trop compliqué ?. Évalué à 3.
J'admets…
Ça dépend de comment tu l'as codé.
Mais pour sortir d'un projet où on a dû faire une migration python 2.4 vers 3.6, avec 150k lignes de code, avec douze ans de passif (oui le projet a été lancé en python 2.4 quand python 3.0 venait de sortir en gros, me demandez pas, j'y étais pas).
Et ben ce n'est pas si compliqué que ça, les modifs de code ne sont pas légions du tout.
Faut être rigoureux, et avoir des batteries de tests déjà prêtes aide beaucoup (tests unitaire, fonctionnels, ou de non régression).
Note bien que j'ai écris :
[^] # Re: Vers la décroissance ;)
Posté par Yth (Mastodon) . En réponse au lien Un film entier sur une disquette. Évalué à 3.
Et ne parlons pas de l'audio…
Ah tiens, eux non plus n'en parlent pas !
[^] # Re: pc avec boite vintage
Posté par Yth (Mastodon) . En réponse au lien Les consoles ATARI VCS arrivent. Évalué à 3.
Ok, donc les PSX et XBOX sont
juste un pc de gamer avec un enrobage vintage à la con que tout le monde pouvait faire dans un fablab avec une imprimante 3d, mais avec en plus de blobs pour fermer le bouzin, et vendues à pertes.Mais fondamentalement, mis à part l'ouverture ou la fermeture, c'est pareil, une console de salon c'est un pc de gamer tout bien emballé.
Donc la critique d'au-dessus vis-à-vis de la console Atari n'a pas tellement lieu d'être, non ?
Tout ce qui compte derrière c'est la quantité de jeux qu'on peut faire tourner dessus, et si on peut avoir des jeux parmi les plus récents.
[^] # Re: pc avec boite vintage
Posté par Yth (Mastodon) . En réponse au lien Les consoles ATARI VCS arrivent. Évalué à 3.
Question probablement un peu con, mais…
En quoi ça distingue fondamentalement cette console d'Atari des autres consoles du marché ?
Ne sont-ce point aussi des ordinateurs assez classiques, avec un GPU, des périphériques, etc ?
# Nope.
Posté par Yth (Mastodon) . En réponse au lien Le Web est-il devenu trop compliqué ?. Évalué à 3.
Si tu cherches à envisager le web dans son ensemble, alors oui, c'est super complexe.
Mais si tu cherches juste à faire un site web, voire une application web, non, c'est pas spécialement plus compliqué qu'avant, c'est même plus simple si tu arrives à ne pas te compliquer la vie.
Ton HTML/CSS/JS/(PHP/Python/CGI (bash/perl/…)/…) d'il y a 20 ans fonctionne encore sans quasiment rien changer, mais chacun des ces langages a évolué et permet souvent de faire pareil en plus clair, plus concis, plus lisible, et plus aisé à maintenir.
Par contre on a une sort d'infinité de fois plus de possibilité de faire de la merde imbitable, impossible à maintenir, lourdinque, bourrée de traqueurs, de pubs, et d'autres saloperies, ça oui, mais personne ne t'y oblige :)
[^] # Re: LineageOS microG sur un XiaoMi Mix 2s
Posté par Yth (Mastodon) . En réponse au journal Installation de LineageOS, complément sur une ancienne dépêche. Évalué à 5.
Ben LineageOS, quand on est enfin dessus et qu'on a quitté l'Android classique, version bloaté google+fabriquant+opérateur, on ne revient pas en arrière.
Grosso-modo, c'est Android comme ça devrait être.
[^] # Re: emacs + mu4e + org-roam
Posté par Yth (Mastodon) . En réponse au journal Mails dans un zettelkasten…. Évalué à 6.
Ooooh, comme je suis d'accord avec toi…
[^] # Re: Programmation pour les femmes
Posté par Yth (Mastodon) . En réponse à la dépêche Apprentissage de la programmation pour les femmes — Émission « Libre à vous ! » du 10 novembre 2020. Évalué à 4.
Non.
Parce que la majorité des formations étant majoritairement masculine - dans les faits - elles perpétuent cet état de fait sur le principe simple de « on ne change pas ce qui marche », et ce qui marche pour la formation, c'est de sortir des gens suffisamment formés.
Il y a deux solutions : faire évoluer doucement mais inexorablement vers une équité, et causer une rupture.
Et aucune des deux ne fonctionne… seule.
Il faut donc un élément de rupture : des formations entièrement féminine pour s'attaquer au problème final et actuel : les femmes sont moins représentées dans le métier parce que elles sont moins représentées dans les formations.
Ceci provoque des discussions, et aussi plus de femmes dans le métier, et donc plus de femmes qui se disent qu'elles peuvent faire des formations tout court, et pas des formations à destination des femmes.
Et au fur et à mesure les choses devraient évoluer dans les formations classiques vers une meilleure parité.
Mais c'est comme quand on fait du sport : on casse la fibre musculaire pour la reconstruire plus souple, plus puissante, etc. Bah là faut casser le modèle pour le reconstruire meilleur. Sauf que comme dans le sport : on ne casse pas tout d'un coup : si on arrache le muscle on peut toujours espérer qu'il repousse, ça va rater.
Dans tous les combats féministes, il y a toujours ces deux approches, caricaturées en : faire changer doucement les choses et foncer dans le tas.
Et les deux sont complémentaires et indispensables.
Donc ce n'est pas sexiste de faire des formations 100% féminines, c'est un impératif d'équité, qui disparaîtra avec le temps, si les choses évoluent dans le bon sens, mais qui augmentera sinon.
[^] # Re: Alphabet phonétique
Posté par Yth (Mastodon) . En réponse au journal rsync. Évalué à 5. Dernière modification le 15 décembre 2020 à 08:43.
Bah, ça se prononce comme ça s'écrit…
[^] # Re: Sylpheed
Posté par Yth (Mastodon) . En réponse au journal Vim ou Emacs pour le courriel ?. Évalué à 2.
Ça fait partie des fonctionnalités communes entre Sylpheed et Claws-Mail : on peut utiliser un éditeur de texte externe pour composer les mails.
D'ailleurs on peut choisir en cours de rédaction de basculer sur l'éditeur de texte externe, puis de revenir sur l'éditeur de mail interne !
Et oui, il y a ce défaut de freeze de l'UI lors de l'incorporation des mails reçus.
Plus précisément :
- Sylpheed récupère une boîte en IMAP, tout va bien ;
- Il a terminé et incorpore les mails reçus : l'UI est gelée ;
- Sylpheed récupère une boîte en POP, et on voit apparaître les mails au fur et à mesure et on peut commencer à les lire pendant qu'ils arrivent.
Ce fut pire par le passé, il y a eu des améliorations ces dernières années à ce sujet.
On peut aussi ne pas faire de récupération automatique, et le faire exclusivement manuellement, un clic et il travaille.
Ou tout désactiver temporairement : il y a un mode hors-ligne, un simple clic et il ne communique plus, on ne risque donc pas d'être dérangé, et on bosse uniquement avec les données locales.
On a aussi l'impossibilité d'envoyer un mail directement pendant qu'une opération de réception est en cours, mais on peut mettre dans la boîte d'envoi et le laisser envoyer plus tard.
Il y a aussi un système de plugin dans Sylpheed, mais je ne sais pas du tout ce qui existe.
Mon plugin pour ouvrir tout type de pièce jointe c'est simplement de l'envoyer vers le système qui utilisera l'application configurée (xpdf, LOo, firefox, etc.)
Mais il affiche quand même les images en interne.
Oh, et bien sûr, lorsqu'on rédige un mail, on peut choisir en cours de route quel compte va envoyer le mail, et en changer autant qu'on veut, ce n'est pas bloqué au moment où on a cliqué sur « répondre » !
# Sylpheed
Posté par Yth (Mastodon) . En réponse au journal Vim ou Emacs pour le courriel ?. Évalué à 10.
J'interviens juste pour faire remarquer qu'il existe toujours Sylpheed, en bien plus léger qu'un Thunderbird, et sans grosse stack graphique. Et aussi Claws-mail, mais je ne l'utilise pas alors je n'en parlerai pas, mais pour ceux qui ne connaissent pas Claws-mail est un fork d'assez longue date de Sylpheed, et je ne connais pas les réelles différences.
J'apprécie Sylpheed depuis longtemps parce que c'est facile de gérer des tas de comptes, y compris temporaires, de garder un compte inactif dans un coin, de ranger et archiver ses mails, aussi bien localement que via IMAP.
Par exemple ma boîte d'archives est auto-hébergée, et j'y archive automatiquement avec des règles de filtrages des mails qui proviennent de toutes les autres boîtes.
On choisit très facilement quelles boîtes sont récupérées quand on clique sur « tout relever », et pour récupérer une autre boîte spécifique non-automatique il suffit de cliquer dessus (et faire relever manuellement si c'est du POP, mais l'IMAP est mis à jour à la volée).
Et tout ça en mails textuels : Sylpheed n'affiche pas les mails en HTML, mais présente la pièce-jointe HTML sur laquelle on peut cliquer pour l'ouvrir dans le navigateur, qui ouvre alors la copie locale hors-ligne de la partie HTML du mail.
J'ai un truc comme 100k mails dans mon Sylpheed, entre de l'IMAP et du local, ça n'a absolument aucun sens, et à part repartir de zéro je ne vois pas comment gérer ça aujourd'hui. Mais Sylpheed n'est pas perturbé par la quantité, ça va vite, ça ne plante pas. J'utilise le même Sylpheed depuis l'an 2000, en mettant à jour, sans jamais avoir rien eu de cassé, sans jamais avoir eu à faire de migration.
Avec tout ce bazar, il pompe 80Mo de RAM alors qu'il tourne depuis 15 jours (changé la batterie de portable fait tomber l'uptime, mais ça pourrait être 300 jours - et ça l'a déjà été - ça serait pareil).
Bref, je ne sais pas si Sylpheed peut répondre à ton besoin, parce qu'il ne s'utilise pas en mode texte, et ne s'interface pas avec org-mode, mais il n'a pas les inconvénients des trois que tu as cités.
Les mails étant stockés localement dans des fichiers individuels - y compris pour le cache local des boîtes en IMAP -, on peut même faire des recherches avec du grep, du find et des trucs comme ça.
Et si la boîte IMAP est définitivement inaccessible, ben tout ce qui est en cache localement est disponible, on peut même en déplaçant simplement le répertoire du cache dans un nouveau répertoire de la boîte locale les intégrer et y accéder comme s'ils avaient toujours été là.
On peut - noter le verbe utilisé qui n'oblige à rien - l'interfacer avec des outils de filtre antispam de façon très simple, il y a un préréglage pour bogofilter, sylfilter et bsfilter, mais comme tout ça se fait par l'invocation de lignes de commandes configurées dans Sylpheed, on peut interfacer un peu ce qu'on veut en bricolant.
On peut re-traiter tous les mails d'une boîte à travers le filtre anti-spam, ou les règles de filtrage, pour organiser après-coup des mails déjà reçus en fonction de nouvelles règles qu'on vient de créer.
Bref, avec un outil comme ça je n'ai jamais ressenti le besoin de subir Thunderbird ou Kmail…
Et sinon je serais probablement resté sous Alpine…
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Yth (Mastodon) . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 5.
Mais en fait, pour faire un DoS, en pratique il faut exploiter une faille, et le symptôme est un déni de service.
Comment tu fais tomber un service avec une attaque simple si tu n'exploite pas une faille dans le service ?
Alors qu'un DDoS c'est autre chose : tu satures le service rendant impossible d'y accéder pour les gens. C'est 2500 personnes qui font la queue à la gendarmerie pour porter plainte contre une vache, et toi qui veut signaler le vandalisme sur ta voiture, ben tu peux pas.
Bref, on joue sur les mots un peu, mais je classifierait plutôt les (D)DoS comme des types d'attaques plutôt que des failles…
Ce qui n'empêche pas de chercher des solutions pour s'en prémunir, mais ces solutions ne sont pas liés à la sécurité intrinsèque de tes outils, ou à la présence ou non de failles logicielles.
Plutôt à l'organisation de ton réseau. Et c'est relativement indépendant des OS sous-jacents.
Bon, inutile de pinailler plus, ça ne fait pas tellement avancer le schmilblick…
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Yth (Mastodon) . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 4.
Mais tout ça ne fait pas du (D)DoS une faille de sécurité en tant que telle.
Ça en fait une attaque, et une attaque affaiblit toujours un peu sa cible, permettant parfois à une autre attaque d'atteindre sa cible.
Une faille c'est un moyen d'atteindre ta cible sans avoir à profiter d'un affaiblissement lié à une attaque massive.
Le gros bouton ON/OFF accessible est une fonctionnalité, pas une faille, si il a été mis là c'est probablement pour une bonne raison. Sinon c'est qu'on a affaire à des bras cassés, et des failles il y en a probablement des douzaines encore plus faciles à exploiter…
Un système sans failles peut quand même tomber, être spoofé, être l'objet de phishing, ou d'arnaques en tout genre.
Ça n'en fait pas des failles de sécurité, même si ça reste des problèmes graves pour lesquels on peut mettre en place des mesures.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Yth (Mastodon) . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 2.
Le déni de service n'est pas une faille de sécurité.
C'est un blocus de camionneurs sur l'autoroute, une grève pas l'occupation des locaux, installer des tentes sur la voie ferrée pour empêcher les trains de partir, etc.
Le service n'est plus rendu, mais il n'y a pas eu de faille de sécurité, l'intégrité du service et de ses données n'est pas engagée.
Ne mélangeons pas tout !
[^] # Re: Mort ?
Posté par Yth (Mastodon) . En réponse au journal Une histoire d'encodage de caractères. Évalué à 8.
Oui, Jésus est né en l'an sept avant la naissance de Jésus.
Récursivement, ça fout un paradoxe temporel de dingue et l'univers implose.
Alors on fait gaffe hein ?