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.
Pareil, comment ça se passe les updates? Les installations de paquets? Les imprimantes/scanners comment sont ils installées? A t'on des rpm? A t'on comme sous fedora silverblue ostree ou rpmstree (je sais plus trop son nom)?
La configuration comment c'est? La racine est elle LSB (classique) ou non LSB?
J'ai eu un coup de foudre pour la deuxième fois sur Nixos, une fois lors de mon 1er essai en 2021 et la sur la version 22.11. C'est comment par rapport à cette dernière?
Tumbleweed pour mon pc perso et principal, pas de soucis, j'ai la fibre, le pc est récent et supporte le btrfs sans ralentis. C'est une autre paires de manches pour les machines de la "famille externe", par exemple chez mes parents, ça ne va pas être possible.
Je pense de plus en plus à Nixos au lieu de Debian, je teste sur un portable et c'est très bon, faut penser à des trucs qui sont automatiser par ailleurs mais une fois oublié ses habitudes c'est bon, ça me donne espoir dans ce que pourrait être ALP et du coup faut vraiment se donner le temps de voir. Par exemple silverblue de fedora pas la peine, ça sera pas possible pour mon entourage, déjà sur ma machine de 2009 ça ne veut pas s'installer!!! Je vais encore retenter mais j'y crois pas des masses.
J'ai quand même hate de voir cette ALP en fonction car SUSE et openSUSE m'ont toujours habitué de faire les choses biens, même quand c'est vraiment mal parti (openSUSE 10 était une merde par rapport à SUSE 9.3). Sinon, je tenterai la Nixos qui s'est simplifié et dont j'ai compris certaines de mes lacunes, notamment le disque externe, faut ajouter le support de ntfs (truc que j'ai zappé tellement habitué que la distribution le fasse automatiquement), les pilotes d'imprimantes et scanners sauf que cette fois en plus il faut spécifier qu'on veut démarrer les services en rapport... Le truc qui est pas mal c'est un fichier que je vais pouvoir partager et adapter dans les grandes lignes pour toutes les machines de mon entourage, fini les configurations post installation.
J'espère juste que ALP partira plus vers ce que fait nixos et son fichier unique de conf que ce que fait fedora.
Sinon, Mageïa, c'est cool. Comme Debian, Fedora, Manjaro, Mint, MX, etc... Mais openSUSE c'est mieux !
Je confirme !!!
Sinon plus sérieusement, faut voir ce que ALP va donner, ça sera peut être une bombe, maintenant ce que je comprends c'est que la communauté va être en charge de tumbleweed et le alp sera plus SUSE.
OpenSUSEAux alentours de 2017, j’ai découvert la distribution OpenSUSE Leap pour mes postes de travail. Cette distribution offre un mix assez intéressant entre un système de base constitué des paquets de la version entreprise SUSE Linux Enterprise et une sorte de modèle semi-rolling par-dessus cette base stable. J’ai utilisé OpenSUSE Leap sur tous mes postes de travail – ainsi que ceux de mes clients – pendant près de cinq ans, jusqu’en été 2022. OpenSUSE offre sans doute une des implémentations les plus propres de KDE, et Leap est un système qui JusteMarche(tm).
HarakiriDans le monde de l’informatique on assiste parfois à un drôle de phénomène, qui ressemble étrangement au mythe de Sisyphe. Dès qu’un projet arrive à maturité, les développeurs décident de tout casser pour repartir à zéro, en remplaçant un système qui fonctionne parfaitement (GNOME 2.32, KDE 3.5.10, PC-BSD) par une abomination truffée d’une forêt de bugs ou autrement inutilisable (GNOME 3.0, KDE 4.0, TrueOS). Apparemment c’est le cas pour OpenSUSE Leap, qui cessera d’exister dans sa forme actuelle à partir de la version 15.5 pour être remplacé par ALP (Adaptable Linux Platform). La politique de communication du projet OpenSUSE à ce sujet est assez erratique, et la seule chose qui est sûre, c’est que l’avenir de Leap est plus qu’incertain.
J’ai tenté l’expérience Tumbleweed, la variante rolling release d’OpenSUSE dont l’avenir semble assuré, mais au bout de même pas deux mois d’utilisation, je tire la conclusion que cette distribution ne me correspond vraiment pas. La cadence des mises à jour est tout bonnement infernale, avec des milliers (!) de nouveaux paquets toutes les semaines. La conclusion que j’en tire, c’est que je hais les cibles mouvantes et que je préfère de loin les solutions entreprise avec des mises à jour à faible risque pendant quelques années.
C'est plus ou moins ce que je pense de la situation, vu la popularité de leap c'est assez casse gueule ce que tente le projet.
Pour la vitesse des dépôt et de zypper, c'est un des gros défauts d'opensuse je trouve. Les dépôts ne sont pas rapides et zypper est clairement plus lent. Quand je vois le temps qu'il faut pour mettre à jour une debian/ubuntu en comparaison ou encore une arch/manjaro c'est ultra flagrant. Sur leap c'est pas trop grave mais sur tumbleweed et ses grosses majs ça se sent passer.
J'ai toujours trouvé zypper rapide, il est censé l'être car il est dans un langage compilé comme rust ou go, alors que les autres sont en perle, ruby ou encore python. Mais c'est vrai que depuis la série 15, je trouve zypper lent mais c'est plus a cause des rpm-delta (je trouve) et surtout de la lenteur des débits des dépôts qui sont 4 fois moins rapides que d'autres. Des fois je suis à peine à 12mo/s alors que ma fibre dépote... Je mets plus de temps pour télécharger des paquets que pour télécharger une iso DVD d'openSUSE...
Citer
Oui, les Debian/Arch sont plus rapides mais est-ce un vrai critère ?
Pas du tout mais ça rallonge le temps des updates, surtout ça donne une lenteur à zypper alors que c'est peut être pas lui la cause. DNF est décrié par bons nombres de personnes pour sa lenteur.
Citer
Pour tumbleweed on peut tester MirrorCache,trouvable sur software opensuse et censé ɓooster les majs en trouvant les meilleurs miroirs. Je n'ai pas testé,étant sous leap auquel MirrorCache n'est pas disponible.
Ah c'est super ça, faut que je teste, si tu veux c'est dispo dans expérimentale pour leap.
Citer
Oui enfin, on est loin du 0 pb de leap quoi. :/ ça nécessite de prévoir du temps de dispo derrière et ça c'est chiant.
Oui mais c'est bien moins casse bonbon que le saut de version annuelle.
Citer
Et brfs + snapshot ça ralenti quand même la chose, même si sur des machines puissantes c'est mois flagrant ça reste le cas. :/ C'est un filet mais qui ne devrait pas être nécessaire et qui confirme du coup que tumbleweed n'est pas équivalent à leap niveau stabilité.
Non sur des machines actuelles ça ne se voit pas, sur mon pc de 2019 c'est invisible et je ne ressens même pas que c'est activé et c'est pas une machine de guerre... Par contre sur des machines de 2009 alors la c'est autre chose, mais j'ai pas retenté, peut être qu'il y a eu des améliorations...
C'est un filet qui est plus que le bienvenue et qui devrait être partout, c'est pas pour rien que même debian stable l'a aussi. Et il est aussi le système de fichier par défaut de leap sauf que vu que celle-ci est moins bougeant, il y a moins de risque. Mais reste les sauts de versions qui peuvent très bien mal se passer.
Citer
Bah, justement. Tumbleweed est d'une stabilité impressionnante car je n'ai jamais - je dis bien jamais - foiré de mise à jour.
Pareil!!! C'est la plus stable des rolling, la plus solide... Depuis juillet 2021 je n'avais pas fait les updates de ma tumbleweed de mon portable, pour justement testé, j'ai fait ça en début de ce mois, je pensais que ça allait casser, poser au moins un soucis, RIEN, RIEN, sans brancher il a fait les updates sans rien dire sans râler, je savais que Debian stable le faisait car j'avais testé mais là une rolling le faire, de plus je n'étais pas en btrfs mais en ext4 car machine de 2009...
Citer
Les éventuels changements dans les fichiers que tu décris ne sont pas répercutés immédiatement sur des logiciels en cours d'utilisation mais seulement à leur réouverture. De même pour les bibliothèques système.
D’où les redémarrages demandés. Non le seul hic a mes yeux c'est la vitesse des dépôts, mais est-ce vraiment si problématique?
Tien nous au courant sur la stabilité de la chose. Tu es en BRFS ou en ext4?
Perso je pense que je ferais leap 15.5 et après je verrais ce que je fais. Tumbleweed n'est de toute façon pas une solution pour mes parents.
C'est stable, c'est ce que je mets chez moi, même en ne faisant pas les updates pendant un long moment (j'avais oublié un portable qu'il était sous tumbleweed, je le pensais sur Leap, 6 mois plus tard j'ai plus de 4000 updates, qui se sont tous finis tranquillement...). Alors sur des machines récentes BTRFS est un vrai plus avec les snaphots, ça permet de revenir en arrière si une update merde, la grande classe... Sur des machines plus vieilles, les miennes datent de 2009, ça commence à se faire sentir les maintenances de btrfs et les snapshots, donc je reste en ext4, c'est stable mais si ça merde bah suis obligé d'attendre que l'orage passe. Maintenant, ça fait un moment que je n'ai pas testé sur ces dites machines, le système de fichier BTRFS donc ça a changé certainement.
Le seul hic, c'est le nombre de mises-à-jour dans la semaine, bien qu'en ce moment c'est calme, mais ça peut aller très vite et il faut une bande passante rapide, la fibre est le top pour une rolling. Exemple:
openSUSE Tumbleweed 20220613-0 -> 20220616-0 2272 paquets à mettre à jour, 76 nouveaux. Taille de téléchargement totale : 3,58 GiB. Déjà en cache
Maintenant, de mon coté le seul soucis que j'ai c'est la vitesse de téléchargement de zypper, je ne dépasse pas les 40mo/s, tout comme Fedora avec des changements de conf pour apporter plus de vitesse, chose que je ne fais pas sous openSUSE car je ne vois pas quoi changer. Alors 40mo/s c'est rapide, surtout si on compare avec de l'ADLS, mais pour comparer, sous Debian je suis dans les 120mo/s.
Là j'attends encore 15.5 pour mes parents, puis après ça sera tumbleweed, à moins que ALP soit une bombe mais je n'y crois pas plus que ça sur de vieilles bécanes, si c'est comme NIXOS qui est super mais qui demande des actions qui sont automatiques chez les distributions classiques comme pour monter ses disques, ses imprimantes, ect... Je ne sais pas trop comment goupiller ça si Tumbleweed parait trop lourd pour cette bécane (2010) et puis je ne suis pas tous les jours la-bas, donc le nombre d'updates me fait un peu peur. Mais on verra bien, peut être que ALP sera le linux qui fera de notre OS la pépite tant attendu, qui fera aussi en sorte de popularisé notre caméléon! Par contre testé siverblue de Fedora et rien ne m'enchante, j'ai trouvé la chose compliqué pour mettre à jour surtout par rapport à NIXOS...
Citer
Techniquement tu peux déjà le faire ça, si tu mettais une centos, ou une almalinux + du flatpak ben tu peux déjà avoir ça. Tu peux faire ça sur toute base "stable", même debian.
Effectivement, c'est ce que je fais avec Debian, pas avec leap car on a des dépôt "experimental" et donc le besoin ne se fait pas sentir par rapport à Debian où on a rien dans ce sens pour combler.
Citer
Perso j'ai vraiment du mal à voir la plus valu de l'ensemble, vu qu'au final tu auras très peu voir pas de différence avec les distributions qui suivront cette même logique vu que le "packetage" c'était vraiment ce qui fait la différence entre les distribs (ainsi que les choix de versions).
C'est une mentalité business, rien de plus, c'est pas pour rien que pour le moment ce sont principalement les distributions affilées/sponsorisées par une entreprise qui doit gagner des capitaux qui nous balancent ça. En fait, de ce que je comprends, il y a pénuries de mains pour packager, ça serait une des solutions qui permettrait de faciliter la vie puisque seule le cœur serait à la charge des devs. Bref, il y a certainement des personnes qui seront plus à l’affût des véritables raisons.
En tout cas, j'espère que ça sera un succès fracassant, car c'est un gros risque étant donné la popularité de Leap, c'est presque quasi le double de la popularité de tumbleweed, d’après les chiffres du projet. (https://metrics.opensuse.org/d/osrt_access/osrt-access?orgId=1)
Le seul hic dans l'histoire, c'est que encore une fois, ils imitent Fedora et redhat, c'est pas plus mal, sauf qu'eux ils gardent pour le moment leurs stable qui est une quasi rolling pratiquement tellement qu'elle bouge mais qui reste quand même moins bougeant que tumbleweed, j'entends par là qu'il y aura pas 3000 updates en une semaine, sauf lors du changement/saut de version. Chez nous Leap disparait au profit de ce que va etre ALP, sauf que ça sera plus lourd qu'une distribution classique (flatpack oblige), que tumbleweed est aussi plus lourd car besoin de btrfs pour se sécuriser, donc dans un cas comme dans l'autre, il y aura des personnes qui seront obligés de changer de crémaillère. J'espère me planter sur ça, en tout cas je la testerais quand elle sera prête en condition réelle là où en tant normal c'est une leap pour me faire une idée... Et puis sinon je changerais déjà pour voir tumbleweed ce que ça donne pour mes parents, puis si trop lourd (btrfs+maintenance de btrfs +les updates en continue...) je changerais encore pour du deb, je sais pas trop, peut être Debian, ou encore Ubuntu et pourquoi pas Devuan.
Oui ou pas car en effet openSUSE nous a habitué de faire des trucs bons, le soucis c'est plus la lourdeur qui me fait peur, j'ai pas mal de pc de 2009, je ne peux pas mettre btrfs et les snapshots a cause de la lourdeur ressentie et pour le coup j'ai un peu peur pour ALP. Pas grave on verra bien
J'espère me tromper mais j'ai l'impression qu'ils sont en train de dire que tumbleweed deviendrait une sorte de brouillon, du moins l'endroit où se développera le reste. Ce que j'aime chez tumbleweed c'était justement cette solidité et ce même dans leur rolling. Je croise les doigts.
Tumbleweed est déjàla version de développement. Le flux actuel (simplifié), c'est Factory (que personne ne peut vraiment installer, si j'ose une comparaison : c'est comme experimental chez Debian ) > Tumbleweed (qui est une photo de Factory automatiquement testée par OpenQA) > SLE/Leap
Non c'est factory la version de dev, le paquet va dans factory puis ça descend après vérification dans tumbleweed, même que dit comme ça c'est aussi faux, de ce que je vois quand je fais un paquet (maintenance de paquets pour opensuse) c'est dans les dépots "expérimentaux" par exemple editor ou game, puis ça va dans factory et enfin dans tumbleweed. Je le vois bien avec les paquets que je balance (responsable ou mainteneur), on me demande ensuite de valider pour factory.
Distributeurs entrant dans Flatpakland Par Jonathan Corbet
Les distributions Linux ont beaucoup changé au cours des 30 dernières années, mais la façon dont elles conditionnent les logiciels est restée relativement statique. Alors que les formats .deb et RPM (et autres) ont évolué avec le temps, leur forme actuelle ne serait pas méconnaissable pour leurs créateurs. Cependant, les distributeurs poussent au changement. Les projets Fedora et openSUSE s'efforcent de réduire le rôle du vénérable format RPM et de passer à Flatpak pour une grande partie de leur distribution de logiciels ; cependant, certains utilisateurs ont du mal à convaincre que c'est une bonne idée.
Un paquet binaire traditionnel d'une distribution contient le programme qui vous intéresse, bien sûr, ainsi que tous les fichiers supplémentaires dont il a besoin. Le package contient également des métadonnées décrivant, entre autres, quels autres packages doivent être installés pour que le programme fonctionne. Le gestionnaire de packages de la distribution utilise ces informations de dépendance pour s'assurer que chaque package est correctement installé.
Le format Flatpak a été décrit comme "juste un autre format de distribution" et, dans une certaine mesure, c'est vrai. Un package Flatpak (ou, simplement, "un flatpak") a tout ce qu'un package .deb ou RPM aurait, mais il existe des différences significatives. Peut-être en haut de la liste se trouve la façon dont les dépendances sont gérées. Un package traditionnel aura une liste (éventuellement longue) indiquant tous les autres packages nécessaires ; un package Flatpak, à la place, listera un seul "runtime" contenant l'ensemble de base des bibliothèques sur lesquelles le package est construit. S'il existe des bibliothèques ou d'autres dépendances qui n'apparaissent pas dans l'environnement d'exécution de votre choix, elles sont simplement regroupées avec l'application dans son flatpak.
Cet arrangement a un certain attrait pour les conditionneurs. L'approche "runtime plus bundling" simplifie la gestion des dépendances, et la possibilité de regrouper des versions corrigées du système ou des bibliothèques d'exécution est appelée en tant que fonctionnalité Flatpak. Un package créé pour un runtime donné peut être installé sur n'importe quel système sur lequel ce runtime est installé, ce qui permet de créer un seul package pouvant être installé sur plusieurs distributions. Les distributeurs peuvent ainsi utiliser ce format pour se simplifier la vie ; les fournisseurs de packages propriétaires voient également un charme évident dans cette idée.
Dans un sens, Flatpak a entrepris de résoudre bon nombre des mêmes problèmes que l'effort malheureux de Linux Standard Base résolu il y a de nombreuses années.
Flatpak est conçu pour fonctionner avec des distributions construites autour d'un noyau immuable ; il ne s'installera pas dans les répertoires système comme /etc ou /usr/bin . Cela le rend attrayant pour les distributeurs qui essaient de créer ce type d'offre.
Un autre argument de vente clé pour Flatpak est le mécanisme de bac à sable intégré. Les applications installées avec Flatpak seront, par défaut, exécutées dans un conteneur qui n'a pratiquement aucun accès au système sous-jacent ou à Internet. Grâce à des déclarations dans le fichier manifeste utilisé pour créer le package, une application spécifique peut demander l'accès, par exemple, aux fichiers locaux de l'utilisateur, à Internet ou au serveur du système de fenêtres. En théorie, au moins, ce bac à sable rend l'installation des packages plus sûre et limite les dommages pouvant être causés par un package compromis ou malveillant.
Flatpak n'est pas sans critiques. Bien que les packages puissent partager le même environnement d'exécution, rien n'empêche une prolifération d'environnements d'exécution et de versions ; cela semble déjà se produire dans une certaine mesure. Les runtimes et les packages eux-mêmes sont volumineux, ce qui augmente considérablement la quantité d'espace de stockage et de mémoire consommée. Il est courant que les applications demandent l'accès aux fichiers locaux et à Internet, qu'elles en aient besoin ou non, au point que certains voient les affirmations du bac à sable de Flatpak comme étant plus exagérées que la réalité.
Tout cela s'ajoute à une certaine opposition à l'utilisation de Flatpak. Il semble également possible qu'une grande partie de l'opposition à Flatpak puisse résulter d'une résistance instinctive à changer la façon dont les choses ont toujours été faites.
Flathub (non) filtré de Fedora
Du côté de Fedora, la discussion a été attisée par cette proposition de modification de Fedora 37 supprimant les filtres actuellement appliqués au référentiel de packages Flathub dans l'application logicielle GNOME de Fedora . Une fois le filtre supprimé, tous les packages disponibles sur Flathub, y compris ceux contenant des logiciels propriétaires ou des programmes qui, pour des raisons telles que des problèmes de brevets, ne peuvent pas être livrés avec Fedora, seront disponibles pour être installés. Flathub dans son ensemble sera toujours désactivé, à moins que les utilisateurs n'activent les référentiels tiers.
On dit que les avantages de ce changement sont qu'il rend plus de logiciels facilement disponibles pour les utilisateurs de Fedora et rend ce logiciel plus sûr en le mettant en bac à sable. Cette dernière raison fait partie des raisons pour lesquelles l'outil logiciel GNOME préférera les flatpaks aux packages RPM traditionnels lorsque les deux sont disponibles. Mais il y a des membres vocaux de la communauté Fedora qui sont fortement opposés à l'idée. Vitaly Zaitsev, par exemple, s'est plaint de la préférence pour les flatpaks, affirmant que cela amènerait les flatpaks à remplacer les packages RPM lors de la mise à jour d'un système. Un grand nombre des points mentionnés ci-dessus - la taille de l'installation et les bacs à sable poreux, par exemple - ont été soulevés dans cette discussion, tout comme le parti pris perçu contre le référentiel RPM Fusion, qui a été discuté en profondeur ici en juin.
Il semble peu probable que ces objections arrêtent le non-filtrage de Flathub - ou la transition vers Flatpak en général. La distribution semble engagée dans cette direction, et la variante Silverblue , qui est construite autour d'une installation de base immuable, nécessite déjà Flatpak. Au cours de la discussion, Michael Catanzaro a vanté les avantages de sécurité du format et a souligné que, malgré des années de plaintes, les opposants à Flatpak n'ont pas proposé d'alternative viable offrant des avantages de sécurité similaires. Richard Hughes a fait valoir que " "les flatpaks sont dans presque tous les cas ce que les utilisateurs devraient utiliser" ". À moins que quelque chose ne change, il semble que le futur Flatpak de Fedora avance à toute vitesse.
Les ALP d'OpenSUSE sont plats
En avril, SUSE a annoncé un effort connu sous le nom de "plate-forme Linux adaptable" (ALP) qui est, d'une certaine manière, destiné à définir l'avenir de la distribution SUSE Linux Enterprise (SLE). Il y avait beaucoup de texte sur la façon dont le processus serait ouvert, mais les observateurs extérieurs pourraient être pardonnés de penser que l'ALP reste assez trouble jusqu'à présent. Il n'y a pas encore beaucoup d'informations publiques sur ce que sera ALP ou comment cela affectera les offres d'entreprise de SUSE ou openSUSE. Les indices qui sont sortis, cependant, suggèrent une distribution construite sur un petit noyau immuable avec des applications gérées séparément, très probablement en utilisant un format comme Flatpak.
Le 5 juillet, Dan Čermák a publié le procès-verbal d'une réunion du groupe de travail ALP qui portait sur « à "quoi ressemblera le bureau ALP et comment nous pouvons dissiper les craintes concernant les flatpaks et les conteneurs en ce qui concerne le bureau ALP" ». Le procès-verbal note que Flatpak sera effectivement utilisé comme format de distribution, mais souligne qu'il ne serait pas nécessaire d'installer des flatpaks à partir de sources externes comme Flathub ; " "le modèle d'emballage ne changera pas, seul le format" ".
Interrogé sur les avantages du passage au flatpak, Čermák a mentionné le mécanisme de sandboxing, mais a déclaré que le principal avantage résidait dans la réduction du travail d'emballage. Les applications de bureau telles que Firefox ou LibreOffice pourraient être construites une fois sur la distribution openSUSE Tumbleweed , puis expédiées pour Tumbleweed, Leap , ALP et probablement tout ce que SUSE pourrait créer. Il n'est pas difficile de comprendre pourquoi les distributeurs sont attirés par une option qui pourrait réduire considérablement la quantité de travail nécessaire pour maintenir les packages actuels d'applications complexes.
Il y avait également une opposition fondamentale à l'utilisation de Flatpak dans la communauté openSUSE. Robert Kaiser, par exemple, a déclaré " "s'il ne reste plus de distribution basée sur RPM sans cet emballage étrange comme flatpak, il est probablement temps de revenir à Windows" ". Dans l'ensemble, cependant, la communauté openSUSE semble moins agitée par la perspective - jusqu'à présent du moins. Il peut y avoir plusieurs raisons à cela, notamment un manque relatif d'expérience avec Flatpak dans la communauté openSUSE et la nature amorphe d'ALP en général. Mais cette assurance de Čermák ne peut qu'aider aussi :
Tumbleweed sera le lieu où le développement aura lieu, mais il n'est pas prévu de modifier fondamentalement Tumbleweed. Vous pourrez toujours utiliser Tumbleweed comme vous l'utilisiez auparavant. De plus, vous pourrez utiliser les "trucs conteneurisés", mais vous n'aurez pas à le faire, du moins dans un avenir prévisible.
Il pourrait bientôt arriver un moment où l'utilisation de Flatpak sur Fedora est inévitable, du moins lorsqu'il s'agit d'installer certaines applications complexes. Jusqu'à présent, openSUSE ne semble pas aller dans cette direction, donc les utilisateurs de Tumbleweed (qui constituent une grande partie de la communauté openSUSE) n'ont pas à craindre d'être poussés contre leur gré dans le monde Flatpak.
Il ne faut pas sous-estimer la valeur de ce dernier point. Une grande partie de l'amertume autour de la transition systemd était certainement causée par le sentiment qu'elle était imposée aux utilisateurs qui étaient satisfaits de leur configuration existante et ne ressentaient pas le besoin de changer. Même si Flatpak est aussi bon que certains le prétendent, une transition mal gérée risque de créer des niveaux de mécontentement similaires.
Cette transition semble susceptible de se produire ; dans une publication ultérieure , Čermák a remis en question la valeur de l'emballage de certaines applications complexes et a suggéré qu'elles ne puissent être mises à disposition que sous forme de flatpak si elles sont expédiées par la distribution. Robert Schweikert a dit plus succinctement : « "Ce que nous avons aujourd'hui a fonctionné raisonnablement bien pendant probablement environ 30 ans, mais le modèle montre certainement son âge" ». Évoluer pour répondre aux besoins actuels est exactement ce que les distributeurs doivent faire, et cette évolution apportera sûrement des changements visibles pour les utilisateurs finaux. La clé sera de gérer les changements avec sympathie pour ces utilisateurs et, espérons-le, d'éviter certaines des turbulences que nous avons vues avec les changements passés.
J'espère me tromper mais j'ai l'impression qu'ils sont en train de dire que tumbleweed deviendrait une sorte de brouillon, du moins l'endroit où se développera le reste. Ce que j'aime chez tumbleweed c'était justement cette solidité et ce même dans leur rolling. Je croise les doigts.
Je viens de lire la traduction du lien donné plus haut, je pense que je vais arrêter simplement openSUSE car de ce que je comprends:
Citer
Tumbleweed sera le lieu où le développement aura lieu, mais il n'est pas prévu de modifier fondamentalement Tumbleweed. Vous pourrez toujours utiliser Tumbleweed comme vous l'utilisiez auparavant. De plus, vous pourrez utiliser les "trucs conteneurisés", mais vous n'aurez pas à le faire, du moins dans un avenir prévisible.
J'ai testé de mon coté microos, je suis pas fan, j'ai pas été loin car j'ai pas vu yast et par la suite j'ai lu que yast pour le moment n'y est pas disponible, du coup je ne vois pas l'interêt d'une distribution openSUSE sans Yast... Fedora pareil qu'est ce qui se passe avec les deux distributions RPM? Autant que la 36 classique est top et me plait pas mal, autant que la silverbluetruc-comme-ça me botte pas du tout.
Ubuntu est dans le déni elle aussi, mettre firefox en snap c'est juste mettre une application qui du temps normal est assez lourde et lente et là on la rend encore plus lente à se lancer. Sur un pc récent ça va mais sur un pc sans sdd c'est pas la même chose...
Citer
Le côté obèse est un des défauts majeurs de l'évolution en cours ...Ce qui m'inquiète principalement c'est que les distributions majeures semblent, d'après ce que je lis ici, toutes s'orienter dans ce modèle. Je suis preneur du nom de celles qui ne le feraient pas.
Pour le moment et on va encore me taxer de vouloir récupérer du monde pour "mon écurie", Debian ne part pas sur ce concepts, slackware, gentoo, arch, ... En faite c'est celles qui sont sous la coupe de sociètés ayant besoin de monétiser qui poussent vers ce sens et surtout les 2 RPM. Deepin il me semble part la dessus aussi.
Sinon une de pas mal dans ce délire là c'est la NIXOS, à part que je me retrouve pommé pour pas mal de truc, l'ensemble est vraiment pas mal.
Merci Chumi, j'ai voulu tester en live sauf que non il doit être installé donc faut que je trouve le courage de le passer sur une autre machine que ma principale
Alors j'ai pas tout pigé, mais me semble t'il que la base est un contener en lecture seule, puis on ajoute par dessus des flatpaks et aussi des rpms si j'ai bien pigé.
Je vais prendre le courage de tester la silverblue de fedora, je dirais ici ce que je pense mais je vais pas aller loin avec.
