freem a écrit 5059 commentaires

Pas s'il fait du DHCP simple….

De nos jours, les noms des interfaces réseau sont "prévisible", générées à partir d'inforamtions techniques. Du coup, le fichier /etc/network/interfaces doit être patché. Les fichiers /etc/hosts (pour associer le hostname à 127.0.1.1 qui est utilisé par sudo) et /etc/hostname (le nom de la machine) également.
Encore que, pour le fichier interfaces, si un gestionnaire réseau graphique est utilisé, c'est inutile, puisqu'ils remplacent le fichier interfaces me semble.

Enfin, je dirais que si:

• les machines ne disposent que d'une seule interface réseau filaire;
• les machines disposent d'au moins un disque SATA;
• avoir un hostname généré n'est pas gênant;

alors y'a moyen de scripter ça vite fait mal fait (code pas testé donc a vérifier et corriger sur machine non nécessaire avant usage):

test -e /var/firstboost.sh && . /var/firstboost.sh

NEW_IFACE=$(ip -o link | grep -v '\<lo\>' | cut -f2 -d:)
OLD_IFACE=$(grep inet /etc/network/interfaces|tail -n1 | cut -f2 -d' ')
sed -i "s/\\<$OLD_IFACE\\>/$NEW_IFACE/g" /etc/network/interfaces
NEW_HOST=$(printf "%s-%s\n" $(hostname) $(udevadm info --query=all --name=sda | awk -F'=' '/ID_SERIAL=/{n=split(tolower($2),array,"_"); print array[n]}'))
OLD_HOST=$(hostname)
echo $NEW_HOST > /etc/hostname
hostname $NEW_HOST
sed -i "s/\\<$OLD_HOST\\>/NEW_HOST/g" /etc/hosts
rm /var/firstboot.sh

En gros, ce script altère les fichiers hosts, hostname et interface pour remplacer le nom de l'interface réseau Éthernet filaire (dans mon cas enpXsY, YMMV) et les noms de la machine par le nom de la dernière interface interface réseau trouvée sur la nouvelle machine (si n'y en a pas, ça pète!) et un nom composé de celui du modèle ainsi que du numéro de série du disque dur sda (idem, s'il n'y en a pas, ça pète, cas qui se présenteras notamment sur des beaglebone black qui n'ont pas de carte mémoire, leurs "disques" internes étant notés "mmcblkX").

Encore une fois, lire, comprendre et tester sur machine pas critique: certaines données sur lesquelles je me suis basé peuvent varier en fonction des logiciels systèmes utilisés ou du hardware!

Pardone la poche que je suis, mais, tel que je lis, il dit juste:

On a une nouvelle techno qui ne garanti rien mais permets à l'utilisateur de faire de la merde et d'installer des virus vu que le bin n'est jamais vérifié.

MAIS LE PUTAIN DE BON POINT QUI ÉCRASE TOUT MAUVAIS SYMPTOME, C'EST QUE LE TRUC EST A JOUR… j'ai mis assez de caps lock la? J'ai un doute….

Pardon, j'ai répondu qu'a une partie.

Le reste sera pas mieux, mais, tu m'as répondu, c'est de mon devoir de faire de meme.

Les distributions en général doivent donc corriger ces écarts de compatibilités évidentes et corriger les problèmes que cela implique aussi.

C'est une des limites du modèle traditionnelle d'une distribution, qui est très gourmande aussi en travail humain pas forcément passionnant.

C'est aussi ce qui fait leur robustesse.
Il est vrai que le travail manuel est énorme, mais c'est justement a mes yeux une des raisons majeures de confiance. Que l'on est en droit d'accorder a du privé, mais je préfère croire des passionnés. En vrai, ces gens m'ont permis d'apprendre a me méfier d'eux, au point de lire le code C de presque tout.

Pour faire ça, il faut sélectionner des logiciels simples a lire, et connaître son OS. Je sais sélectionnner, mais je maitrise encore mal mon OS, c'est pour ça que j'aime mon job: je peux galoper après des cerveaux si précis, avec un recul en plus, que, jamais je pourrais les rejoindre: soit je reste derrière, soit je les dépasserai. Si j'arrive a grimper leurs épaules.

Je suis d'accord, même bien bourré…. en soit, une distro devrais pas être l'autorité absolue. Chaque user devrais pouvoir installer un soft.

Enfin, s'il est permis par le ldap. Et quelle distro intègrre ça? Aucune. Windows le fait depuis au moins 10 ans, sorry. Je veux faire une distro pour ça, mais, c'est un bordel de fou, il me faudra au moins 2 voire 3 mois pour piger comment ça marche, les bases!

A la base, j'avais estimé a 2 semaines, mes chevillles sont encore un peu enflées, on dirait

Et relis Platon :)

ben, pour le coup, source? Histoire qu'on puisse apprendre, quoi :) ou au moins faire semblant :p

Bah, vraiment, j'apprécierais toujours tes interventions, même sans être toujours en accord (plus souvent sur la forme que le fond), elles me font toujours cogiter.

Et qu'on aime ou pas, mais traiter de con des gens qui appliquent des règles pas unanimement conspuées, et utilisées par d'autres, n'est pas objectif.

Du coup, une règle unanimement conspuée est toujours vraie, comme celle qui disait que la terre est ronde? Pardon, tu ne parlais pas de véracité, mais de connerie… ceci étant dit… hum.

Perso, un règle qu'on doit apprendre par coeur et accepter, c'est une preuve de connerie. Le contraire de la connerie, c'est de comprendre les règles, leur pourquoi et leur comment.
Donc, pour moi, nous sommes tous cons, et toutes connes, et pour les non binaires, je sais pas comment le dire.
Je crois qu'il est important de se souvenir que l'on est incapables de tout comprendre, y compris les "génies". Le trip open source pour moi, c'est vraiment "tiens, telle idée je la trouve pas optimale pour telle situation, pourquoi ne pas tenter cette autre?" et laisser les autres bâtir sur cette autre idée si elle est vraiment meilleure. Sinon, ben, elle pourrit, et c'est pas plus mal

En même temps, le net est vu comme un endroit ou l'on peut s'exprimer librement.
Les gens qui connaissent ses limites (je n'en fais pas partie) sont des élites, des pointures, cette science est pas accessible au geek moyen, alors, le lambda…

si tu le regrettes, aides nous.

Tu noteras que tu as un score particulièrement élevé sur ce post, et je pense qu'il est justifié. Par chance, je n'utilise plus le système de vote que pour des contenus excteptionnellement bons ou nuls, du coup je n'ai pas besoin d'annuler des votes.

Pour en venir au fait, je voudrais savoir comment tu reformulerais le journal. Parce que bon, nombre d'entre nous sommes décents voire plus en terme d'info, mais en terme de politiquement correct, j'en doute, et avoir quelques exemples en opposition a d'autres nous permettrait de nous améliorer, pour ceux qui le souhaitent.

Le risque de tomber dans la manipulation étant, bien sûr, présent. Mais, bah, je sais pas, en fait, juste, je voudrais voir comment tu aurais écris ça. Vraiment.

Je serais preneur d'un retour, perso. Voila un sujet qui mériterais un journal, voire serait une dépêche bien plus intéressante que la moyenne (je trouve les journaux souvent plus intéressants que les dépêches, en vrai, pardon pour la critique négative sans arguments)

le traité empirique est nettement plus compliqué que ce que moi je fais pour construire un deb…

Je commence a croire que c'est le manque de doc sur le format binaire qui est le problème de debian.

Je cite, et vous m'excuserez des fautes, je suis hors d'état de conduire, et je ne devrais pas poster sur l'autoroute de l'information… mais je compte sur votre magnanimité, donc:

Il nous faut créer quatre fichiers :

debian/compat
debian/changelog
debian/control
debian/rules

c'est pas une citation exacte, j'ai viré la poncutaition et divers mots de jonction.
Bref, seul control est vital. Je connaissais même pas l'existance de compat, en vrai. On se fait une dépêche en mode coop sur comment faire un deb proprio/freestyle propre, un jour? Je pense que ça permettrait d'aider a perdre cette réput injustifiée du format deb…

Le changelog, c'est d'un pénible a maintenir… on sent que debian est née avant les DVCS, mais, pour être honnête, je ne connais aucun outil capable de gérer C ou C++ qui sache compiler en prenanant en compte facilement le versionning a base de hash. Dur sujet, faut dire. Mais même les tags sont absents… et un admin noob comme moi a pu pondre un script (de merde, je tenterais unjour de faire mieux, et de le publier d'abord sur le temps libre, puis de l'utiliser au taf, en ayant soin dans ce cas d'utiliser GPL) qui peut récup les tag+commit hash d'un dépôt pour générer un numéro de version.
Le changelog, en soit, c'est plus dur, y'a une notion de politique: est-ce destiné a l'utilisateur, ou a l'admin, ou au contributeur? Pas facile.

Le dernier fichier à rédiger est debian/rules

Je croyais que ça devait pas générer un deb source? Ce truc est useless dans le cas d'un deb binaire.
Le ficher rules, c'est en gros un makefile de ce que j'ai compris (confirmé par la 1ère ligne, en fait).

purée, c'est ça, la ceinture blanche? J'ai pas un tiers des connaissances requises, et pourtant, promis, je peux te générer un .deb a partir d'un binaire proprio en moins de de 15 minutes…

Je crois que la complexité, ça s'acquiert quand on cherche a faire du propre, du bien intégré et universel.
Ce qu'on repproche a debian, justement, c'est de vouloir faire trop universel, et le pire c'est que ça marche pas: Debian reste, malgré les efforts (qu'il faut saluer) une distro GNU/linux. Les ports BSD ou non-GNU officiels semblent a l'état de bêta-test, et je suis gentil.

Merci d'arrêter de balancer des rocquettes dans les pattes de cette distro. A la base, c'est censé être une distro geek friendly, pas user-friendly, et il reste des traces, très claires: je peux installer un paquet avec juste du shell unix, et je peux installer un système en mode archlinux, la stabilité en plus.

J'ai parfois l'impression que les "nouveaux geeks" se contentent de lire 1 seul tutoriel, et se proclament maîtres de la techno en question, en ignorant tout de l'histoire et du fonctionnement interne…. le pire, c'est que ces gens semblent se croire aptes a critiquer des choses que peu d'entre nous seraient capables de recreer, même avec l'exemple sous le nez! Ou alors, je suis totalement idiot…. ça me choquerais pas, d'ailleurs, en soit.

Je pense que tu mets le doigt exactement ou est le problème: la maintenance.

Les distros stable type debian, doivent patcher les softs pour qu'ils soient compatibles entre eux et donc mériter la réputation de stabilité. La volonté de fourguer le dernier soft tout frais, ben, c'est pas compatible.

D'un côté, on veux un système a jour, a la pointe, et d'un autre on veut un système stable. C'est pas possible. Il faut des compromis, et je pense que le fait de pouvoir installer un soft pour un user est pas mal. C'est ce que proposent ces formats, mais du coup, je pense qu'en effet ils repartent en arrière en ignorant totalement la notion de système. Bon, j'ai un peu peu bu, je peux pas argumenter correctement, je peux vous laisser construire sur cette notion de format compromis (dans le sens "entre deux extrêmes" pas dans le sens "troué").
Perso, je pense qu'il serait plus efficace de recoder les outils type dpkg pour qu'ils soient utilisables sans etre root. Ca implique de retravailler l'archi systeme, de manièere autrement plus utile que merger /usr et / pour les bin & /sbin (qui en auraient pu être fusionnés avant en plus, m'enfin).

En tout cas, a la vôtre. et pardon pour les fautes de français. Le reste des fautes, je dirais ça a tête repôsés

Lampiris, pour ne pas le nommer — je te/vous laisse deviner dans quel pays j'habite

Je dirais que tu habites dans le "contre-attaque". Comment ça, j'ai faux?

tu as perdu la main…

Faut reconnaître que c'est dommage de la perdre avec un système de paquet nommé fapfap flatpack.

Je suis déjà dehors :)

En fait c'est tellement compliqué de faire un package pour Debian (ya tjs pas de PPA :-) qui soit dans la distro, et je ne parle pas des 6 mois pour être Debian Developer.

Je comprends que la majorité de fasse plus de paquets, mais des images Docker.

Pas moi, si ton objectif est juste d'installer ton blob sur une bécane.

Si tu veux être un paquet Debian officiel, il faut suivre une tétrachiée de règles, un format fixe qui garantit tout plein de truc, et… mais en fait, on s'en fout.

Le but d'un dev, c'est de distribuer son application. Pour la distribuer sur Debian, le plus simple, c'est de filer un paquet Debian binaire, proprio-style, pas un paquet source qui permets… euh… de se prendre la tête?

Et un paquet binaire de Debian, ça se construit hyper facilement, promis. Allez, j'explique, s'pas bien long après tout:

Il faut lancer la commande dpkg-deb -b $TARGET, $TARGET étant une arbo constituée, de mémoire, ainsi:

• DEBIAN/control: fichier qui permets d'avoir le nom du paquet, sa version, ses descriptions courtes/longues, la homepage, etc… dans un format que même un enfant de 10 pourrait comprendre. C'est le seul fichier obligatoire;
• DEBIAN/md5sums contiens les somme de contrôle md5 (on peut aussi utiliser SHA512 je pense). C'est basiquement la sortie de md5sums avec quelques arguments…
• DEBIAN/post-inst (en gros) script lancé après chaque dépaquetage
• DEBIAN/pre-inst (en gros) script lancé avant chaque dépaquetage
• DEBIAN/post-rm (en gros) script lancé après chaque suppréssion
• DEBIAN/pre-rm (en gros) script lancé avant chaque suppréssion
• une arbo qui indique la ou iront les fichiers. En fait, la partie du système concernée par le paquet

Vraiment, pourquoi viser l'officiel? C'est le job des mainteneurs, les paquets source Debian ont des patchs justement pour ça: l'intégrer aux changements systèmes de Debian.
Rien n'empêcherait de faire un paquet avec un binaire lié statiquement qui s'installe dans /usr/local ou /opt…

AppImage ne fournit aucune sécurité, et n'est a ma connaissance pas géré par dépôts, juste l'utilisateur télécharge le fichier d'origine, le chmod, et l'exécute.
Les autres semblent essayer de fournir des sécurités.

J'ai lu plusieurs fois sur linuxfr que les autres ont aussi l'avantage du téléchargement incrémental, contrairement a appimage, mais les auteurs de ces commentaires n'ont jamais du essayer d'utiliser l'appimage de redeclipse2, sinon ils sauraient que c'est faux.

Pour le reste, je n'en sais pas pas plus, je n'ai jamais testé fapfap/snap (désolé, pas pu résister), et jamais analysé un binaire AppImage, donc…

Est-ce une réaction de réactionnaire de chercher a tendre vers un système que l'on est capable de dépanner, de maintenir, de modifier soi-même?

Parce qu'une des raisons qui font que je n'ai pas encore étudié systemd en détails, justement, c'est que je le trouve complexe, alors que j'ai l'impression (est-elle justifiée? C'est pas sûr) de pouvoir faire la même chose avec des outils plus simples, dont je suis même capable de comprendre le source (j'ai encore lu le source de sv aujourd'hui, me suis d'ailleurs demandé si c'était du C K&R…) chose utile quand un comportement n'est pas ou est mal documenté (un logiciel trop documenté s'expose au problème qu'il faut lire trop de trucs pour le juste mettre en place, l'équilibre n'est pas simple).

J'ai parlé de systemd ici, mais la même chose peut s'appliquer a bien des technologies, et il est possible que ces nouveaux systèmes de paquets y aient leur place.

J'ai aussi parlé de tendre vers, parce que je suis conscient que ce n'est pas possible de comprendre la totalité de son système (le kernel linux m'est obscur, et même si je comprenait 100% des binaires de mon système, il resterait les firmwares, le code verilog/whatever qui programme un CPU s'il est en fait un FPGA, puis l'électronique… bref).

Ç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.