Slint 15.0 est disponible

[Didier Spaier]

Je confirme: je n'ai pas le temps de maintenir plusieurs architectures en parallèle. Sinon il y aurait une version ARM.

[dodo]

Je confirme: je n'ai pas le temps de maintenir plusieurs architectures en parallèle. Sinon il y aurait une version ARM.

Vu que la compilation de programmes lourds c'est très très long sous ARM

[Didier Spaier]

Je confirme: je n'ai pas le temps de maintenir plusieurs architectures en parallèle. Sinon il y aurait une version ARM.

Vu que la compilation de programmes lourds c'est très très long sous ARM

Je ne l'ai jamais fait mais je suppose que ça va plus vite de cross-compiler, voir par exemple: https://jensd.be/1126/linux/cross-compi ... -or-ubuntu

[dodo]

Compiler firefox sous arm ça prend plusieurs jours il parait.. J'ai lu ça quelque part.

[Seb]

Je confirme: je n'ai pas le temps de maintenir plusieurs architectures en parallèle. Sinon il y aurait une version ARM.

Note que ce n'était pas une requête et encore moins un reproche. Même avec sur une base solide et stable comme Slackware, je crois que maintenir une distro est un truc que je ne ferais pour rien au monde.

Encore une petite question toutefois: pourquoi btrfs par défaut? Dans mon idée, ça ne servait que pour les serveurs et, à moins que j'aie manqué quelque chose, ext4 reste le FS de référence pour les devs du noyau...

[Didier Spaier]

Encore une petite question toutefois: pourquoi btrfs par défaut? Dans mon idée, ça ne servait que pour les serveurs et, à moins que j'aie manqué quelque chose, ext4 reste le FS de référence pour les devs du noyau...

les devs du noyau, lequels? Le travail des des chefs comme Linus ou Greg consiste en grande partie à vérifier que les patches proposés par des centaines (ou milliers) de développeurs sont dans un état tels qu'ils peuvent être acceptés, et il n'existe pas de système de fichiers par défaut, ext4 est juste le plus répandu. Quand aux avantages, les principaux sont mentionnés ici: https://slint.fr/fr/home.html

Je cite:

Le système de fichiers btrfs est configuré avec des sous-volumes au lieu de partitions séparées. Il permet de diviser par 2 l’espace occupé sur les médias, de prendre des instantanés et est bien adapté aux clés SSD, NVMe et US]

ainsi:

• plus de souci de répartition de l'espace disponible entre / et /home, c'est le même.
• le même volume ou sous-volume peut être à cheval sur plusieurs supports physiques (plus besoin de LVM).
• les instantanés facilitent les sauvegardes et permettent un retour en arrière en cas de mis à jour foireuse.
• Slint installé avec btrfs occupe deux fois moins de place qu'avec ext4.
• btrfs est bien plus adapté aux supports modernes (SSD, NVME, clef USB): très rapide dans ce cas d'emploi, et très résistant.
• le RAID est pris en charge directement au lieu d'être une couche séparée (honnêtement je n'ai jamais utilisé de RAID).

Exemple de cas d'emploi: pour avoir un système entièrement chiffré et ne taper la "passphrase" qu'une seule fois: dans Slackware c'est compliqué (voir les écrits d'Eric Hameleers sur le sujet), dans Slint il suffit de demander à l'installation et pas besoin de partition séparée pour /boot.

[Seb]

le même volume ou sous-volume peut être à cheval sur plusieurs supports physiques (plus besoin de LVM).

Voici qui pourrait m'intéresser. Ça se passe comment quand un disque lâche? Chaque fichier est sur un disque distinct et donc encore accessible (moyennant reconstruction du FS, bien sûr), ou c'est la même galère qu'avec LVM où le FS devient inutilisable (c'est pour cela qu'on couple souvent avec RAID)? Recyclant de vieux disques, c'est un point qui m'a fait abandonner LVM...

Slint installé avec btrfs occupe deux fois moins de place qu'avec ext4.

Tu veux dire que si je testais sur de l'ext4 il faudrait en fait compter minimum 32G?

[Didier Spaier]

le même volume ou sous-volume peut être à cheval sur plusieurs supports physiques (plus besoin de LVM).

Voici qui pourrait m'intéresser. Ça se passe comment quand un disque lâche? Chaque fichier est sur un disque distinct et donc encore accessible (moyennant reconstruction du FS, bien sûr), ou c'est la même galère qu'avec LVM où le FS devient inutilisable (c'est pour cela qu'on couple souvent avec RAID)? Recyclant de vieux disques, c'est un point qui m'a fait abandonner LVM...

Réponse ici: https://btrfs.wiki.kernel.org/index.php ... ed_devices
Plus genéralement: https://btrfs.wiki.kernel.org/index.php ... ed_devices

Slint installé avec btrfs occupe deux fois moins de place qu'avec ext4.

Tu veux dire que si je testais sur de l'ext4 il faudrait en fait compter minimum 32G?

Il y a un moment que je n'ai pas installé en ext4. Actuellement au déballage (utilisant la nouvelle ISO ici: https://slackware.uk/slint/x86_64/slint-15.0/iso/) le système pèse 8,8G. Je prévoirais au moins 18G en ext4, à vérifier.
Mais tu peux enlever quelques gros paquets dont tu ne te serviras pas.

[Seb]

Réponse ici: https://btrfs.wiki.kernel.org/index.php ... ed_devices

C'est implicite dans la doc, mais en cherchant un peu, il semble qu'on puisse effectivement remplacer un disque sans tout perdre. Si je comprends bien, chaque disque est une sorte de sous-volume. Je garde ça dans un coin de ma tête, au cas où ma solution oldescoule actuelle trouverait ses limites. Merci.

Mais tu peux enlever quelques gros paquets dont tu ne te serviras pas.

Oui, mais comme dit précédemment, c'est galère voire impossible d'enlever des paquets sans gestion de dépendances. C'est pour cela que lorsque j'installe une Slack, je procède toujours de bas en haut: d'abord un truc minimal, puis j'ajoute mes applications en installant les paquets manquants jusqu'à ce qu'elles daignent se lancer. C'est la seule manière de faire pour être sûr de n'avoir que les bibliothèques nécessaires sans rien casser. Or, d'après ce que je comprends de la doc de Slint, c'est full-install obligatoire (pas d'équivalent des tagfiles). Donc, même en se contentant d'un gros déblayage grossier pour me faire une idée, ça m'oblige à trouver de quoi faire l'installation initiale, ma partition de test/secours étant, inutilement au final, beaucoup trop petite.

Je dois dire que c'est un point, inattendu parce que je n'en ai jamais fait beaucoup de cas dans un sens ou un autre, où Alpine me ravit. J'ai juste besoin de sauvegarder /etc/apk/world, soit la liste de tous les paquets explicitement demandés, pour rebâtir mon système.

[Didier Spaier]

Or, d'après ce que je comprends de la doc de Slint, c'est full-install obligatoire (pas d'équivalent des tagfiles).

Exact. la gestion des dépendances est automatique quand on installe un paquet avec slapt-get mais pour gérer ça sans installer de "fausses" dépendances il faudrait partir de zéro et faire comme nobodino: mais j'ai déjà assez à faire, tant pis pour les minimalistes.

Incidemment, George Vlahavas a bien eu la gentillesse de calculer les dépendances des paquets slackware, mais ça vaut l'environnement dans lequel chaque paquet a été construit et comme Patrick compile sauf erreur dans une Slackware complète cela rend obligatoire des dépendances normalement facultatives. Pour cette raison j'ai été amené à recompiler pour l'installateur de Slint des paquets qui dans Slackware dépendent de X, par exemple.

J'ai bien autrefois publié une mini-slint avec une liste de paquets minimale mais je n'ai pas le temps de la mettre à jour. Présentement je suis plutôt occupé à adapter grub-btrfs à Slint, le but étant que les utilisateurs avant une mise à jour du système qu'ils estiment risquée puissent faire un instantané du sous-volume / (sans /home) avec timeshift, puis incluent dans le menu de GRUB une entrée pour pouvoir démarrer sur cet instantané s'ils ont foiré le système lors de la mise à jour.