Apiphobe Je n'ai pas voulu me pencher sur la question, tout ce qu'il avait le mec, c'était un prompt de secours qui disait, grosso modo "I don't know what went wrong but it's your shit now, deal with it! >"

Dakien Si j'en crois ça https://wiki.debian.org/fr/InstallFAQ , mini.iso c'est le nouveau nom des ISOs "business card", du coup je reprends foi en l'humanité, c'est nickel.
J'vais pouvoir m'en graver une, tiens.

les business cards faisaient 22 Mo ? Si oui, c'est bien ça

C'était pas un shell grub hein, c'était bien Arch, qui "entâmait" son processus de boot, puis en fait non, cassage de gueule, et prompt à la con.

Dakien De mémoire c'était un peu plus lourd par contre.
Mais ça collait exactement à cette description, par le biais du mode expert tu choisissais les dépôts à utiliser pendant l'install, durant l'étape de choix du miroir.

Aussi, elles ne changent jamais ?
La mienne, du coup, je la récupère ICI ftp://https://www.jeuxvideo.com//ftp.fr.debian.org/debian/dists/unstable/main/installer-amd64/current/images/netboot/

Api Les mino.iso font toujours 23 Mo

J'en ai deux dans mes archives, qui font ~50MB.

Dakien Je ne me rappelle plus de la fréquence à laquelle elles étaient mises à jour, mais les liens de DL étaient donnés sur la page des ISOs de testing (Wheezy était la version testing de l'époque), donc c'était peut être sujet à quelques màjs de temps à autres.

Apiphobe Moi j'ai pas voulu chercher trop loin, je leur avais recommandé (oui, 'sont plusieurs à avoir fait ce choix) d'éviter à tout prix ce style d'OS pour une machine de travail (et surtout, faite pour servir durant les TPs quoi...), mais c'était tellement plus intéressant d'installer un truc hardcore pour épater la gallerie.
A côté de ça, je me traine le même W7 et la même Debian depuis deux ans maintenant, pas une rayure, tout est nickel des deux côtés.

Apiphobe Nous sommes bien d'accord.
Btw faut que je remette tous mes disques de données au propre, dans un mois tout pile c'est la rentrée pour moi, faut que j'arrive avec une bécane légère.

D'accord, je vois, en tout cas, même pour une stable, c'est cool les mini.iso

Je viens de lire Asus, Anus

Google_Bot: Y'a pas de problèmes a avoir Arch sur une machine de travaille, faut juste assumer, se préparer et faire les majs Vendredi soir et pas Lundi matin.

Par contre, ça a un intérêt de séparer les dossiers? Genre une partition pour /boot, /, /home, /tmp, /var, /usr/sbin et /usr/bin (C'est ce que j'ai fait, vive le GPT )

(Hormis le fait de pouvoir utiliser des systèmes de fichiers différents par dossiers)

Tu es très mal réveillé, ou tu as trop forcé sur la boisson hier soir.

Knakis Manifestement cette précaution n'avait pas été prise, car le départ en couille a bien eu lieu le jour d'un TP.

Séparer les partitions, oui, ça a un intérêt.
1) Si tu veux accéder à des données qui sont dans ta partition /home depuis un quelconque OS, tu n'as qu'à monter /home, et pas "tout un / à monter, puis aller chercher le subdir /home";
2) Si ton OS pète, tu gardes la partition /home (et pourquoi pas /var , tant qu'à faire) et tu ne refais que ce qui doit être refait;
3) Si tu as plusieurs systèmes, tu leur fais utiliser le même /home si tu es un aventurier. Là par contre je suis mitigé, car certains fichiers de conf pourraient poser problème d'un OS à l'autre.

En même temps un barbu, dans un /pub qui plus est et qui ne boit pas n'est pas un barbu.

M'par contre, y'a pas d'incovéniant à tout séparer? Au départ j'avais séparer le /home pour avoir accès à mes données sous Windows, puis /var pour les logs et pour la formatter en reiserfs. Puis quand je suis passé en GPT j'ai fait des folies, j'ai séparer boot, /, /home, /tmp, /var, /usr/sbin et /usr/bin. (Limite /tmp sert vraiment à rien m'bon).

Utiliser le même /home est sale, tu te retrouve avec des fichiers de conf inutilisables ou de programmes que tu n'as pas.

Knakis Le premier inconvénient (qui n'en est pas un vrai une fois qu'on sait ce qu'on veut), c'est de devoir décider de l'espace qu'on alloue à /home, à /usr, etc. puis à / . Mais avec l'habitude, tu sais de combien ton OS a besoin pour / , tu sais ce que tu consommes comme /home avant d'utiliser d'autres disques, et pour le reste, tu peux t'inspirer de la conso actuelle sur une arborescence "non séparée", par dossier.
/var ne sert pas qu'aux logs hein, c'est aussi là que vont se mettre les conteneurs de données de tes systèmes de gestion de bases de données, ou encore (en temps normal) les arborescences de sites web que tu souhaites publier depuis un serv web, etc.

Et je confirme, un /home en NTFS ça me ferait bien chier pour ma part.

Meuh non, pas un /home en NTFS, je suis pas crade quand même. Y'avait un soft pour lire l'ext sous Windows, je l'utilisait pour avoir quelques fichiers. M'enfin, c'est de l'histoire ancienne ça.

Mais l'espace à allouer est un petit casse tête quand on connait pas.

« Meuh non, pas un /home en NTFS, je suis pas crade quand même. Y'avait un soft pour lire l'ext sous Windows »
Là c'est pas crade, c'est carrément dangereux pour ton ext ce genre de trucs.
Au même titre que j'ai eu des blagues sur du ntfs avec ntfs3g, même en version récente.

Si tu as du mal à te décider pour l'espace, fixe celui de / , et ne sépare que /home , va.

Apiphobe En lecture passe encore, mais dès que c'est censé écrire, je n'ai pas plus confiance en ce genre de trucs qu'en ntfs3g.
Et je me demade si Knakis utilisait vraiment son /home en lecture seule depuis Windows, enfin, j'attends des précisions à ce sujet mais je maintiens mon avis: même les développeurs respectifs de ces outils indiquent qu'ils sont à utiliser "à vos risques et périls" en écriture.

Knakis > séparer /var et /tmp ont aussi de gros avantages, c'est pour éviter l'étouffement de partitions: si t'as un programme qui déconne et qu'il te pond 30 milliards de lignes dans un log ou un fichier temporaire, et que ta partition racine est complètement pleine, tu ne pourras pas booter (et rappelons que /tmp est vidé au démarrage suivant, pas à l'extinction) du tout, alors que si ton /var ou /tmp est plein c'est bien moins problématique et ça se règle en un clin d’œil.
Pour /boot, ça permet surtout de le mettre en ext2 et éventuellement le monter en lecture seule, pour plus de sécurité.
Pour /usr, tu peux aussi le monter en lecture seule pour rediriger les rares écritures nécessaires vers /var (mais que sous systemd, il me semble).

«Et je me demade si Knakis utilisait vraiment son /home en lecture seule depuis Windows»

C'était bien le cas, j'avais pas besoin d'écrire dessus vu le temps que je passais sous Windows.

Caletlog: Merci pour l'explication, j'ai bien fait de les séparer (Je l'ai fait dans le doute, au départ, vu que ça posait pas de problèmes.)

Hoy. Vous auriez un bon macro sous Fedora ? xmacro était bien sous Ubuntu mais je l'ai pas trouvé sous yum. J'imagine qu'installer un rpm d'une autre Distrib' n'est pas non plus une bonne solution huhu

Knakis > D'une manière générale ça permet aussi une accélération des temps d'accès: si ton disque est partitionné en de multiples zones, les données "similaires" sont toujours proches physiquement sur le disque, au lieu de s'empiler aléatoirement sur d'autres données non liées; par conséquent, il y a plus de probabilités que la broche de ton disque dur ait à faire peu de mouvements pour une même action (elle les fait seulement pour "changer de type d'activité").
L'ordre des partitions intervient donc également, si tu veux tout optimiser, sachant que les partitions en premier ordre sont au centre du disque et donc plus rapides.

Donc si tu le fais bien, plus tu fais de partitions et mieux c'est