J’aurai tendance à voir les choses ainsi :

• /tmp :
  • Lorsque les fichiers n’ont pas besoin de persister au-delà d’une session ou d’un redémarrage.
  • Pour des opérations temporaires rapides qui nécessitent des performances élevées.
  • Pour des fichiers de petite taille, afin de ne pas saturer la RAM.
• /var/tmp :
  • Pour des fichiers temporaires qui doivent persister au-delà des redémarrages.
  • Lorsque l’espace de /tmp monté en RAM n’est pas suffisant pour vos besoins.
  • Pour des opérations qui ne nécessitent pas les performances élevées offertes par le stockage en RAM.

Merci ! Je complète ! L’avantage est qu’il n’y a rien à installer

Avec LVM, tu peux en effet redimensionner les volumes logiques plus facilement que s’il s’agissait d’une partition, car sur le disque, il n’est pas utilisé de la même façon. C’est un des avantage de LVM par rapport à un schéma de partitionnement classique. Dans le cas du tutoriel que tu rédiges, tu ne fais qu’une seule partition. Cette partition est divisée en “subvolumes” BTRFS. Avec des sous-volumes, l’espace est mutualisé et tu ne possèdes au final qu’une seule “partition”. En remplissant de données le sous-volume @home, tu diminues l’espace disponible de @ où se trouve ta racine. Par conséquent, la couche LVM ici est inutile. Je ne suis pas certain que faire sans améliore les performances du système de manière significative, mais cette surcouche ajoute une coomplexité, sans ajouter de fonctionalités en soi, d’autant plus que les “volumes logiques” et “partitions” sont sur un volume chiffré. Par contre, sur un système sans chiffrement, je pense que les bénéfices de BTRFS (par rapport à LVM+BTRFS) est important car BTRFS pourra positionner les données directement comme il l’entend sur le disque à l’emplacement physique adéquat.

C’est mon CMS qui fait clignoter la table des matières, c’est corrigé dans la prochaine version mais je n’ai pas de temps à consacrer à la migration pour le moment (qui échoue). Donc ça reste comme ça pour le moment. La classe est commentée mais le cache reste effectif dans le CMS et dans le serveur web. Ca clignotera plus bientôt, mais je sais pas à quoi ça va ressembler

Je suis d’accord pour les Flatpak, très pratique pour les logiciels propriétaires.

Le fait d’aller vers ce format est je pense la course à la nouvelle technologie. Si une nouvelle version d’un logiciel a besoin d’un Qt plus récent par exemple, il est pris directement via le framework disponible en flatpak et on peut s’affranchir d’une bibliothèque obsolète sur le système source. Je peux comprendre que certains restent sur une Debian stable par exemple tout en voulant des logiciels un poil plus récent qui corrigent parfois des bugs ou ajoutent des fonctionalités intéressantes. Dans le cas d’un LibreOffice sous Debian, il y a en effet les DEB du site tu me diras, mais s’il y a une bibliothèque pas assez récente sur le système, tu es coincé. Je privilégierais un Flatpak sur une base Debian au lieu d’un PPA ou dépôt tiers, qui causera, pour un logiciel, moins de soucis sur le long terme (car rappelons le, on n’installe pas son système toutes les semaines)

Il y a aujourd’hui tellement de petits logiciels qu’il n’est plus possible pour les distributions de tout packager elle-même. Certains logiciels évoluent rapidement et c’est compliqué de les avoir à jour dans les distro (si déjà ils sont présents dans les dépôts car c’est pas forcément le cas).

En tant que développeur d’application, je vois un autre intérêt à Flatpak : je peux packager moi-même mon logiciel d’une manière compatible avec toutes les distributions. À une époque j’avais un PPA pour Ubuntu, des paquets AUR pour ArchLinux, quelques RPM (pas trop dans les règles de l’art) pour Fedora / Mageia, etc. Mais je n’ai plus le temps de m’occuper de tout ça.

Exact il y a plein d’outils, la doc ne manque pas. Pika Backup étant dispo en flatpak, on le retrouve partout sans prise de tête. Son interface simple comme le reste des applis GNOME fait qu’il est facile à prendre en main. C’est pour cela que je le présente sur mon site :)

Oui CF : https://www.journalduhacker.net/s/j7oetp/linux_djing_streaming_twitch_essayons

Linux reconnait parfaitement le matériel, il n’y a aucun souci. Que ce soit Hercules présenté par Benzo ou Pioneer dans mon cas.

Sans parler du streaming, Mixxx souffre de latence lorsqu’on utilise un contrôleur (donc logiciel indispensable) qui ne permet clairement pas de mixer dans des conditions optimales. Mais on en revient toujours au même concernant les conclusions : Le problème n’est pas la reconnaissance du matériel sous Linux, mais belle et bien l’offre logicielle. Avec Pioneer, les mappings ne sont pas tous reconnus et fonctionnels. Il en était de même avec Hercules (j’avais testé le Universal DJ que j’ai toujours dans un carton à la maison)

Rekordbox, et Serato ne sont pas dispo sous Linux pour Pionneer, il en est de même pour DJuced pour Hercules.

Merci pour le retour !

L’article était pour répondre à un besoin particulier. Mais en effet je préfère largement Anydesk qui est fonctionnel correctement et disponible directement en flatpak. D’ailleurs j’ai mis la petite phrase dans l’intro “A noter que je préfère personnellement Anydesk qui est disponible directement en Flatpak.”

Je me suis peut être mal exprimé. Quand je dis ça pour un même VG. rootvg = 1 disque datavg = 1 disque

Si tu as rootvg avec 1 disque de 50Go. Tu veux agrandir à 100Go le tout, j’agrandit le VMDK de 50 à 100 puis pvresize. Je n’ajoute pas un deuxième disque de 50Go et je vgextend mon rootvg

Oui et dans le cas où on utilise ce système parce que les applis qui tournent dessus ne sont pas encore migrées et qu’on a besoin d’outils à installer, ça peut toujours être utile. Après dans le monde entreprise il y a plein de cas où des systèmes obsolètes tournent encore, le cloisonnement réseau via VLAN, parefeu, ou WAF dans le cas d’un applicatif rendent moins vulnérables des systèmes qui peut être complexes à migrer (soit techniquement, soit logiciellement, soit au niveau des moyens humains)

Ahhh, bonne question. J’ai toujours le réflexe de créer une partition dédiée, quelque soit le FS ! ;)

Comme l’article était déjà assez long, j’ai décidé de garder la mise en pratique pour un second article.

Pour répondre à ta question, dans le cas de Ubuntu, il crée automatiquement des volumes @ et @home. Et s’ils sont déjà présents dans la partition, il va les remplacer (et donc en effacer le contenu). Il faudra donc renommer le sous-volume @home (avec la commande mv ou via un navigateur de fichier) avant de procéder à la réinstallation.

Dans le cas de Fedora, l’installateur à une meilleur intégration de Btrfs et on peut créer et sélectionner des sous volumes pour le système, les données, etc. Donc à priori pas de problème (note : j’ai juste testé l’installation de Fedora avec Btrfs, pas sa réinstallation contrairement à Ubuntu)

Pour ce qui est du cas du home partagé entre 2 distributions Linux. À part faire attention à ne pas écraser le sous volume @home, je ne pense pas que ça pose de problème. Il suffira de crée un volume @distrib1 et un autre @distrib2 pour chacun des 2 systèmes. Ça sera plus ou moins simple à faire suivant comment Btrfs est pris en charges par les installateurs des deux distribs.

Certaines personnes n’ont pas le choix ;) (du genre au travail)

C’est sûr que les personnes qui s’intéressent un minimum au respect de leur vie privée n’utiliseront pas Chrome. Et il existe d’autres navigateurs comme Ungoogled Chromium ou Brave qui sont plus respectueux dans ce cas-là.

Il faut que les constructeurs contribuent, mais c’est le cas pour DELL, LENOVO et HP. A noter que GNOME Logiciels sous Fedora intègre nativement le truc et en graphique !