Renault a écrit 7255 commentaires

Ç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.

D'autant qu'il y avait des moyens pour ajouter ce bouton à côté des autres. Comme des extensions.

Le swap est indispensable pour l'hibernation (donc ceux qui s'en servent en ont besoin).

Sinon le swap reste utile. Sur mon portable je ne pourrais pas travailler sans, quand une compilation Yocto a des pics de besoin de mémoire que ma machine ne peut satisfaire, le swap récupère les pages inutiles de la RAM.

La swap est utile dans une certaine mesure pour récupérer les pages inutilisées pour maximiser la taille des caches du système ce qui améliore les performances. Si ta RAM est trop limite par rapport au besoin évidemment. C'est-à-dire quand il est fréquent que tu utilises plus de 75% de ce dernier.

Mais après quand ça swappe trop, la machine est en effet inutilisable. Cela m'est arrivé quelques fois, 3-4 Gio de swap sur le SSD, il était impossible de sauver la machine sans l'éteindre brutalement.

Pas encore, les discussions internes parlaient du premier semestre 2020. Mais difficile de dire si le planning initial sera maintenu dans la situation actuelle.

Qui sait, peut être demain lors de l'annonce de sortie !

Ça pourrait être amusant. :)

Dommage pour la publication en avance, mais ça va, ce sera bon pour demain. ;)

Pour information OS/2 était à la base une collaboration entre IBM et MS. Suite à un désaccord, MS a poursuivi son travail exclusivement sur Windows tandis que IBM a repris la charge de OS/2 mais sans succès pour ce dernier.

Ce n'est en effet pas une source d'énergie perpétuelle. ;)

Techniquement d'ailleurs, ce n'est pas une source d'énergie en tant que telles : ces ondes électromagnétiques sont faites par l'Homme pour émettre la radio, le wifi, etc.

L'idée est donc que certains appareils peu gourmands et portables puissent récupérer cette énergie disponible un peu partout plutôt que de réclamer de l'énergie additionnelle.

Ce serait une forme d'optimisation pour réduire la consommation de ces appareils. Mais si jamais tu n'as pas de l'énergie primaire suffisante pour générer ces ondes, ça ne pourra pas fonctionner. :)

D'où le fait que ce soit une source d'énergie me paraît assez impropre.

Comme barmic l'a dit tu écris et publies ce que tu veux, c'est ton droit.

Non ton code n'est clairement pas parfait, il ne faut pas le prendre mal, j'ai donné les éléments qui m'ont sauté aux yeux pour que tu puisses faire mieux la prochaine fois. Moi aussi j'ai écrit (et j'écris à l'occasion) du code sale. Et je suis content quand quelqu'un m'explique ce que je pourrais améliorer.

Bref, ne prends pas la mouche, il n'y a pas de raisons…

Une erreur de quoi ? Il ne s'agit pas d'une erreur, je sais très bien que systemd est plus qu'un système d'init et c'est bien ça que je lui reproche.

Ta comparaison repose sur l'aspect init, ce n'est pas correcte de focaliser son attention dessus alors qu'il propose plus.

Comportements qui posent problème lorsque tu n'es pas dans les cvlous. Systemd oblige ton besoin à s'adapter à l'outil, plutôt que de s'effacer et de laisser l'admin faire ce qu'il a a faire.

Sur la plupart des OS qui implémentent le même type d'approche, la plupart du temps, tu as tout ce qu'il faut pour configurer un service proprement. Et dès que tu as un besoin qui sort de ce qui t'es proposé" tu peux implémenter le comportement que tu veux. Rien n'oblige de le faire en shell, tu peux le faire avec du python, du ruby, lua, ou n'importe quoi d'autre.

Oui, c'est vrai qu'il y a 25000 façons de redémarrer un service qui a échoué, de configurer les droits SELinux et compagnie… Avec init tu dois toujours te le farcir toi même. Pourtant c'est un besoin de base.

Et comme systemd permet d'appeler un shell ou ce que tu veux, par effet de bord tu peux faire ce que tu veux si le comportement de systemd ne te plaît pas. Il y a d'ailleurs de quoi exécuter des scripts init classiques avec systemd. Donc en gros : tu peux faire comme avant si tu y tiens.

J'aime pas les trucs qui me cachent des choses.

Rien n'est caché, le code de systemd est dispo si tu y tiens.
Personnellement en lisant une unité systemd j'ai en quelques secondes les propriétés essentielles du service. Et je peux en déduire son comportement quelque soit le service.

Si c'est un script init à l'ancienne, pour peu qu'il ne soit pas trivial il te faudra bien plus de temps pour en retirer les mêmes informations. Et comme aucun script init n'est rédigé de la même façon contrairement à une unité systemd, prédire le comportement demande de réévaluer le script systématiquement.

Oui enfin, quand un service fait les choses différemment des autres c'est bien souvent parce qu'il a besoin de faire les choses différemment.

Non, c'est juste que pas tout le monde pense à couvrir tous les besoins. Normal, ce n'est pas simple à anticiper. Même quand tu es le développeur de l'application ou le mainteneur dans une distribution.

Pas tout le monde pense à gérer le cas d'un service qui plante et qui doit redémarrer automatiquement, pas tout le monde pense à ajouter des règles SELinux, pas tout le monde pense à bien gérer les dépendances du service comme s'assurer que le réseau soit opérationnel avant, etc.

Si le mainteneur n'a pas fait son boulot correctement (indice, ça arrivait souvent) tu devais te démerder et c'était chiant. Ici cela se règle très simplement.

Je travaille en embarqué par exemple, contrôler ce qui se passe j'aime bien aussi. Mais sur chaque projet où c'était de l'init classique, je devais régler les mêmes problèmes à la con, réinventer la roue 20 fois, etc. systemd gère tous ces problèmes d'entrée de jeu, écrire une unité systemd qui fait ce que tu veux est très simple. Je n'ai littéralement jamais eu de soucis avec, c'est un confort incroyable.

Donc oui, avec l'init tu as plus de contrôle direct, oui, car toute la difficulté repose sur le dos de l'administrateur. Ce n'est selon moi pas la bonne approche. Si l'admin veut reprendre le contrôle avec systemd, il le peut de toute façon en cas de besoin.

En fait, une phrase résume bien la raison pour laquelle je n'aime pas systemd : "A full exposition of systemd would take a book on its own." alors que les systèmes d'init plus classiques n'ont besoin que d'un chapitre dans un bouquin d'admin système, et de connaitre un peu le scripting shell pour être compris.

Je pense que la véritable erreur est là. systemd n'est pas juste un système d'init, c'est une collection de services bas niveau dont gestionnaire d'init mais aussi de session, etc. Donc il est normal qu'il soit plus complexe et complet, l'ensemble des parties de systemd est bien plus vaste que init.

En plus systemd a de nombreux comportements qui sont fournis d'entrée de jeux. Il suffit de configurer le service pour exploiter le comportement qu'on veut. init de SysV est vraiment rudimentaire, la complexité est en fait dans le script shell du service et tu dois tout faire à la main. Donc oui systemd est complexe à côté, mais la complexité est cachée à l'utilisateur et assumé de manière commune à tous les services.

Et systemd peut prendre en charge de manière uniforme tous les services, configurer SELinux, le redémarrage en cas de crash de l'application, etc. Avec init chaque service le fait à sa sauce, parfois ne le gère pas, parfois de manière différente d'un autre, etc. Bref, ce n'est pas parfait non plus…

Il faut comparer ce qui est comparable, systemd n'est pas qu'un système d'init et au niveau fonctionnel systemd gère la complexité lui même et ne la reporte pas sur le shell et les scripts de démarrages de chaque service.

Moins de femmes très malades que d'homme (c'est dit partout), par contre je me suis trompée d'hormones, ce sont les œstrogènes, désolée.

Oui, malheureusement c'est bien une corrélation et non une causalité. Difficile de dire si ce sont les hormones ou autre choses qui peuvent l'expliquer à ce stade. Comme l'indique la page que tu cites d'ailleurs.

Ils n'ont plus qu'à creuser comme on dit.

Source ? Je n'en ai même pas entendu parler.

Après attention à faire la différence entre corrélation et causalité. En particulier en médecine où les corrélations sont nombreuses avec une causalité cachée.

cela fait quand même 2 ans que les service hospitalier et d'urgence font des grèves pour attirer l'attention sur le drame qui s'y passe, ce n'est pas au 1 mars. je rappel ce magnifique journal :

Je ne vois pas le rapport.

Non pas qu'un système hospitalier à bout de souffle soit souhaitable ou que cela n'a pas accru certaines difficultés, mais la crise liée au coronavirus n'a que peu à voir finalement avec le système de santé en tant que tel.

D'ailleurs globalement les hôpitaux ont su tenir la charge au niveau nationale et il aurait fallu un budget totalement irréaliste pour avoir assez de lits et de personnels pour faire face à une vague non contrôlée par des mesures fortes.

D'ailleurs on le voit, tous les pays ont dû prendre des mesures fortes pour y mettre fin. Même ceux avec pourtant de bonnes capacités hospitalières car toute façon aucun système hospitalier ne peut faire face à une vague non contrôlée. Et la France d'ailleurs n'est pas si mal que ça sur ce critère.

Le problème est plus dans l'anticipation et la prévention, mais ce n'est pas simple. C'est un virus nouveau, il a fallu ingérer de nouvelles données constamment, les réactions trop virulentes de nos précédents gouvernements face aux précédentes épidémies asiatiques ont sans doute refroidi les gouvernements actuels de faire pareil cette fois pour une maladie finalement peu létale en elle même.

En tout cas ça permet de révéler certaines choses qui permettront de mieux gérer une telle situation si elle se reproduit, et pour le dé-confinement.

Bref, la gestion de l'épidémie aurait été tout aussi difficile même avec des services hospitaliers au taquet. Car pour faire face à une horde de malades, tu ne peux pas surdimensionner le système autant.

Tu penses vraiment que c'est grâce au confinement strict (c'est à dire que l'on oblige par la loi à ne pas sortir de chez soi) que l'Allemagne, les Pays-bas et la Suède n'ont pas eu à se confiner ?

À part la Suède que je ne connais pas, les autres pays ont quand même des restrictions strictes à défaut d'un réel confinement. Ce n'est pas faites ce que vous voulez. Donc ne crois pas que chez eux le virus n'a aucun impact alors que chez nous c'est sévère, pour l'Allemagne aussi l'économie va souffrir, les allemands aussi subissent des restrictions légales fortes.

Et la Corée du Sud ? Et Taiwan ? C'est grâce à nous également ?

La Corée du Sud et Taiwan ont l'expérience des épidémies asiatiques de ces 20 dernières années, ça aide à se préparer et à avoir citoyens comme politiciens au taquet.

Ensuite ils ont eu massivement recours à des technologies qui hérissent le poil à certains ici pour faire du confinement très ciblé. Niveau liberté individuelle et vie privée c'est assez limite par rapport à ce qui est autorisé en Europe à ce sujet.

Donc oui ils s'en sortent bien mais ils ont fait des choix. Ce n'est en tout cas uniquement parce que le citoyen local est plus consciencieux.

Comment se fait-il qu'en Allemagne, au Portugal ou même aux Pays bas et en Suède (même si l'histoire n'est pas finie), les modèles ne fonctionnent pas de la même façon (moins de conséquences sur le social et l'économie et également moins de morts) ?

Car l'épidémie n'est pas quelque chose de uniforme que ce soit dans une région ou dans le monde.

Tout d'abord un R0 n'est pas une valeur constante liée au virus. Elle dépend énormément de la densité de population, des échanges au sein de celles-ci, des habitudes culturelles, etc.

Chaque pays a des habitudes et une structure de sa population qui impacte +/- la contamination. D'où le fait que de comparer la situation en Suède avec la France de manière directe n'a pas un grand sens.

Ensuite une épidémie dépend beaucoup des échanges au sein de la population. Plus on tarde à limiter ces échanges au début, plus les conséquences seront fortes et dans la durée. Mais d'ailleurs on le voit, en France l'épidémie a surtout touché le Nord, l'Est et Paris. Le confinement a stoppé les flux avec les autres régions de manière suffisamment forte que les cas sont restés concentrés dans ces régions.

C'est d'ailleurs le cas en Italie ou Espagne où les régions très peuplées et touchées au début de l'épidémie qui concentrent l'essentiel des cas, les régions plus éloignées et moins dense ont profité du confinement pour stopper assez tôt la propagation.

C'est aussi probablement ce qui a aidé à protéger certains pays comme l'Allemagne ou la Suède qui ont été probablement moins touchés à l'origine. Et les mesures prises localement et par les pays voisines ont été suffisamment efficaces pour que le confinement général ne soit pas nécessaire.

De même qu'il n'est pas sûr que de nouveaux confinements soient nécessaires chez nous à l'avenir même si ça remonte. Par contre la vie normale comme avant sans restrictions cela mettra du temps à se revenir oui.