benja a écrit 1211 commentaires

Sans avoir VRAIMENT d'expérience pratique, je vous réponds.

est-ce que ce binaire peut tourner sur n'importe laquelle des machines ordinaires sous glibc

Oui.

est-ce que musl a les mêmes limitations que la glibc quant aux vieux noyaux de la génération 2.6 ?

Non.

What are musl’s dependencies?
Linux 2.6 or later. Earlier versions will suffice for running most simple single-threaded programs, but due to bugs and conformance issues at the kernel level, musl is not offically supported on earlier kernels.

http://www.musl-libc.org/faq.html

En gros le préfix ne sert qu'au configure.
Le configure va typiquement créer un fichier config.h et divers Makefiles. Dans le config.h seront définies des macro du préprocesseur qui permettent à la compilation de connaître la "configuration". Par exemple la macro HAVE_MATH_H sera définie si le script configure a détecté le fichier math.h. Tu auras aussi des constantes utilisées par ton programme, tel que les chemins d'accès. Tout ça c'est gèré par autotools, voir https://github.com/mbroz/cryptsetup/blob/master/configure.ac .

Le préfix va aussi aider à détecter les bonnes bibliothèques. mais dans le cas de la cross compilation, ça ne peut pas marcher car tes bibliothèque cross-compilées ne sont pas installées dans un répertoire standard. I.e. tu veux que ton préfix vaut /usr mais tes bibliothèques sont installées dans /cross/usr/lib/… Ça peut parfois marcher si t'arrives à passer --sysroot=/cross dans les CFLAGS et LDFLAGS (y a peut-être une autre méthode…), Dans ce cas là, le compilateur va traduire de manière transparente les chemins de recherche. En gros les deux approches sont possibles, cela dépends surtout de comment est prévue ta toolchain.

Deuxième point, on peut voire dans ce configure.ac que cryptsetup utilise pkg-config. Là, le prefix joue probablement une influence seulement si tu ne spécifie pas toi-même un chemin de recherche pour pkg-config. Si tu lance ./configure --help, tu devrais retrouver l'option qui te permette de spécifier le chemin de recherche des fichiers pkg-config. Ce sont ces fichiers .pc qui vont dire où sont les bilbiothèques à installer.

Bref, oublie le préfix pour l'instant. Relance ./configure et fais super attention aux valeurs qu'il donne pour
1) le compilateur. normalement ça serait un truc du genre gcc=/tonsdk/bin/arm-linux-gnueabihf-gcc
2) les chemins des bibliothèque détectées.

Vais je directement retrouver mon executable cryptsetup sur la cible dans ce cas la ?

non. le configure va substituer le préfix dans les règles du Makefile, ce qui peut avoir (ou non) une incidence lors du "make install". Mais jamais cela ne va faire une copie via ssh ou que sais-je… (c'est théoriquement pas impossible, mais personne ne s'amuse à le faire).

--enable-static

ok ça c'est bon.

Est ce normal' que j'arrive a lancer cryptsetup depuis mon hote?

Ça dépend… ;-) Il y a moyen d'utiliser qemu avec bin-fmt pour pouvoir lancer de manière transparente un programme d'une autre architecture sous linux. Dans ton cas, cela me semble peu probable que tu aies configuré ton système de la sorte. Si tu lance le programme "file" sur ton binaire (ou "objinfo" ou readelf…) tu seras fixé sur l'architecture de ton binaire.

Bon je remets un couche avec buildroot. Amha tu vas gagner pas mal de temps. Au pire tu n'es pas obligé d'utiliser le rootfs (image SD), tu peux te contenter de copier les binaires qui devront se retrouver quelque part dans un répertoire build. Ça supporte visiblement bien raspberrypi <3:
https://github.com/buildroot/buildroot/tree/master/board/raspberrypi
et il y a un paquet cryptsetup
https://github.com/buildroot/buildroot/blob/master/package/cryptsetup/cryptsetup.mk

Sinon une autre option, c'est de te faire un chroot, armv6 raspbian pour Rpi 1&2, armv7 debian armhf pour le Rpi 3, que tu lances via qemu+binfmt. Ensuite tu fais une compilation "standard" dedans. C'est juste assez lent… cf. https://wiki.debian.org/EmDebian/CrossDebootstrap#QEMU.2Fdebootstrap_approach

Et une dernière option, comme la précédente tu fais un chroot et tu le partage via nfs pour ensuite faire le chroot sur ton Rpi. Ça sera probablement plus rapide qu'avec qemu et sans bug du à la cross-compilation ou à qemu.

Le "prefix" sert généralement à trois choses: 1) enregistrer en dur dans ton programme où il va être installé et où il peut rechercher ses resources, documentation, etc. (p.e. une icone dans "$prefix/share/icons/monprogramme.png"). 2) au moment de faire "make install", l'endroit où vont être installés le programme fraichement compilé et ses resources 3) au moment du configure, déduire l'endroit où sont installés les dépendances/bibliothèque/includes.*

Bref dans ton cas, ça n'a pas beaucoup d'importance, car:
1) cryptsetup n'a pas l'air d'utiliser un fichier de configuration cannonique (tu spécifies tout sur la ligne de commande)
2) tu ne veux surtout pas installer sur le système qui compile. Sauf éventuellement si tu veux faire un staging afin de faire facilement une archive à transfèrer (dans ce cas cf. mon précédent commentaire, il faut que le préfix corresponde à l'endroit où tu veux l'installer sur la cible + le buildsystem doit supporter quelque chose de similaire à un DESTDIR qui va servir de "super" préfix).
3) tu as déja du règler le problème pour réussir à compiler - tu linke en statique - tes libairie seront installées dans un répertoire connu par le linker dynamique (/etc/ld.so.conf sous linux…) - tu cross compile, tu as déja du patcher le build-system pour avoir quelque chose de potable (barrer la mention inutile).

Illustration du point 3: dans ton cas il se pourait que ce soit gpgme. Généralement tu peux souvent "overrider" cela avec un argument de type --with-gpg-error=/usr/local ou bien encore avec un ac_XXX=valeur (regarde la gueule du config.log pour avoir le nom de la variable). Généralement cela marche bien dans le cas non-cross compilation. Par contre, dans le cas de la cross-compilation, c'est parfois plus compliqué car le path des bibliothèque que tu linke n'est pas le même que le path sur la cible finale, ce qui peut poser problème lorsque la dite bibliothèque n'est pas installée dans un endroit standard (cf. encore le ld.so.conf, LD_RUN_PATH et compagnie, man ld.so pour les détails). Si tu compiles en statique tu n'auras pas ce problème bien entendu. Ça peut même être plus intéressant si tu as peu de programmes qui utilisent la même bibliothèque car le code non utilisé va être supprimé. C'est pourquoi busybox lie en statique une libc dans un seul binaire, comme ça seul les objets de la libc vraiment utilisés sont repris. Par contre si tu as beaucoup de programmes différents, ben ce gain de place disparait pour devenir négatif. Bref à toi de voir…

À part cela, as-tu trouvé ton binaire et arrives-tu à le lancer sur ta cible ? Car amha le plus simple pour arriver à te faire progresser c'est d'y aller pas à pas pour que tu comprennes bien comme cela fonctionne…

Pour conclure sur buildroot, c'est une sorte de méta systeme de build, un peu comme portage de gentoo si tu connais. Ça compile toutes les dépendances de "paquets" que tu peux sélectionner via une interface de configuration et au finale ça peut générer un filesystem complet voir même une image à flasher. Ça supporte plus que probablement d'utiliser une toolchain "custom" à la place d'en construire une, c'est prévu pour être relativement facilement modifiable. En fonction de ce que tu veux faire, cela peut être intéressant d'investir en compétences là dedans, histoire de gagner du temps par la suite. Il y a d'autres outils similaire à buildroot, je n'en connais personnellement aucun, à part le truc de openwrt qui est basé (si je ne me trompe pas) sur buildroot.

Pour info, c'est quel genre de cible ? Ton kernel c'est un kernel vanilla ? T'as compilé ta toolchain toi même ou bien c'est un truc proprio ? Peut-être que ta board est déja complètement supporté par buildroot (ou qu'un support complèt n'est plus très loin à ajouter)…

*: Pour être complet, généralement tu as la possibilité de modifier spécifiquement certains endroits de recherche qui, par défaut, seraient calculés à partir de "prefix", p.e. (j'invente) --sysconfdir=/etc, --datapath=/opt/share.

Et puis Je ne sais pas ou récupérer l'exécutable cryptsetup

find / -type f -name crypsetup
Ensuite tu fais un file et un readelf -d dessus pour voir si t'as bien du code ARM et pour connaître les bibliothèque à installer au besoin. Par contre pour les dépendances fichiers/configurations, inspire toi de la doc. J'espère quand même que tu n'as pas essayé de faire un make install sans changer de prefix*… sinon bonjour l'état de ton hôte là :D

Est-ce que tu as utilisé un sdk particulier ? Car tu n'as pas indiqué avoir compilé de libc non plus. De plus mon crypsetup dépend aussi de pcre et udev, je suppose que tu as désactivé leur prise en charge à la compilation ?

Pourquoi ne passerais-tu pas par un truc tout automatisé genre buildroot ?

*: pour être plus correcte, il faut laisser le prefix standard (pour que les programmes aillent chercher leur fichiers dans les paths standards) mais utiliser un truc genre DESTDIR=/répertoire_de_staging pour faire le make install… Ça dépend un peu de chaque programme et il faut donc un peu étudier la question au cas part cas (= lire le Makefile), mais bon je suppose qu'un truc aussi essentiel que cryptsetup support ce genre de use-case. Deusio, comme tu n'installes quand même pas sur la cible, ça sera plus simple de tout faire à la main…

Par "fixer le type polymorphique", j'entends bien le type de l'objet (polymorphique), soit le 'a dans <get : 'a; ...>. La deuxième partie de la fonction -> 'a sera bel et bien fixé à un moment donné (et dans ce cas-ci le (sur)type de l'objet aussi par l'égalité 'a = 'a… mais bon, cf. l'exemple avec mylist, c'est possible).

 use_length' (fun o -> o#length);;
- : int = 2

Notons bien aussi le type de use_any.
- : < get : 'a; .. > -> 'a = <fun>

Cela ressemble à une fonction polymorphique, mais contrairement au polymorphisme classique, le mode objet d'ocaml ne "fixe" pas le type polymorphique une foit qu'elle est utilisée. Comparons

let use_length length =
  let _ = length [1] in
  let _ = length ["a"] in
  ();;
Error: This expression has type bytes but an expression was expected of type
         int

avec

class ['a] mylist l = object method length = List.length l end
let use_length' length =
  let a = length (new mylist [1]) in
  let b = length (new mylist ["a"]) in
  a+b;;
(* val use_length' : ('a mylist -> int) -> int = <fun> *)

Mon exemple ne marche pas et ça tombe bien car cella montre bien que les classe ocaml ne sont pas comme des classes de poo. T'es bien obligé de changer la signature de validated (comme avec les objets immédiats) pour ne pas qu'il soit considéré comme un sous-type de base.

(* c'est accepté par le compilo car le type validated est un sous type de base *)
use_valid_string (new base "invalid")
(*- : bytes = "invalid"  *)

(* on peut faire *)
class ['a] validated f i = let _ = if not (f i) then failwith "invalid" in
  object inherit ['a] base i
  method valid = true
end;;

let use_valid_string (o : _ validated) = print_endline o#get;;

use_valid_string (new base "invalid");;
(*Error: This expression has type bytes base
  but an expression was expected of type bytes validated
  The first object type has no method valid *)
(* ouf... *)

On peut aussi combiner avec un phantom type pour un maximum de safety. Attention, si on retire la méthode repr, ça ne marche à nouveau plus.

class ['a,'b] any repr i =
object(self)
  (* on est obligé de rendre la representation publique ! *)
  method repr : 'b = repr i
  method get : 'a = i
  end;;

type 'a valid (* notre type fantome *)

class ['a, 'b] validated repr i =
(* ici on force la validation, commenté car i'm lazy *)
(* let _ = repr i in *)
object
  constraint 'b = 'a valid
  inherit ['a, 'b] any repr i
end
(* on passe au constructeur une fonction qui "valide" en construisant le type fantome *)
(* le but de cette fonction c'est d'avoir une version spécialisée du constructeur,
  via l'annotation de type sur repr. on peut s'en passser...*)
let make_validated (repr : 'a -> 'a valid) obj =
  new validated repr obj#get

let use_validated (o : _ validated) = o#get
let use_any o = o#get

let id x = x

use_validated (new any id "invalid");;
(*
Error: This expression has type (bytes, bytes) any
       but an expression was expected of type (bytes, bytes valid) validated
       Types for method repr are incompatible
*)

use_validated (make_validated (fun _ -> failwith "i am lazy") (new any id "plain"));;
(* - : bytes = "plain" *)

(* et on peut toujours utiliser un string validated pour un string any *)
use_any (make_validated (fun _ -> failwith "i am lazy") (new any id "plain"));;
(* - : bytes = "plain" *)

S'il y en a par ici qui ont une solution pour cacher repr ?

Note que ces deux codes ont une sémantique différente, à savoir que le deuxième force la validation avant l'usage et le premier non. C'est juste pour l'illustration; tu peux évidemment implémenter le même comportement avec ces deux techniques…

s/plasse/place/ (désolé pour les yeux)
s/que ce que tu a/de ce que tu as/;s/complexe/complèxe/;s/types classes/typeclass ou classes de type ?/;s/permette/permettent/;il y p/il y a p/

C'est ça ! C'est exactement la même "opacification" du type que l'on retrouve en POO classique avec ses "classes".

Maintenant OCaml a aussi un système d'objet qui a un typage autrement plus complexe. Il vaut a lui seul le détour ;-) Par exemple, il n'y a pas de classe au sens POO du terme (=type) mais bien une correspondance par typage réel des méthodes avec évidemment une possibilité d'opacifier la représentation concrète si on veut.

Donc bref une troisième solution serait d'utiliser les objets immédiats, qui nous affranchi du "problème" de pattern-matching de la solutions avec les types variants. Par exemple, avec des objets immédiats là on peut avoir un objet "validé" qui peut être utilisé à la plasse de l'objet non-validé sans devoir modifier le code utilisateur.

let make_obj i = object val _v = i method get = i end;;
(* val make_obj : 'a -> < get : 'a > = <fun> *)

let make_validator f i = object(self) val _v = i#get method validate = if f _v then _v else failwith "invalid" method get = self#validate end;;
(* val make_validator : ('a -> bool) -> < get : 'a; .. > -> < get : 'a; validate : 'a > = <fun> *)

let use_string o = (o#get : string);;
(* val use_string : < get : bytes; .. > -> bytes = <fun> *)
let use_validable_string o = (o#validate:string);;
(* val use_validable_string : < validate : bytes; .. > -> bytes = <fun> *)

(* un validated_string peut être utilisé pour un string *)
use_string (make_validator (fun _ -> true) (make_obj "password"));;
(* - : bytes = "password" *)

Note que j'utilise la méthode "validate" pour discriminer un objet validable, donc si j'oublie d'appeller validate je ne me rendrai pas compte que j'utilise le mauvais type… Note aussi que la solution reste polymorphique donc que tu peux construire n'importe quel type d'objet avec make_validator.

Une autre solution c'est d'utilise les classes ocaml, qui ne sont pas encore tout à fait des classes au sens POO du terme mais qui permette de discriminer avec une contrainte de type (de nouveau, si on oublie cette annotation, ben ça ne sert à rien… le compilo ne peut pas se mettre à deviner ce que tu veux faire non plus :p). Je crois que c'est ce qui se rapproche le plus que ce que tu a demandé.

class ['a] base i = object method get = (i:'a) end;;
class ['a] validated f i = let _ = if not (f i) then failwith "invalid" in object inherit ['a] base i end;;
let make_valid f o = new validated f o#get;;

let use_valid_string (o : string #validated) = o#get;;
let use_any_string o = print_endline o#get;;

use_any_string (make_valid (fun _ -> false) (new base "god"));;
(* Exception: Failure "invalid" *)

Note que cela reste tout à fait polymorphique comme solution :)

(Il y peut-être encore une solution possible avec les gadt pour émuler les types classes d'haskell mais cela dépasse mon niveau de compétence là…)

s/temps/tant;s/ à d/­-à-d/

mais affirmer que les dev n'ont aucune conscience des problématiques d'admin, c'est juste drôle.

Il te visait personnellement, enfin bon libre à toi de généraliser.

Ceci dit, pour en revenir à nos moutons, j'ai l'impression que tu n'as pas compris la différence entre "version X fonctionne avec mon code" et "la version X est maintenue et fonctionne sur mon système". Par exemple dans le cas de debian, tu as de nombreux logiciels en version X qui ne correspondent pas à la version X de upstream car ils contiennent des corrections supplémentaires. C'est à dire que le sysadmin doit s'assurer non seulement que le logiciel fonctionne en tant que tel, mais aussi en temps que composant d'un système. Alors, à moins de nous avouer que tu développes directement sur la prod en tout bon rambo qui se respecte, j'estime que tu n'a pas prouvé ta légitimité pour pouvoir discréditer les sysadmins… ;-)

Quel est l'avantage à créer du matériel pour faire de la musique ? Serait-il possible d'utiliser une solution pure soft à la place ? Quand on voit le prix d'une board ARM, quel est l'intérêt de cette solution ? C'est une question naïve car je n'ai aucune expérience en arduino. Merci de m'éclairer !

Avec cela vient un éditeur multiplateforme (Win, Mac, Linux) open source (MIT)

Apparemment votre lien est incorrect. La bibliothèque (votre lien) est annoncée pour ne fonctionner que sur windows. Pouvez-vous confirmer que la solution complète fonctionne sur ces 3 plateformes ?

peut-être serez-vous intéressés ?
(seriez-vous intéressé)

Je serais intéressé de savoir comment cela fonctionne (+schéma électrique), et aussi de voir une copie d'écran…

Que donnent les sorties de ls -lZ /etc/init.d/varnish /root/varnish et getenforce ?

Il faut lancer apt-get update avant.

Oui je suis à nouveau bien d'accord avec ta précision. Si tu acceptes de prendre le point de vue que tout ce qui aide les utilisateurs de linux aide les utilisateurs des logiciels libre et vice-versa (cercle vertueux toussa quoi), je crois que comprendra mieux que l'on est fondamentalement en accord et tu ne sentiras plus, je l'espère, le besoin de devoir me corriger ;-)

Bref, je n'ai pas de problème à aider les gens à utiliser un logiciels proprio. Ce que je voulais dire dans le passage que tu as repris, c'est que je ne suis pas prêt à installer "Viber" pour essayer de deviner où peut se situer le problème; aucun jugement de valeur de ma part, hein…

Cette demande d'entraide contient trop peu d'information pour que je puisse m'essayer à deviner une probable cause du problème, donc j'ai renvoyer le demandeur vers l'endroit où, selon moi (et dans un monde idéal), il devrait avoir le plus de chances d'obtenir une résolution à son problème. Libre à toi de l'aider. Je ne puis même que t'y encourager, vu que tu sembles avoir une expérience avec le fonctionnement du dit logiciel, au lieu de jouer au justicier. Personnellement je ne suis pas certain que changer de distribution soit une solution idéale. :-P

Pédantiquement incorrect, oui, mais étrange ? ;-) C'est un nom de marque lexicalisé, clairement plus mignon à utiliser que « gestionnaire de suivi des défectuosités » ou encore « bugtracker ».

Merci de confirmer que ça n'est pas Debian qui fourni ces binaires. Si je te fournis un binaire pour Solaris, tu trouverais normal de demander à un forum dédiés au produits d'Oracle de le supporter à ma place ? Admettons même que le fasse grâcieusement (contrairement à Viber) ?

note: ça n'est pas parce que certains logiciels distribués par le projet Debian ne sont pas libres qu'ils ne rentrent pas en contradiction avec les principes moraux du projets. De plus, dans le cas de viber, vu que sa licence est clairement en contradiction avec les 7 premières DFSG (si pas les neufs au complet) et vu sa totale opposition au contrat social que défend Debian, il n'y a clairement aucun espoir de pouvoir considérer qu'il puisse bénéficier de ce même statut d'exception. Enfin, avant de trop diverger et de pouvoir retirer ma casquette d'ayatolla, j'ajoute simplement que, personnellement, je participe aux forums de linuxfr pour promouvoir les logiciels libres et leur utilisation et je pense même pouvoir dire que c'est le but du site. Mais je n'irai pas jusqu'à devenir un client Viber.

Cadeau pour le posteur du forum: https://support.viber.com/ , car je suppose que c'est bien de ce produit dont on parle.

$ apt-cache search viber
$

Il faudrait m'expliquer en quoi le forum debian est pertinent pour t'aider à régler un logiciel qui n'est pas distribué par debian (et à priori, qui est non-libre et donc ne pourrait pas l'être selon leur contrat moral) ?
Ne peux-tu pas t'adresser à ton fournisseur ?

Pour la complétude, en mode pédant:
.xsession-error est créé par le lanceur de session (un script généralement) qui s'occupe de lancer l'environement de bureau et/ou un gestionnaire de fenêtre… Ce lanceur de session est lui même lancé par Xorg. Donc Xorg != du gestionnaire de fenêtre.
Notons aussi parfois qu'il y a un gestionnaire de connexion graphique qui rentre en jeu. Je ne suis pas capable de dire comme ça si .Xsession est lancé avant où après ou pas du tout (et puis ça dépend un peu de chaque distribution). Enfin bref le principe c'est que le stderr est redirigié vers ce fichier (ou un autre, par exampe .gdm-session-error), et ainsi, grâce au fait que les sorties/entrées sont héritées par les processus fils, toutes les erreures des programmes graphique lancé par Xsessions ainsi que ses fils et ainsi de suite sont sensées s'y retrouver (sauf si un programme n'utilise pas la sortie d'erreure par défaut, évidemment).
Pour en revenir à nos moutons, lorsque l'on lance un programme dans un terminal, la sortie d'erreure se retrouve dans le terminal, donc bref cela ne sert à rien de consulter le .xsession-error pour voir les erreures du programme que l'on vient de lancer… Sauf si l'on s'attend à ce que l'erreur proviennne d'un autre programme suite à une interaction avec celui que l'on cherche à débugger…

Effectivement je me suis gouré, j'ai l'habitude d'utiliser la net-install. Désolé pour ça, l'image iso hybride est clairement plus adaptée à un débutant.

Par contre pour ce qui est du stable vs testing vs unstable, ben je crois plus que c'est une question de goût car des difficultés techniques il y en a dans les 3 cas de figures. C'est un peu choisir entre vouloir utiliser des backports avec tous les inconvénients que ça a (je ne vais pas détailler ici mais si on veut, je peux argumenter…), testing qui a les inconvénients des deux, et unstable qui "théoriquement" casse de temps à autres… D'expérience, unstable casse moins souvent qu'ubuntu sort de version, et les upgrades ubuntu sont régulièrement foireuses. Bref, rien de bien dramatique dans tous les cas, juste à chaque fois une nouvelle occasion d'en apprendre plus sur le fonctionnement d'une debian/ubuntu ;-). (D'ailleurs, à moins que le cassage arrive sur un paquet vraiment exotique, on peut être sûr que le bug est déja remonté sur le bugzilla avec un contournement).

Cela n'est pas une erreur fatale.

Mes 2 cents:
- disque dur rempli (df -h, vérifier la partition /, /home et (/var)/tmp si existant!)
- thunderbird est minimisé dans le tray (??)
- firetray fout le bazard, enlève le ?

Très bonne idée ;-)

1 Commences par copier toutes données sur un disque dur externe si ce n'est déja fait.

2 Distribution ?
Je te conseille une distribution purement communautaire, Debian. http://www.debian.org/devel/debian-installer/
http://www.debian.org/intro/about

3 Préparer l'installation:
Télécharge l'image USB suivante:
http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/current/images/hd-media/boot.img.gz
NB: Effectivement je te conseille d'utiliser la version "en développement", mais bon tant qu'à changer de bord autant le faire correctement : si tu rencontres un bug—ce qui est, je l'affirme par expérience, très peu probable—mais néanmoins pourrait arriver pour une raison diverse (combinaison matériel, usage "avancé" en mode expert, etc.), tu auras la possibilité de renseigner cette défectiosité via http://bugs.debian.org …

Elle est compressé avec gzip (extension .gz), il faudra la décompresser avant de la copier sur ta clef. À mon avis, le logiciel libre 7zip qui fonctionne sous windows doit pouvoir le faire… Ensuite il faudra la copier sur une clef usb de manière bit-à-bit (c'est une image). Pour cela, google me dit que tu peux utiliser Win32 Disk Imager : https://sourceforge.net/projects/win32diskimager/ .

Une autre option c'est de télécharger un .iso et de graver un cd. Debian—qui se veut, rappellons le, la distribution universelle—suport une fourtitude d'autre moyens d'installation bien plus spécifiques. Pour ton info, ils sont documentés ici : https://www.debian.org/releases/stable/installmanual .

4 L'installation.
La seule étape un peu délicate c'est le partitionnement et accessoirement l'utilisation du partitionneur de l'installateur demande un léger effort de compréhension, tu arriveras sûrement après quelques essais et erreur. Au minimum, l'idéal c'est de séparer la partition système de la partition "home" ("point de montage" = /home) qui contient tes données… Comme cela, s'il te prend d'essayer une autre distribution ou simplement de réinstaller tu pourras le faire sans devoir reformater la partition utilisateur et ainsi conserver tes données et autres configurations de logiciels. Bref faire attention à la case "formater cette partition" et "utiliser en tant que" et point de montage. Pour la partition swap, n'hésite pas à réduire la taille conseillé, c'est un peu bête de perdre 8GO pour rien car tu n'as de tout pas intérêt à ce qu'un programme bouffe tout ta ram + tout ton swap. Il va de soit qu'il est intéressant de mettre système+home+swap sur ton SSD, il y aura plusieurs options pour rendre ton gros HDD accessible. NB: au lieu de tout sauvegarder sur un hdd externe, tu peux tout mettre sur le HDD et tu le déconnecte avant de démarrer l'installation ! Ensuite après l'avoir reconnecté, tu auras encore tout le loisir d'y accèder avec linux.

5 La post-installation.
5.1 upgrade vers sid
Premièrement, comme c'est debian je te conseille de passer directement à "sid", la version en développement. C'est celle qui t'apprendra le plus de chose, enfin honnêtement je dois pouvoir compter sur les doigts d'une main (depuis +15 ans) le nombre de fois où j'ai du réparer quelque chose après une mise à jour malheureuse. Donc si ce n'est pour le côté pédagogique, au moins pour le côté "avoir les dernières versions de certains logiciels", je pense par example à firefox et à openoffice.
Pour ce faire, tu édite le fichier /etc/apt/sources.list (en root: sudo nano /etc/apt/sources.list ou si sudo ne marche pas, connecte toi en root soit au login soit en lançant "su") et tu changes la partie des lignes qui dit strech ou wheezy par "sid". Ensuite, toujours en root, tu lances "apt update" puis "apt dist-upgrade". Si entre les deux tu te choppe un message te disant que certaines sources n'ont pu être authentifiées, tu lance "apt install debian-keyring" pour installer les toutes dernièrs clefs cryptographique du projet.

5.2 installation de logiciels
Installe, si ce n'a déja été fait pendant l'installation, un environnement de bureau, apt install gnome-desktop ou kde-desktop, ou autre… Tu peux trouver ces méta paquets via l'utilisaire "tasksel" ou "aptitude" (qu'il te faudra probablement installer avant) ou encore en faisant une recherche "apt-cache search desktop".
NB: il existe des interface graphiques pour l'installation des paquets debian. La mieux supportée est "synaptic" : apt-get install synaptic ;-)
Ensuite installe quelques logiciels utiles: libreoffice, vlc, youtube-dl, firefox, etc.

5.3 Pilotes propriétaires.
Compte tenu de la génération de ta carte, je pense que le pilote "reverse-engineered" fonctionne de manière optimale. Je te ne conseille donc pas de faire la suite… Néanmoins si tu désires pousser ta carte dans ses dernière possibilités, installe le paquet "nvidia-driver".

6 Pour continuer
Amuse toi ! Utilise google, les cannaux debian, le bugzilla, ce forum…
Il y a moyen d'installer steam aussi, il commence à y avoir un nombre de jeu propriétaires disponibles sous linux. Renvois ton cd windows à Redmond (ah non, on me dit que ça ne se fait plus ça, des cd d'installations :p).

Note bien que ce code est buggé, lui aussi :p

    set_stdio();
    for(dir in path)
       exec();
    // not found
   print("command not found")

Pourquoi ?
Parce que le print() n'a rien à faire dans le fils ! Le stdout/stderr est (potentiellement) déja modifé par set_stdio(). Tu n'as pas d'autre choix que de faire toi-même une recherche exhautive dans path à coups de fstat, au bien tu laisse tomber car c'est sujet à race condition (i.e. on supprimer le programme juste après que tu l'aie trouvé, je ne sais pas si posix prévois une sorte de exec avec le fd du binaire déja ouvert), ou bien tu fais un exit(valeur_magique) et tu regardes après dans le père si le résultat du wait() te renvois cette valeur, mais bon ce n'est pas infaillible car rien n'empêche le programme de renvoyer légitimement cette valeur (je crois que bash combine ces deux méthodes), merci POSIX…  ;-)

J'oubliais : je pense que tu t'es quelques peu emmêlé les pinceaux au niveau des if et, ce qui n'aide pas, l'indentation n'est pas correcte. Le code après le commentaire "//enfant: exec du programme" n'a rien à faire là, il devrait être dans la clause "else" du if(tmp)… Bref en pseudo code ton programme devrait avoir cette structure:

main() {
  while(lire_entree()) {
    parse_commande();
    if (entree_valide) {
       do_exec()
       wait(pid)
    }
  }
}

do_exec() {
  pid = fork()
  if(pid) { // pere
    return pid;
  }
  else {
    set_stdio();
    for(dir in path)
       exec();
    // not found
   print("command not found")
   exit()
  }
  return 0; // non atteint
}

Ensuite tu as 3 options pour passer tous les paramètres: soit tu utilises des globales, le plus simple dans un premier temps mais le moins facilement "maintenable"; soit tu passes tous les arguments (éventuellement par références), par exemple `pid_t do_exec(const char* bin, const char* stdin, enum redir_mode stdin_redir, const char* stdout, enum redir_mode stdout_redir), soit tu mets tout dans une structure genre "struct commande { const char* binary; …}". C'est cette dernière méthode que je te conseillerais. Tu pourrais avoir alors le corps de ta boucle qui ressemblerait à "struct commande* cmd = parse_commande(); if (cmd) { … //commande_valide… do_exec(cmd); wait(pid); free(cmd);}" ce qui me semble assez lisible. Enfin bon ça dépend un peu du style que l'on vous a conseillé au cours…