Je vais recevoir un nouveau PC avec
- 8 go
- Un SSD de 120 Go
- Un disque dur de 1To.
Je vais installer uniquement une distribution linux dessus et d'autres
systèmes via virtualbox (pour tester et apprendre...).
Quels conseils pour partitionner les disques:
- Quelle taille pour le swap?
Dans un premier temps je pensais mettre tout
simplement:
/ sur le ssd
/home sur le DD.
Mais je pense que que 120 Go pour le / c'est
surdimensionné (même si je vais sans doute avoir envie de
d'essayer différents environnements graphiques).
Je me dit aussi qu'il est peux être intéressants d'avoir les disques
pour mes machines virtuels (au moins certains) sur le SSD ainsi que
certains fichiers de configurations sur le SSD (tout cela pour des
questions de rapidités).
Je pense donc maintenant faire:
- un swap
- / sur le ssd (30 ou 40 Go suffisent pour être assez large non?). A
ce stade il y a un intérêt à avoir d'autres partitions (pour /usr par ex)?
- /home sur une autre partition du SSD
- Une (ou deux partitions ou plus?) du genre /home/login/datas
(ou /datas?) sur le DD pour le reste du /home (en particulier
les gros fichiers (musique,photos,films...) et des sauvegardes de la
partie /home du ssd...
Je fait pas mal de latex donc je pense qu'il est intéressant d'avoir
mes fichiers .tex sur les deux disques (c'est pas les fichiers
tex qui prennent de la place). Prudence (deux dd sont morts récemment...)
lvm n'est pas très user-friendly (tout en ligne de commande)
Ton affirmation est contradictoire.
Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible pour les allergiques à la ligne de commande.
Sauf au moment de la création de la machine (Debian, CentOS et surement d'autres distributions), je ne connais pas d'outil graphique pour gérer lvm.
-- Stéphane
Lucas Levrel
Le 5 novembre 2014, JD a écrit :
Cependant, le principe du SSD étant qu'il "s'use" au fur et à mesure des cycles d'écriture, il me semble tout à fait déconseillé d'y mettre un swap dont le rôle est précisément d'être lu-réécrit à tout bout de champ. Ceci dit, il me semble qu'avec 8 Go de RAM, tu peux te passer de swap.
Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de champ ;-) On peut en revanche vouloir monter /tmp en mémoire.
Un swap au moins aussi gros que la RAM est nécessaire si l'on veut hiberner.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
Le 5 novembre 2014, JD a écrit :
Cependant, le principe du SSD étant qu'il "s'use" au fur et à mesure des
cycles d'écriture, il me semble tout à fait déconseillé d'y mettre un swap
dont le rôle est précisément d'être lu-réécrit à tout bout de champ.
Ceci dit, il me semble qu'avec 8 Go de RAM, tu peux te passer de swap.
Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de
champ ;-) On peut en revanche vouloir monter /tmp en mémoire.
Un swap au moins aussi gros que la RAM est nécessaire si l'on veut
hiberner.
Cependant, le principe du SSD étant qu'il "s'use" au fur et à mesure des cycles d'écriture, il me semble tout à fait déconseillé d'y mettre un swap dont le rôle est précisément d'être lu-réécrit à tout bout de champ. Ceci dit, il me semble qu'avec 8 Go de RAM, tu peux te passer de swap.
Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de champ ;-) On peut en revanche vouloir monter /tmp en mémoire.
Un swap au moins aussi gros que la RAM est nécessaire si l'on veut hiberner.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
Rambo
yamo' wrote, On 06/11/2014 15:33:
Salut,
Le 06/11/2014 10:51, Nicolas George a écrit :
yamo' , dans le message <m3fehs$m8d$, a écrit :
lvm n'est pas très user-friendly (tout en ligne de commande)
Ton affirmation est contradictoire.
Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible pour les allergiques à la ligne de commande.
Sauf au moment de la création de la machine (Debian, CentOS et surement d'autres distributions), je ne connais pas d'outil graphique pour gérer lvm.
Gloire à la ligne de commande. - Supprimons tous ces écrans et ces boutons pour piloter un avion. - Mettons lui un écran et un clavier pour qu'il puisse le piloter en ligne de commande et sans souris ! :-)
yamo' wrote, On 06/11/2014 15:33:
Salut,
Le 06/11/2014 10:51, Nicolas George a écrit :
yamo' , dans le message <m3fehs$m8d$1@usenet.pasdenom.info>, a écrit :
lvm n'est pas très user-friendly (tout en ligne de commande)
Ton affirmation est contradictoire.
Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible
pour les allergiques à la ligne de commande.
Sauf au moment de la création de la machine (Debian, CentOS et
surement d'autres distributions), je ne connais pas d'outil graphique
pour gérer lvm.
Gloire à la ligne de commande.
- Supprimons tous ces écrans et ces boutons pour piloter un avion.
- Mettons lui un écran et un clavier pour qu'il puisse le piloter en
ligne de commande et sans souris ! :-)
lvm n'est pas très user-friendly (tout en ligne de commande)
Ton affirmation est contradictoire.
Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible pour les allergiques à la ligne de commande.
Sauf au moment de la création de la machine (Debian, CentOS et surement d'autres distributions), je ne connais pas d'outil graphique pour gérer lvm.
Gloire à la ligne de commande. - Supprimons tous ces écrans et ces boutons pour piloter un avion. - Mettons lui un écran et un clavier pour qu'il puisse le piloter en ligne de commande et sans souris ! :-)
ptilou
Chalut,
Le jeudi 6 novembre 2014 15:51:58 UTC+1, Rambo a écrit :
yamo' wrote, On 06/11/2014 15:33: > Salut, > > Le 06/11/2014 10:51, Nicolas George a écrit : >> yamo' , dans le message <m3fehs$m8d$, a écrit : >>> lvm n'est pas très user-friendly (tout en ligne de commande) >> >> Ton affirmation est contradictoire. > > Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible > pour les allergiques à la ligne de commande. > > Sauf au moment de la création de la machine (Debian, CentOS et > surement d'autres distributions), je ne connais pas d'outil graphique > pour gérer lvm. > Gloire à la ligne de commande. - Supprimons tous ces écrans et ces boutons pour piloter un avion. - Mettons lui un écran et un clavier pour qu'il puisse le piloter en ligne de commande et sans souris ! :-)
La ligne de commande est fonctionelle sous ms depuis la création de DOS, minix aussi de memoire ...
Ptilou
Chalut,
Le jeudi 6 novembre 2014 15:51:58 UTC+1, Rambo a écrit :
yamo' wrote, On 06/11/2014 15:33:
> Salut,
>
> Le 06/11/2014 10:51, Nicolas George a écrit :
>> yamo' , dans le message <m3fehs$m8d$1@usenet.pasdenom.info>, a écrit :
>>> lvm n'est pas très user-friendly (tout en ligne de commande)
>>
>> Ton affirmation est contradictoire.
>
> Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible
> pour les allergiques à la ligne de commande.
>
> Sauf au moment de la création de la machine (Debian, CentOS et
> surement d'autres distributions), je ne connais pas d'outil graphique
> pour gérer lvm.
>
Gloire à la ligne de commande.
- Supprimons tous ces écrans et ces boutons pour piloter un avion.
- Mettons lui un écran et un clavier pour qu'il puisse le piloter en
ligne de commande et sans souris ! :-)
La ligne de commande est fonctionelle sous ms depuis la création de DOS, minix aussi de memoire ...
Le jeudi 6 novembre 2014 15:51:58 UTC+1, Rambo a écrit :
yamo' wrote, On 06/11/2014 15:33: > Salut, > > Le 06/11/2014 10:51, Nicolas George a écrit : >> yamo' , dans le message <m3fehs$m8d$, a écrit : >>> lvm n'est pas très user-friendly (tout en ligne de commande) >> >> Ton affirmation est contradictoire. > > Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible > pour les allergiques à la ligne de commande. > > Sauf au moment de la création de la machine (Debian, CentOS et > surement d'autres distributions), je ne connais pas d'outil graphique > pour gérer lvm. > Gloire à la ligne de commande. - Supprimons tous ces écrans et ces boutons pour piloter un avion. - Mettons lui un écran et un clavier pour qu'il puisse le piloter en ligne de commande et sans souris ! :-)
La ligne de commande est fonctionelle sous ms depuis la création de DOS, minix aussi de memoire ...
Ptilou
Briancon
Le 06/11/2014 15:43, Lucas Levrel a écrit :
Le 5 novembre 2014, JD a écrit :
Cependant, le principe du SSD étant qu'il "s'use" au fur et à mesure des cycles d'écriture, il me semble tout à fait déconseillé d'y mettre un swap dont le rôle est précisément d'être lu-réécrit à tout bout de champ. Ceci dit, il me semble qu'avec 8 Go de RAM, tu peux te passer de swap.
Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de champ ;-) On peut en revanche vouloir monter /tmp en mémoire.
Bonne idée mais comment fait-on pour monter un répertoire en mémoire? J'ai bon en regardant par exemple
http://doc.ubuntu-fr.org/tmpfs ?
Cela peut être intéressant aussi si on travaille sur de petits fichiers qu'on passe son temps à modifier? Typiquement avec latex où les fichier .tex, .aux, .dvi etc... qui tous ensembles ne prennent pas beaucoup de place (sauf à écrire une encyclopédie en 25 volumes...).
Un swap au moins aussi gros que la RAM est nécessaire si l'on veut hiberner.
Ok. Cela dit l'hibernation est sans doute plus utile pour un portable que pour un pc de bureau.
Le 06/11/2014 15:43, Lucas Levrel a écrit :
Le 5 novembre 2014, JD a écrit :
Cependant, le principe du SSD étant qu'il "s'use" au fur et à mesure
des cycles d'écriture, il me semble tout à fait déconseillé d'y mettre
un swap dont le rôle est précisément d'être lu-réécrit à tout bout de
champ.
Ceci dit, il me semble qu'avec 8 Go de RAM, tu peux te passer de swap.
Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de
champ ;-) On peut en revanche vouloir monter /tmp en mémoire.
Bonne idée mais comment fait-on pour monter un répertoire en mémoire?
J'ai bon en regardant par exemple
http://doc.ubuntu-fr.org/tmpfs ?
Cela peut être intéressant aussi si on travaille sur de petits
fichiers qu'on passe son temps à modifier?
Typiquement avec latex où les fichier .tex, .aux, .dvi etc... qui tous
ensembles ne prennent pas beaucoup de place (sauf à écrire une
encyclopédie en 25 volumes...).
Un swap au moins aussi gros que la RAM est nécessaire si l'on veut
hiberner.
Ok. Cela dit l'hibernation est sans doute plus utile pour un portable
que pour un pc de bureau.
Cependant, le principe du SSD étant qu'il "s'use" au fur et à mesure des cycles d'écriture, il me semble tout à fait déconseillé d'y mettre un swap dont le rôle est précisément d'être lu-réécrit à tout bout de champ. Ceci dit, il me semble qu'avec 8 Go de RAM, tu peux te passer de swap.
Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de champ ;-) On peut en revanche vouloir monter /tmp en mémoire.
Bonne idée mais comment fait-on pour monter un répertoire en mémoire? J'ai bon en regardant par exemple
http://doc.ubuntu-fr.org/tmpfs ?
Cela peut être intéressant aussi si on travaille sur de petits fichiers qu'on passe son temps à modifier? Typiquement avec latex où les fichier .tex, .aux, .dvi etc... qui tous ensembles ne prennent pas beaucoup de place (sauf à écrire une encyclopédie en 25 volumes...).
Un swap au moins aussi gros que la RAM est nécessaire si l'on veut hiberner.
Ok. Cela dit l'hibernation est sans doute plus utile pour un portable que pour un pc de bureau.
Yliur
Le Thu, 06 Nov 2014 18:11:21 +0100 Briancon a écrit :
Le 06/11/2014 15:43, Lucas Levrel a écrit : > Le 5 novembre 2014, JD a écrit : > >> Cependant, le principe du SSD étant qu'il "s'use" au fur et à >> mesure des cycles d'écriture, il me semble tout à fait déconseillé >> d'y mettre un swap dont le rôle est précisément d'être lu-réécrit >> à tout bout de champ. >> Ceci dit, il me semble qu'avec 8 Go de RAM, tu peux te passer de >> swap. > > Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de > champ ;-) On peut en revanche vouloir monter /tmp en mémoire. > Bonne idée mais comment fait-on pour monter un répertoire en mémoire? J'ai bon en regardant par exemple
http://doc.ubuntu-fr.org/tmpfs ?
Cela peut être intéressant aussi si on travaille sur de petits fichiers qu'on passe son temps à modifier? Typiquement avec latex où les fichier .tex, .aux, .dvi etc... qui tous ensembles ne prennent pas beaucoup de place (sauf à écrire une encyclopédie en 25 volumes...).
À moins que tu ne les modifie vraiment en permanence et que chaque modification entraîne une série de modifications d'un tas de fichiers (si tu recompiles un logiciel complètement très souvent par exemple), ton disque devrait tenir un certain temps. Du moins s'il n'est pas en grande partie rempli de fichiers qui ne changent pas de place parce qu'ils ne sont jamais réécrits, afin qu'il y ait plein de place disponible pour répartir les écritures.
Peux-tu estimer combien d'écritures tu fais par jour par exemple ? Avec un multiplicateur du fait que des "cases" (je ne me souviens plus du terme) sont écrites sur le disque. Même si tu écris des fichiers source et que tu considères un multiplicateur de 10 (par exemple à chaque fois que tu écris un fichier de 10ko ça fait une écriture de 100ko, ou du moins ça occupe et donc abîme une case de 100ko, d'autres confirmeront la taille), il va te falloir un certain temps pour remplir plusieurs Go de données. Et a plus forte raison pour faire 100.000 réécritures dessus.
Le Thu, 06 Nov 2014 18:11:21 +0100
Briancon <briancon_tanguy@NOSPAMyahoo.fr> a écrit :
Le 06/11/2014 15:43, Lucas Levrel a écrit :
> Le 5 novembre 2014, JD a écrit :
>
>> Cependant, le principe du SSD étant qu'il "s'use" au fur et à
>> mesure des cycles d'écriture, il me semble tout à fait déconseillé
>> d'y mettre un swap dont le rôle est précisément d'être lu-réécrit
>> à tout bout de champ.
>> Ceci dit, il me semble qu'avec 8 Go de RAM, tu peux te passer de
>> swap.
>
> Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de
> champ ;-) On peut en revanche vouloir monter /tmp en mémoire.
>
Bonne idée mais comment fait-on pour monter un répertoire en mémoire?
J'ai bon en regardant par exemple
http://doc.ubuntu-fr.org/tmpfs ?
Cela peut être intéressant aussi si on travaille sur de petits
fichiers qu'on passe son temps à modifier?
Typiquement avec latex où les fichier .tex, .aux, .dvi etc... qui
tous ensembles ne prennent pas beaucoup de place (sauf à écrire une
encyclopédie en 25 volumes...).
À moins que tu ne les modifie vraiment en permanence et que chaque
modification entraîne une série de modifications d'un tas de fichiers
(si tu recompiles un logiciel complètement très souvent par exemple),
ton disque devrait tenir un certain temps. Du moins s'il n'est pas
en grande partie rempli de fichiers qui ne changent pas de place parce
qu'ils ne sont jamais réécrits, afin qu'il y ait plein de place
disponible pour répartir les écritures.
Peux-tu estimer combien d'écritures tu fais par jour par exemple ? Avec
un multiplicateur du fait que des "cases" (je ne me souviens plus du
terme) sont écrites sur le disque. Même si tu écris des fichiers source
et que tu considères un multiplicateur de 10 (par exemple à chaque fois
que tu écris un fichier de 10ko ça fait une écriture de 100ko, ou du
moins ça occupe et donc abîme une case de 100ko, d'autres confirmeront
la taille), il va te falloir un certain temps pour remplir plusieurs
Go de données. Et a plus forte raison pour faire 100.000 réécritures
dessus.
Le Thu, 06 Nov 2014 18:11:21 +0100 Briancon a écrit :
Le 06/11/2014 15:43, Lucas Levrel a écrit : > Le 5 novembre 2014, JD a écrit : > >> Cependant, le principe du SSD étant qu'il "s'use" au fur et à >> mesure des cycles d'écriture, il me semble tout à fait déconseillé >> d'y mettre un swap dont le rôle est précisément d'être lu-réécrit >> à tout bout de champ. >> Ceci dit, il me semble qu'avec 8 Go de RAM, tu peux te passer de >> swap. > > Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de > champ ;-) On peut en revanche vouloir monter /tmp en mémoire. > Bonne idée mais comment fait-on pour monter un répertoire en mémoire? J'ai bon en regardant par exemple
http://doc.ubuntu-fr.org/tmpfs ?
Cela peut être intéressant aussi si on travaille sur de petits fichiers qu'on passe son temps à modifier? Typiquement avec latex où les fichier .tex, .aux, .dvi etc... qui tous ensembles ne prennent pas beaucoup de place (sauf à écrire une encyclopédie en 25 volumes...).
À moins que tu ne les modifie vraiment en permanence et que chaque modification entraîne une série de modifications d'un tas de fichiers (si tu recompiles un logiciel complètement très souvent par exemple), ton disque devrait tenir un certain temps. Du moins s'il n'est pas en grande partie rempli de fichiers qui ne changent pas de place parce qu'ils ne sont jamais réécrits, afin qu'il y ait plein de place disponible pour répartir les écritures.
Peux-tu estimer combien d'écritures tu fais par jour par exemple ? Avec un multiplicateur du fait que des "cases" (je ne me souviens plus du terme) sont écrites sur le disque. Même si tu écris des fichiers source et que tu considères un multiplicateur de 10 (par exemple à chaque fois que tu écris un fichier de 10ko ça fait une écriture de 100ko, ou du moins ça occupe et donc abîme une case de 100ko, d'autres confirmeront la taille), il va te falloir un certain temps pour remplir plusieurs Go de données. Et a plus forte raison pour faire 100.000 réécritures dessus.
Yliur
Le Thu, 06 Nov 2014 18:11:21 +0100 Briancon a écrit :
comment fait-on pour monter un répertoire en mémoire? J'ai bon en regardant par exemple
http://doc.ubuntu-fr.org/tmpfs ?
Sinon chez moi (Archlinux) je pense que /tmp est déjà monté en mémoire, si je comprends bien le résultat suivant.
$ mount | grep /tmp
tmpfs on /tmp type tmpfs (rw)
C'est peut-être aussi le cas dans ta distribution...
Le Thu, 06 Nov 2014 18:11:21 +0100
Briancon <briancon_tanguy@NOSPAMyahoo.fr> a écrit :
comment fait-on pour monter un répertoire en mémoire?
J'ai bon en regardant par exemple
http://doc.ubuntu-fr.org/tmpfs ?
Sinon chez moi (Archlinux) je pense que /tmp est déjà monté en
mémoire, si je comprends bien le résultat suivant.
$ mount | grep /tmp
tmpfs on /tmp type tmpfs (rw)
C'est peut-être aussi le cas dans ta distribution...
Le Thu, 06 Nov 2014 18:11:21 +0100 Briancon a écrit :
comment fait-on pour monter un répertoire en mémoire? J'ai bon en regardant par exemple
http://doc.ubuntu-fr.org/tmpfs ?
Sinon chez moi (Archlinux) je pense que /tmp est déjà monté en mémoire, si je comprends bien le résultat suivant.
$ mount | grep /tmp
tmpfs on /tmp type tmpfs (rw)
C'est peut-être aussi le cas dans ta distribution...
Nicolas George
yamo' , dans le message <m3g0sh$e95$, a écrit :
lvm n'est pas très user-friendly (tout en ligne de commande)
Ton affirmation est contradictoire.
Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible pour les allergiques à la ligne de commande.
Ils feraient mieux de soigner leur allergie.
Sauf au moment de la création de la machine (Debian, CentOS et surement d'autres distributions), je ne connais pas d'outil graphique pour gérer lvm.
Ça ne le rend pas non user-friendly pour autant. C'est le contraire qui rend un outil non user-friendly : quand il n'y a que des clickodromes pour le contrôler.
yamo' , dans le message <m3g0sh$e95$1@usenet.pasdenom.info>, a écrit :
lvm n'est pas très user-friendly (tout en ligne de commande)
Ton affirmation est contradictoire.
Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible pour
les allergiques à la ligne de commande.
Ils feraient mieux de soigner leur allergie.
Sauf au moment de la création de la machine (Debian, CentOS et surement
d'autres distributions), je ne connais pas d'outil graphique pour gérer lvm.
Ça ne le rend pas non user-friendly pour autant. C'est le contraire qui rend
un outil non user-friendly : quand il n'y a que des clickodromes pour le
contrôler.
lvm n'est pas très user-friendly (tout en ligne de commande)
Ton affirmation est contradictoire.
Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible pour les allergiques à la ligne de commande.
Ils feraient mieux de soigner leur allergie.
Sauf au moment de la création de la machine (Debian, CentOS et surement d'autres distributions), je ne connais pas d'outil graphique pour gérer lvm.
Ça ne le rend pas non user-friendly pour autant. C'est le contraire qui rend un outil non user-friendly : quand il n'y a que des clickodromes pour le contrôler.
JD
Le 06/11/2014 15:43, Lucas Levrel a écrit :
Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de champ ;-) On peut en revanche vouloir monter /tmp en mémoire.
J'avais moi-même prévu cette phrase mot pour mot mais je l'ai effacée, n'étant pas sûr de ne pas dire une connerie (comme précicé, je suis photographe à la retraite, pas informaticien.) Ma remarque ne relevait que d'un certain supposé bon sens
Le 06/11/2014 15:43, Lucas Levrel a écrit :
Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de
champ ;-) On peut en revanche vouloir monter /tmp en mémoire.
J'avais moi-même prévu cette phrase mot pour mot mais je l'ai effacée,
n'étant pas sûr de ne pas dire une connerie (comme précicé, je suis
photographe à la retraite, pas informaticien.) Ma remarque ne relevait
que d'un certain supposé bon sens
Et donc, même s'il en met un, il ne sera pas lu-écrit à tout bout de champ ;-) On peut en revanche vouloir monter /tmp en mémoire.
J'avais moi-même prévu cette phrase mot pour mot mais je l'ai effacée, n'étant pas sûr de ne pas dire une connerie (comme précicé, je suis photographe à la retraite, pas informaticien.) Ma remarque ne relevait que d'un certain supposé bon sens
Rambo
Nicolas George wrote, On 06/11/2014 19:50:
yamo' , dans le message <m3g0sh$e95$, a écrit :
lvm n'est pas très user-friendly (tout en ligne de commande)
Ton affirmation est contradictoire.
Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible pour les allergiques à la ligne de commande.
Ils feraient mieux de soigner leur allergie.
Sauf au moment de la création de la machine (Debian, CentOS et surement d'autres distributions), je ne connais pas d'outil graphique pour gérer lvm.
Ça ne le rend pas non user-friendly pour autant. C'est le contraire qui rend un outil non user-friendly : quand il n'y a que des clickodromes pour le contrôler.
Au moins avec le clickodrome on peut faire ses choix d'options dans devoir aller et venir dans le "man <nom-de-la-commande>"
Nicolas George wrote, On 06/11/2014 19:50:
yamo' , dans le message <m3g0sh$e95$1@usenet.pasdenom.info>, a écrit :
lvm n'est pas très user-friendly (tout en ligne de commande)
Ton affirmation est contradictoire.
Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible pour
les allergiques à la ligne de commande.
Ils feraient mieux de soigner leur allergie.
Sauf au moment de la création de la machine (Debian, CentOS et surement
d'autres distributions), je ne connais pas d'outil graphique pour gérer lvm.
Ça ne le rend pas non user-friendly pour autant. C'est le contraire qui rend
un outil non user-friendly : quand il n'y a que des clickodromes pour le
contrôler.
Au moins avec le clickodrome on peut faire ses choix d'options dans
devoir aller et venir dans le "man <nom-de-la-commande>"
lvm n'est pas très user-friendly (tout en ligne de commande)
Ton affirmation est contradictoire.
Le jour ou un outil comme gparted gèrera lvm, ce sera plus accessible pour les allergiques à la ligne de commande.
Ils feraient mieux de soigner leur allergie.
Sauf au moment de la création de la machine (Debian, CentOS et surement d'autres distributions), je ne connais pas d'outil graphique pour gérer lvm.
Ça ne le rend pas non user-friendly pour autant. C'est le contraire qui rend un outil non user-friendly : quand il n'y a que des clickodromes pour le contrôler.
Au moins avec le clickodrome on peut faire ses choix d'options dans devoir aller et venir dans le "man <nom-de-la-commande>"
