Je pense au contraire que la hiérarchie de système unix correspond à des choix réfléchis et intelligent.
La distinction entre bin et sbin est importante. sbin devrait contenir des utilitaires permettant la configuration du système. Le fait que tous ces utilitaires restent dans sbin permet de restreindre facilement qui a le droit de les utiliser (en utilisant simplement les acl de base unix, pas un truc over complexe à configurer genre SeLinux). A noter que seul les fichiers dans bin et sbin devraient avoir le bit +x.
Les répertoires lib et include sont a mon avis important si on ne veut pas se taper 50 000 répertoires en dépendances (ou alors the great union hack).
La distinction est assez clair entre / /usr /usr/local ... Elles representent chacune des sources distinctes de provenance ou d'utilisation des fichiers (typiquement single user, multi user (system), systeme de package).
/usr/games existe parce que tout le monde n'a pas le droit de jouer :). Il faut être un copain de root pour le faire. Ca serait assez pénible de modifier les droits fichier par fichier plutot que de changer globalement les droits du répertoire /usr/games (et /usr/local/games).
share, libdata et libexec ont une importance un peu moins forte et pourrait peut-être être simplifié.
Globalement, la hiérarchie de fichier est pensé pour être facilement sécurisé, en mettant en place des politiques globales et simples à mettre en place (par rapport à des choses très fines et un peu overkill dans ce cas comme SeLinux, Mac sous FreeBSD, ....).
A propos du rm -rf. Je n'y crois absolument pas. Ca laisse le système de lien completement en vrac et ca casse tout le système de dépendance. C'est la meilleur façon de créer des problèmes (le seul cas ou ca serait possible, c'est dêtre sur à 100% qu'il n'y ait aucune dépendance). En plus, les rm -rf en root, j'evite :). Enfin c'est assez facile de pas supprimer le bon truc :)
Il est possible que de nombreuses distributions prennnent leur aise avec la FHS, elles n'ont qu'a être strictes envers ce FHS.
Evidemment, ces remarques s'entendent majoritairement pour une utilisation multi utilisateur. Pour une utilisation mono utilisateur ou l'utilisateur peut tout faire, les deux architectures n'ont qu'assez peu d'importance.
Notons au passage qu'une de vos critiques du FHS c'est de retrouver nos fichiers. Il est vrai qu'il est facile de deviner que ping est caché dans Netkit ou que ls va se trouver cacher dans CoreUtils ...
[^] # Re: Fausse bonne idée
Posté par zul . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 4.
La distinction entre bin et sbin est importante. sbin devrait contenir des utilitaires permettant la configuration du système. Le fait que tous ces utilitaires restent dans sbin permet de restreindre facilement qui a le droit de les utiliser (en utilisant simplement les acl de base unix, pas un truc over complexe à configurer genre SeLinux). A noter que seul les fichiers dans bin et sbin devraient avoir le bit +x.
Les répertoires lib et include sont a mon avis important si on ne veut pas se taper 50 000 répertoires en dépendances (ou alors the great union hack).
La distinction est assez clair entre / /usr /usr/local ... Elles representent chacune des sources distinctes de provenance ou d'utilisation des fichiers (typiquement single user, multi user (system), systeme de package).
/usr/games existe parce que tout le monde n'a pas le droit de jouer :). Il faut être un copain de root pour le faire. Ca serait assez pénible de modifier les droits fichier par fichier plutot que de changer globalement les droits du répertoire /usr/games (et /usr/local/games).
share, libdata et libexec ont une importance un peu moins forte et pourrait peut-être être simplifié.
Globalement, la hiérarchie de fichier est pensé pour être facilement sécurisé, en mettant en place des politiques globales et simples à mettre en place (par rapport à des choses très fines et un peu overkill dans ce cas comme SeLinux, Mac sous FreeBSD, ....).
A propos du rm -rf. Je n'y crois absolument pas. Ca laisse le système de lien completement en vrac et ca casse tout le système de dépendance. C'est la meilleur façon de créer des problèmes (le seul cas ou ca serait possible, c'est dêtre sur à 100% qu'il n'y ait aucune dépendance). En plus, les rm -rf en root, j'evite :). Enfin c'est assez facile de pas supprimer le bon truc :)
Il est possible que de nombreuses distributions prennnent leur aise avec la FHS, elles n'ont qu'a être strictes envers ce FHS.
Evidemment, ces remarques s'entendent majoritairement pour une utilisation multi utilisateur. Pour une utilisation mono utilisateur ou l'utilisateur peut tout faire, les deux architectures n'ont qu'assez peu d'importance.
Notons au passage qu'une de vos critiques du FHS c'est de retrouver nos fichiers. Il est vrai qu'il est facile de deviner que ping est caché dans Netkit ou que ls va se trouver cacher dans CoreUtils ...