aeris ☣ 🇫🇷
Follow

Ils me cassent les gonades les gens de chez FlatPak & cie…
Les gens t’annoncent comme avantage d’être méga reproductible & cie, mais packagent la glibc dans leur image de base, qui tourne donc sur un kernel totalement inconnu et différent…
Et annoncent que comme ça l’upstream n’aura qu’un seul binaire à construire. Pour l’exécuter partout.
En score de yoloitude, je dirais trop / 42.

@aeris bah quand tu vois de les outils jetbreans embarque du GCC 6 (sur ma arch on en est a la 8)

@Aelisya La version du soft en lui-même n’est pas un problème.
Tant que tu compiles gcc6 depuis la même glibc que celle qui exécutera le programme gcc6 à la fin, pas de souci.

Si on s’emmerde avec du pbuilder ou autre sous Debian pour garantir qu’on livre bien un binaire qui tourne sur la version de la glibc qui l’a compilé, ce n’est pas pour rien hein.
C’est que c’est juste complètement random en terme de comportement d’exécuter un binaire construit sur une glibc différente. Et donc a fortiori sur un kernel différent.

Et moins reproductible que ça le jour où tu as un bug, il n’y a pas.
Tu vas déjà mettre ~ 42 ans rien que pour ne serait-ce qu’envisager que le crash est lié à un delta de glibc ou de kernel…

@bortzmeyer Possible averses orageuses sur Paris d'ailleurs à cette heure là. Coïncidence ? 🤔 @aeris

@aeris entre ça et les critiques sur la sécurité flatpak en prend pour son grade

@aeris Je propose un nouveau standard pour Linux & Cie. Un répertoire (appelons l'on le /bin/GNUSxS) où les softs viendrait mettre leur propre version de la lib qu'ils veulent utiliser. Comme ça, hop plus de problèmes 🤔🤔

(Toutes ressemblances avec le système merdique un OS privateur est purement fortuite)

@Shaft @aeris ne donne pas des idées aux devs de systemd !

@Shaft @aeris y a qu'à faire une image Docker pour chaque binaire, comme ça chacun a sa libc.

#derien

@aeris

Je te cite, « Tant que tu compiles gcc6 depuis la même glibc que celle qui exécutera le programme gcc6 à la fin, pas de souci. »

Ça tombe bien, la glibc fait partie du runtime Freedesktop. Les Flatpaks seront donc compilés avec la même glibc que celle qui exécutera le programme à la fin. Donc pas de souci 😛

@aeris

Accessoirement, la techno existe déjà. T'es donc libre d'installer cinquante distros différentes et de faire tourner ton Flatpak sur chacune d'entre elles pour vérifier que ça tourne bien.

Et pense à nous faire un compte rendu à la fin 😁

@gnomelibre Vérifier que ça tourne bien à l’instant T ne veut pas dire que ça tournera toujours bien à l’instant T+1 hein 😃

@gnomelibre @aeris Je viens de regarder rapide (donc j'ai ptet fait une erreur, à vérifier):

La glibc semble être compilée avec des linux headers 4.14.56.

Je sais pas si ça à changé, mais la glibc possèdait du code pour te balancer une erreur dans la tronche si ton noyau est plus ancien que celui avec lequelle elle à été compilée.

Debian stable à encore un noyau linux 4.9

Bref, je pense pas que les flatpak marchent sous debian stable.

@mutablecoder @gnomelibre Dans tous les cas, exécuter une application compilée pour une glibc 4.14 sur un kernel 4.9, faut être siphonné, et même si ça tombe en marche parce que t’es pas tombé sur un syscall ABI incompatible, ça ne veut absolument pas dire que ça ne sera jamais le cas 😃

@mutablecoder @gnomelibre (Et par exemple flatpak pête aussi l’export display… Impossible de lancer gimp via ssh -X… Alors que gimp hors flatpak, no problem…)

@aeris @mutablecoder

À mon avis, c'est avant tout pensé pour un environnement sûr, avec plutôt Wayland en tête. Ce dernier ne permettant pas non plus l'export, si je ne dis pas de bêtises, ça sera plutôt PipeWire qui devrait apporter cette possibilité

pipewire.org

Toutes les briques ne sont pas encore en place, mais ça tombe bien, personne n'a dit que ça devait être massivement adopté la semaine prochaine 😁

Ni même adopté tout court. Chacun sera libre d'utiliser ce qui lui chante

@mutablecoder @aeris

Je n'ai pas de Debian stable sous la main, mais il y a bien un paquet flatpak dans les dépôts officiels

Il y a également de la doc sur le wiki officiel et chez Debian Facile. J'imagine que ça a donc été testé et approuvé 🙂

wiki.debian.org/FlatpakHowto
debian-facile.org/doc:systeme:

@gnomelibre @mutablecoder Je répète : ce n’est pas parce que ça fonctionne que ça doit être fait. Ça peut péter n’importe quand pour n’importe quoi.

@gnomelibre @mutablecoder Debian Stretch tourne actuellement avec une glibc 2.24-11+deb9u3. Donc si ton image n’est pas buildée avec 2.24, c’est un risque énorme que l’appli se daube à un moment ou à un autre.

@aeris @gnomelibre De ce que je comprend, ça embarque la glibc, non ?

parce que sinon, oui, c'est une recette pour un désastre.

Rapidement, je comprend pas grand chose à leur système de build.

@mutablecoder @gnomelibre La glibc dépend elle-même du kernel. C’est le trio kernel-glibc-app qui est indécoupable.

@mutablecoder @gnomelibre Et comme flatpak n’embarque pas son kernel (sinon ça serait une VM), il faut a minima que la glibc du flatpac soit ABI compatible avec celle de l’hôte. Sinon, tu vas au devant de grosses merdes.

@mutablecoder @gnomelibre Grosso merdo, entre la 2.24 de stretch et la 2.27 de buster, tu as seulement 97.74% de chance que ton programme s’exécute… Et si tu utilises une seule des primitives virées de la 2.26, tu crash.

@mutablecoder @gnomelibre Idem si ton programme compilé avec la glibc 2.27 utilise un des 77 symboles insérés depuis…

@mutablecoder @gnomelibre Si tu utilises librt quelque part, tu tombes même à 86.5% de chance que ça ne plante pas si tu as la 2.26 entre la version de build et la version d’exec…
abi-laboratory.pro/index.php?v

@aeris @gnomelibre J'utilise pas trop la glibc, mais il me semblait qu'il avait emprunté le même chemin que musl, et que librt devenait une coquille vide... uniquement utilisé par des vieux binaires compilés avec des vielles versions de la glibc.

bref, c'est pas un bon exemple. (mais c'est pas une raison pour mélanger des glibc)

@aeris @gnomelibre C'est pas à moi qu'il faut le dire, j'fais pas mal d'embarqué.

Mais j'ai pas rapidement trouvé de la doc sur ce qui est embarqué dans le runtime freedesktop et ce qui l'est pas.

Si le flatpak embarque sa propre version de la glibc, alors y aura pas de problème d'incompatibilité de la glibc[1], il reste juste le problème de version de noyau

Si le flatpak dépend de lib du système par contre, ça va douiller. Le cas le plus fréquent, c'est genre libGL

@mutablecoder @aeris

Le contenu du runtime Freedesktop 18.08

gitlab.com/freedesktop-sdk/fre

Pour les pilotes GL, ça inclut Mesa et la libglvnd de nVidia et à plus long terme, ça devrait pouvoir utiliser les pilotes du système hôte au travers de la libcapsule

media.ccc.de/v/ASG2018-173-lib

@gnomelibre @mutablecoder Tu tournes donc avec la libc 2.27. Debian Stretch tourne en 2.24. Tu te prends la 2.26 qui a des gros breaking change au moins sur librt et a droppé 5 symbol.
Si ton appli juste tombe en marche sur Stretch, ça relève plus du coup de bol que de la garantie absolue…

@gnomelibre @mutablecoder Et donc ça veut dire que flatpak aura une probabilité non nulle de filer des maux de crâne pas possible aux mainteneurs qui devront 1- se coltiner des bugs improbables de crash à cause d’une ABI incompatibilité avec la libc 2- livrer autant de version de leur soft que de libc ABI incompatibles qu’ils souhaitent supporter

@gnomelibre @aeris C'est bien joli, mais quand j'ai acheté ma carte graphique, à l'époque, il n'y avais que les drivers nvidia récent qui la supportait.

Ça m'avais posé problème pour faire tourner des trucs dans un vieux chroot, à l'époque.

Sign in to participate in the conversation
Mastodon

PARCE QUE C’EST MON INSTANCE !