Bonsoir,
Le 17/11/2021 à 22:13, Haricophile a écrit :
> Le Mon, 15 Nov 2021 20:56:12 +0100,
> Olivier Allard-Jacquin <olivieraj@???> a écrit :
>
>> Je ne comprends pas l'intérêt d'avoir un FS qui soit compatible
>> avec un autre OS, si c'est dans l'unique but de pouvoir utiliser un
>> mécanisme de réparation qui tourne sur un autre OS.
>
> Moi je comprends tout à fait l'intérêt d'avoir un système de fichier
> qui tourne sous tous les OS, mais la problématique est en fait: Je vois
> tout a fait l'intérêt qu'un OS supporte les différents systèmes de
> fichiers utilisés.
Je crois que tu es passé un peu vite sur cette partie-là de la phrase :
"si c'est dans **L'UNIQUE BUT** de pouvoir utiliser un mécanisme de
réparation qui tourne sur un autre OS"
Ce qui répondait exactement à la 2nd question de Marc:
"qu'il serait à la fois possible d'utiliser/**vérifier/réparer** sous
Linux et sous Windows ?"
Ceci étant, je travaille tous les jours avec la problématique des
échanges de données Linux / Windows
> Ce n'est pas pour rien que l'April/GNU/FSF... parlent de logiciel
> PRIVATEURS dont Windows est un achétype. Il passent beaucoup de temps a
> programmer non pas des choses pour faire, mais des choses pour empêcher
> de faire. Refuser volontairement la compatibilité est une chose pour
> laquelle Microsoft a été pionier. Une licence libre énumère vos droits,
> une CLUF énumère des interdictions.
OK, je veux bien faire un bilan, pas forcément éxostif, qui regroupe
technique et licence, pour ce qui est de la compatibilité Linux/Windows:
- FAT12: Je ne crois pas qu'il y ait de brevet dessus. Mais il y a une
grosse contrainte technique, car c'est limité aux taille de disquette :
2.88Mo, ou pas beaucoup plus. Supporté par tous les msdos / windows / linux
- FAT16: Probablement aussi pas de licence. Limité à 4Go max. Et un
fichier ne peut pas faire plus de 4Go (et pour cause ! :)) Supporté par
tout les msdos / windows / linux
- FAT32 SANS GESTION DE NOMS LONGS: Pas de licence. Noms en 8+3
caractères seulement. Pas d'espaces non plus, ni de caractères un peu
spéciaux, comme les accents. Un disque formaté sous Windows fait 32Go
max de taille. Sous Linux, on peut formater jusqu'à 128Go (et Windows le
lit aussi). C'est le format "idéal" pour le libriste "puriste", mais il
a une méchante contrainte : Un fichier ne peut pas faire plus de 4Go.
Pas de support par MS-DOS, ni Windows NT et inférieur
- FAT32 AVEC GESTION DE NOMS LONGS: Le mécanisme de noms long a été
protégé par une licence jusqu'en 2013/2014, puis est tombé. Il a les
mêmes contraintes / avantages que plus haut. C'est le plus communs des
systèmes de fichiers compatibles, et il serait suffisant, si ce n'était
ce problème de taille max de fichier limité à 4Go. Bon support par tous
les équipements materiels (appareil photo, TV, autoradio, ...)
- NTFS : Protégé par des brevets. Linux utilise une astuce, en faisant
tourner du code proprio afin d'accéder au FS (ntfs-3G + FUSE). Il yavait
une vielle implémentation native de ntfs jusqu'il y a ~15 ans, mais
c'est abandonné. Pas de grosses limitations techniques, et pour ceux qui
veulent jouer avec, une gestion des droits d'accès aux fichiers. Sous
Linux, les perfs sont mauvaises, spécialement avec des clés USB 2.0 .
C'est le moyen le plus communs pour transférer des fichiers de plus de
4Go entre un Linux et un Windows, via un support externe. Plutôt pas mal
supporté par les TV , autoradio, ..., mais sans pour autant être une
obligation . Pas de support MS-DOS et Windows 98 et inférieur; Supporté
par Windows NT et +. Attention pour Windows NT, il faut un SP4 minimum
pour supporter pleinement l'implémentation 1.1 de NTFS (non, cela ne
sent pas le vécu, et les em... qui vont avec ... :) )
- exFAT : Pour simplifier, je dirai que pour la technique, ce sont les
avantages du NTFS, mais sans ses ennuis. Il y a un problème de brevet
(c'est un produit MS), mais l'OIN
https://fr.wikipedia.org/wiki/Open_invention_network en a une licence.
Intégré en natif dans les kernel Linux depuis le 5.4, et dans Windows XP
+ SP2. Supporté aussi par certaines versions de MacOSX. Pour les TV,
autoradio, box ADSL, ...., le support est variable. Linux peut le
formater, et même le tester (paquet "exfat-utils" dans Debian).
Conclusion:
- exFAT est probablement le meilleur compromis pour des transferts entre
un Linux kernel 5.4 et un Windows 7 et +. Pour les autres "box
hardware", il faut s'attendre à des problèmes de compatibilité
- FAT32 sans gestion des noms long pour les librises puristes, qui sont
sous Linux et qui n'ont pas besoin de compatibilité avec Windows NT,
3.11 et en-dessous
- FAT16 pour les Linuxiens qui traînent encore avec du Windows NT, 95 et
inférieur.
> Par contre il ne faut pas trop m'en demander sous Windows, mais est-ce
> que le «linux subsystem» de windows ne permettrait pas de
> monter des disques en ext4 ?
A voir, je n'ai pas testé ce truc.
Au boulot, j'utilise soit Cygwin, soit une VM Linux.
> Dernier point, les logiciels de "data-recovery" sont à priori
> multi-plate-forme, mais pour réparer le système de fichier en
> production de l'usine à gaz NTFS il n'y a que l'usine à gaz Windows,
> c'est aussi la rançon de ces logiciels mal architecturés où on mélange
> les torchons et les serviettes... je n'ose pas dire à l'inverse de
> Linux parce que la philosophie Unix disparait à grande vitesse avec
> systemd et compagnie.
Ah, un bon vieux troll systemd ! Il en sort encore du bois ? En 2021,
cela manquait ! :)
Si tu as vraiment besoin d'un script /etc/init.d/ , tu peux toujours
l'utiliser (personnellement je m'en suis créer quelques uns), et ils
sont très bien supportés en parallèle de systemd.
Activer/désactiver un service se fait par un simple lien /dev/null dans
/etc/systemd/
Et il y a tellement d'options de systemd, que tu peux en faire quelques
chose de réellement customisable.
Pour ce qui est de journald, les logs sont toujours aussi disponibles.
Certes, tu ne peux pas faire un grep direct dans le /var/log/journal/ .
Mais tu peux piper ton grep à la suite d'un journalctl, qui lui-même a
déjà des options pour filtrer du contenu.
Personnellement, je suis un grand utilisateur des scripts bash "vielle
école" avec des pipes de grep / sed / awk / perl / autres . Mais en
2021, dire qu'il est nécessaire d'avoir ce type d'horreurs dans les
scripts d'init, je trouve que c'est du combat d'arrière garde, qui
n'apporte rien à la philosophie Unix du "un programme par fonction".
Car, si l'on veut pousser ce concept jusqu'au bout, il faut passer au
micro-noyau Linux (bizarrement c'est une hérésie en terme de perfs), et
à la segmentation de l'initrd.
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
