Cette espace vous permet de voir toutes les Voir les messages réalisées par ce membre. Vous ne pouvez voir que les Voir les messages réalisées dans les espaces auxquels vous avez accè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.
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
Les développeurs pensaient qu'il n'y avait pas beaucoup d'utilisateurs car il n'y avait pas beaucoup de rapports de bugs. Mais bon, visiblement ça marchait bien donc, pas de bugs
Ça sera très probablement redéveloppé à partir des changements dans KWin. Le ticket à suivre semble être celui-là.
On peut regretter cette suppression (probablement temporaire) mais ça m'attriste un peu de voir les commentaires dans les tickets. Je lis régulièrement des critiques sur le fait que certains développeurs ne sont pas sympas. Mais quand je vois que des utilisateurs font pression ("je ne mettrai jamais à jour tant que le cube ne sera pas revenu" ou "j'utilise KDE depuis la version 3 et ça va me faire arrêter d'utiliser KDE") voir méchant ("ce comportement ressemble à Windows ou Apple"), je comprends les développeurs qui finissent par répondre de manière cassante.
Cette minorité bruyante me fait vraiment halluciner.
Pour ma part, j'avais compris que les dépôts expérimentaux sont les dépôts "des équipes". Ce sont des dépôts "à thème". Par exemple, le dépôt "Education" dont parle Chalu est maintenu par l'ensemble des contributeurs intéressés par les logiciels éducatifs. En ce sens, ils sont théoriquement mieux maintenus que les dépôts "communautaires" où chaque dépôt est, en fait, le dépôt d'un individu. N'importe qui peut créer son dépôt communautaire. Par contre, n'importe qui ne peut pas créer un dépôt expérimental.
On ne reste donc pas bloqué sur une version de Tumbleweed en utilisant tumbleweed-cli. Cet outil a été créé pour faciliter la gestion des snapshots en facilitant, dans le cas d’un souci avec une mise à jour, le retour à une version choisie de snapshot. Toutefois si on utilise des dépôts externes, il faut aussi continuer à utiliser
je vois que chaque snapshot à un dépôt qui lui est propre
Pas tout à fait du point de vue de l'utilisateur. Chaque snapshot est une distribution de Tumbleweed complète. Mais, lorsque tu fais une mise à jour de ton système tu n'as pas besoin de changer ton dépôt. Les RPM de la snapshot se retrouve dans le repo-oss déjà configuré sur ta machine.
L'utilisation de tumbleweed-cli est totalement facultatif.
je crois comprendre que faire une mise à jour des paquets revient à changer de version.
Oui, tu fais une mise à niveau complète de ton système à chaque fois. Parfois c'est gros (genre, quand Plasma est mis à jour), parfois c'est beaucoup plus petit.
Cependant le "changement de version" est à relativiser. Oui, tu changes de numéro de version (le fichier /etc/os-release est effectivement modifié) mais ce n'est pas complètement comparable avec un changement de version sur Leap.
Sur Leap pour changer de version, tu dois d'abord changer les dépôts. Comme je l'ai dit plus haut, sur Tumbleweed, la nouvelle version est toujours dans le même dépôt. On utilise donc bien un "zypper dup" car on change de version, mais "c'est dans le flux" sur Tumbleweed.
Mais alors, si je ne change pas de version, est-ce que Tumbleweed se comporte comme Leap en faisant des mises à jour des paquets de la version en place ?
Non, si tu utilises l'outil tumbleweed-cli cité dans tes liens, cela va fixer ton dépôt sur une snapshot particulière de Tumbleweed. Dans ce cas, tu n'utilises plus le dépôt officiel de Tumbleweed qui évolue continuellement. Tu te fixes sur une snapshot particulière qui est périmée dès que la suivante sera publiée (et sur laquelle tu ne passeras pas puisque tu t'es fixé sur une snapshot).
En gros, tu n'auras plus de mise à jour dans ce cas.
En moins brutal, tu peux aussi configurer l'applet pour ne vérifier que mensuellement. Parce que je ne pense pas que tu puisses désactiver les mises à jour depuis l'applet.
Historiquement, toutes les dépêches autour d'openSUSE publiées sur LinuxFR étaient dans la section "SUSE". Le contenu autour d'openSUSE grossissant doucement mais sûrement et openSUSE étant indépendant de SUSE, j'ai demandé l'ouverture d'une section dédiée à openSUSE.
C'est donc désormais chose faite et l'administrateur s'étant chargé de la création a également déplacé le contenu openSUSE dans cette nouvelle section. Ce qui est très sympa de sa part.
Pour ceux qui voudront publier du contenu sur LinuxFR, n'hésitez donc pas à le faire dans cette section.
Mon seul gros reproche c'est que SLED est une distribution Gnome.
Je crois que ce n'est que depuis SLE 12 qu'il n'y a que GNOME 3. Dans SLE 11, il y avait GNOME 2 et KDE 4. D'après ce qui se dit, il semble que KDE était le choix par défaut à l'installation, mais j'avoue ne pas pouvoir confirmer. Aujourd'hui, pour avoir Plasma, faut passer par le Package Hub, dont les paquets sont officiellement non supportés par SUSE.
SLED a quelques modules qu'OpenSUSE n'a pas (le support natif et officiel de la connexion de certains iPhone et autres téléphones, il doit aussi y avoir quelques outils en plus). Distribution très stable mais celles et ceux qui veulent le dernier cri doivent rester sur OpenSUSE. SLED c'est avant tout pour les employés, très stable mais avec des paquets plutôt vieux.
Le coeur d'openSUSE Leap est aussi "vieux" que SLED de nos jours (puisque basé sur les mêmes sources). Les paquets communautaire, par contre, peuvent être effectivement assez récents.
SUSE édite SLE mais ce que tu télécharges sont des déclinaisons :
SLES pour les serveurs
SLED pour le desktop
SLES for SAP pour SAP
etc
Le prix est différent en fonction de la variante. Pour le desktop, c'est possible d'acheter (moins cher) avec juste la maintenance (les mises à jour) mais sans support.
Comme tu l'as constaté, il y a moins de paquets sur SLED que Leap. Mais tu as des reconstructions de paquets Leap pour SLE dans le Package Hub que tu cites.
Dans les différences, tu auras GNOME par défaut (et non Plasma) et des Services Pack pendant 10 ans (et non 3). De mémoire, les flags de compilation ne sont pas toujours les mêmes entre Leap et SLE ce qui implique que certains paquets n'ont pas tout à fait les mêmes fonctionnalités (à vérifier).
Allez savoir, mais j'ai laissé traîner mes dépêches pendant 6 mois... Je viens de reprendre/compléter la dépêche sur Leap 15.2 (basé, entre autre, sur votre traduction de l'annonce officielle ! Merci !) qui est désormais publiquement disponible ici.
Si vous voyez des grosses bêtises, n'hésitez pas à l'indiquer dans les commentaires en sourcant pour améliorer le contenu (ou faites le ici si vous ne souhaitez pas créer de compte sur LinuxFR, je pourrai poster moi-même)
Edit : contexte de l'écriture de ce message : je n'avais pas vu qu'il y avait une page 2 et une page 3 dans le sujet Donc, dites vous que j'ai répondu au dernier message de la page 1... Désolé !
J'avais compris que le problème des brevets chez openSUSE et Fedora est lié au fait que les projets n'ont pas de structure légale indépendante de SUSE et Red Hat (respectivement).
Ainsi, en cas d'entorse aux brevets dans ces projets, c'est directement SUSE et Red Hat qui se retrouveraient devant les tribunaux (américains surtout, car si j'ai bien compris, c'est principalement là bas que les brevets logiciels posent problème).
SUSE et Red Hat sont des entreprises qui fonctionnent bien (surtout Red Hat dont le chiffre d'affaire est énorme). Il y a donc plus de risques qu'ils se fassent embarquer dans une guerre de brevet. Une guerre des brevets n'a d'intérêt que sur des grosses entreprises qui ont les moyens.
Aujourd'hui, Mint et Elementary ne sont clairement pas dans la même court. (Edit : les Gentoo, Debian, Arch, Mageia, OpenMandriva sont soutenues par des fondations/associations, parfois européennes, à but non lucratif qui ne débordent pas de moyens que je sache)
Pour Canonical, tout ces trucs là sont dans le dépôt Multiverse qui n'est pas officiellement supporté par Canonical mais par la communauté. Et, comme tu l'indiques @Vigen , c'est une case décochée par défaut. Est-ce que ça suffit à déléguer la responsabilité sur l'utilisateur ? Je ne sais pas. Mais là encore, Canonical ne semble pas gagner beaucoup d'argent. Donc, est-ce que ça vaudrait le coup d'essayer de leur tirer un chèque ?
Dans tous les cas, je suis d'accord avec @Seb95Passionlinux ça rend l’interaction avec l'utilisateur complètement pourrie car difficile à expliquer. Vu de ma fenêtre, les brevets logiciels ressemblent plus à un racket organisé qu'à un mécanisme de protection des inventeurs. Je trouve cela profondément désolant et triste.
Donc, dites vous que j'ai répondu au dernier message de la page 1... Désolé ! 