freem a écrit 5019 commentaires

Ça ne serait pas un projet inintéressant (j'y pense, en vrai), mais je pense que je manque de connaissances, d'expérience en gestion système. Il y a aussi des points qui me semblent mal branlés, mais probable que je ne comprenne juste pas la raison derrière.

Notamment:

• pas encore assez d'expérience avec runit, comme le prouve ma tâche de ce jour: sv check $DAEMON ferme le descripteur de fichier 2 (stdout) avant d'exécuter $SVDIR/$DAEMON/check. Du coup, si le fichier check écrit quelque chose dans stdout, le script plante, ce qui fait croire que le daemon n'est pas fonctionnel… dans mon cas, c'était un tunnel ssh inversé, ce qui mène a un reset du tunnel (le daemon était un watchdog codé à la va-vite) entraînant une sur-consommation de données (parce qu'une liaison ssh, ça bouffe un max a établir, et je n'ai pas étudié IPSEC, donc les VPN, pour ça que je suis parti sur cette solution: je suis dev moi, pas admin);
• gestion des paquets: j'adore le format des binaires debian (une archive cpio qui regroupe 1 fichier texte et 2 tarball, on pourrait en pratique réimplémenter dpkg en shell! voire, ne pas avoir besoin d'installer un paquet pour l'utiliser, si on le montais directement… ça éliminerai peut-être des race-conditions?), mais certains trucs dedans me gênent, genre les scripts pré/post inst/rm. Il y a aussi le fait d'être obligé d'être root pour utiliser apt (je veux dire, on ne peux pas installer de paquets juste pour un seul user, et, justement, j'aime pas l'idée d'utiliser plusieurs systèmes de paquets) qui me gêne, le fait que dpkg ne soit pas parallélisé… sur des points plus techno-politiques, je trouve dommage qu'un daemon soit systématiquement activé quand il est installé, et que la doc soit souvent séparée du paquet principal: quand on code (du C ou juste de simples scripts) on a du coup tendance a bloater le système pour rien, et trouver la doc est pénible;
• je suis toujours incapable de compiler un kernel. Enfin, je sais le compiler, mais juste si j'ai une configuration fonctionnelle. Je ne saurais même pas me passer d'un initrd, alors si c'est juste pour faire une Nième distro comme les autres, je pense que le net peut se passer de bruit inutile supplémentaire;
• j'étudie en ce moment le déploiement d'un LDAP+kerberos. C'est assez difficile de trouver des explications claires, alors que je pense que ce type d'outils devrais être bien intégrés à une distro. Si je comprend pas comment ça marche, je ne peux pas les intégrer;
• je ne sais pas configurer d'outils de monitoring digne de ce nom. Je suis à peine capable de balancer des logs dans svlogd, mais si les logs ne sont jamais lus ou ne déclenchent pas d'alerte, alors ils ne servent pas a grand chose;
• idem pour le backup;
• idem pour le chiffrement;

Bref, j'ai encore un peu de chemin a faire avant de m'attaquer à un truc aussi complet que la création d'une distro. Enfin, si je veux qu'elle apporte vraiment quelque chose.
Parce que je pense qu'il y a de la place pour de nouvelles distro: je verrai bien une distro qui ait un coeur stable et soit relativement simple a installer, comme Debian, mais axée codeurs (que ce soit du C, du python, du java, du bash ou autre). Si on pouvait avoir du dpkg qui marche sans être root, on pourrait du coup intégrer des dépôts "contrib" pour le code "à l'arrache", pas officiellement supportés, comme ce que fait archlinux.

Si c'est juste forker Debian pour refourguer des paquets debian mais avec juste la sélection par défaut et le fond d'écran officiel qui change, je pense sincèrement que c'est pas la peine. Il y a déjà bien assez de variantes de Mint ou d'Ubuntu comme ça.

[edit]
Ah, j'oubliais, je ne sais toujours pas utiliser docker, SElinux ou AppArmor, les cgroups… qui sont pourtant dans l'air du temps. Donc, vraiment, vraiment beaucoup de chemin à faire :)

Salut.

Si tu considères (comme moi) que l'installateur de Debian installe trop de merdes par défaut, tu peux utiliser (c)debootstrap (l'un ou l'autre, peu importe).

Je préviens, c'est une méthode d'installation très "low level", faut connaître son système un minimum, mais bon, on est sur linuxfr ici, ça devrais donc aller.

Pour détailler un peu plus, quand j'installe une Debian maintenant, je commence par booter le CD en mode "dépannage" ou whatever. Je réponds vite fait à la chiée de questions dont on devrait se foutre royalement dans ce mode (domaine, nom de la machine, ce genre de choses) ainsi qu'a celles utiles (config réseau, sur quelle partition me chrooter ou juste me chrooter dans le contexte de l'installateur) en prenant soin de chrooter dans le contexte de l'installateur.

De là, je fais un p'tit fdisk, histoire de préparer mon disque dur (bon, certes, c'est chiant pour le boot UEFI vu qu'il faut bricoler l'UUID de la partoche de boot, du coup j'ai tendance a booter en mode legacy la 1ère fois, et corriger ça ensuite), que j'enchaîne avec quelques mkfs bien sentis. Étape finale: monter la future "/", y créer les dossiers qui vont bien (dans mon cas, /boot/EFI, /var, /home, et le jour ou je serais motivé pour que mon système boot en read-only, probablement le /usr) et y monter les partitions.

Un petit debootstrap --variant=minbase buster /target plus tard, le système réellement minimal est prêt.

for i in dev proc sys
do
  mount --bind /$i /target/$i
done

fini de préparer le chroot /target, ou j'invoque l'installation des paquets qui me permettrons d'avoir un système autonome: apt-get install --no-install-recommends linux-image-amd64 syslinux syslinux-efi syslinux-common busybox vim aptitude runit-init sudo.

L'oeil averti notera que je me permets du confort inutile avec vim, sudo et aptitude, j'aurai pu me passer du 1er puisqu'un close vi est embarqué dans busybox, les autres… bon, bref.
Il notera également l'absence de grub, car je préfère et de très loin syslinux, malgré le fait de devoir copier manuellement (oh mon dieu, une copie manuelle!) les fichiers /initrd et /vmlinuz dans la partition de boot. Je pourrais sûrement installer un hook dans dpkg, mais je n'ai jamais cherché comment faire.
Pour finir, le troll averti notera l'absence de systemd, remplacé par syslinux, Debian 10 mettant à disposition un paquet syslinux-init qui permets de l'utiliser comme système d'init.

Création d'un user qui fait partie de quelques groupes (sudo ici): useradd -m -G sudo user -s /bin/bash , modification des passwords de user et root via passwd ou chpasswd (bien utile pour les scripts, le 2nd) et il me sera possible de me loguer.

Création d'un fichier syslinux.cfg, installation du boot loader et copie des kernel/initrd:

timeout 50
outimeout buster
default buster
prompt 0

ui vesamenu.c32
menu title oOo Chargement du démarrage OoO
append ro

label buster
    menu label Buster
    linux  /buster/vmlinuz
    initrd /buster/initrd.img
    append root=LABEL=main_sys

dd if=/usr/lib/syslinux/gptmbr of=/dev/$TARGET
syslinux -i /dev/$TARGET -d /mnt/bios
mount /dev/$TARGET /mnt
cp -r /usr/lib/syslinux/modules/* /mnt
cp /usr/lib/SYSLINUX.EFI/efi32/syslinux.efi /mnt/efi32/
cp /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi /mnt/efi64/
cp $SOURCE/syslinux.cfg /mnt/bios
cp $SOURCE/syslinux.cfg /mnt/efi32
cp $SOURCE/syslinux.cfg /mnt/efi64
mkdir /mnt/distro
cp /vmlinuz /initrd.img /mnt/distro

Reste plus qu'à créer quelques fichiers systèmes: /etc/fstab et /etc/hostname et configurer le système est bootable.

Bon, je vais être honnête:

• je n'ai jamais utilisé l'efi32,
• d'habitude je ne copie que les modules dont j'ai besoin,
• l'efi64 nécessite quelques autres manipulations pour être réellement utilisable, à base d'efibootmgr, qui ne fonctionne que si le système a booté en mode efi. Pour ça, suivre les excellentes instructions du wiki d'archlinux
• j'ai juste testé ça pour Debian, d'où le "buster" dans debootstrap,
• il est possible de tout installer direct du debootstrap,
• j'utilise perso un proxy apt nommé apt-cacher-ng,

m'enfin, chez moi, ça marche. Si avec ça, t'as encore des cochonneries installées, faut vraiment penser à changer de distro.

En même temps, même s'il sort de ses fonctions a tous les niveaux, il gardera une prestance non négligeable, en tant que fondateur.
Et puis, pas besoin de titre officiel pour un chef d'emmerdeurs. Il pourrait très bien continuer de l'être sans être le chef suprême.

Je suppose que c'est une page qui se tourne, je n'apprécie pas trop le personnage ni les écrits de la GNU/FSF que j'ai lus (j'en ai pas lus beaucoup: les *GPL&co v2, les règles de codage d'un «bon projet GNU» il y a quelques années… c'est tout) mais il est indéniable qu'on lui en doit pas mal. Et s'il n'avait pas eu son caractère, il n'aurait probablement pas osé faire autant. Je ne connais pas de projet libre d'envergure qui n'ait pas un leader au comportement peu diplomatique a sa tête, je pense.

Quant au sujet de ses déclarations, perso, mon avis la-dessus est claire (bien que peut-être erronée, j'ai autre chose a faire que suivre la presse people, faut encore que je finisse de me former sur kerberos+ldap): il a émis des opinions sur l'accusation faite sur une personne qu'il appréciait ou respectait, avant un jugement, donc pendant que cette personne devrait être présumée innocente.

A vue de nez, le matériel semble ne pas être lié correctement après reboot (il ne trouve pas le périphérique). Peut-être que ça viens d'udev. Peu probable cependant.

Je te suggérerais dans le prompt busybox de lister les fichiers dans /dev et /dev/disks/by-uuid, je suis personnellement intrigué par le fait qu'il te parle de mmcblk0p1 pour un PC (à moins qu'il n'y ait réellement un composant soudé, comme pour une beaglebone black?).
Je me serais plutôt attendu a ce qu'il râle de l'absence de /dev/sda1 ou d'un imbuvable 'UUID=foo-bar-baz-deadbeaf' (trouvables dans /dev/disks/by-uuid).

Si tu trouves une partition dans /dev, tu peux ensuite essayer de le passer au boot à grub, en ajoutant "root=/foo/bar" au prompt. Je ne connais pas grub, donc je ne pourrais pas te donner la liste des étapes précises, par contre. Me semble que la touche "e" permets de modifier les entrées, d'accéder a un éditeur de texte en ligne, à vérifier (notes qu'il sera probablement en qwerty).
Si ça corrige (temporairement, vu que ça ne modifiera pas la config réelle du système) le problème, il faudra alors voir pour modifier la config de grub.

Pour le reste, petit conseil de ma part: si tu prévois d'installer des Debian sur des machines, soit assures-toi qu'elles aient un port Éthernet, soit d'avoir un dongle USB WiFi ou Ethernet sous le coude, de telle sorte que tu puisses passer par les pilotes USB et donc te connecter au net. Ce genre de machins la. Je ne fais pas de pub, jamais testé ce modèle, c'est juste histoire que tu voies ce dont je parle.
La raison est que Debian n'intègre pas de code non libre sur ses ISO d'install, et que la plus grande majorité des puces WiFi ne sont pas libres. Pour s'épargner ce genre de problème, utiliser une distribution axée grand publique et sans idéal politique telle qu'Ubuntu serait peut-être mieux (même si perso j'accepte ces "désagréments", ce n'est peut-être pas ton cas).

Quasiment aucune, et juste des distro mineures inconnues, type Debian et ses filles.

Ironie a part, le paquet perl-base, qui est celui qui contiens l'exécutable perl, a une priorité de type "required" et est classé comme "Essential". Il est installé par debootstrap dans tous les cas, contrairement au noyau, à init, à python…

perl-base est requis de manière "Pre-Depends" (ce qui veut dire qu'il doit être installé et configuré avant même d'imaginer installer celui qui en dépend) par: debconf, liblocale-gettext-perl.

Sur ma Debian (bon, chiffres cassés par le fait que j'ai l'archi i386 activée par contre, mais les ordres de grandeur restent), 4788 paquets sont marqués comme implémentés en perl (par les debtags, qui ne sont pas forcément complets), 8003 en C, 2742 en C++, pour donner une idée. Pour python, qui selon certains risque de remplacer perl, on ne parle "que" de 2313 paquets. Autrement dit: C => 1er, perl => 2nd, C++ => 3eme, python => 4eme. Les autres sont a moins de 400.
Je suis pour le coup assez surpris de ces résultats, j'aurais pensé C++ en 2nde place, et java plus haut.
M'enfin, au vu de ces chiffres, le C++ mourra avant perl.

Ubuntu a certes dérivé de Debian, mais je doute que ça soit au point de pouvoir se permettre de se passer de perl.

De mon point de vue, de toute façon, perl ne joue pas dans la même catégorie que les autres, c'est un langage spécialisé dans le traitement de texte brut, pas un langage généraliste comme l'est python.
Perso, au boulot, quand je dois manipuler les systèmes embarqués que l'on vend a distance, plutôt que d'installer python et ses nombreuses batteries pour utiliser puppet/ansible/autre, je me contente de perl et de rex, histoire d'installer moins de trucs (j'ai un doute par contre sur le fait que le paquet "perl" complet est requis. Me semble que oui.).

Avant tout: je ne suis pas expert sur le sujet, je n'ai fait que creuser la surface, peut-être pas avec des docs a jour, et c'était il y a quelques années.

mais openGl utilise la libX pour communiquer avec le serveur X ?

OpenGL est un standard relativement générique. Son implémentation libre sous linux, nommée mesa, est, elle très liée à X11 si ma mémoire est bonne.

Il s'agit d'une API de bas niveau (sur ça, mon point de vue diffère de celui de moi1392 plus bas), puisque la seule chose que sait gérer OpenGL à ma connaissance, sont des polygones convexes, donc les logiciels qui génèrent du code OpenGL doivent implémenter une étape dite de tesselation, que ce soit par l'implémentation d'un shader ou autre méthode. Ou, bien entendu, ne pas utiliser de polygones convexes.

Le lien avec X11 se résume au fait de devoir partager un buffer commun, X11 étant initialement conçu pour du rendu logiciel au travers d'un réseau, tandis qu'opengl vise la performance avec toutes les parties du rendu sur la même machine.

Mon explication est a prendre avec des pincettes, par contre: ça fait longtemps que j'ai étudié ça, et j'ai pas étudié a l'école, mais par moi-même, en creusant le net, ce qui implique des informations erronées, obsolètes ou incomplètes.

LLVM est une toolchain géniale. Mais la license ultra-permissive made-in-apple de LLVM a juste ouvert la porte a une génération entière de compilo dégeulasse qui resteront imbuvables et buggés alors que ces même compilateurs étaient sur la voie de l'exctinction, pour le bien commun.

Moi, j'ai constaté que, depuis que LLVM a pris en popularité, pour des raisons techniques (je l'ai adopté initialement parce que son usage de RAM/process était divisé par 2 comparé à GCC, ce qui m'a permis de coder dans le train en utilisant 5 process au lieu de 2 sur un netbook ayant 1Gio de RAM, sans parler des erreur de templates qui n'étaient déchiffrable qu'avec Clang. Oui, c'était avant C++11), gcc s'est méchamment amélioré, même si je ne considère toujours pas qu'il soit égal. Du coup, je compile en debug avec clang, et en release (because la cible est Debian, et autant éviter les emmerdes d'ABI) avec gcc.
Du coup, j'ai les 2 familles de warn/errors, et j'adore ça, je suis obligé de coder plus proprement, d'avoir un code plus explicite sur son intention (j'active tous les warn, sauf certains que je désactive intentionnellement si je pense comprendre leur raison).

Mais peut-être que, justement, GCC était l'un de ces «compilo dégeulasse»?

Perso, j'aimais bien bitbucket avant qu'ils ne s'amusent a essayer de copie github, mais le résultat a été que le site est passé de plus rapide a consulter (et pas quun peu) à tellement plus lent, avec moins de projets dessus. Ah, ce très cher diable n'a pas fini de nous emmerder.

Ironiquement, sourceforge le mort est lui, toujours utilisé par pas mal de projets pour héberger les release. Bon, j'ai link vers un seul projet, mais il s'agit d'un projet né après la «mort» de SF, né sur github, qui a, en bien moins d'années d'existence que SF quand on l'a déclaré à fuir, mangé un bel exode (pas de ref, ici, dommage, juste un sentiment, mais c'est p'tet juste a cause du vacarme que quelques-un ont causé).

Bref, a mes yeux, github, gitlab, atlassian restent des trucs "de hypster", SF le mort reste ma référence en terme de qualité pour qui recherche un projet auquel participer, de truc facile a utiliser.
À moins que je ne me trompe, github ne supporte toujours pas les ML, par exemple, et si la diffusion de release est régulièrement préférée via SF (malgré les problèmes du passé), il doit y avoir une raison.
Pour ma part, j'ajouterais également que le principe du "fork the original, then clone on your system, then branch, then push, then re-push, then hope" promu par github est franchement douteux, et encourage a beaucoup de blabla même pour un patch de moins de 15 lignes.
Depuis quelques expériences, en fait, j'ai arrêté de contribuer sur un projet qui n'a pas de canal "libre" style irc ou ML, surtout ML. La latence avec les sites type github est bien pénible, et le moindre correctif de patch est bien trop laborieux, nettement plus qu'envoyer un patch par mail.

Juste, demandes leur a ces zouaves (hum, désolé pour les vrais, j'utilise le terme plutôt dans ce sens) si ils ont aussi l'intention de forker gigolo, entres autres. Ou git. Et j'oublie ici pas mal de noms de projets libres qui m'ont bien fait rires quand j'ai compris un sens possible du nom… dans ma langue et culture natale ou pas.

Bref, pour le coup, je pense que contre la connerie, le silence est d'or, et vous avez bien fait de ne pas répondre. Je ne sais pas pour les autres, mais ma sympathie vous est plus qu'acquise.

es sauts sont une plaie pour la CPU qui essaie de commencer son travail en avance (pipelining) et doit donc jeter tout le décodage qu'elle a fait pour rien).

C'est pas très utile, mais pour info, j'ai toujours entendu parler du "débouclage" (loop unroll?) de code comme optimisation.
Je n'ai eu l'occasion de m'en servir pour la 1ère fois que dernièrement (afficher des trucs via /dev/fb0 demande de traiter chaque pixel séparément) et j'ai pu en copiant/collant 8 fois le contenu de ma boucle (et multiplier les incréments par 8, forcément) passer de 20ms de temps a 8ms. Je soupçonne quand même le compilo d'avoir utilisé SSE, mais je maîtrise pas du tout le sujet (du coup, j'étudie un peu cette hypothèse, mais dur de trouver des infos sur le sujet).
Faudrait que je me replonge dans l'asm, pour comprendre, mais j'ai quasi tout oublié…

Euh … Monter a 75% d'occupation CPU, c'est loin d'être négligeable

J'admets.

Je dois être marginal alors.

Si c'est la majorité de tes usages réseau non-local, alors clairement, je pense que c'est le cas. Et dans ce cas, je pense qu'il fautque je précise que je respecte plus cette marge que la norme (ce n'est pas le seul cas).

Ce serait comle se dire "je m'en fous de la consommation de ma voiture (ou des rejets CO2), ya des camions qui roule sur la route et consomment (ou rejettent) bien plus"

Je suis d'accord avec toi, de base, mais du coup, ne devrait-on pas considérer la totalité du système? Je suis né en 86, je me souviens de vieilles machines, qui faisaient du traitement de texte. Je n'ai connu le net que dans les années 2000, les débuts de google, je crois.
Je n'ai pas l'impression de faire plus de choses plus vite, de nos jours. Par coutre, oui, je vois qu'il ya de jolies transparences, des coins arrondis, etc etc… qui ne servent a rien, mais, c'est joli.

Perso, depuis plusieurs années je suis passé à du tiling, justement parce que bon, je préfère passer 2H a apprendre a utiliser un truc, que de supporter du soft hyper lent. Pas par considération pour la planète, juste par confort personnel. Dans ce confort personnel, j'inclue la réduction des douleurs de poignet liées a prendre la souris pour la moindre action, d'ailleurs.

Sauf que la majorité, aka les non marginaux, semble préférer le bling-bling. Même si c'est plus lent, mauvais pour la planète, mauvais pour la santé (au niveau pro, notamment)…

Cet article est bien entendu écrit dans le but de faire peur aux utilisateurs de MySQL pour les convaincre d’utiliser un vrai produit professionnel comme Microsoft SQL Server et non pas un produit de bidouilleur comme MySQL, ce qui tombe bien puisque Microsoft SQL Server est disponible depuis quelques mois sous Linux.

Sans aller jusque la, je me contenterais de dire que ce truc est paru sur developpez.com. Ce site était une mine d'or il y a 15 ans (aux yeux du débutant que j'étais alors), mais pour ma part j'ai souvenir que ce site était plus orienté "technique" que "décideurs" alors qu'aujourd'hui ça semble être l'inverse. Ca explique le fait que je ne le consulte d'ailleurs plus trop, trop de bullshit, pas assez d'informations objectives, et dans les commentaires, pas loin de 0 critique argumentées en moyenne, et quand il y en a, personne ne semble les lire.

C'était un demi trait d'humour. Ce que je voulais dire, c'est surtout qu'il est probable que de toute façon l'outil qui va le plus être utilisé est un navigateur web, et je serai peu surpris que ça bouffe bien plus que wicd, avec la tétrachiée de JS dans la majorité des sites web.
Après, oui, forcément, on est pas obligé, on peu utiliser un client lourd (et dans le cas de thunderbird, j'ai bien l'impression qu'il inclue le moteur de rendu de FF, je me demande d'ailleurs ce que ça ferait d'ouvrir un mail avec du JS?) pour les mail, utiliser irc, faire du ssh & co, mais je crains que ça ne devienne marginal a notre époque.

Aurais-tu des alternatives à me proposer ? C'est ce que j'ai de plus pratique aujourd'hui pour connecter mon ordinateur portable à divers réseaux lors de mes déplacements ou chez moi (wifi de mon domicile, chez la famille, sur mon smartphone, éventuellement comme tu dis pour accéder à des réseaux genre hotel).

Perso, j'utilise juste wpasupplicant, mais comme je l'ai dis, je ne m'en sers que pour les réseaux wifi avec wpa, je ne sais pas configurer mon système pour les réseaux wep ou non protégés, donc, non, je n'ai pas d'alternative a te proposer.
Enfin, sauf d'utiliser wpasupplicant, mais j'imagine que l'idée d'ajouter tes clés wifi a un fichier texte puis relancer un daemon ne te paraît pas pratique (pas besoin de les supprimer, il utilise la clé associée au réseau courant, jamais essayé dans la situation ou il y aurait 2 réseaux connus en même temmps).

C'est pas comme si les notes non massives était pertinentes, non plus… Ironiquement, d'ailleurs.

systemd ça devient vraiment n'importe quoi.

T'inquiètes, bientôt il intégrera le noyau, ça ira mieux après.

Est-ce la faute du langage ou celle du développeur? Parce que si c'est rapport au fait des langages interprétés, je te rappelle que la quasi totalité des sites web dynamiques sont implémentés en PHP ou ruby, quelques uns en perl, mais rares sont ceux basés sur des CGI en C, C++ ou autre langage compilés.
Accessoirement, python dispose, de mémoire, d'au moins un compilateur.
Le HTML lui-même gagnerais énormément a être compressé, en terme d'efficacité ce truc est une aberration.
Et, pour le coup, wicd sert plus a utiliser le web qu'internet.

Moi, je pense que c'est aussi la faute aux utilisateurs: pourquoi tu utilises wicd? C'est pas comme s'il n'y avais pas moyen de s'en passer… et personnellement, je n'ai utilisé ce genre de truc que pour accéder a des réseaux non chiffrés (genre hotels), parce qu'ironiquement, je ne sais pas configurer mon système pour ces réseaux, alors que c'est tellement simple de le faire pour du wpa.
Dans ta distribution, je n'ai aucun doute qu'une quantité non négligeable de choses se reposent sur du shell, du perl ou du python.

Oups, j'ai marché dedans.

Merci pour les explications.

c’était pas mon PC … Malheureusement …

Peux-tu encore contacter la personne a qui il a appartenu? Cela pourrait aider. Sinon, si elle a réussi, on finira bien par y arriver, ça sera juste plus long.

Pour faire écho au commentaire ci-dessus, sur le sujet de l'UEFI, il existe ce qui s'appelle le «secure boot» qui permets de ne démarrer que des systèmes d'exploitations reconnus par l'UEFI.

Dans ce cas de figure, il existe plusieurs cas, notamment:

• les signatures sont hard-codées, il est impossible d'en ajouter, d'en supprimer ou de les désactiver: j'ai jamais rencontré le cas, et j'espère que c'est un mythe, parce que sinon, va falloir aller voir un hacker (pas dans le sens pirate cher à la presse, dans le sens noble du terme) qui gère, genre, vraiment;
• il est possible de désactiver le secure boot: c'est ma solution favorite, je trouve ça superflu pour des machines perso. Le fait que cette solution n'empêche pas le boot par UEFI est pratique, on a les avantages de l'UEFI sans la prise de tête si son OS n'as pas de clé ou sans s'emmerder a l'ajouter à l'UEFI;
• il faut passer en mode legacy boot, seconde solution la plus simple;
• il est possible d'ajouter la signature du noyau/boot loader à l'UEFI, mais impossible de booter en mode legacy ou sans secure-boot: ton système n'est alors compatible qu'avec peu de distros, notamment Ubuntu, et je ne connais pas les détails;

On n'est pas dredi, mais, je ne peux pas résister…

le groupe input suffit et je pourrais donc modifier le service systemd pour lancer le démon avec des droits plus restreints

Dans la ligner de commande, ou équivalent, utiliser chpst nobody:input [command] devrais faire le boulot.
La commande chpst est fournie, chez Debian, via le paquet runit, et j'ai eu l'agréable surprise de constater en passant a Debian 10, une nouvelle implémentation officielle du méta-paquet "init": "runit-init" (c'est un peu pour ça que je me permets cette digression, faut que je vérifies certaines choses avec, et si ça déconne ou si je peux améliorer, voire comment aider, si y'a pas trop de tours autour du pot…).

Pour les capabilities, c'est juste pas le rôle du système d'init de gérer ça, c'est le rôle du système de paquets, vu que, de ce que j'en comprend, c'est lié au fichier lui-même. Je reconnaît ne pas y comprendre grand chose, cela dit. Et puis, systemd gérera bientôt le boot, alors les paquets, qui sait?

Plus sérieusement, je pense que la gestion par groupes est bien plus pertinente que la gestion par capabilities: déjà, moins de risques que la capability nécessaire soit la cap' DIEU (je me comprend, flemme de rechercher le lien dans lequel il était expliqué qu'une cap' était utilisée pour tout ce qui n'avais pas de catégorie, ce qui résultait en en une cap' "root"), de plus c'est plus portable, et «accessoirement», pas besoin d'être root pour installer le binaire, parce que de ce que je sais, pour donner a un binaire des capacités, il faut être root (cf remarque précédente sur mon niveau de compréhension du sujet).

Bon, j'avoue ne pas encore connaître vraiment les bases de ce monde la, je ne sais pas en détails comment marche le système de droits: est-ce un processus sous root qui initialise tous le /dev avec divers user:groups? Se sert-il de capabilities? Je sais pas. Faudrait que j'aille jouer avec hurd, je pense que ça m'en apprendrais beaucoup sur le sujet, du fait de se baser sur une philosophie différente. Ou les BSD, chose que je me promets de faire depuis des années, mais a chaque fois je le fais que via VM, ça risque pas de me motiver…

Effectivement par la suite je vais installer un noyau stable pour le au cas ou ça sera plus sage …

Plutôt une distro "complète", pas besoin de bureau super joli, juste assez d'outils pour que toi tu te sentes apte a dépanner. Enfin, c'est ce que je fais :)

Du coup si je vais tous supprimer de manière Windowsienne je fais comment je prends un clef bootable et au démarrage je fais F12 ?

Oui.
Ou alors un autre moyen que j'ai oublié de mentionner mais qui nécessite une bonne connaissance du système: debootstrap.
Je te conseilles l'installation par clé USB quand même, c'est plus simple (j'ai mentionné debootstrap par souci de complétude).

L'ouverture des périphériques /dev/input/event nécessite (à raison) les droits root, donc le démon tourne aussi en root.

Euh, ici j'ai (debian 10, mais c'est aussi valide sur la 9):

$ ls -lh /dev/input/event*
crw-rw---- 1 root input 13, 64 août  12 16:14 /dev/input/event0
crw-rw---- 1 root input 13, 65 août  12 16:14 /dev/input/event1
crw-rw---- 1 root input 13, 74 août  12 16:14 /dev/input/event10
crw-rw---- 1 root input 13, 75 août  12 16:14 /dev/input/event11
crw-rw---- 1 root input 13, 76 août  12 16:14 /dev/input/event12
crw-rw---- 1 root input 13, 77 août  12 16:14 /dev/input/event13
crw-rw---- 1 root input 13, 78 août  12 16:14 /dev/input/event14
crw-rw---- 1 root input 13, 66 août  12 16:14 /dev/input/event2
crw-rw---- 1 root input 13, 67 août  12 16:14 /dev/input/event3
crw-rw---- 1 root input 13, 68 août  12 16:14 /dev/input/event4
crw-rw---- 1 root input 13, 69 août  12 16:14 /dev/input/event5
crw-rw---- 1 root input 13, 70 août  12 16:14 /dev/input/event6
crw-rw---- 1 root input 13, 71 août  12 16:14 /dev/input/event7
crw-rw---- 1 root input 13, 72 août  12 16:14 /dev/input/event8
crw-rw---- 1 root input 13, 73 août  12 16:14 /dev/input/event9

Et du fait qu'au taf j'ai implémenté un toolkit pour framebuffer, je dirais qu'il suffit que l'utilisateur qui lance le soft appartienne au groupe input. Dans mon cas, il faut aussi le groupe video pour /dev/fb0, et malheureusement root parce que sinon pas moyen (ou alors pas trouvé lequel) de passer un TTY en mode graphique (pour virer le curseur entres autres, via ioctl( fd, KDSETMODE, KD_GRAPHICS, j'ai même essayé de chercher avec les capabilities, mais rien trouvé, faudrait que je cherche a nouveau).

Ceci étant dit, moi, j'ai utilisé libinput, et pas evdev, que je pense lié à Xorg. Peut-être est-ce la raison.

Du coup, comment Trump peut-il interdire aux Chinois d'utiliser Android ?

La totalité d'Android est-elle vraiment libre?

Certaines parties sont probablement sujettes à brevet et/ou sont non-libre (pilotes, notamment). Après tout, me semble bien qu'à une époque, les utilisateurs d'Android payaient une redevance à MS à cause d'un soupçon a ce niveau.

Même sans ça, les outils de chiffrement étaient suffisants à une époque pour interdire la distribution de systèmes à certains pays il me semble.

Yep, celui-là, merci. J'aurais été bien incapable de retrouver l'URI…

Un des innombrables sites persos qui vont bientôt disparaître si les navigateurs bloquent l'accès aux sites sans https ?

Perso, aller sur certains sites sans https ne me dérange pas, tant que je n'ai pas a saisir d'informations, c'est "juste" le risque d'être pisté.
Reste évidemment le risque d'usurpation d'identité, mais sur un site ou il n'y à aucune information saisissable et pas de softs réellement destinés à être utilisés (plutôt à être étudiés) ça me semble être un gain inutile pour l'attaquant.

Bref, un navigateur qui m'interdit le protocole http, je pense qu'il ira juste faire un tour dans /dev/null. C'est pas comme si https empêchait les gens de se faire tracker par des google ou facebook de toute façon.

Il y a au moins 2 manières:

• le dérivé de manie windowsienne: réinstaller tout. C'est dérivé, parce que, au moins sous linux/bsd/… il est aisé de mettre sa configuration utilisateur sur une autre partition;
• le mode avancé, qui nécessite d'avoir des bases sur le fonctionnement de son système: démarrer dans le mode le plus fonctionnel, et régénérer l'image de démarrage, sous Debian cela se fait par la commande sudo update-initramfs, mais sans avoir identifié le problème de base, je doute que ça résolve le souci;

Personnellement, j'ai tendance à opter pour une 3ème solution: sur toutes mes machines, j'ai au moins un système fonctionnel de secours, le plus stable possible et modifié le moins possible. Ce système me permets de réparer un de mes systèmes principaux qui serait en panne, ce que je ne peux faire que parce que j'utilise majoritairement des logiciels peu automatisés, qui nécessitent parfois des interventions manuelles pour appliquer leurs changements (syslinux au lieu de grub, runit-init au lieu de systemd-init, environnement de bureau spartiate, etc). Le fait de bosser dans le domaine aide peut-être aussi un peu.

Quoique tu fasses, n'oublies pas de faire une sauvegarde de tes données importantes avant.

Je suis désolé, mais je ne vois pas comment aider plus pour l'instant, je n'ai malheureusement pas assez de maîtrise des logiciels les plus répandus (je connais un peu grub, mais pas du tout systemd). Quand j'ai eu affaire a ce type de problèmes, j'ai plus joué de la démerde, très peu de doc tirées du web (que j'aurais citées sinon).

[EDIT]

Ah, peut-être tout bêtement passer par ton gestionnaire de paquet en mode sans échec pour réinstaller le noyau, ça pourrait marcher. Peut-être remonter a une version précédente, au cas ou ça serait une upgrade kernel la source du problème?