wismerhill a écrit 2608 commentaires

Je ne l'utilise pas personnellement, mais il me semble que borg fait ce que tu demande (sauvegarde distante et chiffrée dans une archive, donc pas de chemin identifiable) https://borgbackup.readthedocs.io/en/stable/

Deux exemples de supports pour ordinateur portable:
https://www.ergotron.com/en-us/products/product-details/33-334
https://www.fellowes.com/us/en/products/product-details.aspx?prod=US-8024601

On en trouve de toutes sortes (plus ou moins encombrantes/pratique), ça suppose généralement d'avoir un clavier/souris externes en complément.

Pourtant, il est également possible d'avoir des bureaux virtuels sous windows.
Il semble que c'est en natif avec windows 10, voir par exemple https://www.howtogeek.com/197625/how-to-use-virtual-desktops-in-windows-10/
Avant, c'était déjà possible en installant un programme spécial (je le faisait déjà avec windows 98, il y a plus de 20 ans).

En shell, tidy pour refaire du XML propre à partir d'un HTML quelconque, et ensuite xmlstarlet pour en extraire les liens.
(bien entendu, ça ne fonctionne qu'avec du HTML statique, pas pour des pages générées par javascript)

Par contre en standard, depuis java9 tu as la modularisation du jdk avec jlink tu peux créer un jdk sans les parties qui ne t'intéressent pas et c'est une étape que tu ne fais qu'une fois et si d'aventure tu change les module du jdk dont tu as besoin, mais ça ne devrait pas arriver tous les 4 matins.

Ça ce n'est intéressant que pour les développeurs qui veulent fournir un binaire prêt à l'emploi, sans devoir demander d'installer un JDK complet (car il n'y a plus de JRE), c'est un peu comme compiler en statique, ou fournir une image pour une technologie de conteneur quelconque.
Ce n'est pas destiné aux distributions, où on veut au contraire que tous les programmes java utilisent le même JDK installé globalement, et ne surtout pas devoir recompiler chaque programme si on met à jour ce JDK.

Même les documents qui ont des réflecteurs a temps pleins peuvent avoir des fautes.

Relecteurs ;-)

Aaahhh

Last-Modified: Mon, 29 Sep 2003 08:34:25 GMT

regarder le source de la page à un effet rafraichissant 😊

Oui, parce que là l'index sur date_time peut être utilisé, c'est à peu près équivalent au between (je ne sais plus s'il correspond à des <= >= ou à des < >) que je recommandais plus haut.
Tu devrais le voir dans un explain.

Ce n'est pas étonnant que le query plan soit très différent quand on fait un changement de version majeure, surtout sur une requête qui n'était pas du tout optimisée (4s, c'était déjà horriblement lent pour une requête qui ne devrait ressortir que peu de résultats).

Forcément, si tu transforme la valeur de la colonne, l'index ne sera pas utilisé, c'est pour ça que j'indiquais d'utiliser between.

https://use-the-index-luke.com/

S'il n'y a pas d'index, ce sera forcément lent.

Ensuite, il ne faut pas utiliser des expressions rationnelles pour comparer des dates, même s'il y avait un index sur la colonne date_time, il ne serait pas utilisé parce que tu lui demande de convertir le timestamp en chaine de caractère.
Il y a des fonctions pour extraire une partie d'une date, ou convertir un timestamp en date.
Mais pour profiter d'un éventuel index, le mieux est d'utiliser l'opérateur between (ou équivalent).

En SQL natif, tu fais ce que tu veux.
Ce n'est pas supporté en DQL de base, mais c'est relativement facile d'ajouter une fonction DQL sur mesure pour ça.

Je le trouve plutôt léger à l'usage, mais c'est vrai que je suis en bureau plasma.
Si tu préfère GTK, il y a gcstar dans le même genre.

Essaie tellico, c'est un gestionnaire de collections.
Il y a des types de collections pré-définis (livres, vins, jeux, …) auxquels on peut ajouter des champs personnalisés, vori vaire son type sur mesure.
On peut ensuite faire des recherches, ou des tris, sur base des différent champs.

De fait, c'est pour ça que la remarque que je pointe se trouve dans la section compatibility, c'est une déviation par rapport au standard SQL.
Ils indiquent que les contraintes déférées ont un impact sur les performances, je suppose que c'est pour ça qu'elles ne le sont pas par défaut.

Je dois dire qu'en une dizaine d'années à travailler avec PG, il ne m'est arrivé qu'une fois d'avoir l'usage pour des contraintes déférées (c'était une contrainte d'unicité).

C'est documenté, et il y a un contournement:
https://www.postgresql.org/docs/current/sql-createtable.html#id-1.9.3.85.9.4

Son problème d'origine est qu'il n'avait pas partitionné sdb, donc il n'y avait pas de partition d'origine et il ne pouvait pas en créer une nouvelle.

Sauf que …

Comme sont système de fichier est ext4, d'après https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Layout les 1024 premiers octets sont inutilisé.
Donc il aurait été également possible de créer une table de partition de type MBR (qui est placée dans les premiers 512 octets), pour ensuite créer une vrai partition au-delà de la zone où se trouve encore le FS, puis à coup de dd copier le FS dans la partition ainsi créée.
Ça évite de jouer avec losetup, mais c'est tout aussi tordu puisqu'on se retrouve avec un sdb "hybride" partitionné/non-partitionné.

Aurait-il été possible de faire la même opération sans table de partition ?

Il y a moyen, mais c'est tordu risqué.

pvcreate a une option --setphysicalvolumesize qui permet de forcer la taille utilisée.
On veut qu'il soit au début du volume, donc il faut décaler ton système de fichier à la fin.
Ça peut se faire à coup de dd (il y a peut-être des outils pour faire ça mieux/plus simplement), c'est la partie la plus risqué de l'opération.
Tu crée alors ton volume physique dans l'espace libéré, puis les goupes et volumes logiques normalement.
Après, tu as deux options.
Soit tu recopie ton FS qui traine encore à a fin de sdb dans un fichier, puis tu étends (avec pvresize) ton volume physique pour récupérer l'espace, et tu monte le fichier en loopback our recopier les fichiers (si tu n'a pas fait d'erreur avant).
Ou alors tu utilise losetup avec l'option --offset pour accéder directement à la fin de sdb en loopback, tu recopie les fichiers, et ensuite tu récupère l'espace avec pvresize.

Par contre, je ne comprend pas pourquoi tu te complique la vie à essayer de copier le système de fichier brut, ce sont les fichiers qui sont dedans qui sont importants, et ils prendront forcément moins de place que le FS complet.

Si c'est du bash, alors tu peux éviter la sous-commande:

for i in {1..3} ;do …

Non, ce n'est pas une récursion, ça s'apparente plutôt à une machine virtuelle (le programme s'exécute dans une machine virtuelle, qui est elle-même simulée par un programme qui s'exécute sur la machine réelle (ou elle-même virtuelle, pour continuer à imbriquer)).

En mode semi-graphique (ncurse dans le terminal), il y a ncdu qui est bien pratique.

(oups, déjà cité, j'aurais du lire jusqu'au bout avant de répondre)

Je ne vois pas ce que le firmware vient faire là-dedans, lire le système de fichier c'est le problème de l'OS que tu installe sur ta machine. Le firmware, au mieux (si c'est de l'UEFI), il cherchera une partition d'un type bien particulier et essaiera de la lire, donc il n'y a que celle-là qui doit bien correspondre au type défini. Et sinon (en mode MBR) il ne se soucie même pas des partitions.

Le type que l'on peut mettre au niveau de la table de partitions n'est qu'une indication (comme un plaque que tu accroche à ta porte d'entrée), elle ne contraint pas ce qu'on peut effectivement mettre dans la partition.

Rien ne t'empêche de définir une partition de type fat, puis de faire un mke2fs dessus.
Certains OS ne comprendront pas ce qui leur arrive si le système de fichiers ne correspond pas au type défini dans la table de partitions, mais un OS correct permettra au minimum de forcer le type de FS au montage, ou l'auto-détectera sur base du contenu réel de la partition.

Ça veut dire que si tu veux utiliser un nouveau type de système de fichier (par exemple btrfs), tu peux le mettre dans une partition au format MBR avec un type quelconque, du moment que tu fais le nécessaire pour qu'elle soit montée correctement.

Pourquoi les crevures et les mec qui n'ont pas un minimum de formation deviennent directeur ou responsable de service ?

Principe_de_Dilbert

Si ton objectif est seulement de pouvoir ré-utiliser l'espace, c'est plus simple de re-créer un groupe de volumes propre plutôt que d'essayer d'en réparer un qui est corrompu.

Si tu veux essayer de récupérer des données dont tu n'a pa de sauvegarde, il ne faut surtout pas modifier le VG actuel.
Utilise lvdisplay -m pour voir s'il y a des volumes encore complets.
Si oui, tu les monte en lecture seule et copie les donnes importantes ailleurs.
S'il y en a des partiels, ce n'est probablement pas la peine d'essayer de les monter, même en lecture seule. Tu peux tenter un photorec dessus, mais s'il manque beaucoup de blocs ça risque de ne pas donner grand chose d'utile.

Ça dépend de la façon dont tu avait organisé tes volumes logiques dans le groupe de volume qui contenait tes trois disques dur.
Les volumes qui sont entièrement sur les deux disques encore fonctionnels sont probablement récupérable, peut-être en forcer LVM à créer le groupe en mode dégradé.
Mais si certains des blocs d'un volume se trouvaient sur le disque mort, ce sera difficile d'y retrouver des choses cohérentes.