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...)
FERREC Romain , dans le message <m3ifck$rns$, a écrit :
Dans le WM awesome par defaut on a pas de CTRL-C, il faut faire Ctrl-insert et Shift-insert pour coller
Tu es au courant que ces combinaisons sont largement antérieures à la série Ctrl-X/Ctrl-C/Ctrl-V, j'espère, y compris chez les mastodontes industriels.
FERREC Romain , dans le message <m3ifck$rns$2@dont-email.me>, a écrit :
Dans le WM awesome par defaut on a pas de CTRL-C, il faut faire
Ctrl-insert et Shift-insert pour coller
Tu es au courant que ces combinaisons sont largement antérieures à la série
Ctrl-X/Ctrl-C/Ctrl-V, j'espère, y compris chez les mastodontes industriels.
FERREC Romain , dans le message <m3ifck$rns$, a écrit :
Dans le WM awesome par defaut on a pas de CTRL-C, il faut faire Ctrl-insert et Shift-insert pour coller
Tu es au courant que ces combinaisons sont largement antérieures à la série Ctrl-X/Ctrl-C/Ctrl-V, j'espère, y compris chez les mastodontes industriels.
yamo'
Salut,
Sam17 a écrit le 08/11/2014 10:18 :
On ne peut le faire que pour des partitions qu'on peut demonter, donc pas pour la racine! En meme temps il est assez difficile de le faire pour /var, car il faut tuer tous les deamons qui utilisent cette partition pour pouvoir la demonter!
Au taf,un collègue et moi agrandissons régulièrement à chaud des points de montage. Jamais fait pour la racine. Pour éviter les ennuis je fais un reboot pour avoir immédiatement les éventuels problèmes mais ça se passe toujours bien (sauf pour mes tests préparatoires mais ils étaient faits pour ça). Je n'ai pas mon aide mémoire, je le copierai ici lundi si j'y pense.
J'utilise même des disques non partitionnés (il me semble que ce n'est pas possible pour la racine) afin de les agrandir plus facilement (en virtuel bien sûr!).
-- Stéphane <http://pasdenom.info/fortune/?> L'hypocrisie est un hommage que le vice rend à la vertu. -+- François de La Rochefoucauld (1613-1680), Maximes 218 -+-
Salut,
Sam17 a écrit le 08/11/2014 10:18 :
On ne peut le faire que pour des partitions qu'on peut demonter, donc pas
pour la racine! En meme temps il est assez difficile de le faire pour /var,
car il faut tuer tous les deamons qui utilisent cette partition pour pouvoir
la demonter!
Au taf,un collègue et moi agrandissons régulièrement à chaud des points
de montage. Jamais fait pour la racine. Pour éviter les ennuis je fais
un reboot pour avoir immédiatement les éventuels problèmes mais ça se
passe toujours bien (sauf pour mes tests préparatoires mais ils étaient
faits pour ça). Je n'ai pas mon aide mémoire, je le copierai ici lundi
si j'y pense.
J'utilise même des disques non partitionnés (il me semble que ce n'est
pas possible pour la racine) afin de les agrandir plus facilement (en
virtuel bien sûr!).
--
Stéphane <http://pasdenom.info/fortune/?>
L'hypocrisie est un hommage que le vice rend à la vertu.
-+- François de La Rochefoucauld (1613-1680), Maximes 218 -+-
On ne peut le faire que pour des partitions qu'on peut demonter, donc pas pour la racine! En meme temps il est assez difficile de le faire pour /var, car il faut tuer tous les deamons qui utilisent cette partition pour pouvoir la demonter!
Au taf,un collègue et moi agrandissons régulièrement à chaud des points de montage. Jamais fait pour la racine. Pour éviter les ennuis je fais un reboot pour avoir immédiatement les éventuels problèmes mais ça se passe toujours bien (sauf pour mes tests préparatoires mais ils étaient faits pour ça). Je n'ai pas mon aide mémoire, je le copierai ici lundi si j'y pense.
J'utilise même des disques non partitionnés (il me semble que ce n'est pas possible pour la racine) afin de les agrandir plus facilement (en virtuel bien sûr!).
-- Stéphane <http://pasdenom.info/fortune/?> L'hypocrisie est un hommage que le vice rend à la vertu. -+- François de La Rochefoucauld (1613-1680), Maximes 218 -+-
Nicolas
Sam17 wrote:
Pascal Hambourg wrote:
yamo' a écrit :
Avec lvm et ext4, on peut agrandir des partitions (sauf la racine?) à chaud.
Pourquoi "sauf la racine" ?
On ne peut le faire que pour des partitions qu'on peut demonter, donc pas pour la racine! En meme temps il est assez difficile de le faire pour /var, car il faut tuer tous les deamons qui utilisent cette partition pour pouvoir la demonter!
L'extension de système de fichiers ext3/4 monté fonctionne quel que soit le point de montage, racine ou autre. Exemple ci-dessous, tout étant fait dans le système en question, sans utiliser de LiveCD:
- état de la partition racine (4Go):
Filesystem Size Used Avail Use% Mounted on /dev/mapper/system-root 4.0G 867M 2.9G 24% /
# resize2fs /dev/mapper/system-root resize2fs 1.42.5 (29-Jul-2012) Filesystem at /dev/mapper/system-root is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 Performing an on-line resize of /dev/mapper/system-root to 1310720 (4k) blocks. The filesystem on /dev/mapper/system-root is now 1310720 blocks long.
- état de la partition racine:
Filesystem Size Used Avail Use% Mounted on /dev/mapper/system-root 5.3G 867M 4.2G 18% /
C'est la réduction qui nécessite un démontage préalable.
-- Nicolas
Sam17 <moto@sdesimeur.com> wrote:
Pascal Hambourg wrote:
yamo' a écrit :
Avec lvm et ext4, on peut agrandir des partitions (sauf la racine?) à
chaud.
Pourquoi "sauf la racine" ?
On ne peut le faire que pour des partitions qu'on peut demonter, donc pas
pour la racine! En meme temps il est assez difficile de le faire pour /var,
car il faut tuer tous les deamons qui utilisent cette partition pour pouvoir
la demonter!
L'extension de système de fichiers ext3/4 monté fonctionne quel que soit
le point de montage, racine ou autre. Exemple ci-dessous, tout étant
fait dans le système en question, sans utiliser de LiveCD:
- état de la partition racine (4Go):
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/system-root 4.0G 867M 2.9G 24% /
# resize2fs /dev/mapper/system-root
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mapper/system-root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/mapper/system-root to 1310720 (4k) blocks.
The filesystem on /dev/mapper/system-root is now 1310720 blocks long.
- état de la partition racine:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/system-root 5.3G 867M 4.2G 18% /
C'est la réduction qui nécessite un démontage préalable.
Avec lvm et ext4, on peut agrandir des partitions (sauf la racine?) à chaud.
Pourquoi "sauf la racine" ?
On ne peut le faire que pour des partitions qu'on peut demonter, donc pas pour la racine! En meme temps il est assez difficile de le faire pour /var, car il faut tuer tous les deamons qui utilisent cette partition pour pouvoir la demonter!
L'extension de système de fichiers ext3/4 monté fonctionne quel que soit le point de montage, racine ou autre. Exemple ci-dessous, tout étant fait dans le système en question, sans utiliser de LiveCD:
- état de la partition racine (4Go):
Filesystem Size Used Avail Use% Mounted on /dev/mapper/system-root 4.0G 867M 2.9G 24% /
# resize2fs /dev/mapper/system-root resize2fs 1.42.5 (29-Jul-2012) Filesystem at /dev/mapper/system-root is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 Performing an on-line resize of /dev/mapper/system-root to 1310720 (4k) blocks. The filesystem on /dev/mapper/system-root is now 1310720 blocks long.
- état de la partition racine:
Filesystem Size Used Avail Use% Mounted on /dev/mapper/system-root 5.3G 867M 4.2G 18% /
C'est la réduction qui nécessite un démontage préalable.
-- Nicolas
pehache
Le 07/11/2014 09:21, Doug713705 a écrit :
Description réaliste de la situation sous les distribs Gnu/Linux
J'ai quand même un peu forcé le trait, hein. Sous Linux aussi il ya des guide lines.
Yep... Gnome a ses guidelines, KDE a les siennes, Xfce aussi je suppose, etc... Du coup quand on utilise une appli basée sur Qt dans Gnome ou une appli basée sur Gtk dans KDE, c'est la foire aux guidelines.
Sous Windows ou OS X les utilitaires et applis suivent souvent la même logique provenant des guidelines de MS et Apple (sous OS X les préférences sont toujours dans le menu qui porte le nom de l'appli, et le menu aide s'appelle toujours "Aide"). Oui certes, c'est une quasi-dictature pour les développeurs, ça craint...
A part ça, le simple fait d'avoir les options sous les yeux rend le recours à la doc beaucoup plus rare.
Même quand l'option s'appelle "Ne pas désactiver l'activation automatique" et que le choix est "activer" ou "desactiver" ?
Une mauvaise doc est une mauvaise doc, que ce soit en CLI ou GUI...
Honnêtement, il n'y a pas vraiment de différence entre une GUI et une CLI sur ce genre de point.
Exact
Il y a des outils en CLI dont tu lis une seule la page de man voir l'option --help seule et d'autres disposant d'une page de man de 42 kilomètres dont 98% des options ne te serviront que rarement et dont tu ne te souviendras pas le jour où tu en as besoin rendant la lecture d'une partie de la page de man quasi nécessaire à chaque utilisation (genre ffmpeg).
Pour les GUI le problème est le même. Certaines sont bien faites et 'inuitives' au point qu'aucune lecture de doc n'est nécessaire (rare) et d'autres sont des merdiers sans nom dont la lecture de la doc ne fait qu'embrouiller davantage l'utilisateur (n'est-ce pas MS ?).
On est donc d'accord (mais je n'en doutais pas :-)), entre CLI ou GUI il n'y en a pas une intrinsèquement supérieure à l'autre. Suivant le type d'outil et le contexte, l'une peut être plus adaptée que l'autre.
Si je veux ripper+encoder un DVD je vais utiliser HandBrake en GUI parce que je ne connais aucun outil aussi pratique pour faire ça. Si je veux convertir les 160 épisodes d'une série vers un autre format, je vais utiliser ffmpeg en CLI dans un script parce que c'est de loin la façon la plus efficace.
Rendons donc grâce au trolleur amateur-mais-qui-trolle-mieux-qu'un-pro-parce-qu'il-aime-ça, à savoir NG, d'avoir relancé ce débat inutile pour nous permettre de nous occuper ce week-end.
Mais, pour reprendre l'exemple de ffmpeg, faire une GUI _complète_ pour ffmpeg serait un vrai casse tête. Il est finalement bien plus commode de l'utiliser en ligne de commandes.
Il y a en fait plein d'outils en GUI qui utilisent ffmpeg par derrière. Mais ils ne prétendent en effet pas reproduire TOUTES les options de ffmpeg.
Le 07/11/2014 09:21, Doug713705 a écrit :
Description réaliste de la situation sous les distribs Gnu/Linux
J'ai quand même un peu forcé le trait, hein. Sous Linux aussi il ya des
guide lines.
Yep... Gnome a ses guidelines, KDE a les siennes, Xfce aussi je suppose,
etc... Du coup quand on utilise une appli basée sur Qt dans Gnome ou une
appli basée sur Gtk dans KDE, c'est la foire aux guidelines.
Sous Windows ou OS X les utilitaires et applis suivent souvent la même
logique provenant des guidelines de MS et Apple (sous OS X les
préférences sont toujours dans le menu qui porte le nom de l'appli, et
le menu aide s'appelle toujours "Aide"). Oui certes, c'est une
quasi-dictature pour les développeurs, ça craint...
A part ça, le simple fait d'avoir les options sous les yeux rend le
recours à la doc beaucoup plus rare.
Même quand l'option s'appelle "Ne pas désactiver l'activation
automatique" et que le choix est "activer" ou "desactiver" ?
Une mauvaise doc est une mauvaise doc, que ce soit en CLI ou GUI...
Honnêtement, il n'y a pas vraiment de différence entre une GUI et une
CLI sur ce genre de point.
Exact
Il y a des outils en CLI dont tu lis une seule la page de man voir
l'option --help seule et d'autres disposant d'une page de man de 42
kilomètres dont 98% des options ne te serviront que rarement et dont tu
ne te souviendras pas le jour où tu en as besoin rendant la
lecture d'une partie de la page de man quasi nécessaire à chaque
utilisation (genre ffmpeg).
Pour les GUI le problème est le même. Certaines sont bien faites et
'inuitives' au point qu'aucune lecture de doc n'est nécessaire (rare) et
d'autres sont des merdiers sans nom dont la lecture de la doc ne fait
qu'embrouiller davantage l'utilisateur (n'est-ce pas MS ?).
On est donc d'accord (mais je n'en doutais pas :-)), entre CLI ou GUI il
n'y en a pas une intrinsèquement supérieure à l'autre. Suivant le type
d'outil et le contexte, l'une peut être plus adaptée que l'autre.
Si je veux ripper+encoder un DVD je vais utiliser HandBrake en GUI parce
que je ne connais aucun outil aussi pratique pour faire ça. Si je veux
convertir les 160 épisodes d'une série vers un autre format, je vais
utiliser ffmpeg en CLI dans un script parce que c'est de loin la façon
la plus efficace.
Rendons donc grâce au trolleur
amateur-mais-qui-trolle-mieux-qu'un-pro-parce-qu'il-aime-ça, à savoir
NG, d'avoir relancé ce débat inutile pour nous permettre de nous occuper
ce week-end.
Mais, pour reprendre l'exemple de ffmpeg, faire une GUI _complète_ pour
ffmpeg serait un vrai casse tête. Il est finalement bien plus commode de
l'utiliser en ligne de commandes.
Il y a en fait plein d'outils en GUI qui utilisent ffmpeg par derrière.
Mais ils ne prétendent en effet pas reproduire TOUTES les options de ffmpeg.
Description réaliste de la situation sous les distribs Gnu/Linux
J'ai quand même un peu forcé le trait, hein. Sous Linux aussi il ya des guide lines.
Yep... Gnome a ses guidelines, KDE a les siennes, Xfce aussi je suppose, etc... Du coup quand on utilise une appli basée sur Qt dans Gnome ou une appli basée sur Gtk dans KDE, c'est la foire aux guidelines.
Sous Windows ou OS X les utilitaires et applis suivent souvent la même logique provenant des guidelines de MS et Apple (sous OS X les préférences sont toujours dans le menu qui porte le nom de l'appli, et le menu aide s'appelle toujours "Aide"). Oui certes, c'est une quasi-dictature pour les développeurs, ça craint...
A part ça, le simple fait d'avoir les options sous les yeux rend le recours à la doc beaucoup plus rare.
Même quand l'option s'appelle "Ne pas désactiver l'activation automatique" et que le choix est "activer" ou "desactiver" ?
Une mauvaise doc est une mauvaise doc, que ce soit en CLI ou GUI...
Honnêtement, il n'y a pas vraiment de différence entre une GUI et une CLI sur ce genre de point.
Exact
Il y a des outils en CLI dont tu lis une seule la page de man voir l'option --help seule et d'autres disposant d'une page de man de 42 kilomètres dont 98% des options ne te serviront que rarement et dont tu ne te souviendras pas le jour où tu en as besoin rendant la lecture d'une partie de la page de man quasi nécessaire à chaque utilisation (genre ffmpeg).
Pour les GUI le problème est le même. Certaines sont bien faites et 'inuitives' au point qu'aucune lecture de doc n'est nécessaire (rare) et d'autres sont des merdiers sans nom dont la lecture de la doc ne fait qu'embrouiller davantage l'utilisateur (n'est-ce pas MS ?).
On est donc d'accord (mais je n'en doutais pas :-)), entre CLI ou GUI il n'y en a pas une intrinsèquement supérieure à l'autre. Suivant le type d'outil et le contexte, l'une peut être plus adaptée que l'autre.
Si je veux ripper+encoder un DVD je vais utiliser HandBrake en GUI parce que je ne connais aucun outil aussi pratique pour faire ça. Si je veux convertir les 160 épisodes d'une série vers un autre format, je vais utiliser ffmpeg en CLI dans un script parce que c'est de loin la façon la plus efficace.
Rendons donc grâce au trolleur amateur-mais-qui-trolle-mieux-qu'un-pro-parce-qu'il-aime-ça, à savoir NG, d'avoir relancé ce débat inutile pour nous permettre de nous occuper ce week-end.
Mais, pour reprendre l'exemple de ffmpeg, faire une GUI _complète_ pour ffmpeg serait un vrai casse tête. Il est finalement bien plus commode de l'utiliser en ligne de commandes.
Il y a en fait plein d'outils en GUI qui utilisent ffmpeg par derrière. Mais ils ne prétendent en effet pas reproduire TOUTES les options de ffmpeg.
pehache
Le 07/11/2014 12:18, Doug713705 a écrit :
Le 07-11-2014, Jean Bambois nous expliquait dans fr.comp.os.linux.debats () :
J'ai quand même un peu forcé le trait, hein. Sous Linux aussi il ya des guide lines.
Oui c'est sûr. Un coup on fait CTL+C CTL+V pour copier/coller, et ailleurs on fait SHIFT+CTL+C (V). Très logique. Certainement un impératif de compatibilité avec un logiciel aussi mythique que préhistorique.
Je n'ai _jamais_ eu besoin de faire autre chose que ctrl+c/ctrl+v pour faire un copier/coller.
Dans quelle application en as tu eu besoin ?
La plus part du temps, un surlignage de la zone à copier et un clic milieu dans la zone à coller et ça roule (et à ma connaissance ni Windows ni mac le permettent).
Sous OS X on peut le faire dans le Terminal. Mais ce n'est pas un comportement standard dans le reste de l'OS et des applis.
Le 07/11/2014 12:18, Doug713705 a écrit :
Le 07-11-2014, Jean Bambois nous expliquait dans
fr.comp.os.linux.debats
(<mn.3a6c7deb39f540b4.115094@tres.nvalid>) :
J'ai quand même un peu forcé le trait, hein. Sous Linux aussi il ya des
guide lines.
Oui c'est sûr. Un coup on fait CTL+C CTL+V pour copier/coller, et
ailleurs on fait SHIFT+CTL+C (V).
Très logique. Certainement un impératif de compatibilité avec un
logiciel aussi mythique que préhistorique.
Je n'ai _jamais_ eu besoin de faire autre chose que ctrl+c/ctrl+v pour
faire un copier/coller.
Dans quelle application en as tu eu besoin ?
La plus part du temps, un surlignage de la zone à copier et un clic
milieu dans la zone à coller et ça roule (et à ma connaissance ni
Windows ni mac le permettent).
Sous OS X on peut le faire dans le Terminal. Mais ce n'est pas un
comportement standard dans le reste de l'OS et des applis.
Le 07-11-2014, Jean Bambois nous expliquait dans fr.comp.os.linux.debats () :
J'ai quand même un peu forcé le trait, hein. Sous Linux aussi il ya des guide lines.
Oui c'est sûr. Un coup on fait CTL+C CTL+V pour copier/coller, et ailleurs on fait SHIFT+CTL+C (V). Très logique. Certainement un impératif de compatibilité avec un logiciel aussi mythique que préhistorique.
Je n'ai _jamais_ eu besoin de faire autre chose que ctrl+c/ctrl+v pour faire un copier/coller.
Dans quelle application en as tu eu besoin ?
La plus part du temps, un surlignage de la zone à copier et un clic milieu dans la zone à coller et ça roule (et à ma connaissance ni Windows ni mac le permettent).
Sous OS X on peut le faire dans le Terminal. Mais ce n'est pas un comportement standard dans le reste de l'OS et des applis.
pehache
Le 07/11/2014 14:49, Doug713705 a écrit :
Le 07-11-2014, Kevin Denis nous expliquait dans fr.comp.os.linux.debats () :
Je n'ai _jamais_ eu besoin de faire autre chose que ctrl+c/ctrl+v pour faire un copier/coller.
Dans quelle application en as tu eu besoin ?
Si je ne m'abuse, le nouveau Terminal de XFCE ne prend plus le CTRL-C CTRL-V.
Dans un terminal et xfce4-terminal (que j'utilise également), j'utilise le clic milieu.
Le clic du milieu ce n'est pas toujours la panacée pour le copié-collé.
Le 07/11/2014 14:49, Doug713705 a écrit :
Le 07-11-2014, Kevin Denis nous expliquait dans
fr.comp.os.linux.debats
(<slrnm5ppr8.bs4.kevin@slackwall.local.tux>) :
Je n'ai _jamais_ eu besoin de faire autre chose que ctrl+c/ctrl+v pour
faire un copier/coller.
Dans quelle application en as tu eu besoin ?
Si je ne m'abuse, le nouveau Terminal de XFCE ne prend plus le CTRL-C
CTRL-V.
Dans un terminal et xfce4-terminal (que j'utilise également), j'utilise
le clic milieu.
Le clic du milieu ce n'est pas toujours la panacée pour le copié-collé.
Le 07-11-2014, Kevin Denis nous expliquait dans fr.comp.os.linux.debats () :
Je n'ai _jamais_ eu besoin de faire autre chose que ctrl+c/ctrl+v pour faire un copier/coller.
Dans quelle application en as tu eu besoin ?
Si je ne m'abuse, le nouveau Terminal de XFCE ne prend plus le CTRL-C CTRL-V.
Dans un terminal et xfce4-terminal (que j'utilise également), j'utilise le clic milieu.
Le clic du milieu ce n'est pas toujours la panacée pour le copié-collé.
pehache
Le 06/11/2014 15:51, 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 ! :-)
:-)))
Le 06/11/2014 15:51, 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 ! :-)
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 ! :-)
:-)))
Michel
Le 08/11/2014 16:14, pehache a écrit :
Le 07/11/2014 14:49, Doug713705 a écrit :
Le 07-11-2014, Kevin Denis nous expliquait dans fr.comp.os.linux.debats () :
Je n'ai _jamais_ eu besoin de faire autre chose que ctrl+c/ctrl+v pour faire un copier/coller.
Dans quelle application en as tu eu besoin ?
Si je ne m'abuse, le nouveau Terminal de XFCE ne prend plus le CTRL-C CTRL-V.
Dans un terminal et xfce4-terminal (que j'utilise également), j'utilise le clic milieu.
Le clic du milieu ce n'est pas toujours la panacée pour le copié-collé.
Ah, et la panacée, pour le copier collé, c'est quoi selon toi?
Michel
Le 08/11/2014 16:14, pehache a écrit :
Le 07/11/2014 14:49, Doug713705 a écrit :
Le 07-11-2014, Kevin Denis nous expliquait dans
fr.comp.os.linux.debats
(<slrnm5ppr8.bs4.kevin@slackwall.local.tux>) :
Je n'ai _jamais_ eu besoin de faire autre chose que ctrl+c/ctrl+v pour
faire un copier/coller.
Dans quelle application en as tu eu besoin ?
Si je ne m'abuse, le nouveau Terminal de XFCE ne prend plus le CTRL-C
CTRL-V.
Dans un terminal et xfce4-terminal (que j'utilise également), j'utilise
le clic milieu.
Le clic du milieu ce n'est pas toujours la panacée pour le copié-collé.
Ah, et la panacée, pour le copier collé, c'est quoi selon toi?
Le clic du milieu ce n'est pas toujours la panacée pour le copié-collé.
Ah, et la panacée, pour le copier collé, c'est quoi selon toi?
Je n'ai pas dit qu'il en existait une.
Briancon
Le 07/11/2014 21:11, Lucas Levrel a écrit :
Le 6 novembre 2014, Briancon a écrit :
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.
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 ?
Oui, le 3.1.
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...).
Le problème c'est que tu veux garder les .tex normalement ! Le tmpfs est en RAM, bye bye à l'extinction.
Ben oui l'idée est la suivantes: - je tape mon texte je compile je corrige je recompile etc... Quand je suis content du résultat: je sauve sur le disque dur.
Bon un jour j'oublierai la dernière phase c'est sur...
A moins de faire un script qui sauve à l'extinction. Un peu compliqué...C'est sans doute une monter une usine à gaz pour pas grand chose.
Ok. Cela dit l'hibernation est sans doute plus utile pour un portable que pour un pc de bureau.
Oui, surtout qu'avec un SSD ça va démarrer au huitième de tour !
Oui. Pour le moment ça démarre TRES vite (ça se compte en secondes...).
Le 07/11/2014 21:11, Lucas Levrel a écrit :
Le 6 novembre 2014, Briancon a écrit :
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.
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 ?
Oui, le 3.1.
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...).
Le problème c'est que tu veux garder les .tex normalement ! Le tmpfs est
en RAM, bye bye à l'extinction.
Ben oui l'idée est la suivantes:
- je tape mon texte je compile je corrige je recompile etc...
Quand je suis content du résultat: je sauve sur le disque dur.
Bon un jour j'oublierai la dernière phase c'est sur...
A moins de faire un script qui sauve à l'extinction.
Un peu compliqué...C'est sans doute une monter une usine à gaz
pour pas grand chose.
Ok. Cela dit l'hibernation est sans doute plus utile pour un portable
que pour un pc de bureau.
Oui, surtout qu'avec un SSD ça va démarrer au huitième de tour !
Oui. Pour le moment ça démarre TRES vite (ça se compte en secondes...).
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 ?
Oui, le 3.1.
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...).
Le problème c'est que tu veux garder les .tex normalement ! Le tmpfs est en RAM, bye bye à l'extinction.
Ben oui l'idée est la suivantes: - je tape mon texte je compile je corrige je recompile etc... Quand je suis content du résultat: je sauve sur le disque dur.
Bon un jour j'oublierai la dernière phase c'est sur...
A moins de faire un script qui sauve à l'extinction. Un peu compliqué...C'est sans doute une monter une usine à gaz pour pas grand chose.
Ok. Cela dit l'hibernation est sans doute plus utile pour un portable que pour un pc de bureau.
Oui, surtout qu'avec un SSD ça va démarrer au huitième de tour !
Oui. Pour le moment ça démarre TRES vite (ça se compte en secondes...).
