palainp a écrit 12 commentaires

Parfois on ne leur donne pas le droit : https://www.actubis.com/claude-francois-electricite-interdit-tribunal-de-commerce/

Je confirme, j'ai déjà adopté pour moi :)
Je n'ai utilisé que des diapos simples avec surtout du texte et quelques images et il y a sûrement des fonctionnalités pour rattraper le retard vs LaTeX notamment sur la construction de dessins mais ça viendra sans doute un jour.

Il est également préférable de se limiter au type void*.

Tout définir en void* a l'avantage de permettre de traiter une variable entière en flottant ou tableau, et se rapprocher un peu de Perl!

Le site n'indique pas de support Linux malheureusement :( (plus exactement il n'y a que windows 10 et MacOS de cité)

C'est possible d'utiliser le une clé ssh avec l'option IdentityFile (avec ssh-agent ou une clé sans mot de passe et autofs pour rendre le montage transparent, mais la seconde solution est moins sûre car il n'y a qu'avoir possession de la clé privée pour pouvoir accéder au serveur).
Oups, en fait la réponse est bien non pas vraiment, il faut une clé, désolé pour le bruit :)

J'ai un pi1 pour gérer les aspects domotique chez moi. Mais j'ai aussi un pi0 sans WiFi que je n'utilise pas.
Comme la consommation du 1 est faramineuse par rapport au 0, est-ce que tu peux me donner la référence de ton adaptateur pour être sûr d'en acheter un compatible et que je puisse faire un échange entre les deux ?
D'avance merci !

Quelques remarques (mais qui ne vont pas vraiment aller dans le bon sens pour toi je le crains :( ) :
- La version fc25 de dom0 n'est pas un soucis car dom0 n'est pas reliée aux autres VM (c'est comme vault qui ne sert en gros qu'à exécuter keepassxc), les mises à jour ne sont permises qu'avec les dépôt officiels, les hash sont systématiquement vérifiés, il y a le minimum de code qui s'exécute dedans et la copie vers dom0 est plutôt compliquée. Cependant c'est la fc32 qui sera utilisée pour la prochaine version 4.1. Toujours en 4.1, la GUI sera séparée de dom0 (pour limiter le nombre de processus tournant dans dom0) et il y aura peut-être plus de latitude dans le choix de l'interface.
- La mise à jour de keymap dans les AppVM est une issue qui est toujours en cours depuis un moment. Je ne change pas souvent de keymap dans les VM, par contre j'ai actuellement un bug que je n'ai pas pu creuser, quand j'attache un périphérique USB à une VM, celle-ce passe en keymap us au lieu de fr :(
- La copie de fichier était il y a longtemps possible en ligne de commande (qvm-copy vm-name files) mais le fait de passer par une popup pour indiquer le nom de la vm destination est justement une fonctionnalité de sécurité, il n'est plus possible de le faire de manière transparente pour l'utilisateur, on est forcément conscient de l'action qu'on réalise.
- C'est la même idée pour le presse-papier inter VM, le fait de ne pas avoir de tampon commun entre les VM (et de n'avoir que du texte quand on passe par le mécanisme géré par dom0) permet d'éviter de dégrader la sécurité d'une VM en ayant une copie d'item d'une VM moins sécuritaire. La encore ce passage d'une VM à une autre est forcément conscient (mais plus long à réaliser oui). Pour les copies d'écrans c'est encore pire tu vas voir, il faut sauver la copie dans dom0 puis la déplacer dans la VM souhaitée avec {copy,move}-to-vm…
- Là tu ne vas sans doute pas rire (voir supprimer tout le système), j'ai également des soucis de connexion avec un dock USB-C thunderbolt. Pour utiliser le port réseau inclus au dock, comme le dock est usb, je dois transférer le contrôle d'une partie du hub usb à sys-net pour gérer le réseau et je me retrouve avec le noyau qui considère que mon cable est de mauvaise qualité (j'ai pu creuser jusqu'à comprendre qu'en fait c'est un ack qui n'est pas renvoyé correctement). Pour le moment je ne m'en sert donc pas pour le réseau (pour l'affichage multiple ou recharger le portable cela ne pose pas de soucis).

Comme je le disais, c'est une utilisation très différente de mon usage d'un ordinateur quand j'avais encore une distribution classique (la séparation VMs travail et VMs perso est très marquée), et j'ai vraiment eu l'impression de rajeunir de 20 ans :)

Le principal problème que tu vas rencontrer pour tester du BSD/windows/whatever c'est que sans les drivers spéciaux pour utiliser un mode PVH tu seras contraint d'utiliser un mode HVM (matériel virtualisé) ce qui est probablement malheureusement trop lent pour garder une bonne image de Qubes :)

Tu as complètement raison, c'est moi qui me suis trompé de terme, partout où j'ai mis paravirtualisation il faut comprendre virtualisé sans passer par la virtualisation du matériel : https://www.qubes-os.org/doc/glossary/#pvhvm je ne sais pas quel est le terme pour remplacer ?
Toutes mes confuses.

Clairement les performances sont présentes hein et très peu diminuées par l'hyperviseur, mais vraiment (je pense que les gens seraient étonnés de la facilité d'installation si le matériel est supporté, et d'utilisation au quotidien du système :) ). Si tu veux des performances (pour par exemple utiliser tous les coeurs, et toute la ram pour un processus qui fait de gros calculs) ce n'est à mon avis ni QubesOS ni un système à conteneurs qu'il faut utiliser mais un système classique et contrôler l'environnement de la machine (qui y accède, pour faire quoi, etc.).

Ce qu'on peut pointer comme reproche c'est le "besoin" d'avoir 16Go de RAM pour être "à l'aise" avec plusieurs appVMs et plusieurs applications dans chaque (et ainsi bénéficier de l'isolement entre les VM pour séparer les usages applicatifs).
Avec 8Go c'est compliqué d'avoir plusieurs appVMs applicatives mais on garde le principal : le fait d'avoir des VM pour les "fonctions" (de base : sys-net pour servir de frontal avec le réseau local, sys-usb pour accéder aux périphériques, sys-firewall pour filtrer les échanges inter-VM, etc.) et ainsi on a une sécurité pour nos applications liée à l'isolement qui reste intéressante (encore une fois sans perte de performance, juste d'espace mémoire).
Par rapport au conteneurs, le fait de ne pas partager le noyau est justement ce qui fait la sécurité du système.

Enfin mirageOS (un noyau écrit en ocaml cité ici) est sur le point booter correctement dans un mode PVH ce qui ouvre la voie à un firewall utilisant 32Mo de RAM au lieu d'un linux classique montant rapidement dans la consomation mémoire.

Le portable que j'utilise n'a jamais eu d'autre système que Qubes, donc je ne peux pas comparer sur du matériel identique.
Le besoin en mémoire est clairement plus important (mais avec des VM et des unikernels il est possible de réduire l'empreinte mémoire sur certaines fonctions comme le firewall ou le vpn), l'hyperthreading est désactivé, la consommation disque est sûrement un peu plus grosse qu'un seul système car il y en a plusieurs. Je n'ai cependant pas l'impression que mon pc se traîne à cause du système d'exploitation :)

Ce n'est pas à proprement parlé GNU/Linux, mais j'ai retrouvé les sensations de découverte d'il y a 20 ans que tu décris avec QubesOS. C'est depuis 2 ans mon système quotidien.