Cette espace vous permet de voir toutes les Messages réalisées par ce membre. Vous ne pouvez voir que les Messages réalisées dans les espaces auxquels vous avez accès.
Bonjour, J'ai fais quelques upgrades ce matin et hier, je pense que c'est côté flatpak le problème mais remmina ne se lance plus.
Citer
flatpak run org.remmina.Remmina remmina-Message: 07:41:43.995: Remmina does not log all output statements. Turn on more verbose output by using "G_MESSAGES_DEBUG=all" as an environment variable. More info available on the Remmina wiki at: https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging Load modules from /app/lib/remmina/plugins Remmina plugin glibsecret (type=Secret) has been registered, but is not yet initialized/activated. The initialization order is 2000.
(process:2): libsoup-ERROR **: 07:41:44.106: libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.
Je ne sais pas si c'est propre à leap, mais en l'état c'est bien galère vu que j'ai besoin de remmina pour bosser... c'est la première fois que le problème se pose en flatpak...
Du coup j'installe la version des dépôts qui est souvent plus anciennes pour me débloquer en attendant.
Mageia est un peu à mi chemin entre une rolling release et une fixed. Le kernel est mis à jour de manière régulière (je ne sais plus s'ils restent uniquement sur les LTS mais en tous cas il est upgradé), les programmes sont souvent montés de versions aussi mais pas toujours. (c'est bien firefox ESR qui est utilisé par exemple)
Mais pour les gros changements, il faut attendre la version +1. Par exemple mageia 8 a toujours la même version de kde, et je pense que la monte de version ne se fera que lorsque mageia 9 sortira.
Donc c'est un compromis entre les deux. Oui le panneau de contrôle est plus archaïque. Maintenant perso yast en dehors de l'installation des programmes une fois la conf initiale effectuée je n'y mets plus du tout les pieds. Mais openSuse n'est pas installé en tant que serveur chez moi.
A voir s'ils ciblent réellement cette architecture ou s'ils font un choix plus pragmatique de x86-64-v2. Pour tumbleweed par contre ça pourrait avoir un sens de basculer sur x86-64-v3.
Gentoo ==> compilation, donc si tu choisis bien tes flags, tu as les meilleures instructions possibles supportées par ton processeur, on peut difficilement faire mieux, c'est du spécifique à ta machine. Clearlinux ==> Fait par intel, pour ses cpu, donc là aussi c'est une compilation optimisée aux petits oignons pour les cpu dernière génération en activant les options qui vont bien.
ça a toujours été plus ou moins le cas, ce n'est pas pour rien que gentoo ou clearlinux performent autant en général en comparaison avec les distribs plus généralistes.
C'est toujours la même problématique, soit on supporte plein de vieux matos, soit on optimise pour le matériel récent, donc en utilisant lors de la compilation des instructions modernes, mais donc on laisse de côté pas mal de matériel.
Si c'est ce qu'ils confirment alors espérons que ça soit réellement le cas. Après comme dit, même si ce n'est pas direct, tu peux quand même avoir cet effet de bord de départ des participants.
Sinon ce que tu évoques là avec les rolling release, c'est typiquement le genre de truc qui tue l'intéret de la rolling release. Si c'est pour au final se retrouver avec du flatpak, quel est l'intéret de la rolling release?
Bon après si c'est très exceptionnel pour éviter un dépôt externe ok, mais tu mentionnes pacman donc déjà toute la partie multimedia et codec, si on rajoute en plus steam and co en flatpak quel est l'intéret de la rolling release???
Comme dit, la majorité des distributions freezées prennent cette voie. Un socle sur lequel ils mettront des flatpak. C'est le cas de redheat/Fedora à ma connaissance. C'est le cas d'ubuntu qui a choisi Snap Et c'est donc visiblement le choix de Suse SLE.
En distribution freezées qui ne font pas ça il reste donc: - Mint qui se bas contre les choix d'ubuntu, ou qui a une voie via LMDE en étant dependant de Debian - Debian mais qui a du coup des soucis de paquets, chromium n'était pratiquement plus mis à jour sur la dernière année. Firefox passe encore grasse à ESR, mais lorsque ESR change de version on peut retomber dans le même pb - Mageia ou le sujet ne semble pas évoqué (enfin rien vu passer), distrib un peu à part vu que c'est freezé mais qu'ils font de grosses update d'un coup, donc des montées de versions ne posent pas de problème, sauf que pour la correction des majs de securité il y a forcément un temps de latence. C'est un peu comme une rolling release au final avec plus de retenu.
Et donc toutes les rolling releases qui sont à part car tout est fait au fur et à mesure.
Tumbleweed est à part, à ma connaissance c'est la seule distrib rolling release qui a des bases communes avec un os freezé. Je ne sais pas comment le cheminement se fait, et toute la problématique est justement de savoir si tumbleweed dépend de SLE. SI des choses sont communes ou pas et si SUSE participe d'une quelconque manière à ça. Car si SLE passe en flatpak, sauf à ce que la méthode soit la même pour faire un flatpak que pour participer à tumbleweed, ils n'auront aucune raison de continuer à le faire.
Au delà de ça, tu peux aussi perdre des contributeurs qui étaient ceux qui participaient à LEAP + TUmbleweed (vu que beaucoup de choses sont communes) et donc l'un dans l'autre on peut aussi perdre des contributeurs. IL me semblait que Tumbleweed servait de réservoir à Leap, et donc à SLE, donc Suse avait un intéret à participer. Sans Leap ni SLE (enfin pas conçu pareil) il n'est pas sûr que cette utilité perdure. Donc je ne serais clairement pas aussi catégorie sur le "pas d'impact pour tumbleweed".
Si ça peut aider, j'ai un tuxedo pulse. Tuxedo ne participe plus trop à opensuse mais ce n'est pas pour ça que cela ne fonctionne pas sans problème.
APrès c'est pareil quand on parle d'opensuse il faut savoir de quoi on parle, si c'est Leap ou tumbleweed. Vu que tu parlais du noyau 5.14 tu parlais donc de leap.
A mon avis il faut éviter les cpu 6XXX de ryzen qui seront trop récents, il faut vérifier le nom du gpu intégré et voir si on trouve le firmware sous leap mais j'ai un doute. Aucun soucis pour un 4XXX ou un 5XXX avec vega par contre.
Savez vous s'il y a un risque que tumbleweed soit impactée? Dépend-elle de SLE au final?
J'avoue avoir tester pas mal de distrib, et seule opensuse permet de facilement faire un chiffrement LVM encrypt avec /boot non chiffré... (bref un truc à la carte).
Ah mais comme évoqué, je n'ai pas dit que les flatpak c'était le mal absolu, juste que c'est ok pour certains logiciel spécifique qu'il faut tenir à jour, mais pas pour la totalité et/ou pour un logiciel qu'on utilise tout le temps à cause du temps de lancement supplémentaire qui n'était pas négligeable. (test à refaire pour comparer)
Si ça peut te rassurer j'ai moi même des flatpaks, mais pour des choses très spécifiques (client matrix, teams), le navigateur web, le client mail, les edi de dev, bref toutes les choses que j'utilise en continu et que j'ouvre et referme en boucle eux sont en natif.
@scroll44 je ne suis pas si à l’aise que ça j’utilise Yast aussi, il est très bien. Après sur ma TW je ne fais pas grand-chose par rapport à l’installation par défaut. c’est bon dès la livraison 😄
Le besoin de mises à jour fréquentes s’est accentué ces dernières années et puis il y a peut-être des utilisateurs qui veulent du stable avec du récent.
Pourquoi l’idée d’avoir des applis dans des conteneurs vous inquiète ? Pc trop vieux ? Peur que ça rame ? Les smartphones Android ne fonctionnent pas avec la technologie des conteneurs ? Édit : pour ceux qui veulent se renseigner sur la techno des conteneurs, cet article semble intéressant, je ne suis pas allée au bout, je n’ai plus le temps là mais je le ferai https://jpetazzo.github.io/2018/03/28/containers-par-ou-commencer/
Pourquoi j'en veux pas? Parce que c'est justement lent et lourd. C'est bien le problème.
Oui les machines récentes sont sur dimensionnées et peuvent faire tourner ça en le masquant plus ou moins, mais ça n'en change pas pour autant le problème de fond. Ce n'est pas parce qu'il est masqué que le problème n'est pas présent. Après même sans ça ça se verra sur des machines moins récentes.
Il faudrait que je refasse des tests de temps de lancement d'application flatpak vs snap vs natif, mais ce n'était vraiment pas glorieux. ça dû s'améliorer je suis sûr et c'est de plus en plus masqué avec la puissance des machines, mais le problème reste présent.
Quand à android le problème n'est pas tout à fait le même, là c'est plus le compilé natif vs les applications utilisant un émulateur. Niveau lib ça utilise quand même les libs du systême pour tout ce qui est java ou app google. ça tourne dans des sandbox mais c'est tout, donc ce n'est pas tout à fait pareil.
Le modèle de mageia est peut être à étudier ... Maintenant leap avait les problèmes que tu décris et a bien fonctionné depuis des années …
Mageia est un fork de mandriva qui était un fork de mandrake, centos a eu un fork rocky linux (entre autres Lien ) , on est pas à l'abri d'un fork de leap (il faut pas l'enterrer trop vite).
Sauf qu'openSuse LEAP dépendait grandement du travail de SUSE. La grande majorité des choses c'était fait par SUSE sur SLE, je doute que tu trouves des dev bénévoles qui arrivent à suivre la cadence qui suivait SUSE avec des dev payés à temps plein pour faire ça. C'est bien le problème de fond. C'est un peu comme mint (pas LMDE), si ubuntu ferme les vanne, MINT en tant que tel n'a pas l'équipe pour reprendre tout le travail fait par Canonical.
