Choix d'une distribution vaec certaines contraintes
173 réponses
vincent
Bonjour,
Je dois mettre en place un linux pour une utilisation principalement
multimédia et internet des utilisateurs. Les personnes ne
feront/pourront l'administration et la configuration des machines.
J'ai cependant quelques contraintes :
- L'administration doit pouvoir se faire entièrement en mode console.
Ca, je pense que toutes les distributions le font, mais les fichiers
de config sont-ils clairs ? Ainsi qu'une façon simple de mettre à jour
?
- Les packages doivent être récents. Ce qui enlève donc Debian stable.
- Il faut une release de temps en temps pour avoir les même outils sur
toutes les machines. Ce qui enlève Debian testing et unstable. Avec
une fréquence de release assez raisonnable (n'est-ce pas Debian ? ;-)
) mais pas non plus toutes les 2 jours.
- Les packages doivent (pour une question de faciliter) être sous
forme binaire. Ce qui enlève Gentoo
- La distribution doit bien sûr être entièrement libre et gratuite.
- L'installation doit être faite sur le disque dur.
Je pensais aux distributions Knoppix, Fedora ou Mandrake. Quels sont
vos avis sur la question ? D'autres distributions vous viennent
semblent peut-être plus adaptée ?
J'avais envisagé la solution d'un *BSD, mais ce serait pour mettre en
place sur des ordinateurs portables, donc Linux me semble mieux
adapté.
On Wed, 10 Dec 2003 18:31:48 +0000 (UTC), Nicolas George wrote:
Et sinon, cvs ?
Si chacun se met à faire tourner son petit serveur CVS dans un coin, bonjour la sécurité...
Surtout qu'une repository CVS a deux types d'utilisateurs : lecture seule, et lecture/écriture partout. Et pour faire des droits plus fins, on mappe les utilisateurs CVS à ... des utilisateurs système ! Retour à la case départ, en quelque sorte.
Sam. -- Sam Hocevar <http://sam.zoy.org/>
On Wed, 10 Dec 2003 18:31:48 +0000 (UTC), Nicolas George wrote:
Et sinon, cvs ?
Si chacun se met à faire tourner son petit serveur CVS dans un coin,
bonjour la sécurité...
Surtout qu'une repository CVS a deux types d'utilisateurs : lecture
seule, et lecture/écriture partout. Et pour faire des droits plus fins,
on mappe les utilisateurs CVS à ... des utilisateurs système ! Retour à
la case départ, en quelque sorte.
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
On Wed, 10 Dec 2003 18:31:48 +0000 (UTC), Nicolas George wrote:
Et sinon, cvs ?
Si chacun se met à faire tourner son petit serveur CVS dans un coin, bonjour la sécurité...
Surtout qu'une repository CVS a deux types d'utilisateurs : lecture seule, et lecture/écriture partout. Et pour faire des droits plus fins, on mappe les utilisateurs CVS à ... des utilisateurs système ! Retour à la case départ, en quelque sorte.
Sam. -- Sam Hocevar <http://sam.zoy.org/>
Vincent Bernat
OoO En cette fin de nuit blanche du mercredi 10 décembre 2003, vers 05:38, Emmanuel Florac disait:
Oui, c'est tourner autour du pot car n'importe quelle distrib qui gère les dépendances sait faire ça.
De toute façon la question n'est pas là à mon avis. La slackware est facile à installer, facile à administrer, facile à customiser et bien plus rapide que RedHat/Debian sur le même matériel. Ensuite le système de paquetage, on peut vivre avec, il a des avantages (extrème simplicité à créer des paquets, gestion très simple des paquets) et des inconvénients (pas de dépendances, lent à la désinstallation). Voilà.
Entièrement d'accord (je ferme les yeux sur le "plus rapide" que je ne comprends pas), suffit de le dire. -- /* Nobody will ever see this message :-) */ panic("Cannot initialize video hardwaren"); 2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c
OoO En cette fin de nuit blanche du mercredi 10 décembre 2003, vers
05:38, Emmanuel Florac <eflorac@verisign.com> disait:
Oui, c'est tourner autour du pot car n'importe quelle distrib qui gère
les dépendances sait faire ça.
De toute façon la question n'est pas là à mon avis. La slackware est
facile à installer, facile à administrer, facile à customiser et bien
plus rapide que RedHat/Debian sur le même matériel. Ensuite le système de
paquetage, on peut vivre avec, il a des avantages (extrème simplicité à
créer des paquets, gestion très simple des paquets) et des inconvénients
(pas de dépendances, lent à la désinstallation). Voilà.
Entièrement d'accord (je ferme les yeux sur le "plus rapide" que je ne
comprends pas), suffit de le dire.
--
/* Nobody will ever see this message :-) */
panic("Cannot initialize video hardwaren");
2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c
OoO En cette fin de nuit blanche du mercredi 10 décembre 2003, vers 05:38, Emmanuel Florac disait:
Oui, c'est tourner autour du pot car n'importe quelle distrib qui gère les dépendances sait faire ça.
De toute façon la question n'est pas là à mon avis. La slackware est facile à installer, facile à administrer, facile à customiser et bien plus rapide que RedHat/Debian sur le même matériel. Ensuite le système de paquetage, on peut vivre avec, il a des avantages (extrème simplicité à créer des paquets, gestion très simple des paquets) et des inconvénients (pas de dépendances, lent à la désinstallation). Voilà.
Entièrement d'accord (je ferme les yeux sur le "plus rapide" que je ne comprends pas), suffit de le dire. -- /* Nobody will ever see this message :-) */ panic("Cannot initialize video hardwaren"); 2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c
Alexis Guillaume
Évidemment, on va me répondre que c'est normal, qu'on n'ajoute pas des membres à un projet à la légère, et enore moins créer un projet, etc. Mais si. Dans un réseau de grande école ou d'université, si deux élèves veulent travailler ensemble sur un projet de TP, ils ne vont pas aller faire chier l'administrateur qui a 300 postes et 3000 utilisateurs à gérer.
À la fac, si l'ambiance n'est pas trop pourrie, le plus simple pour travailler à plusieurs est de mettre les permissions à g+rwx. En licence/maîtrise d'info à Lyon, la culture est d'avoir des permissions gentilles sur ses tps. Je me souviens que quand j'étais en galère, je lançais des énormes find /home -exec grep. :-)
-- Alexis Guillaume <http://cowsoft.free.fr> : ressources universitaires en vrac
"Il est minuit. La pluie fouette les vitres."
Évidemment, on va me répondre que c'est normal, qu'on n'ajoute pas des
membres à un projet à la légère, et enore moins créer un projet, etc.
Mais si. Dans un réseau de grande école ou d'université, si deux élèves
veulent travailler ensemble sur un projet de TP, ils ne vont pas aller
faire chier l'administrateur qui a 300 postes et 3000 utilisateurs à
gérer.
À la fac, si l'ambiance n'est pas trop pourrie, le plus simple pour
travailler à plusieurs est de mettre les permissions à g+rwx.
En licence/maîtrise d'info à Lyon, la culture est d'avoir des permissions
gentilles sur ses tps. Je me souviens que quand j'étais en galère, je
lançais des énormes find /home -exec grep. :-)
--
Alexis Guillaume
<http://cowsoft.free.fr> : ressources universitaires en vrac
Évidemment, on va me répondre que c'est normal, qu'on n'ajoute pas des membres à un projet à la légère, et enore moins créer un projet, etc. Mais si. Dans un réseau de grande école ou d'université, si deux élèves veulent travailler ensemble sur un projet de TP, ils ne vont pas aller faire chier l'administrateur qui a 300 postes et 3000 utilisateurs à gérer.
À la fac, si l'ambiance n'est pas trop pourrie, le plus simple pour travailler à plusieurs est de mettre les permissions à g+rwx. En licence/maîtrise d'info à Lyon, la culture est d'avoir des permissions gentilles sur ses tps. Je me souviens que quand j'étais en galère, je lançais des énormes find /home -exec grep. :-)
-- Alexis Guillaume <http://cowsoft.free.fr> : ressources universitaires en vrac
"Il est minuit. La pluie fouette les vitres."
Patrice Karatchentzeff
Sam Hocevar <sam+ writes:
Je n'ai pas d'onduleur chez moi, ça coûte trop cher. Un filesystem journalisé, ça ne me coûte presque rien. Et un onduleur n'a jamais protégé contre toutes les défaillances matérielles, il ne rend donc pas les filesystems journalisés inutiles. Un journal sert d'ailleurs à bien d'autres choses que les pannes de courant, par exemple les filesystems réseau et notamment les filesystems distribués.
Là, un bémol.
Contraint et forcé d'avoir un onduleur chez moi faute d'une livraison stable de notre EDF bien national - montagne oblige diront certains..., je ne regrette pas ce choix. L'onduleur ne protège pas que des incapacités d'EDF, il protège aussi en amont le matériel (alimentation notamment mais aussi protection contre la foudre (ligne électrique et téléphonique)).
Mais je reconnais que le ticket d'achat est onéreux - enfin, en regard du service... Moins de 2000 francs pour cela, j'ai signé. Depuis, mon voisin a déjà changé une carte-mère, deux modems, et sa bécane ne tourne presque jamais, contrairement à la mienne ;-)
Je n'ai pas d'onduleur chez moi, ça coûte trop cher. Un filesystem
journalisé, ça ne me coûte presque rien. Et un onduleur n'a jamais
protégé contre toutes les défaillances matérielles, il ne rend donc pas
les filesystems journalisés inutiles. Un journal sert d'ailleurs à bien
d'autres choses que les pannes de courant, par exemple les filesystems
réseau et notamment les filesystems distribués.
Là, un bémol.
Contraint et forcé d'avoir un onduleur chez moi faute d'une livraison
stable de notre EDF bien national - montagne oblige diront
certains..., je ne regrette pas ce choix. L'onduleur ne protège pas que
des incapacités d'EDF, il protège aussi en amont le matériel
(alimentation notamment mais aussi protection contre la foudre (ligne
électrique et téléphonique)).
Mais je reconnais que le ticket d'achat est onéreux - enfin, en regard
du service... Moins de 2000 francs pour cela, j'ai signé. Depuis, mon
voisin a déjà changé une carte-mère, deux modems, et sa bécane ne
tourne presque jamais, contrairement à la mienne ;-)
Je n'ai pas d'onduleur chez moi, ça coûte trop cher. Un filesystem journalisé, ça ne me coûte presque rien. Et un onduleur n'a jamais protégé contre toutes les défaillances matérielles, il ne rend donc pas les filesystems journalisés inutiles. Un journal sert d'ailleurs à bien d'autres choses que les pannes de courant, par exemple les filesystems réseau et notamment les filesystems distribués.
Là, un bémol.
Contraint et forcé d'avoir un onduleur chez moi faute d'une livraison stable de notre EDF bien national - montagne oblige diront certains..., je ne regrette pas ce choix. L'onduleur ne protège pas que des incapacités d'EDF, il protège aussi en amont le matériel (alimentation notamment mais aussi protection contre la foudre (ligne électrique et téléphonique)).
Mais je reconnais que le ticket d'achat est onéreux - enfin, en regard du service... Moins de 2000 francs pour cela, j'ai signé. Depuis, mon voisin a déjà changé une carte-mère, deux modems, et sa bécane ne tourne presque jamais, contrairement à la mienne ;-)
OoO En ce milieu de nuit étoilée du mercredi 10 décembre 2003, vers 03:08, Stephane TOUGARD disait:
Tout ce que nous inventons, ecrivons ou creons repose sur ce qu'ont invente, ecrit et cree nos ancetre. Nous ne pouvons rien construire en ignorant ou meprisant leur travail.
Ce qui n'empêche pas de créer et d'utiliser des outils plus récents et aptes à répondre aux besoins actuels que ceux d'il y a 30 ans que tu sembles tant affectionner.
Mais il est inutile de te dire ça à toi vu que tu es bloqué 10 ans en arrière à brailler que tout ce qui est plus récent est de la merde. -- BOFH excuse #8: static buildup
OoO En ce milieu de nuit étoilée du mercredi 10 décembre 2003, vers
03:08, Stephane TOUGARD <stephane@unices.org> disait:
Tout ce que nous inventons, ecrivons ou creons repose sur ce qu'ont
invente, ecrit et cree nos ancetre. Nous ne pouvons rien construire en
ignorant ou meprisant leur travail.
Ce qui n'empêche pas de créer et d'utiliser des outils plus récents et
aptes à répondre aux besoins actuels que ceux d'il y a 30 ans que tu
sembles tant affectionner.
Mais il est inutile de te dire ça à toi vu que tu es bloqué 10 ans en
arrière à brailler que tout ce qui est plus récent est de la merde.
--
BOFH excuse #8:
static buildup
OoO En ce milieu de nuit étoilée du mercredi 10 décembre 2003, vers 03:08, Stephane TOUGARD disait:
Tout ce que nous inventons, ecrivons ou creons repose sur ce qu'ont invente, ecrit et cree nos ancetre. Nous ne pouvons rien construire en ignorant ou meprisant leur travail.
Ce qui n'empêche pas de créer et d'utiliser des outils plus récents et aptes à répondre aux besoins actuels que ceux d'il y a 30 ans que tu sembles tant affectionner.
Mais il est inutile de te dire ça à toi vu que tu es bloqué 10 ans en arrière à brailler que tout ce qui est plus récent est de la merde. -- BOFH excuse #8: static buildup
Emmanuel Florac
Dans article , disait...
Entièrement d'accord (je ferme les yeux sur le "plus rapide" que je ne comprends pas), suffit de le dire.
Tu ne comprends pas "plus rapide"? Ben ça veut dire plus rapide, quoi. C'est à dire qu'une slack instalée de frais avec les services que l'on veut configurés démarre plus vite, lance les programmes plus vite, qu'une RedHat/Debian. Maintenant en bidouillant longuement une Debian ou une RedHat (ce que j'ai fait dans le cas de Debian) on arrive aux mêmes résultats, mais c'est long, compliqué et douloureux.
Exemple : j'ai une slack sur mon PC, le boot entre l'invite lilo et la bannière gdm prend 18 secondes. J'ai changé 1 ligne dans un des scripts de démarrage. J'ai une Debian standard sur un autre PC, avec nettoyage fait dans les services : 40 secondes de démarrage. Enfin j'ai une Debian "optimisée" que j'ai fabriqué : 18 secondes, mais le noyau, les scripts de démarrage, tout est spécifique (garanti non debian).
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <m3vfooctev.fsf@neo.loria>, vincent.bernat@raysa.org
disait...
Entièrement d'accord (je ferme les yeux sur le "plus rapide" que je ne
comprends pas), suffit de le dire.
Tu ne comprends pas "plus rapide"? Ben ça veut dire plus rapide, quoi.
C'est à dire qu'une slack instalée de frais avec les services que l'on
veut configurés démarre plus vite, lance les programmes plus vite, qu'une
RedHat/Debian. Maintenant en bidouillant longuement une Debian ou une
RedHat (ce que j'ai fait dans le cas de Debian) on arrive aux mêmes
résultats, mais c'est long, compliqué et douloureux.
Exemple : j'ai une slack sur mon PC, le boot entre l'invite lilo et la
bannière gdm prend 18 secondes. J'ai changé 1 ligne dans un des scripts
de démarrage. J'ai une Debian standard sur un autre PC, avec nettoyage
fait dans les services : 40 secondes de démarrage. Enfin j'ai une Debian
"optimisée" que j'ai fabriqué : 18 secondes, mais le noyau, les scripts
de démarrage, tout est spécifique (garanti non debian).
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Entièrement d'accord (je ferme les yeux sur le "plus rapide" que je ne comprends pas), suffit de le dire.
Tu ne comprends pas "plus rapide"? Ben ça veut dire plus rapide, quoi. C'est à dire qu'une slack instalée de frais avec les services que l'on veut configurés démarre plus vite, lance les programmes plus vite, qu'une RedHat/Debian. Maintenant en bidouillant longuement une Debian ou une RedHat (ce que j'ai fait dans le cas de Debian) on arrive aux mêmes résultats, mais c'est long, compliqué et douloureux.
Exemple : j'ai une slack sur mon PC, le boot entre l'invite lilo et la bannière gdm prend 18 secondes. J'ai changé 1 ligne dans un des scripts de démarrage. J'ai une Debian standard sur un autre PC, avec nettoyage fait dans les services : 40 secondes de démarrage. Enfin j'ai une Debian "optimisée" que j'ai fabriqué : 18 secondes, mais le noyau, les scripts de démarrage, tout est spécifique (garanti non debian).
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Vincent Bernat
OoO Vers la fin de l'après-midi du mercredi 10 décembre 2003, vers 16:41, Emmanuel Florac disait:
Entièrement d'accord (je ferme les yeux sur le "plus rapide" que je ne comprends pas), suffit de le dire.
Tu ne comprends pas "plus rapide"? Ben ça veut dire plus rapide, quoi. C'est à dire qu'une slack instalée de frais avec les services que l'on veut configurés démarre plus vite, lance les programmes plus vite, qu'une RedHat/Debian. Maintenant en bidouillant longuement une Debian ou une RedHat (ce que j'ai fait dans le cas de Debian) on arrive aux mêmes résultats, mais c'est long, compliqué et douloureux.
Exemple : j'ai une slack sur mon PC, le boot entre l'invite lilo et la bannière gdm prend 18 secondes. J'ai changé 1 ligne dans un des scripts de démarrage. J'ai une Debian standard sur un autre PC, avec nettoyage fait dans les services : 40 secondes de démarrage. Enfin j'ai une Debian "optimisée" que j'ai fabriqué : 18 secondes, mais le noyau, les scripts de démarrage, tout est spécifique (garanti non debian).
Tu mesures la vitesse d'un système à la vitesse du boot ? Soit. -- Make sure input cannot violate the limits of the program. - The Elements of Programming Style (Kernighan & Plaugher)
OoO Vers la fin de l'après-midi du mercredi 10 décembre 2003, vers
16:41, Emmanuel Florac <eflorac@verisign.com> disait:
Entièrement d'accord (je ferme les yeux sur le "plus rapide" que je ne
comprends pas), suffit de le dire.
Tu ne comprends pas "plus rapide"? Ben ça veut dire plus rapide, quoi.
C'est à dire qu'une slack instalée de frais avec les services que l'on
veut configurés démarre plus vite, lance les programmes plus vite, qu'une
RedHat/Debian. Maintenant en bidouillant longuement une Debian ou une
RedHat (ce que j'ai fait dans le cas de Debian) on arrive aux mêmes
résultats, mais c'est long, compliqué et douloureux.
Exemple : j'ai une slack sur mon PC, le boot entre l'invite lilo et la
bannière gdm prend 18 secondes. J'ai changé 1 ligne dans un des scripts
de démarrage. J'ai une Debian standard sur un autre PC, avec nettoyage
fait dans les services : 40 secondes de démarrage. Enfin j'ai une Debian
"optimisée" que j'ai fabriqué : 18 secondes, mais le noyau, les scripts
de démarrage, tout est spécifique (garanti non debian).
Tu mesures la vitesse d'un système à la vitesse du boot ? Soit.
--
Make sure input cannot violate the limits of the program.
- The Elements of Programming Style (Kernighan & Plaugher)
OoO Vers la fin de l'après-midi du mercredi 10 décembre 2003, vers 16:41, Emmanuel Florac disait:
Entièrement d'accord (je ferme les yeux sur le "plus rapide" que je ne comprends pas), suffit de le dire.
Tu ne comprends pas "plus rapide"? Ben ça veut dire plus rapide, quoi. C'est à dire qu'une slack instalée de frais avec les services que l'on veut configurés démarre plus vite, lance les programmes plus vite, qu'une RedHat/Debian. Maintenant en bidouillant longuement une Debian ou une RedHat (ce que j'ai fait dans le cas de Debian) on arrive aux mêmes résultats, mais c'est long, compliqué et douloureux.
Exemple : j'ai une slack sur mon PC, le boot entre l'invite lilo et la bannière gdm prend 18 secondes. J'ai changé 1 ligne dans un des scripts de démarrage. J'ai une Debian standard sur un autre PC, avec nettoyage fait dans les services : 40 secondes de démarrage. Enfin j'ai une Debian "optimisée" que j'ai fabriqué : 18 secondes, mais le noyau, les scripts de démarrage, tout est spécifique (garanti non debian).
Tu mesures la vitesse d'un système à la vitesse du boot ? Soit. -- Make sure input cannot violate the limits of the program. - The Elements of Programming Style (Kernighan & Plaugher)
LiNuCe
[...] Le rwxrwxrwx c'est quelque chose de complètement obsolète, incapable de régler des problèmes de droits simplissimes (comme par exemple donner +r à un utilisateur A, +w à un utilisateur B, +rw à un utilisateur C).
Les systèmes de fichiers XFS, JFS, EXT2/3 et Reiserfs supportent les ACLs, parfois après applications de patches. Donc je ne pense pas qu'il soit judicieux de "chier" sur le "rwxrwxrwx" de Unix/Linux dans la mesure où la solution existe. Il suffit juste de mettre les mains dans le cambouis, et à mon avis, cela ne devrait pas être une difficulté pour toi d'après ton profil utilisateur. D'autant qu'avec une distribution comme Debian ou Slackware, mettre les mains dans le cambouis fait parti du "jeu".
Ça fait des années que les ACL sont standard sous NT, en revanche.
Ce n'est pas parce que c'est standard sous NT que c'est forcément une bonne solution technique en tant que telle. En ce qui me concerne, *je* trouve le "rwxrwxrwx" plus que suffisant au regard de *mes* besoins et de ceux que j'ai pu avoir lors de mon parcours. De plus, ils ont l'avantage de permettre une administration claire et conscise, ce qui est moins vrai avec les ACLs qui rajoutent vite une complexité supplémentaire pour quelques cas spécifiques qui peuvent être résolus autrement.
À titre d'exemple, il est très facile d'avoir une vision d'ensemble des permissions d'un système de fichier sans ACLs. Une commande aussi simple que find DOSSIER -printf "%u %g %m %p" permet d'obtenir une bonne vue d'ensemble sur les accès aux fichiers de l'arborescence du dossier DOSSIER. Avec ACLs, je doute fort qu'in puisse obtenir quelquechose d'aussi évident et clair.
-- LiNuCe
[...] Le rwxrwxrwx
c'est quelque chose de complètement obsolète, incapable de régler des
problèmes de droits simplissimes (comme par exemple donner +r à un
utilisateur A, +w à un utilisateur B, +rw à un utilisateur C).
Les systèmes de fichiers XFS, JFS, EXT2/3 et Reiserfs supportent les
ACLs, parfois après applications de patches. Donc je ne pense pas qu'il
soit judicieux de "chier" sur le "rwxrwxrwx" de Unix/Linux dans la
mesure où la solution existe. Il suffit juste de mettre les mains dans
le cambouis, et à mon avis, cela ne devrait pas être une difficulté pour
toi d'après ton profil utilisateur. D'autant qu'avec une distribution
comme Debian ou Slackware, mettre les mains dans le cambouis fait parti
du "jeu".
Ça fait des années que les ACL sont standard sous NT, en revanche.
Ce n'est pas parce que c'est standard sous NT que c'est forcément
une bonne solution technique en tant que telle. En ce qui me concerne,
*je* trouve le "rwxrwxrwx" plus que suffisant au regard de *mes* besoins
et de ceux que j'ai pu avoir lors de mon parcours. De plus, ils ont
l'avantage de permettre une administration claire et conscise, ce qui
est moins vrai avec les ACLs qui rajoutent vite une complexité
supplémentaire pour quelques cas spécifiques qui peuvent être résolus
autrement.
À titre d'exemple, il est très facile d'avoir une vision d'ensemble
des permissions d'un système de fichier sans ACLs. Une commande aussi
simple que find DOSSIER -printf "%u %g %m %p" permet d'obtenir une bonne
vue d'ensemble sur les accès aux fichiers de l'arborescence du dossier
DOSSIER. Avec ACLs, je doute fort qu'in puisse obtenir quelquechose
d'aussi évident et clair.
[...] Le rwxrwxrwx c'est quelque chose de complètement obsolète, incapable de régler des problèmes de droits simplissimes (comme par exemple donner +r à un utilisateur A, +w à un utilisateur B, +rw à un utilisateur C).
Les systèmes de fichiers XFS, JFS, EXT2/3 et Reiserfs supportent les ACLs, parfois après applications de patches. Donc je ne pense pas qu'il soit judicieux de "chier" sur le "rwxrwxrwx" de Unix/Linux dans la mesure où la solution existe. Il suffit juste de mettre les mains dans le cambouis, et à mon avis, cela ne devrait pas être une difficulté pour toi d'après ton profil utilisateur. D'autant qu'avec une distribution comme Debian ou Slackware, mettre les mains dans le cambouis fait parti du "jeu".
Ça fait des années que les ACL sont standard sous NT, en revanche.
Ce n'est pas parce que c'est standard sous NT que c'est forcément une bonne solution technique en tant que telle. En ce qui me concerne, *je* trouve le "rwxrwxrwx" plus que suffisant au regard de *mes* besoins et de ceux que j'ai pu avoir lors de mon parcours. De plus, ils ont l'avantage de permettre une administration claire et conscise, ce qui est moins vrai avec les ACLs qui rajoutent vite une complexité supplémentaire pour quelques cas spécifiques qui peuvent être résolus autrement.
À titre d'exemple, il est très facile d'avoir une vision d'ensemble des permissions d'un système de fichier sans ACLs. Une commande aussi simple que find DOSSIER -printf "%u %g %m %p" permet d'obtenir une bonne vue d'ensemble sur les accès aux fichiers de l'arborescence du dossier DOSSIER. Avec ACLs, je doute fort qu'in puisse obtenir quelquechose d'aussi évident et clair.
-- LiNuCe
Emmanuel Florac
Dans article , disait...
Tu mesures la vitesse d'un système à la vitesse du boot ? Soit.
Non, mais c'est un exemple. Je mesure la vitesse à la sensation subjective de vitesse d'une part, et à la vitesse de lancement des applis. Ensuite une fois lancée, une appli a pau ou prou les mêmes perfs sur les différentes distrib.
Je remarque néammoins par exemple que le gcc de la Debian fait des binaires énormes par rapport à celui de la slack (en moyenne, presque le double). Si toutes les applis debian sont compilées avec les options debug, évidemment ça doit pas aider.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <m3r7zc9jhp.fsf@neo.loria>, vince@khabale.org disait...
Tu mesures la vitesse d'un système à la vitesse du boot ? Soit.
Non, mais c'est un exemple. Je mesure la vitesse à la sensation
subjective de vitesse d'une part, et à la vitesse de lancement des
applis. Ensuite une fois lancée, une appli a pau ou prou les mêmes perfs
sur les différentes distrib.
Je remarque néammoins par exemple que le gcc de la Debian fait des
binaires énormes par rapport à celui de la slack (en moyenne, presque le
double). Si toutes les applis debian sont compilées avec les options
debug, évidemment ça doit pas aider.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Tu mesures la vitesse d'un système à la vitesse du boot ? Soit.
Non, mais c'est un exemple. Je mesure la vitesse à la sensation subjective de vitesse d'une part, et à la vitesse de lancement des applis. Ensuite une fois lancée, une appli a pau ou prou les mêmes perfs sur les différentes distrib.
Je remarque néammoins par exemple que le gcc de la Debian fait des binaires énormes par rapport à celui de la slack (en moyenne, presque le double). Si toutes les applis debian sont compilées avec les options debug, évidemment ça doit pas aider.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Emmanuel Florac
Dans article <br981u$htl$, disait...
En ce qui me concerne, *je* trouve le "rwxrwxrwx" plus que suffisant au regard de *mes* besoins et de ceux que j'ai pu avoir lors de mon parcours.
Dans la pratique, il me semble que les gens qui n'ont pas de réseau de plusieurs centaines de postes (c'est à dire une infime minorité des sociétés, associations, mairies, etc) n'ont rien à péter des ACLs.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <br981u$htl$1@news-reader2.wanadoo.fr>,
linuce@home.sweet.home disait...
En ce qui me concerne,
*je* trouve le "rwxrwxrwx" plus que suffisant au regard de *mes* besoins
et de ceux que j'ai pu avoir lors de mon parcours.
Dans la pratique, il me semble que les gens qui n'ont pas de réseau de
plusieurs centaines de postes (c'est à dire une infime minorité des
sociétés, associations, mairies, etc) n'ont rien à péter des ACLs.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
En ce qui me concerne, *je* trouve le "rwxrwxrwx" plus que suffisant au regard de *mes* besoins et de ceux que j'ai pu avoir lors de mon parcours.
Dans la pratique, il me semble que les gens qui n'ont pas de réseau de plusieurs centaines de postes (c'est à dire une infime minorité des sociétés, associations, mairies, etc) n'ont rien à péter des ACLs.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
