La distribution Debian 11 « Bullseye » a été publiée le 14 août 2021. Cette dépêche est largement tirée de l'annonce du projet.
Après deux ans, un mois et neuf jours de développement, le projet Debian est fier d’annoncer sa nouvelle version stable n° 11 (nom de code « Bullseye ») qui sera suivie pendant les cinq prochaines années grâce à l’effort combiné de l'équipe de sécurité de Debian (EN) et de l'équipe de gestion à long terme de Debian (EN).
Cette version contient plus de 11 294 nouveaux paquets pour un total de 59 551 paquets, avec un nombre significatif de paquets (9 519) marqués comme « obsolètes » et supprimés. 42 821 paquets ont été mis à jour et 5 434 demeurent inchangés.
Sommaire
Les nouveautés
Debian 11 « Bullseye » inclut maintenant notamment les environnements de bureau suivants :
Gnome 3.38 ;
KDE Plasma 5.20 ;
LXDE 11 ;
LXQt 0.16 ;
MATE 1.24 ;
Xfce 4.16.
« Bullseye » est la première version de Debian à fournir un noyau Linux avec la prise en charge du système de fichiers exFAT et qui l’utilise par défaut pour monter les systèmes de fichiers exFAT. Par conséquent, il n’est plus nécessaire d’utiliser l’implémentation du système de fichiers dans l’espace utilisateur fournie par paquet exfat-fuse. Les outils pour créer et vérifier un système de fichiers exFAT sont fournis par le paquet exfatprogs.
La plupart des imprimantes récentes sont capables d’utiliser l’impression et la numérisation sans pilote donc sans avoir besoin des pilotes spécifiques du fabricant (souvent non libres). « Bullseye » introduit un nouveau paquet, ipp-usb, qui utilise le protocole IPP-over-USB indépendant du fabricant et pris en charge par beaucoup d’imprimantes récentes. Cela permet à un périphérique USB d’être vu comme un périphérique réseau. Le dorsal officiel SANE sans pilote est fourni par sane-escl du paquet libsane1 qui utilise le protocole eSCL.
Dans « Bullseye », systemd active par défaut sa fonctionnalité de journal persistant avec un repli implicite sur un stockage volatil. Cela permet aux utilisateurs qui ne dépendent pas d’une fonctionnalité particulière de désinstaller les démons de journalisation traditionnels et de passer à l’utilisation exclusive du journal de systemd.
L’équipe Debian Med a pris part à la lutte contre la COVID-19 en empaquetant des paquets pour la recherche sur le virus au niveau de son séquençage et pour combattre la pandémie avec les outils utilisés en épidémiologie. Ce travail va continuer en mettant l’accent sur les outils d’apprentissage automatique dans ces deux domaines. Le travail de l’équipe sur l’assurance qualité et l’intégration continue est essentiel sur le plan de la cohérence et de la reproductibilité des résultats indispensable dans le domaine scientifique. Le mélange Debian Med possède une série d’applications cruciales pour leurs performances qui bénéficient maintenant de SIMD Everywhere. Pour installer les paquets entretenus par l’équipe Debian Med, il suffit d’installer les métapaquets nommés med-* qui sont en version 3.6.x.
Le chinois, le japonais, le coréen et d’autres langues bénéficient de la nouvelle méthode de saisie Fcitx 5 qui succède à la méthode Fcitx 4, populaire dans « Buster ». Cette nouvelle version prend bien mieux en charge les extensions de Wayland (le gestionnaire d’affichage par défaut).
Debian 11 « Bullseye » inclut de nombreux paquets logiciels mis à jour (plus de 72 % des paquets de la distribution précédente), par exemple :
Apache 2.4.48
Serveur DNS BIND 9.16
Calligra 3.2
Cryptsetup 2.3
Emacs 27.1
GIMP 2.10.22
Collection de compilateurs GNU 10.2
GnuPG 2.2.20
Inkscape 1.0.2
LibreOffice 7.0
Noyaux Linux série 5.10
MariaDB 10.5
OpenSSH 8.4p1
Perl 5.32
PHP7.4
PostgreSQL 13
Python 3, 3.9.1
Rustc 1.48
Samba 4.13
Vim 8.2
plus de 59 000 autres paquets prêts à l’emploi, construits à partir de plus de 30 000 paquets source.
Avec cette large sélection de paquets, ainsi que sa traditionnelle gestion de nombreuses architectures, Debian, une fois de plus, confirme son but d’être le « système d’exploitation universel ». Elle est appropriée pour bien des cas différents d’utilisation : des systèmes de bureau aux mini portables, des serveurs de développement aux systèmes pour grappe, ainsi que des serveurs de bases de données aux serveurs web ou de stockage. En même temps, des efforts supplémentaires d’assurance qualité tels que des tests automatiques d’installation et de mise à niveau pour tous les paquets de l’archive Debian garantissent que « Bullseye » répond aux fortes attentes de nos utilisateurs lors d’une publication stable de Debian.
Un total de neuf architectures sont gérées : PC 64 bits/Intel EM64T/x86-64 (amd64), PC 32 bits/Intel IA-32 (i386), PowerPC 64 bits Motorola/IBM petit-boutiste (ppc64el), IBM S/390 64 bits (s390x), pour ARM, armel et armhf pour les anciens et nouveaux matériels 32 bits plus arm64 pour l’architecture 64 bits « AArch64", et pour MIPS, mipsel (petit-boutiste) pour les matériels 32 bits et mips64el pour le matériel 64 bits petit-boutiste.
Vous voulez l’essayer ?
Si vous voulez simplement essayer Debian 11 « Bullseye » sans l’installer, vous pouvez utiliser une des images autonomes « live » qui chargent et exécutent le système d’exploitation complet, dans un mode en lecture seule, dans la mémoire de votre ordinateur.
Ces images autonomes sont fournies pour les architectures amd64 et i386 et sont disponibles pour des installations à l’aide de DVD, clés USB ou d’amorçage par le réseau. Les utilisateurs peuvent choisir entre plusieurs environnements de bureau : GNOME, KDE Plasma, LXDE, LXQt, MATE et Xfce. Debian « Bullseye » autonome fournit une image autonome standard, ainsi, il est possible d’essayer un système Debian de base sans interface utilisateur graphique.
Si le système d’exploitation vous plaît, vous avez la possibilité de l’installer sur le disque dur de votre machine à partir de l’image autonome. Celle-ci comprend l’installeur indépendant Calamares ainsi que l’installeur Debian standard. Davantage d’informations sont disponibles dans les notes de publication et sur la page de la section des images d’installation autonomes du site de Debian.
Si vous souhaitez installer Debian 11 « Bullseye » directement sur le disque dur de votre ordinateur, vous pouvez choisir parmi les nombreux supports d’installation tels que les disques Blu-ray, CD et DVD et les clefs USB, ainsi que par une connexion réseau. Plusieurs environnements de bureau — Cinnamon, GNOME, KDE Plasma Desktop et Applications, LXDE, LXQt, MATE et Xfce — peuvent être installés grâce à ces images. De plus, des disques « multi-architecture » sont disponibles et permettent l’installation à partir d’un choix entre plusieurs architectures à partir d’un seul disque. Vous pouvez aussi toujours créer un média d’installation amorçable sur clef USB (voir le manuel d’installation pour plus de détails).
Au sein de l’installateur Debian, beaucoup de développement a été réalisé aboutissant à une amélioration de la prise en charge du matériel et à d’autres nouvelles fonctionnalités.
Dans certains cas, une installation réussie peut encore présenter des problèmes d’affichage lors du redémarrage dans le système installé ; pour ces cas, il y a quelques solutions (EN) qui pourraient aider à se connecter quand même. Il existe aussi une procédure basée sur isenkram (EN) qui permet aux utilisateurs de détecter et de corriger l’absence de microcode dans leur système de façon automatique. Bien sûr, il faut peser le pour et le contre de l’utilisation de cet outil dans la mesure où il est probable qu’il nécessitera l’installation de paquets non libres.
En complément à cela, les images d’installation non libres qui incluent les paquets de microcode (EN) ont été améliorées pour qu’elles puissent anticiper le besoin de microcode sur la machine installée (par exemple, pour les cartes graphiques AMD ou Nvidia ou pour les dernières générations de matériel audio d’Intel).
Pour les utilisateurs et utilisatrices de nuage, Debian propose la prise en charge directe de beaucoup des plateformes de nuage bien connues. Les images officielles de Debian sont faciles à sélectionner sur chaque offre d’image. Debian publie également des images OpenStack (EN) toutes prêtes pour les architectures amd64 et arm64, prêtes à être téléchargées et utilisées dans des configurations de nuage locales.
Debian peut maintenant être installée en 76 langues, dont la plupart sont disponibles avec des interfaces utilisateur en mode texte et graphique.
Les images d’installation peuvent être téléchargées dès à présent au moyen de bittorrent (le moyen recommandé), jigdo ou HTTP ; consultez la page Debian sur CD pour plus d’informations. « Bullseye » sera également bientôt disponible sur DVD, CD et disques Blu-ray physiques chez de nombreux distributeurs.
Mise à niveau de Debian
La mise à niveau vers Debian 11 à partir de la version précédente, Debian 10 (nom de code « Buster ») est gérée automatiquement par l’outil de gestion de paquets APT pour la plupart des configurations.
Pour « Bullseye », la suite de sécurité s’appelle maintenant bullseye-security et les utilisateurs devraient adapter leur fichier de liste de sources d’APT en conséquence lors de la mise à niveau. Si votre configuration d’APT comprend également l’épinglage ou la ligne APT::Default-Release, il est vraisemblable qu’elle nécessite aussi des adaptations. Consultez la section Changement de l’organisation de l’archive security des notes de publication pour plus de détails.
Si vous effectuez une mise à niveau à distance, n’oubliez pas de consulter la section Impossible d’établir de nouvelles connexions SSH durant la mise à niveau.
Comme toujours, les systèmes Debian peuvent être mis à niveau sans douleur, sur place et sans période d’indisponibilité forcée, mais il est fortement recommandé de lire les notes de publication ainsi que le manuel d’installation pour d’éventuels problèmes et pour des instructions détaillées sur l’installation et la mise à niveau. Les notes de publications seront améliorées et traduites dans les semaines suivant la publication.
À propos de Debian
Debian est un système d’exploitation libre, développé par plusieurs milliers de volontaires provenant du monde entier qui collaborent à l’aide d’Internet. Les points forts du projet sont l’implication basée sur le volontariat, l’engagement dans le contrat social de Debian et le logiciel libre, ainsi que son attachement à fournir le meilleur système d’exploitation possible. Cette nouvelle version représente une nouvelle étape importante dans ce sens.
Aller plus loin
- Debian (181 clics)
- Debian LTS (82 clics)
- Debian security (32 clics)
- Compilation de 0.A.D Alpha 25 pour Debian Bullseye (56 clics)
- Annonce Debian (61 clics)
# C'est qui, Bullseye ?
Posté par windu.2b . Évalué à 10. Dernière modification le 18 août 2021 à 23:42.
Pour ceux qui, comme moi, se demandent quel personnage de Toy Story est Bullseye : c'est le cheval apparu dans Toy Story 2, et dont le nom français est Pile-Poil.
[^] # Re: C'est qui, Bullseye ?
Posté par vv222 (site web personnel) . Évalué à 5.
Jolie trouvaille de la part des traducteurs, ils ont fait mouche !
[^] # Re: C'est qui, Bullseye ?
Posté par j (site web personnel) . Évalué à 5.
pour plus de détails : https://toy-story.fandom.com/fr/wiki/Pil_Poil
et https://pixar.fandom.com/wiki/Bullseye
# upgrade process
Posté par tuxicoman (site web personnel) . Évalué à -2.
A quand un bouton ou commande de mise a jour de version pour mme michu qui ne veut pas passer du temps à savoir comment editer le source list avec VI dans un terminal?
Sinon, blague a part. Le "apt full-upgrade" direct ne marche pas. Il faut d'abord faire un upgrade puis le full-upgrade.
[^] # Re: upgrade process
Posté par thomasv . Évalué à 3.
J’ai fait deux mises à niveau avec
apt full-upgradehier. Qu’est-ce qui n’a pas fonctionné pour toi ?[^] # Re: upgrade process
Posté par barmic 🦦 . Évalué à 6.
Quelque chose comme ?
Si tu as des dépôts tiers à virer c'est probablement que tu as su les ajouter ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: upgrade process
Posté par vv222 (site web personnel) . Évalué à 10.
Je pense qu’il faut plutôt proposer quelque chose de "moderne" :
[^] # Re: upgrade process
Posté par raphj . Évalué à 7. Dernière modification le 19 août 2021 à 15:07.
Ouais, mais le copier coller d'une longue commande comme ça c'est dangereux, je propose plutôt d'utiliser npx, c'est plus simple que Curl dont on comprend rien aux paramètres, en plus piper vers bash c'est mal, donc :
Je suggère que le script affiche le nombre de paquets vulnérables, et une soupe d'émojis pour indiquer la progression de la mise à jour et sa réussite, du style : « All done! ✨ 🍰 ✨ »
# un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par roger21 . Évalué à 6. Dernière modification le 19 août 2021 à 09:57.
la doc de maj de bullseye précise que l'arborescence de base va changer sur la version 12
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.fr.html#deprecated-components
bookworm c'est une luciole/veilleuse verte et joufflue
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par roger21 . Évalué à 3.
bon le lien vers freedesktop permet de voir que c'est pas vraiment neuf tout ça
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par thomasv . Évalué à 6.
Ce n’est pas neuf dans Debian non plus, puisque c’est l’arborescence utilisée par défaut sur les nouvelles installations depuis Buster (cf. les notes de publication de Debian 10).
Ce qui va changer avec Bookworm, c’est que tous les systèmes passeront sur cette arborescence fusionnée.
Dans les archives de la liste debian-devel, on peut voir que tout le monde n’est pas ravi par cette transition (fil 'merged /usr considered harmful'), donc ça arrive peut-être même trop vite !
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par barmic 🦦 . Évalué à 6.
Ce qui est dommage, c'est que c'est pas l'organisation la plus en vue pour parler de ça.
C'est plus du ressort de FHS. Note je ne dis pas que le changement n'a pas d'intérêt, mais que ça serait intéressant de pousser un FHS 4 pour porter ces changements et élargir la discussion avec les amis bsdistes par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par claudex . Évalué à 3.
Du coup, il y a plus de chance d'avoir les bsdiste avec freedesktop qui se veut généraliste qu'avec FHS qui est géré par le Linux Standard Base workgroup de la Linux Foundation.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par barmic 🦦 . Évalué à 4.
J'ai vraiment un doute. Déjà en terme de groupe de travail l'un est dans la LSB, mais l'autre est dans systemd. Mais la spécification freedesktop ne semble pas être un travail de standardisation avec groupe de travail, mais une documentation pour entérinée le travail fait sur fedora. Les liens entre freedesktop et RedHat forts au détriment des autres acteurs de linux (Gnome/KDE par exemple) est assez habituel et semble encore être le cas ici (indépendamment de la qualité qui en sort).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Et peut être qu'un jour on renommera usr et etc en quelque-chose de parlant !
/Programs et /Configs ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . Évalué à 5.
Tu veux dire https://www.gobolinux.org/ ?
https://link-society.com - https://kubirds.com
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Oui mais avec plus de 3 utilisateurs !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par legranblon (site web personnel) . Évalué à 5.
Bah alors autant renommer en "Program Files" et ProgramData …
… on pourrait même envisager un mappage de Program Files vers Programmes quand le système est localisé Fr_fr histoire de "simplifier" les choses …
Toute ressemblance avec un système existant serait fortuite …
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . Évalué à -2.
Sincèrement, c'est quoi le soucis avec "Program Files" ?
Avant qu'on me réponde : "ça duplique les fichiers (ex: les dlls)" :
C'est facile de voir ce qui est installé avec un simple "ls".
https://link-society.com - https://kubirds.com
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par legranblon (site web personnel) . Évalué à 2.
Avis perso : on s'éloigne vachement du KISS avec ce genre de trucs (espace dans le chemin, pas mal d'applis qui peuvent -ou pas- le gérer correctement, accès au dossier dépendant de la locale …), pour un gain pas particulièrement perceptible (pour rester pudique).
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . Évalué à 2. Dernière modification le 24 août 2021 à 02:41.
Allez, je vais faire l'avocat du diable.
Quoi de plus simple que de "tar xf appli.tgz -C /programs/appli" ?
Pourquoi un gestionnaire de paquet ne pourrait pas installer les dépendances dans /programs et /libraries et gérer les liens symboliques si nécessaire ?
En quoi c'est moins KISS que ce qui est fait aujourd'hui:
Aujourd'hui une appli est éclatée partout sur le système de fichier, et à moins d'avoir le gestionnaire de paquet pour:
Ben c'est pas "KISS" selon moi, alors que tout dans /programs/appli, ça l'est.
Je parlais du concept derrière, pas du détail d'implem. Dans "/programs" il n'y a pas d'espaces.
Une appli n'est pas censée être dépendante de la où elle est installée. La preuve la majeure partie des softs sous linux peuvent être installé dans /bin, /usr/bin, /usr/local/bin, /home/user/.local/bin, /opt/appli/bin, etc…
Donc /programs/appli/bin ça change quoi ?
Sous Windows, c'est l'explorateur qui fait la traduction. Il me semble que la plupart des bureaux GNOME te créent aussi des dossiers dans ton $HOME : Documents, Musics, Videos, etc… dépendant de la locale.
Si ls et cd gèrent que /programmes ca veut dire /programs, au niveau du FS j'ai toujours qu'un seul dossier.
Ou alors, si c'est pas possible, j'ai des liens symboliques (cc Gobolinux).
Windows a su se passer d'un gestionnaire de paquet depuis les 30 dernières années. Il est extrêmement simple de packager pour Windows. Et même la sauvegarde se résume à un simple copier/coller (pour peu que l'application n'utilise pas le registre windows).
D'ailleurs, la retro compatibilité de windows est phénoménale. Je peux installer MS-DOS et upgrade jusqu'à Windows 10 sans soucis.
Je peux travailler avec un installeur standalone, le Marketplace Microsoft, chocolatey, ou simplement copier coller les fichiers dans program files, rien ne se marche dans les pattes.
Essaye d'utiliser 2 gestionnaires de paquets différents sur un même système Linux, et bonjour les emmerdes.
Il est ou le KISS sous Linux ?
Et si tu es développeur, c'est encore pire. Je ne fais plus confiance à APT pour installer mes dépendances, heureusement en python il y a poetry/conda, en Go il y a go mod, en rust il y a cargo, en JS il y a npm/yarn, en Elixir il y a mix et avec Docker il y a ton registry favoris.
Je n'installe même plus mes interpréteurs/compilateurs via le gestionnaire de paquet. J'utilise :
Docker n'est pas dans les dépôts officiels, mais ils fournissent le leur.
Au final, que je travaille sous Windows, dans un WSL, sur un Linux baremetal, mon workflow restera le même, car sous Linux je finis avec plus de choses dans /opt que dans le gestionnaire de paquet.
https://link-society.com - https://kubirds.com
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par Watchwolf . Évalué à 1.
Totalement d'accord !
Linux c'est le bordel comparé à Windows.
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par Psychofox (Mastodon) . Évalué à 7.
Il n'y a rien qui t'empêche d'installer tout ce que tu veux dans /opt/ si ça te change. C'est d'ailleurs de cette manière que bon nombre d'applis proprios sont installées sous linux.
S'il y a une séparation des répertoires, c'est qu'il y a une raison. On sépare binaires, librairies, config et données volatiles. Je ne vois pas en quoi c'est le bordel, au contraire c'est bien rangé.
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . Évalué à 2.
Qu'il y ait une raison, soit. Il y a toujours une raison pour faire les choses d'une certaine façon. Mais dire que cette façon de faire est plus KISS que le reste, c'est juste faux.
C'est une vision orientée système, et non orientée application. Franchement, regardez Gobolinux pour voir ce qu'il est possible de faire tout en restant compatible.
Chacune de ces visions répond à des besoins différents, et il s'avère que dans le second cas, on peut se passer d'un gestionnaire de paquet, et se la jouer à la Slackware (la seule distribution linux vraiment KISS).
Peut-être, mais quid de mon argument qui expose la nécessité d'avoir un gestionnaire de paquet pour savoir qui a installé quoi ?
Si tu m'as lu entièrement, c'est ce que je fais la plupart du temps.
https://link-society.com - https://kubirds.com
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par jyes . Évalué à 9.
En même temps, c’est justement l’intérêt d’un OS de proposer une organisation à une échelle plus large que l‘application, parce-que si tu veux des applis les plus autonomes possibles qui font ce qu’elles veulent et que tu peux mettre où tu veux, tu vas finir par trouver que DOS est l’OS qui te convient le mieux.
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . Évalué à 3.
DOS au moins, c'était KISS.
https://link-society.com - https://kubirds.com
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par claudex . Évalué à 5.
Je ne vois pas en quoi avoir tout dans le même répertoire te permet de savoir qui a installé quoi. Ni même si c'est installé tout court (installer, ça veut souvent dire plus que copier des fichiers, ça veut dire enregistrer des raccourcis pour qu'on puisse trouver l'exécutable rapidement, peut-être une configuration par défaut (dans le registre ?), des services à démarrer…).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . Évalué à -1.
Mauvaise fois.
Dans mon cerveau ça fait tilt que tout ce qui est listé a été installé par firefox.
Dans mon cerveau ça fait pas tilt a qui appartient les 1400 binaires qu'on y trouve.
Et j'explore plus souvent mon système à coup de cd et ls qu'avec un package manager.
Oui, mais rien n'empêche le reste de l'OS d'aller chercher ces informations dans le dossier de l'application.
https://link-society.com - https://kubirds.com
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par claudex . Évalué à 5.
Pas de bol, ça a été installé par wapt.
Comment il sait ce qu'il faut chercher dans ce dossier ? Il y a 5 exécutables mais un seul est à lancer l'utilisateur. Quel fichier de conf il faut utiliser par défaut ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par barmic 🦦 . Évalué à 7.
Pas vraiment. On a de la déduplication active en option sur zfs et probablement sur btrfs. C'est très consommateur en ressource, sinon il y a de la copie en écriture, mais il faut produire les copies, les une à partir des autres (avec
cp --reflinkpar exemple). Ce n'est pas comme ça que fonctionne les gestionnaires de paquets.Quel est l'intérêt par rapport à la commande de ton gestionnaire de paquet ? (qui va pouvoir en plus t'indiquer la version, une description, etc)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par jyes . Évalué à 6.
Vu ce que tu décris, j’ai l‘impression qu’un
lsdans/gnu/store/répondra encore mieux à ton besoin quedirdansC:\Program Files. Et ça règle le problème de la duplication des bibliothèques. Personnellement, j‘aime bien trouver toute la documentation dans/usr/share/docet toutes les configurations dans/etc/mais quitte à changer ces habitudes pour pouvoir lister les logiciels comme des dossiers, la solution de Guix et Nix est autrement plus élégante que le fourre-tout desProgram Files. Et tu n’as pas besoin de changer d‘OS pour en profiter.[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . Évalué à 1.
Oui NixOS est carrément une avancée dans le domaine, surtout au niveau config a un seul endroit <3
https://link-society.com - https://kubirds.com
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par Lutin . Évalué à 10.
Si déjà tous les logiciels respectaient les specs freedesktop XDG machin pour nettoyer un peu le /home ça serait un grand pas.
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 19 août 2021 à 20:16.
User (or Unix) Shared Ressources contient des des éléments partagés par les programmes (bibliothèques logiciels surtout), ainsi que divers éléments mis à disposition de tous les usagers (cas des docs)
Les programmes, au sens de binaires à lancer, sont dans
/bin/ou/sbin/Du moins, c'était la philosophie unixienne (FHS) et
/usr/ne devrait rien contenir qui ne soit pas utilisable quand cette partition est montée en réseau ou en lecture seule par exemple. En tout cas le nommage/Programsne serait que confusant…Editable Text Configurations c'est certes des configurations (au format textuel…) mais plus précisément des configuration globales (ou systèmes comme diraient certaines personnes) mais aussi les paramètres par défaut des applications.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par Cyril Brulebois (site web personnel) . Évalué à 10.
Ça fait des années que certaines configurations globales sont déployées sous
/usr. Quelques exemples :/usr/share/fontconfig/conf.avail/10-autohint.conf/usr/share/X11/xorg.conf.d/40-libinput.conf/usr/share/X11/xorg.conf.d/70-wacom.confEt il est possible de changer du comportement par défaut en créant/modifiant/adaptant ces fichiers sous
/etcen tant qu'admin local.C'est exactement la même chose avec les configurations
systemdetudev, les règles par défaut sont catapultées sous(/usr)/lib/{systemd,udev}et les admins locaux peuvent adapter sous/etc.Pour l'aspect « textuel » d'
/etc, je vois des zip, des clés publiques/privées (SSH, X.509), des trousseaux GPG, et des choses vraiment binaires comme/etc/ld.so.cacheou du Berkeley DB pour les fichiers de postfix. J'ai un peu la flemme de sortir les vieilles sources d'UNIX pour voir à quel point ce « Editable Text Configuration » est un backronym, mais au moins la page wikipedia FHS suggère qu'il y a débat… :)Debian Consultant @ DEBAMAX
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Pour l'aspect textuel, je n'ai pas souvenir d'avoir vu du binaire dans
/etcjusqu'à une époque récente, et même là on avait le fichier compilé à côté du fichier source textuel (cas de pureftp pour son fichier de comptes local par exemple) ; et encore le binaire pouvait être ailleurs (quelque part dans/varnormalement, et il me semble l'avoir déjà vu pour postfix sauf erreur.) Quand aux clés ce sont bien des fichiers textuels héhé.Dans les exemples que tu prends (
fontconfig/conf.availetX11/xorg.conf.d), ce sont justement des ressources mutualisées (et mis dans/usr/sharecomme par hasard, et dans une Debian ils sont souvent posés par des paquets-commonet similaires) ou partagées par les programmes (d'où/usr/libcomme par hasard)Ceci dit mon propos était de signaler que
/usrn'est pas synonyme de/ProgramsMême si les distributions Linux veulent maintenant tout foutre dedans… sujet initial du fil. D'ailleurs quand tu mentionnes du systemd et du udev il ne faut pas oublier que c'est linuxien et sans volonté de respect des conventions…)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Non au majuscule par pitié !
Les chemins courts sont une forces d'UNIX. Marre des dossiers à nom à rallonge ;-)
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Alors:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par groumly . Évalué à 1.
/Applications pour les applis, /Library/Application Support pour la config (ou la variante ~/ pour la config utilisateur).
Par dessus ça, tu peux mettre la config de launchd^W^W systemd dans /Library/LaunchDaemon (ou la variante ~/ pour la config utilisateur).
Rajoute un kernel mach, et ça finira enfin par ressembler à un vrai unix.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 0.
Façon détournée de dire que "vrai unix" c'est "MacOS X" et non "UNIX AT&T" ou "UNIX POSIX"
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par groumly . Évalué à 1.
Tu crois? Troller un vendredi, ca serait pas mon genre.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 20 août 2021 à 22:12.
Il manquera encore une licence privatrice et un prix exorbitant pour que ce soit un VRAI Unix et pas un OS de communistes.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par Loïc Blot (site web personnel) . Évalué à 1.
Waouw, merci de l'information, j'avais oublié ce changement sur mon desktop.
Je suis hyper étonné qu'ils n'aient toujours pas fait ca, Archlinux a fait ce merge au moment où c'était devenu la norme en 2013, il y a donc 8 ans, et ca fera donc 10 ans quand ils sortiront Debian 12 :o
https://lists.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html
C'est même du coup 3 ans avant que systemd arrive sur Archlinux :p
Veepee & UNIX-Experience
# Surprise, retour à eth0
Posté par dr191 . Évalué à 8.
Pour info, petite surprise ici lors du passage de 10 à 11.
Retour au nommage des interfaces réseau non persistent enp3s0 -> eth0. Ca fait mal au premier reboot quand ssh ne répond plus.
Apres branchement clavier et écran, et en créant le fichier /etc/systemd/network/99-default.link, c'est revenu à la normale.
C'est sans doute du à l'historique de ces 2 machines qui ont bien vécues: installation initiale en Lenny, survécu au passage de systemd…
Je crois qu'il faudra prévoir une réinstall from scratch pour la version 12.
[^] # Re: Surprise, retour à eth0
Posté par Faya . Évalué à 5.
Juste pour être sûr de bien comprendre, ce changement est intervenu sur tes machines ("dû à l'historique") mais on a pas à s'attendre à la même blague pour toutes ? Tu as une idée de ce qui a provoqué ça chez toi ?
[^] # Re: Surprise, retour à eth0
Posté par dr191 . Évalué à 5.
Sur ces 2 ebox B202 avec ce soucis, c'est du i386, qui est tjs supporté par Debian, mais sans doute moins testé. Plus l'historique de monté de version qui doit pas aider.
Difficile de diagnostiquer plus avant sur des historiques aussi anciens, mais il faut peut etre être prudent avant de faire ces majs à distance sur des configs aussi chargées.
Sur 2 autres machines x64 "moins" fossilisées ( seulement 8->9->10->11), c'est passé sans ce désagrément.
[^] # Re: Surprise, retour à eth0
Posté par Cyril Brulebois (site web personnel) . Évalué à 7.
Vu d'ici, la différence
i386vs.amd64devrait être absolument sans rapport.Je soupçonne plutôt l'existence ou l'absence d'un fichier, lien, autre, quelque part, que ça soit une vieille règle
udevou quelque chose de similaire, qui a pu provoquer ce souci. Vu le nommage « moderne » que tu avais avant la mise à jour, j'imagine que tu n'avais pas denet.ifnamesqui traîne…En regardant la page de wiki NetworkInterfaceNames j'imagine que tu as pu avoir un
70-persistent-net.rules… mais si c'est bien ça, pourquoi est-il ignoré avant la mise à jour ?Il y a peut-être la réponse dans tes logs.
:)Debian Consultant @ DEBAMAX
[^] # Re: Surprise, retour à eth0
Posté par dr191 . Évalué à 1. Dernière modification le 20 août 2021 à 20:18.
Oui, j'avais aussi pensé à une régle udev mais pourtant:
Et notamment pas le 70-persistent-net.rules que j'avais supprimé lors d'une dernière migration.
J'ai jeter un oeil à /var/log/apt/term.log mais rien d'évident, à mon niveau en tout cas.
Si vous avez d'autres idées de log à regarder, je veux bien regarder par curiosité intellectuelle.
De toute facon entre l'age des machines, et la possible fin de support de i386, pas sur que ca passe à Debian 12.
[^] # Re: Surprise, retour à eth0
Posté par Cyril Brulebois (site web personnel) . Évalué à 2.
Je pensais plutôt aux logs du système avant/après la mise à jour, à comparer avant et après correction.
Je vois typiquement ceci ici (installation Debian 11 standard, pas de migration) dans
/var/log/{kern,syslog}*et/oudmesg(en fonction de l'uptime/du logrotate) :ou bien (installation Debian 10 standard, pas de migration) :
(Ici j'ai cherché le
eth0historique qui se retrouve renommé en autre chose, mais je t'invite à chercher les deux noms dans les logs en question.)Debian Consultant @ DEBAMAX
[^] # Re: Surprise, retour à eth0
Posté par dr191 . Évalué à 1.
Voici ce que j'ai pu trouver.
Je n'ai pas retrouvé de log de démarrage avant mise à jour.
Démarrage après upgrade
puis un peu plus loin
Enfin, après rétablissement de /etc/systemd/network/99-default.link
# Souci de dispo du nouveau noyaux
Posté par xandercagexxx . Évalué à 1.
Perso, la mise à jour (de 10 à 11) cest plutôt bien passé sur un serveur sauf pour ce qui concerne le noyau.
Il n'a pas été ajouté dans /boot et après pas mal de galère, il a fallut faire un
install --reinsintallpour que le nouveau noyau soit ajouté correctement au /boot et donc puisse être utilisé.Cette situation semble pas très courante car difficile de trouver des infos (un apt install me disais que tout était correctement installé avec la bonne version).
[^] # Re: Souci de dispo du nouveau noyau
Posté par Cyril Brulebois (site web personnel) . Évalué à 4.
Tu aurais les logs de la mise à jour ? Typiquement, sous
/var/log/apt/, fichiersterm.log*.J'ai du mal à voir comment l'installation d'un noyau a pu « oublier » de déployer
vmlinuz& friends dans/boot, surtout sans laisser de message d'erreur explicite, et un statut « pas content » au niveau dpkg…ENOSPCchemin faisant ?Note que les deux commandes
apt-getetaptgère la commandereinstall(pourinstall --reins(in)tall).;)Debian Consultant @ DEBAMAX
[^] # Re: Souci de dispo du nouveau noyau
Posté par xandercagexxx . Évalué à 1.
Je n'ai rien trouvé de probant dans le fichier term.log. C'est d'autant plus bizarre que j'avais bien les symlink de visible dans
/(qui pointais donc vers le bon nom de fichier pour le nouveau noyau mais sans qu'il n'y ai de fichier dans/boot).J'ai fait les même étapes sur une autre machine ce weekend, sans problématique de noyau.
Un
apt autoremoveetapt autocleanv entre l'étapeapt upgradeetapt full-upgrade` aurait-il pu avoir un impact sur le noyau disponible ? (Je me demande si j'ai pas fait un autoremove avant de refaire un update avant le full-upgrade).P.S: j'arrive pas à éditer mon message précédent pour l'erreur de frappe ^
# Le retour de Kiwix
Posté par Apichat (site web personnel) . Évalué à 8.
Une autre bonne nouvelle pour cette onzième version de Debian : Le retour de Kiwix dans les dépôts (même dans ceux de Buster) !
Ce retour est bien expliqué dans ce billet.
Kiwix permet notamment d'avoir tout Wikipédia sur son ordi, hors ligne. Son retour sera donc particulièrement utile pour tous les projets éducatifs.
[^] # Re: Le retour de Kiwix
Posté par yal (Mastodon) . Évalué à 1.
Je ne connaissais pas, merci pour le partage :)
# Évolutions de l'installeur
Posté par orfenor . Évalué à 6.
Puisque Cyril Brulebois traîne par ici, peut-on avoir un résumé des travaux effectués sur l'installeur de Debian ?
Et puis, je le trouve toujours aussi bon et souple, très léger aussi, mais je me demande quelles évolutions futures sont prévues ou juste imaginées. Les contraintes d'autrefois avec les multiples architectures supportées, sont-elles encore importantes (c'est juste une question) ?
Voilà voilà et merci pour le boulot!
[^] # Re: Évolutions de l'installeur
Posté par Cyril Brulebois (site web personnel) . Évalué à 10.
J'envisageais de faire une petite rétrospective “d-i vs. Debian 11” sur le blog de ma boîte, comme je travaille trop et ne rédige pas assez, c'est encore sur une todo-list… → C'est parti pour quelques réponses en commentaire sur cette dépêche, en te remerciant pour les questions.
Tu peux jeter un œil aux annonces publiées sur la liste
debian-devel-announce@, à savoir une annonce par version publiée (Alpha ou RC). Dans chacune, j'essaie de reprendre les changements dans les composants individuels qui peuvent être impactants pour les utilisateurs (plus rarement les développeurs) du système d'installation, et de les résumer à destination des utilisateurs avancés.Par exemple, pour le cycle de publication de Debian 11 :
C'est donc le
debian-installerde la RC 3 qui est utilisé pour Debian 11.0, puisque nos développements de dernière minute n'ont pas explosé en vol.C'est principalement de la maintenance corrective, ou ce qui semble maintenant s'appeler du « maintien en condition opérationnelle ». La base de code n'est pas toute récente, elle pourrait bénéficier de simplifications, réécritures, etc. (notamment en ce qui concerne la gestion des différentes architectures) mais globalement le système d'installation actuel a une certaine flexibilité (mode texte, mode graphique, installation par SSH ou console série, démarrage par le réseau, etc.), et les investissements en temps/énergie pour le maintenir en état sont relativement raisonnables. À titre personnel, j'aurais aimé avoir plus de temps à y consacrer pendant ce cycle de publication, et les évolutions pour la gestion des micrologiciels sont arrivées bien tard (cf. introduction de l'annonce D-I Bullseye RC 3), mais elles ont fini par arriver…
Cela étant dit, il ne s'agit pas que de corriger les problèmes quand ils apparaissent. Comme cela peut être constaté en parcourant les annonces mentionnées ci-dessus, il y a régulièrement de petites améliorations à gauche à droite dans tel ou tel composant, à la demande d'utilisateur, ou parce que telle technologie de stockage/réseau/autre propose des options supplémentaires, etc.
Dans les évolutions nécessaires durant le nouveau cycle de publication (Debian 12), il y a le passage de GTK 2 à GTK 3 ou 4. Les premiers paquets GTK 3 n'étaient pas utilisables directement dans le contexte du système d'installation, donc cela a traîné. Simon McVittie a indiqué que le passage à GTK 3+ supposera de revoir l'architecture. Nous ne sommes pas passés loin de la catastrophe à forcer de rester sur GTK 2, d'où mes chaleureux remerciements en introduction de l'annonce D-I Bullseye RC 2 (cf. les entrées
cdebconfetgtk+2.0pour plus de détails).J'ai également des patches qui traînent depuis des années pour proposer, par exemple à mi-chemin du cycle de publication, des images d'installation de
stablequi utiliseraient le noyau destable-backportsafin de simplifier l'installation sur du matériel tout récent, mais il faudrait changer quelques composants (commebase-installer) pour avoir une intégration propre. J'espère que Steve McIntyre (debian-cd) et moi (debian-boot) arriverons à trouver le temps d'intégrer cela dans les mois qui viennent. Note : Il s'agit des noms historiques,debian-cds'occupe « bien évidemment » de produire les images d'installation pendant quedebian-boots'occupe de produire le système d'installation à intégrer dans lesdites images.Peut-être aurons-nous aussi un jour une nouvelle résolution générale concernant les micrologiciels, et peut-être pourrons-nous proposer des images qui ne soient plus marquées au fer rouge de l'aspect unofficial. Cela étant, je ne considère pas qu'une telle évolution relève des prérogatives de l'équipe du système d'installation (
debian-boot) ou de celle qui gère les images d'installation (debian-cd), et Steve semble d'accord sur ce point : c'est au niveau du projet tout entier que cela devrait être discuté, et validé. Cf. mon premier message sur le rapport de bogue #989863.Il y a plus ou moins régulièrement des personnes qui veulent révolutionner le système d'installation. Elles sont libres de proposer des alternatives, et c'est ensuite au projet Debian en général et à l'équipe qui gère le site web, etc. de voir ce qui est mis en avant et comment. Je note qu'un certain nombre de telles propositions reposent sur des images autonomes (« live ») que nous avons déjà du mal à produire… Nous avons d'ailleurs déjà une alternative à D-I (Calamares).
Pour ma part, je contribue à maintenir l'existant depuis bientôt 10 ans (mon tout premier message sur
debian-devel-announce@date de mai 2012), et bien qu'imparfait, cela permet d'installer Debian de versions majeures en versions majeures… Ce n'est pas forcément fascinant côté utilisateur, mais il me semble que cette constance colle plutôt à la réputation de stabilité de Debian.Debian Consultant @ DEBAMAX
[^] # Re: Évolutions de l'installeur
Posté par orfenor . Évalué à 8.
Ben mon vieux, je n'en espérais pas tant! merci pour toutes ces infos.
De mon point de vue d'utilisateur avancé c'est un des meilleur, essentiellement pour sa polyvalence et sa souplesse et parce qu'il permet de revenir en arrière, de voir où on en est et de voir où on va.
[^] # Re: Évolutions de l'installeur
Posté par Vincent Danjean . Évalué à 2.
Cyril, si tu es encore dans le coin, que dois-je faire pour avoir un retour sur le patch proposé dans https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913431 (partman-base: Add support for kiB, MiB, … input) ?
En tout cas, merci pour le boulot sur l'installer. Je l'utilise et l'apprécie vraiment beaucoup (la plupart du temps en mode texte, assez souvent en mode rescue dès que j'ai un problème sur une machine)
# Mon seul regret : freeipa-client
Posté par rahan . Évalué à 4.
Mon seul regret de cette version de Debian c'est l'absence de FreeIPA-client. Toutes mes machines s'authentifient sur 2 serveurs FreeIPA. Je vais devoir attendre que le paquet apparaisse dans les backports avant de faire la mises à jour…
Par contre je ne sais pas comment est décidé du portage d'un paquet vers backports. Visiblement il faut déjà que le paquet migre vers testing…
[^] # Re: Mon seul regret : freeipa-client
Posté par vv222 (site web personnel) . Évalué à 5.
En effet, il faut que le paquet soit déjà dans testing. Ensuite il faut qu’il soit suffisamment utilisé pour qu’un mainteneur considère que ça vaut le coup qu’il prenne de son temps pour maintenir le backport.
À savoir que si un paquet est déjà dans testing mais sans backport officiel, je suis en train de bricoler un petit outil pour construire des backports à partir des paquets sources dispo via les dépôts Debian : Debian backports builder
Attention, ce n’est testé que sur quelques unes de mes machines, pas documenté, et avec des valeurs hardcodées comme l’adresse locale de mon instance de apt-cacher-ng. Et cette situation ne changera que si des tickets sont ouverts sur la forge donnée en lien pour le requérir ;)
[^] # Re: Mon seul regret : freeipa-client
Posté par claudex . Évalué à 5.
Si tu es intéressé par cette migration, je te conseille de compiler le paquet testing sur stable et de vérifier qu'il fonctionne sans problème pour le rapporter au mainteneur pour qu'il fasse le backport.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mon seul regret : freeipa-client
Posté par koopa . Évalué à 1.
Je suis dans la même situation: j'ai découvert qu'il manquait le paquet freeipa-client après avoir migré une de mes machines. Mais plutôt que de revenir en arrière, j'ai installé manuellement le paquet depuis sid.
C'est assez laborieux, car il faut aussi installer toutes les dépendances ( les 5 ou 6 paquets qui ont ipa dans leurs noms) et qui ont aussi été retiré bullseye
Lorsque toutes les dépendances manquantes ont été installées, il suffit de terminer l'installation par
apt install --fix-brokenEt pour l'instant ça a l'air de bien fonctionner.
[^] # Re: Mon seul regret : freeipa-client
Posté par sebas . Évalué à 1.
Quand c'est comme ça et que j'ai besoin d'un paquet venant de sid ou testing, et qu'il y a plus de 2 ou 3 dépendances, j'intègre sid ou testing dans mon debian.list (normalement, main suffit, pour ne pas avoir à charger la liste complète des paquets), puis un apt-update et une simulation pour voir si ça colle (ne pas oublier de rétablir debian.list en fin de procédure :-))
Dans ce cas, il semble que je chargerais beaucoup plus de paquets de sid que tu as eu besoin de le faire (peut-être parce que freeIPA n'était pas installé dans ma buster ?), mais, comme mon système reste cohérent, ça ne m'a jamais posé de problème.
Dans ce cas, la simulation me donne :
# Un total de neuf architectures sont gérées=> Et RISC-V????
Posté par tao popus . Évalué à 1. Dernière modification le 24 août 2021 à 15:45.
Je l'ai installé en version RISC-V il y a quelque mois, les mises à jour sont toujours présentes. C'est peut-être pas totalement officiellement supporté ?
ps. je crois que j'ai compris, il n'y a pas d'« ISO » tout prêt, il faut debootstraper, c'est la différence.
[^] # Re: Un total de neuf architectures sont gérées=> Et RISC-V????
Posté par claudex . Évalué à 4.
La différence, c'est que RISC-V n'est pas officiellement supporté https://wiki.debian.org/SupportedArchitectures
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# bonne cuvée selon Jack Wallen
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
https://www.techrepublic.com/article/debian-11-moving-forward-while-standing-still/
un article sobre et intéressant à sa manière.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.