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.
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.
Antix est dérivé de debian. Donc derrière tu dois avoir les mêmes défauts que debian, et ça reste le travail de debian.
ça reste un fait, maintenir une distrib "freezée" suffisamment longtemps pause problème. :/ Après tu peux avoir un "compromis" comme le fait mageia, ou tu es à mis chemin entre du rolling release et du freezé, je ne sais pas si ce genre de fonctionnement a les mêmes pbs que le "stable" et si ça arrive à couvrir tous les cas.
IL ne reste pas énormément de distributions "stables" basé sur un système de dépot originel. Le problème de fond reste valable, maintenir une base stable suffisamment longtemps, demande des logiciels freezé LTS. Or ça bouge beaucoup trop sur tous les logiciels/lib pour que ça soit fait.
Cette tendance reste globale à cause de ce problème là. RedHat (+ fedora) prennent la même direction que SUSE, Ubuntu l'a déjà prise. On voit que ceux qui essaient de continuer continuent à avoir soit des problèmes de securité, soit de paquet non mis à jour.
Regarde debian Stable, très rapidement tu as des soucis de navigateur qui ne sont plus mis à jour (chromium) car nécessitant une base plus moderne niveau lib. Le seul navigateur au final garantie sur le long terme ça reste firefox, parce qu'il existe en version ESR.
ça reste malheureusement un constat, de nos jours maintenir une distrib stable avec des logiciels à jour niveau secu est problématique, nécessite beaucoup de monde et je pense qu'avec toutes les personnes qui ont migré sur des rolling release tu as moins de volontaire (et moins d'implication de la part des devs à maintenir deux versions) pour suivre ça.
De même comme déjà évoqué sur d'autres topic, il se trouve que côté dev, flatpak/snap/docker, c'est l'idéal pour eux, aucune prise de tête, ils fournisse un truc qui passe sur toutes les distribs. C'est la solution de facilité et le gain de temps. ça implique d'autres problèmes (vu que c'est du coup à eux de gérer tous les pbs de sécurité et de monté de version de lib alors que normalement cette tâche incombe à l'admin sys), mais de ce point de vu là c'est clair et net. Côté entreprise, pratiquement tous les logiciels livrés en entreprise web, sont dans des conteneurs docker...
Il faut aller en discuter sur les liens donnés alors, indiquer les soucis.
Le problème c'est que ce n'est pas un "soucis", c'est un choix de conception. Tu peux pas aller dire: "je veux pas d'un truc tout flatpak ou au final on aura un truc à la ouin ouin mais plus lourd puisque flatpak/snap ont un cout" alors que c'est le choix qui est pris. Ils font ce choix, à partir de là faut "accompagner et proposer des trucs", mais pour moi le problème de fond c'est ce choix là.
La seule autre possibilité ça serait que chaque logiciel soit maintenu en version LTS et dernière version (pour les rolling release) pour que ça puisse être différent.
Je comprends parfaitement leur problème, et on voit clairement le problème de nos jours, le problème de fond, c'est plus côté dev. Et d'un autre côté de leur côté je conçois qu'ils ne puissent pas maintenir deux versions.
C'est malheureux mais c'est la vitesse d'évolution qui veut ça. Seul alternatives possible à ce systême full flatpak, le rolling release.
En fait, partir sur snap/flatpak, ça revient à dire que microsoft and co avaient raison, que la seule solution possible c'est que chaque logiciel embarque ses libs. :/ Donc en gros ça revient à laisser tomber tout le système de dépôt de linux, de paquet etc.
Espérons qu'il restera bien toujours les rolling release.
Le problème c'est qu'avoir quelques logiciels via pacman ok, mais pratiquement tout perso je suis pas fan. ça a quand même un sacré impact niveau perf, niveau maintenance etc.
Au final ça revient à avoir ce que fait microsoft mais en plus lent (même si mieux cloisonné via les sandbox etc) ou chaque logiciel embarque ses libs.
... En fonction de ce qui se passera je risque de devoir migrer sur une rolling release ...
Personnellement je ne passerai pas sur une rolling realease. Pour le jeu, j'ai essayé manjaro et je me mangeais des mises à jour de 900 Mo en Adsl. C'est hors de question.
Oui en ADSl c'est mort.
Maintenant dans mon cas je suis en fibre chez moi et idem chez mes parents, mais ça ne change pas le problème de fond. Sur leap je ne me pose pas de question il y a une maj sur ta version, tu mets à jour, au moins t'es sûr de pouvoir passer tes majs de secu. Sur une rolling release, pour peu que ça se cumule avec une grosse maj, t'es parti pour un bon moment, même si ça se télécharge vite avec la fibre, ça n'empêche que le temps n'est pas le même. :/ D'ailleurs de ce côté là Opensuse est vraiment lent comparé à manjaro, tant côté dépôt que côté vitesse d'installation de zypper par rapport à Pacman.
J'ai des vm que je mets à jour de manière aléatoire, que ça soit de la manjaro ou de la tumbleweed, aucun soucis pour l'instant. Chez manjaro j'ai déjà eu des soucis par rapport aux clefs des serveurs qui avaient changés mais en dehors de ça c'est toujours passé sans pb.
Mais bon, comme dit ce n'est pas un truc que je peux exploiter chez mes parents, et chez moi j'avoue que ça risque de bien m'embêter. j'ai une connaissance qui est pourtant utilisateur lambda qui utilise manjaro sans soucis.
Mon problème aussi c'est que j'utilise une partition LVM chiffrée, et ça j'ai pas confiance sur le long terme sur une rolling release, c'est un coup à se retrouver totalement bloqué en cas de soucis.
EDIT: comme évoqué est ce qu'on est sûr que Tumbleweed ne sera pas impacté par ces changements?
Sauf que faire des snapshot ce n'est pas une solution valable pour moi. Leap et les release stable évitaient ce genre de problème en permettant de tester avant les montées de version et on sait quand on a besoin d'être dispo. Le fonctionnement est totalement différent.
En fonction de ce qui se passera je risque de devoir migrer sur une rolling release pas le choix malheureusement. :/ J'ai aussi une leap chez mes parents, là pour le coup je ne sais pas ce que je ferais. :/
Je transmets quelques infos suite à un échange avec @Guillaume_G sur Telegram. Le projet est à définir, il se lancera vraiment cet été. L’idée est bien d’avoir un système minimal complété par des logiciels conteneurisés via flatpak ou autre conteneurs afin de simplifier la maintenance. «Ça sera plus facile à gérer pour tout le monde. Aujourd'hui il y a des soucis avec python dans leap par exemple. Avec ALP, il ne devrait plus y avoir ce genre de soucis car chaque container pourra utiliser sa propre version »
merci pour l'info. Au final ça correspond à ce que j'imaginais. Et je trouve ça vraiment triste.
Au final quel sera l'utilité de choisir Leap/ALP face à Ubuntu ou encore fedora/Redheat qui prennent la même voie. :/ Si c'est pour faire ça une seule distribution utilisant les flatpak suffit.
J'avoue être vraiment déçu de la direction annoncée. J'ai quitté ubuntu justement à cause de ça. On n'aura donc plus que le choix entre des distribs rolling release ou alors des petites bases avec tout le reste en flatpak, et donc très peu de différences...
Tu as des infos sur l'impact potentiel sur tumbleweed? Tumbleweed est elle vraiment totalement indépendante de Suse?
J'avoue que si je dois passer sur une rolling release, je ne sais pas si j'aurais plus confiance en Tumbleweed par rapport à Manjaro.
En gros ce qui est sur: Il n'y aura pas de leap > 15.5 (donc il reste 2.5 ans pour voir). SLE 15. continuera à exister niveau patch, mais ça ne sera pas redescendu dans un "openSuse leap".
A côté de ça, une Suse ALP dont on ne sait pour l'instant trop rien va être le futur de SLE 15. Ils invitent donc les contributeurs à participer à "ALP" pour en faire ce qu'on veut, soit un futur "leap" si possible. La seule possibilité pour qu'une leap 15.6 arrive serait que Suse ALP soit en retard et donc qu'une version intermédiaire soit nécessaire, ce qui ne reste de toute façon que transitoire.
En l'état c'est donc totalement flou malheureusement.
