Renault a écrit 7419 commentaires

changer de mode de chauffage ne résout pas le problème si c'est pour mettre toute l'énergie dehors

Oui et non.
Normalement il faut en effet isoler puis changer de mode de chauffage. Mais parfois à cause du coût de l'isolation total du logement et de la vétusté de la production de chauffage, il peut être préférable de le faire avant.

Car en effet si on isole après coup, le moyen de production de chauffage sera surdimensionné et donc moins efficace et plus coûteux à l'usage (sans compter l'installation).

Cependant passer d'un chauffage charbon / mazout à un chauffage gaz / pompe à chaleur / bois sans isolation préalable entraine déjà un gain important vis à vis des gaz à effet de serre. Ou ne serait-ce prendre une chaudière plus efficace sans changer le mode de production. Même si isoler reste nécessaire.

Sans compter que l'isolation à part les coûts de fabrication et d'installation, les coûts récurrents sont très limités.

Personnellement je suis en plein dans la démarche, il faut aussi reconnaître que le coût initial est très important et que c'est assez chronophage (audit, devis, prêts, urbanisme, etc.). Idéalement il faudrait que le politique aide encore plus (et contraigne) pour que cela se fasse plus massivement.

Il y a aussi d'ailleurs comme sujet la cuisson des aliments et la production d'eau chaude (bien que cela soit souvent lié à la production de chauffage pour ce dernier).

Et mortelle, 100% des vivants finissent par en mourir.

Après il est peu probable que ton emprunte environnementale soit suffisamment basse par rapport aux objectifs visés. Donc tu pourrais faire mieux mais pas forcément dans ce qui a été listé. ;)

Par exemple ici le chauffage a été entièrement passé sous silence (alors que c'est un gros sujet à tous les niveaux). Baisser la température de croisière, changer de mode de chauffage, isoler, etc.

J'ai toujours été étonné par le fait que "droit" en Français veut dire à la fois "pas à gauche" et "correct", "juste", et que parallèlement "right" en Anglais apporte les même double sens.

Il ne faut pas oublier qu'à part quelques langues européennes, toutes héritent d'un bagage commun et que par les échanges et la culture elles se sont influencées mutuellement dans le temps.

C'est particulièrement vrai pour l'anglais qui a hérité beaucoup du français (et où les échanges ont été nombreuses aussi), mais cela est valable entre le français et le néerlandais sur certains points aussi, comme l'origine de certains mots ou expressions aussi.

C'est amusant mais pas si surprenant en fait.

Après dans le cas actuel, on n'a pas forcément besoin de vacciner tout le monde (mais une portion significative de celle-ci) et en ciblant bien les premiers vaccinés tu peux déjà faire le gros du boulot.

On peut facilement prioriser les vaccinations selon des critères précis pour maximiser son utilité. D'abord vacciner les personnes fragiles qui risquent d'y succomber et ceux à leur contact (donc personnel soignant en somme).

Ensuite tu peux facilement vacciner les professions ayant un contact important avec d'autres individus : commerçants, politiques, enseignants, etc.

Enfin tu vaccines le reste de la population.

En agissant ainsi tu peux déjà mesurer des effets globaux avant même d'avoir vacciné tout le monde ou même les 70-80% de la population pour atteindre l'immunité de groupe.

Ensuite, vacciner ça va très vite, en une heure tu peux en vacciner du monde. De souvenir dans une école pour une classe de 30 élèves ça prend 20 minutes. Donc un établissement scolaire peut vacciner l'ensemble de ses élèves en une / deux semaines sans trop de problèmes. De même que la médecine du travail peut vacciner une zone industrielle importante dans un délai aussi court.

Sans oublier les hôpitaux qui peuvent vacciner les patients en consultation et hospitalisés, ou les maisons de repos leurs pensionnaires dans des délais là encore raisonnable.

Bref il ne me semble pas aberrant de croire qu'en peu de temps on puisse régler le problème si le vaccin est efficace et en quantité suffisante.

Parce que ça ne fait pas « sérieux » de citer un site d'amateurs qui font du libre, c'est-à-dire des logiciels donnés gratuitement en plus ? Je fais un peu d'ironie, mais on a beau être une source d'actualité, je pense que ça ne fait pas méga-crédible quand même, même si c'est dommage. Pour les tunisiens, disons qu'ils sont peut-être moins apeurés par le côté artisanal ?

Dans un document type thèse ou mémoire de master, une des étapes est toujours de citer l'état actuel des connaissances sur un sujet. De rappeler l'état de l'art en somme.

Donc citer des sites d'actualité d'un domaine quelconque est un moyen de le faire qui n'est pas aberrant.

Je vois dans ma boule de cristal que bientôt toutes les applications seront écrites avec un langage comme Go, Rust ou Cristal qui permettent de créer un gros binaire avec toutes les bibliothèques liées statiquement.

De plus en plus oui, mais totalement j'ai de gros doutes.

Si nous sommes bien dans cette ligne temporelle, est-ce qu'il ne faudrait pas faire sauter la ring "stack" ? Ou en tout cas ne pas trop investir de temps dessus.

Oui et non.

Pour l'utilisateur d'une application tu as raison et techniquement Flatpak comme Toolbox s'en chargent déjà.

Le problème est pour les développeurs. Quand tu développes ton logiciel avec Python tu as besoin d'un accès à crrtains composants et potentiellement en plusieurs versions. Tu gères ça comment ? Il te faut quelque chose qui gère la couche Stack pour ça, ici Toolbox.

L'installation d'un paquet avec rpm-ostree nécessite absolument un reboot pour pouvoir utiliser l'application.

Oui et c'est expliqué pourquoi. ;)

L'installation des premiers paquets via flatpak fait un peu peur (900Mo pour installer une petite application). Je n'ai pas cette impression avec snap.

Comme expliqué dans l'article suivant sur la mise en pratique de Silverblue, en fait pour une première application d'un écosystème type GNOME ou KDE, la première fois tu vas télécharger le runtime qui contient les bibliothèques communes avec les autres applications. Du coup pour la 2e application, le poids sera proche de la normale.

Snap n'a pas ce comportement par conception mais c'est un inconvénient dans le cas d'un système qui a beaucoup d'applications installées ainsi.

Contrairement à Qubes, je ne pense pas que l'on puisse avoir une image qui servent de template. Donc si l'on lance plusieurs toolbox, ils utilisent la même image de base, mais je dois faire les mises à jour dans chaque toolbox.

En effet mais je crois avoir vu des idées pour résoudre ce problème via le système hôte. À voir. :)

Est-il possible d'installer un rpm à la main avec rpm-ostree ? Que ce passe-t'il si je fais un rpm -i ?

Je ne sais pas, mais je dirais que cela devrait être possible via les overlays de rpm-ostree. Essaye et raconte !

Est-ce une bonne idée d'installer snap en plus de flatpak sur SilverBlue ?

Il n'y a pas de contre indication même si cela n'a pas été prévu pour. Il faudra probablement l'installer à la base du système avec rpm-ostree au préalable.

Je ne sais pas. :)

Je dirais tester, relever les problèmes et contribuer pour les résoudre. Donc savoir développer / empaqueter c'est nécessaire pour faire avancer le sujet.

Rejoins la liste de diffusion liée à Silverblue.

En théorie c'est possible si tu ajoutes le bureau KDE à minima comme overlay via rpm-ostree.

Mais je n'ai pas testé, je ne vois pas de raisons pour laquelle cela ne fonctionnerait pas. Après idéalement ce serait pris en charge via les Spins quand Silverblue sera suffisamment mature.

C'est précisé que /etc et /var sont en lecture écriture. Donc tu peux changer ta configuration système évidemment.

Enfin, c'est précisé dans l'article précédent parlant de Silverblue dont je recommande la lecture au préalable. Peut être que cela devrait être précisé en début d'article au cas où.

Si je comprends bien il y a trois grammaires à apprendre pour installer ou mettre à jour le système : rpm-ostree, Fedora Toolbox, Flatpak.

Oui. Du moins en théorie.
Pour un usage bureautique pur, il te suffit de savoir manipuler un outil comme GNOME Logiciels qui gère tout ça pour toi. Car Fedora toolbox ne sert pas dans ce contexte et rpm-ostree ne serait que pour des mise à jour.

rpm-ostree, il faut bien comprendre que le but de cette partie du système est d'être vraiment minimal. Une fois que ton système est installé, à part les MaJ et problèmes particuliers, tu ne devrais pas y toucher. Donc à la limite sa maitrise n'est pas requise. Toolbox ou Flatpak par contre un peu plus oui.

Bon, c'est peut être pas plus simple à l'arrivée du coup ?

Qui a dit que cela devait être plus simple ? :)
Je dirais que tout dépend du profil d'utilisateur et de son but, dans certains cas je vois un apport important de Silverblue, parfois non.

Par exemple prenons le cas d'un utilisateur lambda, ni développeur, ni utilisateur avancé. Par exemple un travailleur de bureau qui n'est pas informaticien.

Il installe des paquets avec Flatpak, mets à jour le système quand on lui demande. Il accepte ou refuse des permissions et basta. Il profite de la flexibilité des Flatpak.

Pour le système de base, il s'en fout, il ne le gère pas. Par contre ce système est plus robuste donc moins probable qu'il y ait besoin d'une maintenance. Et s'il faut remettre à 0 le système pour X ou Y raisons, c'est assez facile à faire (genre donner la machine à un autre collègue ou lors d'une revente). Avec une distro classique c'est bien plus chiant comme opération.

Est-ce que finalement il n'aurait pas été plus simple de faire prendre en charge les applis non graphiques par Flatpak ?!

Pas sûr, disons que peut être qu'il y aurait moyen mais je vois un argument pour ne pas le faire du moins pour l'instant. Mais comme je ne connais pas la raison, elle est peut être fausse.

Un Flatpak est isolé, et son intérêt est de pouvoir autoriser des actions à la volée pour sortir du bac à sable. La capture d'écran faite maintenant, ton application peut y accéder ou pas ? La caméra, elle peut y accéder maintenant ?

Avec une interface graphique c'est facile de gérer le cas, une pop up ou une notification et tu peux facilement avoir la requête et son traitement par l'utilisateur. Tu fais ça comment avec une CLI ?

La CLI par essence impose que les droits dans ce cas soient permanents et peut être que cela est un problème.

Mais si quelqu'un a une source à ce sujet, je suis preneur.

Sauf qu'il vient d'être déposé sur FlatHub !

Après rien n'empêche quelqu'un de Flathub de pousser Epiphany sur leur dépôt. Même si mcatanzaro est contre par principe. Tout comme Zenitram ne peut pas envoyer boulet Fedora si mediainfo est poussé dans les dépôts dans les conditions qui ne lui plaisent pas en terme de qualité par exemple.

Ce n'est pas clair comment ça a été fait ici.

mcatanzaro a cette réponse : "nobody is responsible for security response" mais je ne comprends pas ce qu'il entend par là ?

Je présume qu'il se plaint que Flathub n'a pas une équipe orientée sécurité pour s'assurer du suivi en cas de problèmes ? Ce que les distributions ont en général.

Mais c'est ambigüe je trouve aussi.

Apparemment le mainteneur d'Epiphany (et de son Flatpak) a retiré Epiphany de Flathub. La raison est que GnuTLS a reçu des MaJ de sécurité que le runtime de Freedesktop ne veut pas mettre à jour car l'API a légèrement changé (de nouvelles fonctions seulement, pas de retrait ou de changement de comportements).

Or pour lui le navigateur Web doit être proposé si GnuTLS est à jour pour des raisons de sécurité. Pourquoi pas, ça se défend.

Et ensuite une longue tirade sur qui est responsable de la situation et devrait le corriger. Pas très pertinent. La conclusion est que le retour d'Epiphany sur Flathub se fera à cette condition.

Ça c'est en théorie. L'ABI ne fait pas tout et les problème sus-nomé de pitivi ne sont pas au niveau de l'ABI je présume.

L'ABI ne fait pas tout, en effet.

Mais bon si le comportement applicatif reposait sur un comportement erroné de la bibliothèque (et dont la correction pose soucis) ou que un changement de comportement essentiel casse les utilisateurs de la bibliothèque dans une version mineure, le problème est insoluble. Et étant donné que ce serait très problématique, je doute que cela soit le cas souvent.

Les problèmes d'ABI ou de changements plus profonds sont quant à eux déjà bien plus fréquents.

C'est là dessus que travaillent les distributions stables.

C'est difficile à faire et parfois elles n'y parviennent pas.

Mais en terme de correctifs manuels, je ne crois pas qu'il y en ai tant que ça (je serais intéressé de regarder). Debian s'est fait connaître à cause de plusieurs histoires là dessus, mais cet éclairage important sur quelques cas donne une fausse impression qu'il y a beaucoup de modifications.

Debian est sans doute la distribution populaire qui a le plus de correctifs en interne. De part ses objectifs et sa taille. Elle a sa réputation à ce sujet et ce n'est pas infondé.

Par ailleurs, mon boulot fait que je touche beaucoup à Yocto voire buildroot donc les problématiques des distributions avec le support et l’intégration qui va avec je connais plutôt bien. La quantité de correctifs internes pour chaque paquet est immense. Il n'y a pas de raisons que Debian avec ses contraintes propres n'en aient pas plus encore !

Il peut profiter de ces vielles applications des failles de sécurité qui vont avec, de l'occupation disque des runtime devenu obsolètes,… En soit cette flexibilité a un coût avec ou sans flatpak, c'est quelque chose à assumer.

La vie est faite de choix. Personnellement ça m'amuse un peu les positions extrêmes car elles renient souvent le droit de faire des compromis, ou de le faire de manière différente. Même si tu mets de l'eau dans ton vin par après, cette partie reste assez typique.

La sécurité n'est pas un tout absolu, je conçois qu'un gars préfère utiliser un logiciel qui a quelques failles connues si cela lui permet de faire son travail (ou ses loisirs) en attendant que le correctif arrive (s'il arrive).

L'avantage de Flatpak c'est aussi de cloisonner. Ce cloisonnement n'est pas une protection absolue mais elle permet justement de limiter la surface d'attaque d'une part, et le potentiel des dégâts d'autre part.

Puis niveau sécurité dans l'informatique, exiger l'infaillibilité en permanence est une chimère. Travaillant dans l'embarqué, je le vois. La plupart des box Internet utilisent des noyaux antédiluviens avec une pile réseau pas maintenue à jour (ou du moins, pas suffisamment !), peu de téléphones ont la dernière version du système dans la nature car la maintenance a toujours une date de fin et que pas tout le monde abandonne son périphérique quand cela arrive à échéance. Et je ne parle pas des gens qui ont des Windows ou macOS pas à jour sans parler des applications dessus. Et changer tout ça pour avoir une sécurité convenable est sans doute possible, mais ça aura un coût de formations et financier. :)

Et dans ce petit monde, qui met à jour le BIOS ou l'UEFI ? Pourtant des correctifs de sécurité du constructeur, il y en a plusieurs les premières années après le lancement du produit.

Et tu voudrais que le monde applicatif de Linux soit rigide pour apporter un petit gain de sécurité potentiel au détriment du reste ? Bof. Je ne crois pas que cela soit une démarche très cohérente en fait. Sauf dans des cas très précis où la sécurité doit passer avant le reste.

Je ne dis pas que l'ancien monde des distributions va et doit disparaître. Je pense que comme tout, il y a des compromis et que selon l'objectif il faudra choisir l'un ou l'autre.

il faut tout de même être conscient de ses limites et que c'est une solution encore jeune qui va encore évoluer en fonction de son usage et des problèmes rencontrés

Personne n'a dit ici que Flatpak était parfait, mature et allait tout remplacer. ;) Même pas moi. J'utilise des Flatpak avec bonheur mais j'ai bien conscience de ses défauts et de ses limites actuelles aussi.

De rien, ravis que ça plaise ! Merci.

Si le runtime sur le quel s'appuie Pitivi est mis à jour avec une version d'une dépendance qui le casse tu ne pourra pas le mettre à jour (même si ce nouveau runtime fixe des CVE ou apporte une version d'une autre dépendance qui elle t'apporterait quelque chose).

Une application Flatpak a une dépendance à une version du runtime. Ce runtime en théorie pour une version donnée ne doit proposer que des mises à jour avec une ABI conservée. En gros les seuls correctifs sont des failles de sécurité ou des bogues.

Donc il n'y a pas de raison qu'une mise à jour du runtime casse l'application qui en dépendait.

Si l'ABI est mis à jour ou que le correctif est plus important, le runtime change de version. Les applications maintenues utiliseront la nouvelle version dès qu'ils seront compatibles avec celui-ci et les non maintenus pourront utiliser l'ancien.

Donc cela fonctionne très bien, tu gardes la possibilité d'avoir un système assez à jour tout en évitant de casser ton application à cause d'une maj pour laquelle la dite application n'est pas prête.

Les distributions font d'ailleurs beaucoup de travail, parfois bancal pour s'assurer que l'ensemble fonctionne. Car à quelques exceptions près, toute application doit utiliser la même version d'une bibliothèque alors qu'elles ont rarement été développées pour ces versions. Donc cela requiert beaucoup de tests, de correctifs manuels dans tous les sens pour s'assurer qu'elles seront fonctionnelles. Beaucoup de maj ont du retard à cause de cela : le nécessaire doit être fait avant pour que tout fonctionne en bloc.

Flatpak apporte la possibilité de le faire en plusieurs étapes. Les applications très maintenues peuvent bénéficier très vite des derniers correctifs, les applications qui le sont moins en profiteront quand elles seront prêtes. Et entre temps, l'utilisateur peut profiter de toutes ses applications.

Comme je l'ai précisé dans l'article, le fonctionnement traditionnelle d'une distribution n'est pas magique. Elle fait un compromis qui a ses avantages et inconvénients pour l'utilisateur comme les mainteneurs. Flatpak propose un autre modèle, avec aussi ses avantages et inconvénients. Aucune solution n'est parfaite et universelle. Il est bon de le reconnaître.

C'est un avis tout à fait personnel, mais je trouve que les runtimes standards/classiques/supportés son beaucoup trop gros.

Pour info n'importe qui peut créer ou maintenir un runtime pour en avoir des plus petits s'il le juge nécessaire.

Ensuite, par essence, une application KDE ou GNOME va faire appel à pas mal de bibliothèques que les autres applications de cet écosystème utilisent aussi. Ces écosystèmes étant gros, les runtimes le font aussi. Mais si tu utilises beaucoup de ces applications ensemble, finalement tu seras proche de la taille d'installation qu'avec ta distribution préférée aujourd'hui.

Donc oui pour installer une application en Flatpak seulement, ce sera un gros poids en plus. Mais si ton système repose dessus (comme c'est le cas avec Silverblue) finalement ça devient intéressant.

Ça donne l'impression que c'est avec des œillères, il y a d'autres solutions qui existent depuis plus longtemps ça aurait était intéressant de faire un état de l'art avant de pondre quelque chose et pas que d'un point de vu technique mais aussi d'un point de vu écosystème.

L'état de l'art a été fait, et Flatpak a trouvé des solutions pour conserver la flexibilité d'installation, avoir un bac à sable tout en évitant d'avoir un système trop lourd et difficile à maintenir en terme de sécurité. Aucune solution existante ne permettait de gérer tout ça à la fois. Surtout l'aspect bac à sable par ailleurs qui est manquant et non trivial à implémenter.

Attention à ne pas tout confondre. Je ne suis pas expert du sujet d'autant que la terminologie est ici assez confuse. J'espère ne pas me planter.

D'abord Silverblue tire origine du projet Atomic d'un point de vue historique, il est normal de parler d'Atomic car c'est évidemment comme cela que ça s'est construit.

Ensuite, de ma compréhension, le projet Atomic en tant que tel n'est pas mort. D'ailleurs Atomic en lui même n'est qu'une collection d'outils, d'une conception particulière. Silverblue utilise toujours ces outils et n'a pas changé de conception non plus.

Ce qui a changé c'est que Fedora Atomic, qui est le nom de l'ancien Fedora Cloud en se basant sur le projet Atomic, a changé pour devenir Fedora CoreOS. Pour notamment tirer profit de CoreOS qui a été racheté par Red Hat et dont le but de ce système collait parfaitement avec le besoin de Fedora Cloud / Atomic. Ce qui en tant que tel n'a pas d'impact pour Silverblue car c'est un produit indépendant. Et Silverblue ne cherche pas à exploiter CoreOS car le but diffère quelque peu sur ce point : sa cible c'est un ordinateur personnel, pas d'être en lui même dans un conteneur pour lancer une application.

Il y a un fichier json dans le répertoire /home (mais pas dans le répertoire /home/user qui est lui chiffré) qui contient les informations relatives au compte : groupes, ID, potentiellement ces données, etc.).

Oui tout à fait, je me suis mal exprimé sur ce point.

Mais cela ne change rien, tu ne récupères pas une erreur que tu peux traiter normalement.

Oui, je ne dis pas spécialement le contraire tu noteras.

Avoir une swap égale à la RAM est utile pour hiberner, ou alors cela signifie que tu as beaucoup de RAM qui ne sert à rien l'essentiel du temps quand tu as besoin d'hiberner. C'est plus une précaution qu'une nécessité dans mon message.

Après se tromper dans l'accès à un tableau signifie que tu n'as au choix :

• Pas vérifié la taille du tableau avant l'accès ;
• Pas utilisé d'itérateur.

Ce n'est pas bien.

En plus je suis toujours dubitatif de recevoir une erreur pour ça. Tu en fais quoi, de cette erreur au runtime ? Étant donné que c'est surtout un problème de bonne pratique plus que d'une erreur légitime.

Or, être capable de détecter cette erreur au runtime a un coût non nul. Ça peut se comprendre qu'ils décident de ne pas le considérer comme une erreur valide.

Je précise que la plupart des langages modernes agissent ainsi malgré une meilleure préoccupation de la gestion des erreurs qu'à l'époque du C. Je pense à Rust notamment où l'accès direct hors du tableau est possible et génère une belle erreur de segmentation à l'ancienne.

L'hibernation c'est copier l'intégralité de la RAM dans la swap pour pouvoir couper l'alimentation électrique totalement (donc aucun risque de perte de données en cas de coupure de courant entre temps).

Au redémarrage, la machine restaure l'état de ta mémoire entièrement.

Ta swap doit avoir de libre au moins la taille totale de la mémoire allouée. Donc en général, au moins la taille de ta RAM soit ici 8 Gio.

Apparemment Machines est destiné aux cas plus complexes, qui nécessitent plus d'options.

Les deux utilisent le même code derrière donc c'est surtout une question d'interface et de simplicité d'usage.