Ç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 :)
[^] # Re: debootstrap est ton ami
Posté par freem . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 3. Dernière modification le 16 octobre 2019 à 19:32.
Ç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:
sv check $DAEMONferme le descripteur de fichier 2 (stdout) avant d'exécuter$SVDIR/$DAEMON/check. Du coup, si le fichierchecké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);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 :)