Je suis sous LinuxMint. J'ai plusieurs partitions de 150, 200, 280 Go.
Plusieurs sont bien remplies. J'ai également un disque dur externe de
500 Go sur lequel se trouvent 2 partitions en ext4 (251 et 95 Go) et 1
autre en ntfs (100 Go).
Lors de sauvegarde avec rsync, elle se se fait dans /media/user.
Il se trouve que /media *fait partie de la racine*. Dans ces conditions,
je ne peux pas utiliser mon disque dur externe car la sauvegarde est
supérieure à la capacité de la partition de /media/user/sauvegarde.
Comment faire pour pouvoir utiliser mon disque dur externe comme outil
de sauvegarde, ce pourquoi il est généralement destiné.
--
JJG
Entre Dauphiné et PACA!
découvrez la généalogie et l'histoire de votre famille :
http://memoire-des-hommes.fr/
Doug713705 , dans le message <o770r7$4na$, a écrit :
Aucune idée du coupable mais si l'option -R existe c'est qu'on doit pouvoir s'en servir.
Bien sûr. Il y a une option -r à rm, aussi, on doit pouvoir s'en servir. Tu en déduis que rm -rf / est une bonne idée ? Je ne critique pas l'usage de l'option -R, je critique le choix de faire l'opération elle-même.
Je propose qu'on reboote la machine jusqu'à ce qu'elle reparte. J'ai bon ?
C'est à peu près du même niveau que certaines réponses qu'on a lues ici.
Chmod -R malheureux ? Règle udev à la con, fstab bancale, il y a tellement de raisons possibles...
C'est précisément pour ça qu'il fallait, avant toute chose, regarder précisément le problème.
Doug713705 , dans le message <o770r7$4na$1@golgoth99.redatomik.org>, a
écrit :
Aucune idée du coupable mais si l'option -R existe c'est qu'on doit
pouvoir s'en servir.
Bien sûr. Il y a une option -r à rm, aussi, on doit pouvoir s'en servir.
Tu en déduis que rm -rf / est une bonne idée ?
Je ne critique pas l'usage de l'option -R, je critique le choix de faire
l'opération elle-même.
Je propose qu'on reboote la machine jusqu'à ce qu'elle reparte. J'ai bon ?
C'est à peu près du même niveau que certaines réponses qu'on a lues ici.
Chmod -R malheureux ? Règle udev à la con, fstab bancale, il y a tellement
de raisons possibles...
C'est précisément pour ça qu'il fallait, avant toute chose, regarder
précisément le problème.
Doug713705 , dans le message <o770r7$4na$, a écrit :
Aucune idée du coupable mais si l'option -R existe c'est qu'on doit pouvoir s'en servir.
Bien sûr. Il y a une option -r à rm, aussi, on doit pouvoir s'en servir. Tu en déduis que rm -rf / est une bonne idée ? Je ne critique pas l'usage de l'option -R, je critique le choix de faire l'opération elle-même.
Je propose qu'on reboote la machine jusqu'à ce qu'elle reparte. J'ai bon ?
C'est à peu près du même niveau que certaines réponses qu'on a lues ici.
Chmod -R malheureux ? Règle udev à la con, fstab bancale, il y a tellement de raisons possibles...
C'est précisément pour ça qu'il fallait, avant toute chose, regarder précisément le problème.
François Patte
Le 05/02/2017 12:04, Doug713705 a écrit :
Le 05-02-2017, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5896eae6$0$3361$) :
Pour commencer, si l'utilisateur avait fait des modifications sur les groupes de ses fichiers, pour travailler collectivement sur un projet ou laisser un CGI accéder à ses fichiers, ça les annule.
Sur un homedir c'est généralement sans conséquence, les gens laissant accéder des fichiers de leur homedir à un CGI ne doivent plus être très nombreux au XXIème siècle et pour travailler collectivement sur un projet on utilise plutôt un outil comme git qu'un partage qui a toutes les chances d'être contraignant sinon foireux, tout au moins foiré un jour où l'autre.
Pour un simple échange de fichiers entre membres d'un me labo/groupe c'est peut-être un peu lourd, non? -- François Patte Université Paris Descartes
Le 05/02/2017 12:04, Doug713705 a écrit :
Le 05-02-2017, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5896eae6$0$3361$426a74cc@news.free.fr>) :
Pour commencer, si l'utilisateur avait fait des modifications sur les
groupes de ses fichiers, pour travailler collectivement sur un projet ou
laisser un CGI accéder à ses fichiers, ça les annule.
Sur un homedir c'est généralement sans conséquence, les gens laissant
accéder des fichiers de leur homedir à un CGI ne doivent plus être très
nombreux au XXIème siècle et pour travailler collectivement sur un projet
on utilise plutôt un outil comme git qu'un partage qui a toutes les chances
d'être contraignant sinon foireux, tout au moins foiré un jour où l'autre.
Pour un simple échange de fichiers entre membres d'un me labo/groupe
c'est peut-être un peu lourd, non?
Le 05-02-2017, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5896eae6$0$3361$) :
Pour commencer, si l'utilisateur avait fait des modifications sur les groupes de ses fichiers, pour travailler collectivement sur un projet ou laisser un CGI accéder à ses fichiers, ça les annule.
Sur un homedir c'est généralement sans conséquence, les gens laissant accéder des fichiers de leur homedir à un CGI ne doivent plus être très nombreux au XXIème siècle et pour travailler collectivement sur un projet on utilise plutôt un outil comme git qu'un partage qui a toutes les chances d'être contraignant sinon foireux, tout au moins foiré un jour où l'autre.
Pour un simple échange de fichiers entre membres d'un me labo/groupe c'est peut-être un peu lourd, non? -- François Patte Université Paris Descartes
Nicolas George
François Patte , dans le message <o774mp$etf$, a écrit :
Pour un simple échange de fichiers entre membres d'un me labo/groupe c'est peut-être un peu lourd, non?
Non, au contraire c'est plus facile que la plupart des autres solutions. En revanche, Git n'est réellement utile qu'avec des fichiers texte. Mais bon, dans un labo sérieux, tout le monde utilise LaTeX de toutes façons.
François Patte , dans le message <o774mp$etf$1@dont-email.me>, a écrit :
Pour un simple échange de fichiers entre membres d'un me labo/groupe
c'est peut-être un peu lourd, non?
Non, au contraire c'est plus facile que la plupart des autres solutions.
En revanche, Git n'est réellement utile qu'avec des fichiers texte. Mais
bon, dans un labo sérieux, tout le monde utilise LaTeX de toutes façons.
François Patte , dans le message <o774mp$etf$, a écrit :
Pour un simple échange de fichiers entre membres d'un me labo/groupe c'est peut-être un peu lourd, non?
Non, au contraire c'est plus facile que la plupart des autres solutions. En revanche, Git n'est réellement utile qu'avec des fichiers texte. Mais bon, dans un labo sérieux, tout le monde utilise LaTeX de toutes façons.
Doug713705
Le 05-02-2017, François Patte nous expliquait dans fr.comp.os.linux.configuration (<o774mp$etf$) :
Le 05/02/2017 12:04, Doug713705 a écrit :
Le 05-02-2017, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5896eae6$0$3361$) :
Pour commencer, si l'utilisateur avait fait des modifications sur les groupes de ses fichiers, pour travailler collectivement sur un projet ou laisser un CGI accéder à ses fichiers, ça les annule.
Sur un homedir c'est généralement sans conséquence, les gens laissant accéder des fichiers de leur homedir à un CGI ne doivent plus être très nombreux au XXIème siècle et pour travailler collectivement sur un projet on utilise plutôt un outil comme git qu'un partage qui a toutes les chances d'être contraignant sinon foireux, tout au moins foiré un jour où l'autre.
Pour un simple échange de fichiers entre membres d'un me labo/groupe c'est peut-être un peu lourd, non?
Si c'est un simple échange ponctuel, un tar.gz ira bien. Si l'échange doit être régulier voire permanent, un partage NFS fera l'affaire auquel cas il n'aura rien à faire dans le homedir d'un utilisateur. Si les fichiers ne sont pas trop volumineux, git gère ça très bien et n'a rien de lourd. La nature des fichiers doit entrer en compte dans le choix de la solution (fichiers binaires/textes). -- Oh, papa ! tu tournes en rond dans ta psychose T'es qu'un dealer de black-out. T'es aussi coincé qu'un rollmops Tombé dans une cuve à mazout -- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout
Le 05-02-2017, François Patte nous expliquait dans
fr.comp.os.linux.configuration
(<o774mp$etf$1@dont-email.me>) :
Le 05/02/2017 12:04, Doug713705 a écrit :
Le 05-02-2017, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5896eae6$0$3361$426a74cc@news.free.fr>) :
Pour commencer, si l'utilisateur avait fait des modifications sur les
groupes de ses fichiers, pour travailler collectivement sur un projet ou
laisser un CGI accéder à ses fichiers, ça les annule.
Sur un homedir c'est généralement sans conséquence, les gens laissant
accéder des fichiers de leur homedir à un CGI ne doivent plus être très
nombreux au XXIème siècle et pour travailler collectivement sur un projet
on utilise plutôt un outil comme git qu'un partage qui a toutes les chances
d'être contraignant sinon foireux, tout au moins foiré un jour où l'autre.
Pour un simple échange de fichiers entre membres d'un me labo/groupe
c'est peut-être un peu lourd, non?
Si c'est un simple échange ponctuel, un tar.gz ira bien.
Si l'échange doit être régulier voire permanent, un partage NFS fera
l'affaire auquel cas il n'aura rien à faire dans le homedir d'un
utilisateur.
Si les fichiers ne sont pas trop volumineux, git gère ça très bien et
n'a rien de lourd.
La nature des fichiers doit entrer en compte dans le choix de la
solution (fichiers binaires/textes).
--
Oh, papa ! tu tournes en rond dans ta psychose
T'es qu'un dealer de black-out.
T'es aussi coincé qu'un rollmops
Tombé dans une cuve à mazout
-- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout
Le 05-02-2017, François Patte nous expliquait dans fr.comp.os.linux.configuration (<o774mp$etf$) :
Le 05/02/2017 12:04, Doug713705 a écrit :
Le 05-02-2017, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5896eae6$0$3361$) :
Pour commencer, si l'utilisateur avait fait des modifications sur les groupes de ses fichiers, pour travailler collectivement sur un projet ou laisser un CGI accéder à ses fichiers, ça les annule.
Sur un homedir c'est généralement sans conséquence, les gens laissant accéder des fichiers de leur homedir à un CGI ne doivent plus être très nombreux au XXIème siècle et pour travailler collectivement sur un projet on utilise plutôt un outil comme git qu'un partage qui a toutes les chances d'être contraignant sinon foireux, tout au moins foiré un jour où l'autre.
Pour un simple échange de fichiers entre membres d'un me labo/groupe c'est peut-être un peu lourd, non?
Si c'est un simple échange ponctuel, un tar.gz ira bien. Si l'échange doit être régulier voire permanent, un partage NFS fera l'affaire auquel cas il n'aura rien à faire dans le homedir d'un utilisateur. Si les fichiers ne sont pas trop volumineux, git gère ça très bien et n'a rien de lourd. La nature des fichiers doit entrer en compte dans le choix de la solution (fichiers binaires/textes). -- Oh, papa ! tu tournes en rond dans ta psychose T'es qu'un dealer de black-out. T'es aussi coincé qu'un rollmops Tombé dans une cuve à mazout -- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout
Lucas Levrel
Le 5 février 2017, à 08:37, Doug713705 a écrit :
Le 05-02-2017, Jo Engo nous expliquait dans fr.comp.os.linux.configuration (<5896d5c0$0$4276$) :
sudo chown -R user:user /home/user
Ah. John Doe bénéficie o-to-ma-ti-que-ment d'un groupe John Doe ?
Sur la plupart des distributions oui.
C'est idiot, non ? Ça annule la notion même de groupe. Sur les distribs que je connais les utilisateurs sont tous (par défaut) dans un même groupe nommé « users ». -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 5 février 2017, à 08:37, Doug713705 a écrit :
Le 05-02-2017, Jo Engo nous expliquait dans
fr.comp.os.linux.configuration
(<5896d5c0$0$4276$426a74cc@news.free.fr>) :
sudo chown -R user:user /home/user
Ah. John Doe bénéficie o-to-ma-ti-que-ment d'un groupe John Doe ?
Sur la plupart des distributions oui.
C'est idiot, non ? Ça annule la notion même de groupe.
Sur les distribs que je connais les utilisateurs sont tous (par défaut)
dans un même groupe nommé « users ».
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Le 05-02-2017, Jo Engo nous expliquait dans fr.comp.os.linux.configuration (<5896d5c0$0$4276$) :
sudo chown -R user:user /home/user
Ah. John Doe bénéficie o-to-ma-ti-que-ment d'un groupe John Doe ?
Sur la plupart des distributions oui.
C'est idiot, non ? Ça annule la notion même de groupe. Sur les distribs que je connais les utilisateurs sont tous (par défaut) dans un même groupe nommé « users ». -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Nicolas George
Lucas Levrel , dans le message , a écrit :
Sur les distribs que je connais les utilisateurs sont tous (par défaut) dans un même groupe nommé « users ».
C'est idiot, non ? Ça annule la notion même de groupe. :-Þ
Lucas Levrel , dans le message
<alpine.LSU.2.20.13.1702131651290.3798@coulomb.u-pec.fr>, a écrit :
Sur les distribs que je connais les utilisateurs sont tous (par défaut)
dans un même groupe nommé « users ».
C'est idiot, non ? Ça annule la notion même de groupe.
Sur les distribs que je connais les utilisateurs sont tous (par défaut) dans un même groupe nommé « users ».
C'est idiot, non ? Ça annule la notion même de groupe.
Ah non. Ça annule la notion de groupes mais pas de groupe. :-ÞÞ Cordialement Dominique
Lucas Levrel
Le 14 février 2017, à 20:35, Nicolas George a écrit :
Lucas Levrel , dans le message , a écrit :
Sur les distribs que je connais les utilisateurs sont tous (par défaut) dans un même groupe nommé « users ».
C'est idiot, non ? Ça annule la notion même de groupe.
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux d'avoir trois niveaux de permissions u/g/o vu que u=g. On peut concevoir aussi que l'admin veuille donner des droits d'accès spécifiquement aux « humains » et pas aux démons, auquel cas il suffit de régler le groupe sur « users » plutôt que d'ajouter chaque compte aux ACL (et devoir le faire à chaque nouvelle création de compte). -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 14 février 2017, à 20:35, Nicolas George a écrit :
Lucas Levrel , dans le message
<alpine.LSU.2.20.13.1702131651290.3798@coulomb.u-pec.fr>, a écrit :
Sur les distribs que je connais les utilisateurs sont tous (par défaut)
dans un même groupe nommé « users ».
C'est idiot, non ? Ça annule la notion même de groupe.
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux
d'avoir trois niveaux de permissions u/g/o vu que u=g.
On peut concevoir aussi que l'admin veuille donner des droits d'accès
spécifiquement aux « humains » et pas aux démons, auquel cas il suffit de
régler le groupe sur « users » plutôt que d'ajouter chaque compte aux ACL
(et devoir le faire à chaque nouvelle création de compte).
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Le 14 février 2017, à 20:35, Nicolas George a écrit :
Lucas Levrel , dans le message , a écrit :
Sur les distribs que je connais les utilisateurs sont tous (par défaut) dans un même groupe nommé « users ».
C'est idiot, non ? Ça annule la notion même de groupe.
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux d'avoir trois niveaux de permissions u/g/o vu que u=g. On peut concevoir aussi que l'admin veuille donner des droits d'accès spécifiquement aux « humains » et pas aux démons, auquel cas il suffit de régler le groupe sur « users » plutôt que d'ajouter chaque compte aux ACL (et devoir le faire à chaque nouvelle création de compte). -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Nicolas George
Lucas Levrel , dans le message , a écrit :
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux d'avoir trois niveaux de permissions u/g/o vu que u=g.
Si tous les utilisateurs sont dans le même groupe, ça n'a plus de sens pour eux d'avoir trois niveaux de permissions u/g/o vu que g=o.
On peut concevoir aussi que l'admin veuille donner des droits d'accès spécifiquement aux « humains » et pas aux démons, auquel cas il suffit de régler le groupe sur « users » plutôt que d'ajouter chaque compte aux ACL (et devoir le faire à chaque nouvelle création de compte).
On peut concevoir plein de choses. Tellement, en fait, qu'il est oiseux de spéculer. Il faut que l'infrastructure soit là, évidemment, pour pouvoir servir quand il y en a besoin. Mais en pratique la plupart des gens n'en ont pas besoin dans un premier temps, et quand ça arrive c'est tellement du cas-par-cas que ce qu'a fait la distribution par défaut est souvent inadapté. Ce qui n'est pas un problème puisqu'il faut de toutes façons faire le boulot. C'est comme quand tu achètes un cadre en magasin pour mettre une photo : pour mettre le cadre en valeur, dans le magasin on met la photo d'un modèle dedans. Mais une fois que tu l'as acheté et que tu es rentré chez toi, tu jettes la photo du modèle et tu mets la photo que tu voulais encadrer à la place. C'est un peu pareil pour le culte des runlevels à la RedHat.
Lucas Levrel , dans le message
<alpine.LSU.2.20.13.1702151052410.3580@coulomb.u-pec.fr>, a écrit :
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux
d'avoir trois niveaux de permissions u/g/o vu que u=g.
Si tous les utilisateurs sont dans le même groupe, ça n'a plus de sens
pour eux d'avoir trois niveaux de permissions u/g/o vu que g=o.
On peut concevoir aussi que l'admin veuille donner des droits d'accès
spécifiquement aux « humains » et pas aux démons, auquel cas il suffit de
régler le groupe sur « users » plutôt que d'ajouter chaque compte aux ACL
(et devoir le faire à chaque nouvelle création de compte).
On peut concevoir plein de choses. Tellement, en fait, qu'il est oiseux
de spéculer. Il faut que l'infrastructure soit là, évidemment, pour
pouvoir servir quand il y en a besoin. Mais en pratique la plupart des
gens n'en ont pas besoin dans un premier temps, et quand ça arrive c'est
tellement du cas-par-cas que ce qu'a fait la distribution par défaut est
souvent inadapté. Ce qui n'est pas un problème puisqu'il faut de toutes
façons faire le boulot.
C'est comme quand tu achètes un cadre en magasin pour mettre une photo :
pour mettre le cadre en valeur, dans le magasin on met la photo d'un
modèle dedans. Mais une fois que tu l'as acheté et que tu es rentré chez
toi, tu jettes la photo du modèle et tu mets la photo que tu voulais
encadrer à la place.
C'est un peu pareil pour le culte des runlevels à la RedHat.
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux d'avoir trois niveaux de permissions u/g/o vu que u=g.
Si tous les utilisateurs sont dans le même groupe, ça n'a plus de sens pour eux d'avoir trois niveaux de permissions u/g/o vu que g=o.
On peut concevoir aussi que l'admin veuille donner des droits d'accès spécifiquement aux « humains » et pas aux démons, auquel cas il suffit de régler le groupe sur « users » plutôt que d'ajouter chaque compte aux ACL (et devoir le faire à chaque nouvelle création de compte).
On peut concevoir plein de choses. Tellement, en fait, qu'il est oiseux de spéculer. Il faut que l'infrastructure soit là, évidemment, pour pouvoir servir quand il y en a besoin. Mais en pratique la plupart des gens n'en ont pas besoin dans un premier temps, et quand ça arrive c'est tellement du cas-par-cas que ce qu'a fait la distribution par défaut est souvent inadapté. Ce qui n'est pas un problème puisqu'il faut de toutes façons faire le boulot. C'est comme quand tu achètes un cadre en magasin pour mettre une photo : pour mettre le cadre en valeur, dans le magasin on met la photo d'un modèle dedans. Mais une fois que tu l'as acheté et que tu es rentré chez toi, tu jettes la photo du modèle et tu mets la photo que tu voulais encadrer à la place. C'est un peu pareil pour le culte des runlevels à la RedHat.
Lucas Levrel
Le 15 février 2017, à 11:02, Nicolas George a écrit :
Lucas Levrel , dans le message , a écrit :
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux d'avoir trois niveaux de permissions u/g/o vu que u=g.
Si tous les utilisateurs sont dans le même groupe, ça n'a plus de sens pour eux d'avoir trois niveaux de permissions u/g/o vu que g=o.
Il y a tout de même un certain nombre de services qui ne sont pas dans le groupe users.
On peut concevoir plein de choses. Tellement, en fait, qu'il est oiseux de spéculer. Il faut que l'infrastructure soit là, évidemment, pour pouvoir servir quand il y en a besoin. Mais en pratique la plupart des gens n'en ont pas besoin dans un premier temps, et quand ça arrive c'est tellement du cas-par-cas que ce qu'a fait la distribution par défaut est souvent inadapté. Ce qui n'est pas un problème puisqu'il faut de toutes façons faire le boulot.
Ce n'est pas un problème, mais ça donne plus ou moins de boulot suivant l'état de départ ?
C'est un peu pareil pour le culte des runlevels à la RedHat.
De quoi s'agit-il ? (Je parle du culte à la RedHat, pas des runlevels.) -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 15 février 2017, à 11:02, Nicolas George a écrit :
Lucas Levrel , dans le message
<alpine.LSU.2.20.13.1702151052410.3580@coulomb.u-pec.fr>, a écrit :
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux
d'avoir trois niveaux de permissions u/g/o vu que u=g.
Si tous les utilisateurs sont dans le même groupe, ça n'a plus de sens
pour eux d'avoir trois niveaux de permissions u/g/o vu que g=o.
Il y a tout de même un certain nombre de services qui ne sont pas dans le
groupe users.
On peut concevoir plein de choses. Tellement, en fait, qu'il est oiseux
de spéculer. Il faut que l'infrastructure soit là, évidemment, pour
pouvoir servir quand il y en a besoin. Mais en pratique la plupart des
gens n'en ont pas besoin dans un premier temps, et quand ça arrive c'est
tellement du cas-par-cas que ce qu'a fait la distribution par défaut est
souvent inadapté. Ce qui n'est pas un problème puisqu'il faut de toutes
façons faire le boulot.
Ce n'est pas un problème, mais ça donne plus ou moins de boulot suivant
l'état de départ ?
C'est un peu pareil pour le culte des runlevels à la RedHat.
De quoi s'agit-il ? (Je parle du culte à la RedHat, pas des runlevels.)
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Le 15 février 2017, à 11:02, Nicolas George a écrit :
Lucas Levrel , dans le message , a écrit :
Si chaque utilisateur a son propre groupe, ça n'a plus de sens pour eux d'avoir trois niveaux de permissions u/g/o vu que u=g.
Si tous les utilisateurs sont dans le même groupe, ça n'a plus de sens pour eux d'avoir trois niveaux de permissions u/g/o vu que g=o.
Il y a tout de même un certain nombre de services qui ne sont pas dans le groupe users.
On peut concevoir plein de choses. Tellement, en fait, qu'il est oiseux de spéculer. Il faut que l'infrastructure soit là, évidemment, pour pouvoir servir quand il y en a besoin. Mais en pratique la plupart des gens n'en ont pas besoin dans un premier temps, et quand ça arrive c'est tellement du cas-par-cas que ce qu'a fait la distribution par défaut est souvent inadapté. Ce qui n'est pas un problème puisqu'il faut de toutes façons faire le boulot.
Ce n'est pas un problème, mais ça donne plus ou moins de boulot suivant l'état de départ ?
C'est un peu pareil pour le culte des runlevels à la RedHat.
De quoi s'agit-il ? (Je parle du culte à la RedHat, pas des runlevels.) -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
