[Index Informatique] Tout sur l'informatique ? c'est ici...

[ikh]

Pour la longueur du mot de passe, au delà d'une certaine limite, les mots de passe passant par une fonction de hachage (qui donne un résultat d'une longueur fixée), on pourrait imaginer que 2 (ou plus) mots de passe différents de longueur plus grandes que la longueur des hash puissent retomber sur le même résultat en sortie, ce qui pourrait théoriquement poser des problèmes. IBM a d'ailleurs un paramètre pour limiter la longueur maximale d'un mot de passe : https://www.ibm.com/docs/en/i/7.4?topic ... qpwdmaxlen

Un hash SHA-512 dispose (comme son nom l'indique) de 2 ⁵¹² combinaisons uniques et se stocke sur 128 caractères en hexadécimal (une broutille de nos jours). Les possibilités qu'un mot de passe soit utilisé à place d'un autre ayant le même hachage semblent encore moindres que mes chances d'obtenir un dîner en tête à tête avec Emilia Clarke.

Au demeurant, j'en conviens, infinitésimal n'est pas nul (sauf pour mon rencard). Les preuves conceptuelles d'attaques par collisions pour SHA-1 ont précipité sa mort. Quand ça arrivera pour SHA-2, ça va être quelque chose ...

Mais cela reste encore du domaine du théorique, avec des mots de passe qui devraient minimum faire 64 caractères pour à priori retomber sur des collisions.

À cette taille-là, je réclame un SSO pour ne pas taper mon mot de passe à chaque authentification.

[Jiheu]

Gwénaël R. assemble une console de rétrogaming embarquant visiblement une pelletée de copies illégales de jeux vidéo et la vend 280 euros. Une affaire qui fait du bruit jusqu’à en faire fermer le site de vente de ladite console.
Retour sur le bad buzz du week-end et l’hypocrisie de ceux qui crient au loup.

https://www.frandroid.com/produits-andr ... e#comments

[SourisGrognon]

L'idée serait que lorsque j'utilise mon navigateur sous VM2 et que je vais sous http://localhost:xxxx, je puisse arriver sous Jellyfin de VM1.

Sur VM2, http://localhost:xxxx ira sur ... VM2 (sans passer par le réseau). Sauf à mettre un proxy sur VM2.

Chacune des VM devrait avoir une adresse IP exposée (en 192.168. quelque chose en IPv4, je manque encore d'automatismes en IPv6). Depuis VM2, on irait sur http://IP_VM1:xxxx, et VM1 verrait arriver un client depuis IP_VM2; potentiellement routé en interne sur la machine hôte hébergeant les deux VM (l'hôte n'a pas besoin de réseau pour que les deux VM communiquent). Après je fais avec mes vieux souvenirs et je ne suis guère versé dans le SDN (Software Defined Network, pas la Société Des Nations).

À titre personnel, j'aurais fait un ssh -Y IP_VM1 depuis VM2, qui aurait assuré l'affichage des clients X11 de VM1 sur la GUI de VM2. De mémoire, pas possible sans programme tiers avec Wayland qui n'est pas nativement réseau (sans chercher à initier une guerre de religions, je fais avec les outils que je maîtrise).

Je te remercie *enfin* de ton retour : j'étais très occupé ces derniers temps y compris à essayer ta proposition.
Finalement, je n'y suis pas arrivé.

Et quelques tests effectués entre "Ubuntu Server" et Lubuntu montre un avantage pour Lubuntu avec desktop de fonctionnement (moins gourmant en ram, cpu,...)


Aujourd'hui, j'ai un nouveau problème qui nécessite ton/votre aide :

Cela concerne une VM sous Lubuntu 24.04 (distro Ubuntu).


La structure de la VM est la suivante :

• sda1 /boot/efi
• sda2 /
• sda3 /var/lib
• sdb swap
• sdc /var

En fait, je souhaiterais que sda2 et sda3 ne fassent qu'une seule partition : comme il s'agit d'une VM, j'essaie d'harmoniser les espaces de stockages en séparant les dossiers volatives de ceux qui durent un plus longtemps (même si je sais que /var n'est pas vraiment volatile).
Apparement, il faut éviter les SymLink sur les points de montage en /var.

Quelqu'un aurait-il une idée ?
Par ailleurs, puis-je réaliser ce nouveau partionnement à l'installation du système ou uniquement lorsqu'il est installé ?

J'essaie avec la fonction mount -o bind mais j'avoue ne pas bien comprendre.

[ikh]

Aujourd'hui, j'ai un nouveau problème qui nécessite ton/votre aide :

Pas d'outils pour fusionner les partoches ext4 AFAIK. Pas vérifié les autres systèmes de fichiers. Alors on va faire œcuménique et à la truelle.

S'assurer déjà que sda2 et sda3 soient bien contigües (ce qui peut ne pas être le cas, le numéro ne préjugeant en rien des secteurs de début et de fin), sinon, ça va être coton pour les fusionner.



Ensuite, vérifier si l'une des partitions dispose d'assez de place libre pour recevoir toutes les données de l'autre.
Auquel cas, recopier le contenu de la « petite » partition dans le point de montage de la « grande ».
Pas de cp -r ou cp -a ici, ça pourrait recopier le contenu des sous points de montage (/dev, /proc, /sys et autres pour / par exemple).
Utiliser quelque chose du genre:

Code : Tout sélectionner

tar -C / cf - | tar -C /var/lib xf -

ou l'inverse (à tester au préalable dans les deux cas parce que là, je fais a capella).

Penser à éditer /etc/fstab:

• Si sda2 (/) est fusionnée dans sda3 (/var/lib), modifier l'entrée pour la racine (/) vers sda3 pour éviter un message flippant « kernel panic: unable to mount root ».
• Dans tous les cas, supprimer l'entrée de sda3 (/var/lib).

Une fois cela fait, supprimer la partition qui n'a plus lieu d'être et étendre l'autre.
Des outils ++puissants que fdisk (gparted a minima de mémoire) existent pour déplacer le début de sda3 à celui de sda2, on n'a plus à se casser la tête avec un dd dont le buffer n'écrase pas ce qui devra être lu à l'itération suivante (vécu).
Après ça, étendre le système de fichier à la taille de la partition, avec par exemple:

Code : Tout sélectionner

resize2fs /dev/sda2

Si pas assez de place, recopier le contenu en deux fois en passant par une (ou plusieurs) autre(s) partition(s) disponible(s). En pensant à supprimer ce qui aura été temporairement recopié. Toujours avec du tar | tar.



C'est ludique et comme au boulot, je passe plus de temps à rédiger la doc qu'à faire le taf moi-même ... :–/
Si je ne suis pas compréhensable quand je m'élocute, ça me rappellera aussi le boulot. Ou l'érable.

Bonne chance, Jim.

[ikh]

même si je sais que /var n'est pas vraiment volatile

/var/run et /var/lock hautement.
/var/cache et /var/spool moins.
;–)

[Curiouser]

Une réponse complète et de compet' ! Merci pour lui.
Il regardera ça demain à tête reposée, mais il te remercie grandement.

[ikh]

EDIT: correction artéfact image.

[SourisGrognon]

Une réponse complète et de compet' ! Merci pour lui.
Il regardera ça demain à tête reposée, mais il te remercie grandement.

EDIT: correction artéfact image.

Et bien, je vois que l'on s'amuse bien à mes dépends.

Aujourd'hui, j'ai un nouveau problème qui nécessite ton/votre aide :

Pas d'outils pour fusionner les partoches ext4 AFAIK. Pas vérifié les autres systèmes de fichiers. Alors on va faire œcuménique et à la truelle.

S'assurer déjà que sda2 et sda3 soient bien contigües (ce qui peut ne pas être le cas, le numéro ne préjugeant en rien des secteurs de début et de fin), sinon, ça va être coton pour les fusionner.



Ensuite, vérifier si l'une des partitions dispose d'assez de place libre pour recevoir toutes les données de l'autre.
Auquel cas, recopier le contenu de la « petite » partition dans le point de montage de la « grande ».
Pas de cp -r ou cp -a ici, ça pourrait recopier le contenu des sous points de montage (/dev, /proc, /sys et autres pour / par exemple).
Utiliser quelque chose du genre:

Code : Tout sélectionner

tar -C / cf - | tar -C /var/lib xf -

ou l'inverse (à tester au préalable dans les deux cas parce que là, je fais a capella).

Penser à éditer /etc/fstab:

• Si sda2 (/) est fusionnée dans sda3 (/var/lib), modifier l'entrée pour la racine (/) vers sda3 pour éviter un message flippant « kernel panic: unable to mount root ».
• Dans tous les cas, supprimer l'entrée de sda3 (/var/lib).

Une fois cela fait, supprimer la partition qui n'a plus lieu d'être et étendre l'autre.
Des outils ++puissants que fdisk (gparted a minima de mémoire) existent pour déplacer le début de sda3 à celui de sda2, on n'a plus à se casser la tête avec un dd dont le buffer n'écrase pas ce qui devra être lu à l'itération suivante (vécu).
Après ça, étendre le système de fichier à la taille de la partition, avec par exemple:

Code : Tout sélectionner

resize2fs /dev/sda2

Si pas assez de place, recopier le contenu en deux fois en passant par une (ou plusieurs) autre(s) partition(s) disponible(s). En pensant à supprimer ce qui aura été temporairement recopié. Toujours avec du tar | tar.



C'est ludique et comme au boulot, je passe plus de temps à rédiger la doc qu'à faire le taf moi-même ... :–/
Si je ne suis pas compréhensable quand je m'élocute, ça me rappellera aussi le boulot. Ou l'érable.

Bonne chance, Jim.

Bonsoir Ikh,

Encore une question... impossible !

Je fais suite à ta procédure et t'en remercie beaucoup.
J'ai travaillé dessus en début d'après-midi... malheureusement, il semble que ma version de Linux n'aimait pas ton code :

Code : Tout sélectionner

tar -C / cf - | tar -C /var/lib xf -
tar: Vous devez choisir une option parmi « -Acdtrux », « --delete » ou « --test-label »

Et puis, après j'ai commencé à réfléchir : "tar"... "tar"... Oui, comme les fichiers compressés.
J'ai alors cherché sur la grande toile pour m'aider.
Voici le code que j'ai créé :

Code : Tout sélectionner

sudo mkdir -pv /.var_lib
cd /var/lib
sudo tar -cvf var_lib.tar *
sudo mv /var/lib/var_lib.tar /.var_lib
sudo mv /var/lib /var/lib_bck
cd /.var_lib
sudo tar -xvf var_lib.tar -C /.var_lib
sudo rm /.var_lib/var_lib.tar
echo -e "\n# Mise en place du point de montage de '/.var_lib' pour '/var/lib'#\n/.var_lib /var/lib none bind 0 0" | sudo tee -a /etc/fstab
sudo systemctl daemon-reload
sudo mount -a
sudo rm -dr /var/lib_bck

Il n'est pas encapsulé dans un bash pour le moment. Je le ferai ultérieurement.

Après, je me suis dit : << Pourquoi ne pas plutôt compresser tout le dossier "/var" - sans le "/var/lib" - et envoyer ce fichier compressé vers une autre partition ? >> Et là, c'est l'abordage intellectuel : une horde d'idées est venue pirater mon cerveau...

Voici mon nouveau problème.

• Matériel Hôte : SSD
• Fichier Hôte : 00_SYS.vmdk
• Disque Virtuel : /dev/sda1
• Emplacement virtuel : "/", "/var/lib" uniquement sans le reste de "/var", sans le "/swapfile"

• Matériel Hôte : HDD
• Fichier Hôte : 01_VAR.vmdk
• Disque Virtuel : /dev/sdb1
• Emplacement virtuel : "/var" & "/swapfile"

Cependant, dans mon premier code, la partition sdb1 est montée sur "/var". Donc, pour le moment je suis obligé de créer mon nouveau /swapfile dans le /var.

Code : Tout sélectionner

sudo swapoff -a
sudo fallocate -l 12G /var/swapfile
sudo chmod 600 /var/swapfile
sudo mkswap /var/swapfile 
sudo swapon /var/swapfile
sudo swapon -s

sudo featherpad /etc/fstab

Code : Tout sélectionner

/var/swapfile /swapfile swap swap defaults 0 0

Je ne trouve pas ça très glorieux.
J'ai pensé à une liaison symbolique pour le swapfile... Pas bien non plus.

En fait, j'aurais voulu que le /swapfile soit à la racine de sdb1. Cependant, pour une fois, il semble que le système du Mont Rouge soit plus intéressant pour ce point là... et uniquement ce point là...


C'est alors que je me suis penché sur le cas des partitions swap.

• Matériel Hôte : SSD
• Fichier Hôte : 00_SYS.vmdk
• Disque Virtuel : /dev/sda1
• Emplacement virtuel : "/", "/var/lib" uniquement sans le reste de "/var", sans le "/swapfile"

• Matériel Hôte : HDD
• Fichier Hôte : 01_VAR.vmdk
• Disque Virtuel : /dev/sdb1
• Emplacement virtuel : "/var" & "/swapfile"

• Matériel Hôte : HDD
• Fichier Hôte : 02_swap.vmdk
• Disque Virtuel : /dev/sdc1
• Emplacement virtuel : swap

Ici, le '02_swap.vmdk' serait "persistant" afin qu'il ne soit pas imbriqué dans les snapshots.

Que faire ? Swapfile ou Swap-partition ? Quel est le mieux pour une VM ?
Et si Swapfile, comment la placer à la racine d'un autre disque dur ?

Je suis obligé d'utiliser un important volume SWAP à cause des navigateurs (ici Librewolf) Internet qui rament. Gmail fait "freezer" la VM sans un swap à 8Go minimum.

Il semblerait que mullvad browser me donne de meilleurs résultats.

Enfin, j'ai pensé à une structure LVM... Mais, c'est peut-être le canon pour tuer la mouche... enfin, je veux dire, une grosse architecture juste pour aller sur Internet.

J'ai flingué un SSD en moins de 4 ans à cause du "/var".

J'utilise Deluge pour le T*r*ent. J'envoie ces fichiers sur le "Shared Folder" de VM*are.

Voici le code du /etc/fstab

Code : Tout sélectionner

.host:/                                     /mnt/hgfs         fuse.vmhgfs-fuse   auto,allow_other   0 0

Or, je viens de m'apercevoir que le "Shared Folder" est en fait un disque réseau... donc... "/var/log" (dont ufw.log) est continuellement écrit jusqu'à ce qu'il n'y ait plus d'espace libre sur le disque virtuel.
Depuis, j'envoie mes données t*r*ent entrantes sur une partition virtuelle montée sous /mnt. Et lorsqu'elles sont bouclées, je les envoie vers mon "Shared Folder".

Voilà... Voilà...
Bonne Chance M. Ikh.

[Curiouser]

EDIT: correction artéfact image.

Bien joué.

Et puis, après j'ai commencé à réfléchir : "tar"... "tar"...

Tar... dis ?
Tar...di...grade ?

Un tardigrade dans un Tardis !

[SourisGrognon]

Que faire ? Swapfile ou Swap-partition ? Quel est le mieux pour une VM ?

J'ai osé demander son avis à... TalkAI (ChatGPT).
Voici nos échanges :

Dans un environnement virtuel (machine virtuelle), sous Ubuntu, est-il préférable d'utiliser un /swapfile ou une partition Swap ?

Le choix entre un fichier d'échange (`swapfile`) et une partition d'échange (`swap partition`) sous Ubuntu dépend de divers facteurs, surtout dans un environnement virtuel. Voici quelques considérations pour vous aider à faire le choix :

### Avantages du fichier d'échange (/swapfile) :

1. Flexibilité : Un fichier d'échange peut être facilement redimensionné ou supprimé sans avoir besoin de re-partitionner le disque.
2. Installation Simplifiée : Il est souvent plus simple à mettre en place, particulièrement dans un environnement virtuel où les partitions peuvent être plus difficiles à gérer.
3. Pas besoin de redémarrer : Changer la taille d'un fichier d'échange ne nécessite pas de redémarrer la machine, contrairement à une partition swap.

### Avantages de la partition d'échange :

1. Performance : Dans certains cas, une partition swap peut offrir de meilleures performances, surtout si le système effectue beaucoup d'échanges, car une partition est généralement plus rapide à accéder qu'un fichier situé sur un système de fichiers.
2. Isolation : Une partition dédiée peut être plus efficace pour les systèmes qui ont des exigences strictes concernant l'utilisation de l'échange, car elle est séparée du reste du système et ne sera pas fragmentée par d'autres fichiers.

### Considérations spécifiques à un environnement virtuel :

• Capacité de Disque : Étant donné que les VM ont souvent des allocations de disque limitées, un fichier d'échange peut être plus approprié car il utilise l'espace de manière plus souple.
• Snapshots et Sauvegardes : Si vous utilisez des instantanés (snapshots) de votre machine virtuelle, un fichier d'échange peut être plus simple à gérer que des partitions qui sont souvent incluses dans ces images.

### Conclusion :
Dans la plupart des cas, pour une utilisation générale dans une machine virtuelle sous Ubuntu, un fichier d'échange est souvent recommandé pour sa flexibilité et sa facilité de gestion. Cependant, si vous avez des besoins spécifiques qui nécessitent de meilleures performances ou une séparation stricte, une partition swap pourrait être une meilleure option. Évaluez vos besoins et faites des tests si possible pour déterminer ce qui fonctionne le mieux dans votre environnement.

Conclusion : je vais partir sur une partition swap pour la rapidité d'accès et la simplicité à mettre en oeuvre (plutôt qu'un /swapfile monté sur /mnt)... sauf si l'abydossien pense que je suis fou !

[ikh]

Tar... dis ?
Tar...di...grade ?

Un tardigrade dans un Tardis !

Il est plus grand à l'intérieur ...



Et moi je suis un peu taré. ;–ppp

[ikh]

Code : Tout sélectionner

tar -C / cf - | tar -C /var/lib xf -
tar: Vous devez choisir une option parmi « -Acdtrux », « --delete » ou « --test-label »

J'avais écrit « quelque chose du genre » et « à tester au préalable ».
Parce que j'avais jeté ça de tête sans trop gamberger. Qu'on m'enduise de goudron et qu'on apporte des plumes !
Les commandes (cf - et xf -) doivent être avant l'option de changement de répertoire (-C / ou -C /var/lib).

Code : Tout sélectionner

tar cf - -C / | tar xf - -C /var/lib

Après, je me suis dit : << Pourquoi ne pas plutôt compresser tout le dossier "/var" - sans le "/var/lib" - et envoyer ce fichier compressé vers une autre partition ? >>

C'est là que la ligne tar tar est maline: l'archive est crée depuis un répertoire et extraite dans un autre à la volée. Pas besoin de stockage (et donc pas besoin de perdre du temps et du CPU en compression). Marche aussi avec cpio mais les options sont plus difficiles à retenir (-icdvum de mémoire) et l'installation de cet outil est moins répandue que celle de tar.

Voici mon nouveau problème.

• Matériel Hôte : SSD
• Fichier Hôte : 00_SYS.vmdk
• Disque Virtuel : /dev/sda1
• Emplacement virtuel : "/", "/var/lib" uniquement sans le reste de "/var", sans le "/swapfile"

• Matériel Hôte : HDD
• Fichier Hôte : 01_VAR.vmdk
• Disque Virtuel : /dev/sdb1
• Emplacement virtuel : "/var" & "/swapfile"

Dans l'idée que je m'en fais, les .vmdk devraient être vus en /dev/sda et /dev/sdb tout court.
VMware présente ses fichiers comme des disques à la machine virtuelle, charge à elle de partitionner ensuite.

Que faire ? Swapfile ou Swap-partition ? Quel est le mieux pour une VM ?
Et si Swapfile, comment la placer à la racine d'un autre disque dur ?

Je n'ai jamais fait de fichier swap, toujours des partitions.
Raison simple: le contenu du fichier peut être fragmenté à travers le système de fichiers qui le contient; la partition n'a pas ce problème. Gain de temps (au temps jadis des disques mécaniques, peut être moins depuis l'âge SSD).
Dans le cas ici, avec une couche de virtu, c'est kif kif. Le .vmdk sera forcément fragmenté à un moment donné.

Enfin, j'ai pensé à une structure LVM... Mais, c'est peut-être le canon pour tuer la mouche... enfin, je veux dire, une grosse architecture juste pour aller sur Internet.

LVM, je l'utilise beaucoup sur les serveurs au boulot. C'est pratique d'agréger tous les disques physiques (y compris les vmdk de l'hôte) dans un seul volume groupe pour ensuite redécouper. On peut même réduire une partition pour réaffecter l'espace libéré à une autre à chaud.
Pas de LVM sur mes ordis perso. Je taille une racine, une swap et une données. Avec un lien symbolique de /var/cache/{apt,pacman,xbps} de la racine vers les données (parce que c'est gros ce truc).
Les seuls cas où j'ai eu à retailler les partitions, c'est quand je finissais par récupérer dans le Linux la partition Windows conservée mais jamais utilisée. J'étais jeune et candide, je ne fais désormais plus d'illusion quant au destin des partitions d'origine (système et restauration).

J'ai flingué un SSD en moins de 4 ans à cause du "/var".

C'est moche. :–/ Étant récemment passé au SSD moi aussi, ça devrait bien finir par me tomber sur le coin de la face.
J'ai aussi eu pas mal de soucis de mémoire avec le navigateur quand j'avais 4 Go de RAM. Rien depuis que je suis passé à 16 sur mon nouveau chassis.

Voilà. Pas certain d'être d'une grande aide avec ce message. Au moins le soutien moral.

[SourisGrognon]

Parce que j'avais jeté ça de tête sans trop gamberger. Qu'on m'enduise de goudron et qu'on apporte des plumes !

Bah, faut pas ! Quand même : il y a pire comme erreur. Et puis, cela m'a appris à utiliser tar en mode ligne de commande.

Cela étant, grâce à toi, Curiouser a fait le rapprochement entre tarring et le goudron de pin ... et Monkey Island auquel elle a joué récemment.

C'est là que la ligne tar tar est maline: l'archive est crée depuis un répertoire et extraite dans un autre à la volée. Pas besoin de stockage (et donc pas besoin de perdre du temps et du CPU en compression). Marche aussi avec cpio mais les options sont plus difficiles à retenir (-icdvum de mémoire) et l'installation de cet outil est moins répandue que celle de tar.

Je vais essayer aujourd'hui... Mais j'ai encore une question...

Dans l'idée que je m'en fais, les .vmdk devraient être vus en /dev/sda et /dev/sdb tout court.

Effectivement, il s'agit d'une erreur de ma part. Je te confirme que VM*are n'envoie que des /dev/sd* sans numéro complémentaire... et le numéro complémentaire est le...

Pas certain d'être d'une grande aide avec ce message.

Bien au contraire : comme je disais à Curiouser hier soir, cela me permet d'apprendre des choses, et puis, tu as la connaissance des disques mécaniques, c'est un gage d'expertise !

Je n'ai jamais fait de fichier swap, toujours des partitions.

Je taille une racine, une swap et une données. Avec un lien symbolique de /var/cache/{apt,pacman,xbps} de la racine vers les données (parce que c'est gros ce truc).

Voilà ma question : pourrais-tu me dire la répartition des dossiers que tu fais sur chacune des partitions ?
Je m'en inspirerai pour mes nouvelles VM sur la dernière architecture :

• Matériel Hôte : SSD
• Fichier Hôte : 00_SYS.vmdk
• Disque Virtuel : /dev/sda
• Emplacement virtuel : "/", "/var/lib" uniquement sans le reste de "/var", sans le "/swapfile"

• Matériel Hôte : HDD
• Fichier Hôte : 01_VAR.vmdk
• Disque Virtuel : /dev/sdb
  Emplacement virtuel : "/var"

• Matériel Hôte : HDD
• Fichier Hôte : 02_swap.vmdk
• Disque Virtuel : /dev/sdc
• Emplacement virtuel : partition swap

Ici, le '02_swap.vmdk' serait "persistant" afin qu'il ne soit pas imbriqué dans les snapshots.

Au moins le soutien moral.

NSFW

J'apprends vraiment plein de choses avec toi !
Merci beaucoup.

NSFW

Couvrez ce sein que je ne saurais voir
- Tartuffe, Acte III, Scène 2 -

Désolé pour ça...

[ikh]

Cela étant, grâce à toi, Curiouser a fait le rapprochement entre tarring et le goudron de pin ... et Monkey Island auquel elle a joué récemment.

Moi je connaissais de:

Mais Monkey Island reste une valeur sûre.

Je vais essayer aujourd'hui...

« There is no try { } », c'est une réplique de dev en C.

Gression. ;–ppp
Ah ! La pensée en arborescence (et son difficile équilibrage).

tu as la connaissance des disques mécaniques, c'est un gage d'expertise !

Comme le disaient Georges et Alceste: « le temps ne fait rien à l'affaire ». On peut travailler un sujet depuis des temps immémoriaux et demeurer incompétent dans le domaine. Preuves en sont mes déplorables capacités en relations humaines.
Pour ce qui est de disque et de mécanique:

Voilà ma question : pourrais-tu me dire la répartition des dossiers que tu fais sur chacune des partitions ?
Je m'en inspirerai pour mes nouvelles VM sur la dernière architecture :

Un slash avec tout le système (un peu plus de 8 GiB d'utilisés).
Une swap de la taille de la RAM (pour l'hibernation).
Un /data pour tout le reste, à savoir:

• /data/home/ikh.
• /data/var/cache/pacman.

Tous deux avec des liens symboliques depuis la racine:

Code : Tout sélectionner

/var/cache/pacman -> /data/var/cache/pacman
/home/ikh -> /data/home/ikh

Ça vole pas haut, mais ça respecte le vieux principe KISS.

Ici, le '02_swap.vmdk' serait "persistant" afin qu'il ne soit pas imbriqué dans les snapshots.

Ça, c'est malin.

Désolé pour ça...

Surtout pas, c'est le premier truc auquel j'ai pense en voyant le titre du bloc [spoiler].
Ça m'arrive même de le chanter dans l'open space. Ce qui ne manque jamais de surprendre les collègues n'ayant pas eu le temps de me ... découvrir.

[freeshost]

Salut, la gang,

En allant sur une page d'un site (où un article est écrit), peut-on savoir à quelle date la page a été créée (ou modifiée la dernière fois) ?

Car certains sites ne mentionnent pas la date de rédaction de l'article.

J'utilise Ubuntu et Firefox.