openSUSE 11.0 : nouvelle mouture du caméléon disponible

Posté par . Modéré par Christophe Guilloux.
0
19
juin
2008
Suse
Ce jeudi 19 juin, après 10 nouveaux mois de gestation, la nouvelle version de la distribution soutenue par Novell est disponible au téléchargement. Cette nouvelle version d'openSUSE propose en standard :
  • Un noyau Linux 2.6.25.4, une glibc 2.8 branch, gcc 4.3 branch, D-Bus 1.2.1 et X.org 7.3
  • Côté utilisateur NetworkManager 0.7svn, PulseAudio 0.9.10, Alsa 1.0.16, ConsoleKit 0.2.10, PackageKit 0.2.1 et PolicyKit 0.7
  • Ainsi que Samba 3.2pre2, CUPS 1.3.7, AppArmor 2.3, Xen 3.2.1 RC1
  • Et pour les développeurs Perl 5.10, binutils 2.18.50 SVN, gdb 6.8, libzypp 4.23.0 et cmake 2.6
Outre quantité d'autres nouveautés et améliorations usuelles, cette version introduit une amélioration très attendue : le système de paquets ZYpp couplé à un solveur booléen, se profilant comme une nouvelle approche pour la gestion des paquets sous Linux.

openSUSE 11.0 est disponible pour architecture x86, x86_64 et PPC, en version 2 Live-CD ou 1 DVD. Une version boîte contenant un 1 DVD double couche (x68, x86_64) et un DVD source sera prochainement proposée à la vente (60 €). Innovante, intégrant aussi bien les bureaux GNOME que KDE avec une finition professionnelle et léchée, la distribution openSUSE se présente comme une très bonne alternative parmi les distributions ciblant l'utilisateur final, qu'il soit débutant ou utilisateur averti. La distribution openSUSE, mal connue du public francophone, propose comme à son habitude une grande quantité d'améliorations qui raviront ses utilisateurs :
  • Une intégration poussée de KDE 4.0, par un gros travail sur la branche "KDE-opensuse", développée en parallèle de la branche principale. Outre un look par défaut à la sauce openSUSE, un travail sur la stabilité de KDE 4.0.4 a été fait via le backport de plusieurs patchs et de certaines fonctionnalités de la branche 4.1.x, ceci afin de garantir un fonctionnement optimal de cette version somme toute "risquée".

  • Une amélioration conséquente sur la procédure d'installation. L'objectif pour cette mouture est dessiné sur 3 axes principaux : une installation plus simple, plus sexy et plus rapide.
    • Plus de simplicité, par un gros travail sur l'interface. Un regroupement de certaines étapes, une meilleure séparation des tâches d'installation et d'administration, permet au nombre d'étapes nécessaires de passer d'une vingtaine (!) à 8. Également, les supports d'installation sont totalement revisités. Les 5 ou 6 CDs traditionnels sont désormais remplacés par 2 Live-CD (version KDE 4 ou Gnome). Le DVD et l'ISO "net install" sont toujours disponibles. L'installateur des Live-CD propose un maximum d'options pré-sélectionnées par défaut, tandis que l'installateur DVD connaît également une réduction d'étapes, tout en restant très flexible et complet. Ce dernier propose le bureau KDE 3.5.9 en addition des bureaux KDE 4.0.4 et Gnome 2.22.1.
    • Plus de sex-appeal, par le passage des outils maisons à Qt4. L'installateur (sur le DVD) connaît une toute nouvelle jeunesse, via un nouveau thème gris-vert attractif. Les front-end YaST en version Qt et SaX profitent aussi de plus de légèreté grâce à la bibliothèque revisitée de TrollTech.
    • Plus de rapidité, grâce au nouveau gestionnaire de paquets et au passage à la compression lzma. Outre un temps de décompression des RPMs moindres, ceux-ci sont plus petits et donc plus nombreux sur les médias. Le temps d'installation d'openSUSE, historiquement conséquent par rapport aux autres distributions, la place désormais dans le peloton de tête (20 minutes pour l'install DVD par défaut, une dizaine pour l'install via Live-CD).

  • On note également une plus forte séparation des logiciels non libres, par l'éradication des logiciels non-oss (non-Open Source Software) du support DVD. Le CD optionnel non-oss est cependant toujours disponible séparément en téléchargement. Aussi, l'intégration des dépôts externes (dépôts communautaires et Build Service) au sein de la distribution est renforcée.
Cette version 11.0 introduit, comme énoncé, une nouvelle version de ZYpp, le système de gestion des paquets d'openSUSE depuis quelques versions. Se différenciant des outils similaires tels que Apt ou Yum, le gestionnaire ZYpp utilise une nouvelle approche pour la résolution des dépendances et veut poser un nouveau standard en termes de fiabilité et de performances.

Rappel des faits menant à ZYpp :
  • Suite à ses rachats consécutifs de Ximian et SuSE GmbH, Novell décide de fusionner les systèmes RedCarpet et YaST package manager à son système Zen Management Network, destiné à la gestion de grand parc hétérogène. Alors que le gestionnaire résultant, ZYpp, fonctionne bien sur les produits Entreprise avec le démon ZMD, il n'était pas très bien adapté à une distribution grand public, débouchant sur un "fiasco" total : la version openSUSE 10.1 sortit avec un système de paquets fonctionnant très mal à l'origine. Ned (ou "Novell Entropy Departement") était né dans la communauté openSUSE.
  • La version 10.2 corrigeait tant bien que mal les défauts de cette version "ratée" à l'aide de la bibliothèque revisitée libzypp v2, et ZMD fut finalement supprimé définitivement de la version 10.3 d'octobre dernier et réservé uniquement à la version Entreprise. Tandis que ZYpp v3 munissait openSUSE d'un gestionnaire de paquets de niveau équivalent aux autres systèmes de gestion de paquets existants, il souffrait néanmoins de quelques défauts dans son implémentation qui limitait ses performances.
  • En mai 2007, à l'occasion de la "29th International Conference on Software Engineering" ont été publiés les résultats du solveur expérimental OPIUM ("OPtimal Package Install/Uninstall Manager"), une première implémentation dans un système linux d'un solveur SAT (Boolean satisfiability problem). Ce nouvel outil est destiné à combler les déficiences, parfois inacceptables, des solveurs de dépendances traditionnels tels que Apt[1]. Le solveur SAT, issu de la théorie de la complexité[2], travaille fondamentalement différemment de ceux-ci (voir [3] pour le fonctionnement de l'algorithme d'Apt et Aptitude). Alors qu'ils doivent gérer un compromis entre la rapidité de la résolution du problème de dépendances et la qualité de cette même solution, le solveur SAT est complet : il ne trouve pas une solution possible, mais il trouve la meilleure solution possible dans un temps très raisonnable.

Cependant, cette implémentation pour gérer un système Linux n'est pas optimisée : bien qu'il soit beaucoup plus fiable qu'Apt, OPIUM est aussi plus lent, puisque ses concepteurs se sont concentrés avant tout sur la démonstration de la qualité des solutions de l'algorithme. Prenant parti de la Hackweek de Novell en juin 2007 (semaine d'"Innovation libre" pour les employés), des résultats du solveur OPIUM ainsi que des outils serveurs debcheck/rpmcheck[4], Michael Schröder, employé à Nürnberg, démontra la faisabilité de l'implémentation d'un tel solveur dans libzypp, bien meilleur que celui alors implémenté dans libzypp. Les autres membres de l'équipe ZYpp se sont alors occupés à stabiliser et optimiser ZYpp v3 pour la sortie de la 10.3, avant de travailler sur ce nouveau solveur.

Après quelques mois de travail, les résultats se montrent plus qu'encourageants : les tests de performances de ZYpp v4 par rapport à YUM et Smart, sur la même machine, sont éloquents (voir [5] pour quelques graphiques très parlants) et les "use-case" de Smart[6] sont correctement gérés. Une autre particularité étonnante de ce nouveau ZYpp est sa capacité à invoquer des recommandations matérielles de paquets. Besoin d'installer une nouvelle webcam ? Un simple branchement du matériel et un "zypper update" en ligne de commande (ou via YaST) et ZYpp va essayer de récupérer les bons drivers des dépôts onlines.

Ainsi, ZYpp v4 est la première implémentation opensource d'un solveur "de production" exprimant les problèmes de résolution des dépendances comme un problème SAT. Il permet une fiabilité optimale et est capable de résoudre des situations où apt et yum échouent, tout en étant doté de très bonnes performances d'exécution, en particulier sur la consommation mémoire.

ZYpp se veut d'être un projet indépendant de la distribution openSUSE :
  • Il respecte donc une certaine interopérabilité[7] avec le "standard de fait" yum, et peut être utilisé avec d'autres distributions : l'interface graphique PackageKit implémente un backend ZYpp complet. Prenant partie de la souplesse de l'openSUSE Build Service, le gestionnaire de paquets ZYpp est dès à présent disponible pour la distribution Fedora, et des paquets pour Mandriva Linux[8] sont aussi prévus.
  • Les front-end YaST en version Qt et GTK+ connaissent aussi leur lot d'améliorations, en particulier le module de gestion des paquets, avec une interface à la "PackageKit". L'applet de mise à jour sous Gnome est ainsi PackageKit lui même, tandis que l'applet du bureau KDE est lui aussi porté vers Qt4 et dispose maintenant d'un backend optionnel PackageKit : il est donc dès maintenant réutilisable par toute autre distribution.

les projets et la communauté openSUSE
Ces derniers mois ont également vu passablement de changement au sein de projets d'openSUSE et dans la communauté :
  • La séparation complète de la bibliothèque Yast-UI, permettant à partir des mêmes sources de créer une interface Qt, GTK+ ou ncurse via une simple recompilation. Cette bibliothèque peut désormais être utilisée par tout projet indépendant pour un développement plus flexible et plus rapide, et ceci à partir de différents langages (C++, python, perl, ruby). Autre conséquence directe de cette meilleure séparation de code : la portabilité de YaST est améliorée. Les efforts pour obtenir une version de YaST sur Fedora continuent.

  • L'apparition d'une version majeure de l'openSUSE Build Service (oBS). Cette pièce majeure de l'infrastructure d'openSUSE permet de créer des paquets pour différentes distributions (à base .rpm ou .deb) à partir des mêmes sources et d'un fichier descriptif unique. Également, il dynamise le développement des projets, pas forcément liés à openSUSE, par une plus grande interaction entre ceux-ci. Cette version 0.9 intègre la notion de décentralisation, permettant d'installer des Build Services individuels tout en ayant la possibilité de synchroniser les travaux sur un build service centralisé. L'oBS, comme toute l'infrastructure openSUSE, est libre et disponible au téléchargement.

  • La nomination d'un "Community manager", en la personne de Joe 'Zonker' Brockmeier[9], ancien rédacteur en chef de LinuxMagazine et auteur de plusieurs livres. Il est chargé de la promotion d'openSUSE, notamment dans les grands rassemblement du libre (tel que FOSDEM, LinuxTag,..). Il contribue aussi, avec les 5 membres de la board openSUSE, à faire l'intermédiaire entre Novell et la communauté. Aussi, le processus de nomination de la board a été amplement discuté et la nouvelle volée sera élue prochainement.

  • En plus de l'arrivée en novembre dernier d'une newsletter hebdomadaire officielle[10], l'ouverture des forums officiels[11] marquent la pose de pièces maîtresses manquantes. Par la fusion des 3 forums anglophones les plus populaires (suseforums.net, suselinuxsupport.de et les forums Novell openSUSE), ces forums ouverts il y a quelques jours, rapprochent encore la communauté sous une même bannière, tout en conservant les données existantes.

  • La publication de "Managing Firm-Sponsored Open Source Communities - A Case Study on Novell and The openSUSE Project"[12] le mois dernier, mémoire de Master de Jan Fredrik, un étudiant de l'université d'Oslo. Ce travail d'info-sociologie, fruit d'une année de recherche, détaille la collaboration entre Novell et la communauté openSUSE. Bien qu'openSUSE centriste, ce document devrait intéresser quiconque veut en savoir plus sur les relations tendues d'un écosystème où se mêlent désir de contrôle d'une entité économique, et ouverture vers la communauté Open Source.

[1] C. Tukker, D. Shuffelton, R. Jhala, S. Lerner, OPIUM: OPtimal Package Install/Uninstall Manager, 29th International Conference on Software Engineering (ICSE'07), 2007 : http://www.cs.ucsd.edu/~lerner/papers/opium.pdf
[2] http://en.wikipedia.org/wiki/Computational_complexity_theory
[3] D. Burrows, Modelling and Resolving Software Dependencies, June 2005 : http://people.debian.org/~dburrows/model.pdf
[4] F. Mancinelli, J. Boender, R. di Cosmo, J. Vouillon, Managing the Complexity of Large Free and Open Source Package-Based Software Distributions, 21st IEEE International Conference on Automated Software Engineering (ASE'06), 2006
[5] Yum, Smart and ZYpp speed / memory usage : http://duncan.mac-vicar.com/blog/archives/309
[6] http://svn.labix.org/smart/trunk/README, http://duncan.mac-vicar.com/blog/archives/310, http://duncan.mac-vicar.com/blog/archives/311
[7] The greatest unknown openSUSE 11.0 package management feature - Interoperability : http://duncan.mac-vicar.com/blog/archives/314
[8] http://download.opensuse.org/repositories/zypp:/Backport/
[9] http://zonker.opensuse.org/
[10] http://news.opensuse.org/category/weekly-news/
[11] http://forums.opensuse.org/
[12] http://janfredrik.wordpress.com/master-thesis/

Aller plus loin

  • # Intéréchant

    Posté par (page perso) . Évalué à 7.

    J'aime bien le chant sur le nouveau gestionnaire de paquets.... mais depuis le temps que c'est le b....l de quitter les paquets "officiels" de sa distribution, j'ai du mal à y croire....

    Quelqu'un utilise le Build Service pour une autre distribution que Suse?

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Intéréchiant

      Posté par (page perso) . Évalué à 7.

      C'est effectivement le bordel généralisé dans les gestionnaires de dépendances et de téléchargement, du style apt-get/urpmi/yum/zypp...

      Le LSB définit le format RPM comme standard, mais pas le DEB. Bon... Dommage/tant mieux ? Je sais pas.

      En revanche, il faudrait peut-être faire un effort d'homogénisation des formats de repositories par exemple... Je sais pas non plus...

      En revanche, sans aucun doute, il serait bon de ne pas diluer les efforts dans les n refontes/ré-écritures de ces gestionnaires de dépendances et de téléchargement du style apt-get/urpmi/yum/zypp... Non pas que les paquets vont devenir automagiquement cross-distro, mais au moins avoir des outils cross-distro... Sinon, le monde Linux va continuer de subir une fragmentation, certes loin, mais qui fait penser à celle des Unix proprio morts du siècle dernier.

      À ce jour, c'est encore une croyance généralisée qu'un gestionnaire de dépendances et de téléchargement est ce qui différencie les distros entre elles... mais en fait non, tout ça est résolu, avec plus ou moins de bonheur et de perfs, dans toutes les distros majeures, depuis longtemps, et quasiment de la même façon, aux détails techniques prêts... En gros, la commande et le fichier conf sont juste un peu différents.

      M'enfin, moi je dis ça, j'ai rien dit hein... ;-) Tout marche plutôt bien, dans toutes les distros que j'utilise...
      • [^] # Re: Intéréchiant

        Posté par . Évalué à 9.

        > une croyance généralisée qu'un gestionnaire de dépendances et de téléchargement est ce qui différencie les distros entre elles... mais en fait non, tout ça est résolu, avec plus ou moins de bonheur et de perfs, dans toutes les distros majeures, depuis longtemps, et quasiment de la même façon, aux détails techniques prêts

        Faut le dire vite...

        Ca fait 5-6 jours que je teste Fedora... et donc yum, que je ne connaissais pas du tout...

        ... et bien, je cherche encore la manière de désinstaller automatiquement les dépendances pullées par un paquet installé...

        Genre :

        - yum install revisor : m'installe plein de trucs
        - yum remove revisor : ne me vire que l'espèce de méta-paquet (mea culpa si la terminologie est inexacte) revisor... et rien de ce qui le compose vraiment, ie ses moult dépendances
        - par contre, les dépendances inversées marchent bien (il y a eu un journal assez trollesque là-dessus récemment) : si je vire revisor-cli, il me vire revisor-gui, revisor-comps et revisor... m'enfin : c'est quand j'ai installé revisor, que ça a fait venir tout ça, pas revisor-cli...

        J'ai demandé aux Fedoriens que je connais, je suis allé sur le forum de Fedora, j'ai googlé : tout ce que j'ai vu, c'est une remarque comme quoi c'est bel et bien une feature [1], et des bidouilles totalement inutiles avec package-clean, et hors-propos, dès lors que ce qu'on veut virer n'est pas une lib (or, les dépendances ne sont pas toujours des libs)... Mouais : bah feature ou pas, à la désinstallation, yum ne gère pas les dépendances, seulement les dépendances inversées...

        Je ne connaissais donc pas du tout jusqu'ici, mais je vois mal comment on peut comparer ça avec apt/aptitude (hors troll rpm/deb dont je me fous pour l'instant, n'ayant pas encore essayé de crafter du rpm... mais sachant déjà que ce n'est pas spécialement la joie avec les debs, en comparaison de ce que j'ai également pu voir sous Gentoo)... ou alors, je me suis tout confusé, et l'explication est vraiment bien cachée... l'instabilité de KDE, je peux encore faire avec, et c'était justement une des motivations de tester la distro (juillet et KDE 4.1 approchant fort, et KDE 4.0.5 étant sorti au début du mois, et ayant été updaté) : mais un gestionnaire de paquets qui ne gère les dépendances qu'à moitié, ie à l'installation, là, j'ai plus de mal...

        [1] http://fedoraproject.org/wiki/FWN/Issue100#Yum_Reverse_Depen(...)
        • [^] # Re: Intéréchiant

          Posté par . Évalué à 3.

          cherche pas .... c'est pas possible malheureusement
          • [^] # Re: Intéréchiant

            Posté par . Évalué à 5.

            J'ai bien crû comprendre... mais ne connaissant pas et ne m'attendant pas du tout à ça, surtout sur une distro plus ou moins vouée à tester plein de choses...

            ... c'est dommage, parce que la distro me plaisait conceptuellement plutôt bien : bleeding edge extrême et activement pro-libre, c'est ce que je recherchais...

            Mais là, franchement, je considère mon système comme déjà irrémédiablement bloaté, après avoir installé 4 ou 5 trucs... paie ta maintenance à l'ancienne. Je me vois vraiment mal mettre un truc qui utilise ce "gestionnaire" de paquets sur un serveur : déjà que ça risque de me saouler vite sur de la workstation... ma période Slackwaro-LFSiste, je ne la regrette pas, mais elle est derrière moi depuis long.

            Ce genre de trucs, ça me donne une très grosse envie de resortir assez vite les backups Debian sur les machines où j'ai testé - même si ça m'embête, parce que je n'y aime pas X.org (7.1 est trop lent, 7.3 pas assez stable, pour ce qui m'ennuie le plus). Non, franchement, après avoir testé yum, une chose est claire : il existe des différences dantesques entre les distros, au niveau du gestionnaire de paquets... On peut cacher ça derrière PackageKit (j'ai même tendance à penser que c'est souhaitable, pour unifier les syntaxes et ne pas confuser les nouveaux arrivants), ça ne change rien aux possibilités respectives.

            Bon, ça me fera toujours un truc à dire, la prochaine fois qu'IsNotGood tonitruera que soit-disant, yum n'a pas de très graves problèmes au niveau de la gestion des dépendances.
            • [^] # Re: Intéréchiant

              Posté par . Évalué à -6.

              Si vous jugez ce gestionnaire de paquets sur ce seul manque de possibilité, permettez moi de vous dire que vous n'avez pas tout compris.

              1) C'est une possibilité qui est apparue assez tard dans Debian, avec l'arrivée d'aptitude, sinon il fallait utiliser deborphan (à confirmer...).
              2) Les personnes qui installent un paquet pour le désinstaller plus tard sont assez rares. Vous faites sans doute partie de ces personnes qui croient qu'une distro est optimisée parce qu'on peut installer le moins de choses possibles, et qui n'arrêtent pas de tester des paquets toute la journée. Je ne vous blâme pas : je suis passé par là aussi.
              3) Ce n'est pas si grave si des paquets non utilisés restent sur le système.
              4) C'est une possibilité à utiliser avec précaution. Si par exemple vous installez un logiciel qui ne provient pas d'un paquet de votre distribution.
              • [^] # Re: Intéréchiant

                Posté par . Évalué à 6.

                1 ) Oui, mais deborphan existait :-). Un outil similaire doit bien exister sur Fedora.

                2) Je suis désolé de vous contredire mais beaucoup de personnes installent des applications pour les tester puis les désinstallent après coup ( même sur un serveur ). Installer les CMS XXX et YYY pour les tester et se rendre compte qu'ils ne conviennent pas ne signifie pas qu'on s'amuse toute la journée à installer/désinstaller

                Je fais également partie des personnes qui pensent que moins on en installe, mieux on se porte (et nous devons être nombreux) .

                3) C'est pas grave et ennuyeux
                • [^] # Re: Intéréchiant

                  Posté par . Évalué à -1.

                  2) Dans ces cas particuliers on consulte l'historique pour savoir ce qu'on avait installé, et on désinstalle à la main. Personnellement, je n'aime pas trop qu'on fasse tout pour moi.

                  4) Encore un autre exemple. Parfois X fonctionne même si Y n'est pas installé. Mais l'ajout de Y est un plus. Si Z installe Y, et qu'on désinstalle Z, donc Y, on risque de ne pas comprendre d'où vient le problème de la fonctionnalité perdue dans X.
                  • [^] # Re: Intéréchiant

                    Posté par . Évalué à 10.

                    Dans ces cas particuliers on consulte l'historique pour savoir ce qu'on avait installé, et on désinstalle à la main.

                    C'est clair que c'est de cette manière que Linux et les distrib vont se démocratiser.
                • [^] # Re: Intéréchiant

                  Posté par (page perso) . Évalué à 7.

                  Je fais également partie des personnes qui pensent que moins on en installe, mieux on se porte (et nous devons être nombreux) .


                  Mouais, pareil pour moi. Déjà rien que vois qu'on a exim et bind installés d'origine sur Debian, ça m'agace :-)

                  La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever.
                  Antoine De Saint-Exupéry
                  • [^] # Re: Intéréchiant

                    Posté par . Évalué à -3.

                    Vous parlez certainement pour un usage serveur.
                    Mais combien de personne ai-je vu sur le forum debian-fr dont l'obsession était de faire faire un régime à leurs Debian sans trop savoir pourquoi ?
              • [^] # Re: Intéréchiant

                Posté par . Évalué à 5.

                1) Ce n'est pas tant que ce ne soit pas dispo dans yum, à la limite, qui me dérange : c'est que ce ne soit pas dispo du tout... même dans les yum-utils, il n'y a que package-clean, qui n'est capable comme je l'ai dit que de virer les libs qui ne dépendent de rien ; c'est très maigre...

                Après, deborphan ne fait rien de mieux que packageclean non plus... La question est plutôt l'option autoremove d'apt, ou le comportement par défaut d'aptitude, qui sont quand même fonctionnels depuis un moment. Quand on est habitué, ça fait drôle de ne plus avoir.


                2) Je fais surtout partie des personnes qui aiment bien savoir ce qu'il y a sur la machine et qui détestent les répertoires bourrés d'inutilités, parce que c'est plus dur de s'y retrouver... je ne vois pas ce que l'optimisation a à voir là-dedans : c'est une question d'administrabilité.


                3) Mettons que j'ai un problème de sécurité, non encore connu, et donc encore moins patché, dans un programme installé en tant que dépendance, de quelque chose que j'ai viré depuis. Si le gestionnaire de paquets gère complètement les dépendances à la désinstallation, je ne suis pas sujet à cette faille ; dans le cas de yum, j'y suis.

                Laisser le bloat s'installer, si, ça peut être grave. Ou alors, avoir tout et n'importe quoi sur les machines, ce n'est pas grave ? Ce n'est pas en niant qu'on résoud les problèmes.


                4) Qu'est-ce qui est à utiliser avec précaution ? Enlever les dépendances installées quand elles ne sont plus utiles ? Ca fait au moins depuis Etch que c'est le comportement par défaut, sous Debian, et je n'ai eu aucun problème avec.

                Maintenant, si c'est une possibilité, par contre, comment on fait ? Jusqu'ici, pour moi, ce n'est même pas une possibilité... Un revdep-rebuild à l'envers (pour les dépendances, elles, à l'endroit), à la Gentoo, ie pas dans le gestionnaire de paquets en lui-même, ça m'irait pourtant parfaitement... mais non, même pas.
                • [^] # Re: Intéréchiant

                  Posté par . Évalué à -4.

                  je ne vois pas ce que l'optimisation a à voir là-dedans : c'est une question d'administrabilité.

                  Aucun rapport avec l'optimisation en effet. C'est ce que je croyais quand j'étais n00b.

                  3) Mettons que j'ai un problème de sécurité, non encore connu, et donc encore moins patché, dans un programme installé en tant que dépendance, de quelque chose que j'ai viré depuis. Si le gestionnaire de paquets gère complètement les dépendances à la désinstallation, je ne suis pas sujet à cette faille ; dans le cas de yum, j'y suis.

                  Non, parce que vous ne l'utilisez pas. (Sauf cas particuliers comme des services, mais dans ce cas ce n'est pas au gestionnaire de paquets qu'il faut faire confiance).
                  Ce qu'il vous faudrait peut être c'est Gentoo.
                  • [^] # Re: Intéréchiant

                    Posté par . Évalué à 2.

                    >Non, parce que vous ne l'utilisez pas
                    Ca, je n'en sais rien... si un autre utilisateur s'en sert, pour voir, par exemple, alors qu'en tant qu'administrateur, j'aurais pourtant voulu que non.


                    >Ce qu'il vous faudrait peut être c'est Gentoo.
                    J'aime beaucoup Gentoo, j'y ai passé beaucoup de temps, et il m'arrive encore de m'en servir (enfin, surtout le fabuleux livecd minimal, qui m'a plus d'une fois sorti de la panade), mais elle ne me convient tout simplement plus (recul sur le bleeding-edge, plus envie de compiler des heures, et je trouve que le projet est bien moins robuste qu'il y a 4 ans, quand j'avais commencé à l'utiliser - pour résumer).

                    Non, là, je veux une orgie de bleeding-edge, tout en restant fidèle à mes principes et mes affinités (donc, pas de suse ni d'ubuntu), mais sans trop me casser la tête non plus... bon, forcément, il va y avoir des compromis à faire ; mais la demi-absence de gestion des dépendances, ce n'en est pas un petit, pour moi : c'est tout.
                    • [^] # Re: Intéréchiant

                      Posté par . Évalué à -2.

                      Ça commence à me gonfler tous ces gens qui pensent qu'il n'y a que des administrateurs sous Linux.
                      • [^] # Re: Intéréchiant

                        Posté par . Évalué à 2.

                        Plaît-il ?
                        • [^] # Re: Intéréchiant

                          Posté par . Évalué à -2.

                          Ben oui faut comprendre !
                          Dès qu'il y a un truc qui manque sous Linux "bah moi j'en ai pas besoin je suis admin". Bon là c'est l'inverse ("putain ça me manque pour mon serveur donc Fedora saynul").
                          Dès qu'on dit que Linux a peu de parts de marchés "bah moi je m'en fou mon serveur il roule".
                          Dès qu'on veut changer un truc dans debian "bah moi je veux pas changer ma Debian elle marche"
                          Dès qu'on se plaint du manque de jeux "bah moi je m'en fou je suis admin je joue pas".

                          Ça me gonfle et je suis sérieux arrêtez d'être égoïstes svp !!!! :(
                          • [^] # Re: Intéréchiant

                            Posté par . Évalué à 4.

                            Si je comprends bien, ce qui te gonfle, c'est qu'il y ait des administrateurs sous Linux ?

                            Bah installe un bon vieux ouin-ouin qui tourne en root, alors.
                            • [^] # Re: Intéréchiant

                              Posté par . Évalué à 2.

                              Non, c'est que les admins dictent ce que doit être Linux (et Debian en particulier).
                              Et surtout, ce sont ceux qu'on entend le plus, alors qu'ils sont une minorité.
                              • [^] # Re: Intéréchiant

                                Posté par . Évalué à 4.

                                Sur mon desktop non plus je n'aime pas qu'il reste des paquets inutilisés ....

                                Comme quoi c'est pas une volonté juste pour les serveurs ou une volonté d'admin.

                                A mon avis, le système doit plaire d'abord aux admins. Une fois que ça marche pour eux, on peut éventuellement proposer une version aux utilisateurs normaux, si c'est applicable... mais en tout cas après (et un admin peut éventuellement bosser en graphique .... s'il est maso)
                              • [^] # Re: Intéréchiant

                                Posté par (page perso) . Évalué à 4.

                                Non mais bon, faut arrêter la mauvaise foi à un moment...

                                Je ne comprends pas l'opposition admin / utilisateurs "normaux". A partir du moment ou tu es root sur ta machine, tu es administrateur, que tu le veuille ou non, que tu le sache ou non. Un utilisateur "normal" est certainement un mauvais admin, mais il en a néanmoins la charge. Si sa workstation connectée a internet se transforme en open-relay, c'est de sa faute a lui, en temps qu'administrateur. Raison de plus, si tu veux démocratiser Linux, d'avoir des outils de gestion de packages efficaces, même avec des administrateurs totalement incompétent. C'est un des griefs principaux a l'encontre de windows: il est très facile de mettre en place un service "qui marche", il est surtout très facile de laisser ce service plein de failles. Pendant longtemps, on a mis en avant la relative difficulté d'installer un service sur Linux comme un garde-fou contre les administrateurs incompétents (ce qui est quand même un peu de la mauvaise foi aussi), maintenant qu'on peut avoir des services "qui marchent" en une ligne de commande, il faut aussi s'assurer que l'administrateur médiocre arrive à gérer sa machine. Et clairement, le problème pointé ici est tout a fait valide. Un utilisateur de base qui installe "toto", puis se rend compte qu'il n'en veut plus et le desinstalle, le systeme de package DOIT lui indiquer que "toto" a aussi installé "titi" et "tata", maintenant inutiles.

                                Nier se problème, c'est faire l'autruche. Je suis un Débianeux/Ubuntiste endurci, ,mais ça fait tellement longtemps que je ne me suis pas frotté a un système basé sur RPM que j'évitais de faire valoir cet argument dans ma préférence, après cette discutions je vais encore attendre un peu avant de refaire un tour chez les cousins d'en face...
                                • [^] # Re: Intéréchiant

                                  Posté par . Évalué à -4.

                                  Plus le système de paquet sera évolué, avec des dépendances très fines, des paquets divisés en petits paquets, des recommends, plus le système sera fragile au moindre petit pépin.
                                  • [^] # Re: Intéréchiant

                                    Posté par . Évalué à 7.

                                    D'où la nécessité de conserver une arborescence propre, en supprimant aux maximum les paquets inutiles.

                                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Intéréchiant

          Posté par (page perso) . Évalué à 5.

          Effectivement, c'est un manque des distributions basées sur les RPM : pas une n'a implémenté cela à ma connaissance. Par contre je sais que c'est dans les spécifications de la Mandriva 2009.0, prévue pour mi-Septembre.

          Sans vouloir lancer de troll, d'un point de vue "Grand Public", cette fonctionalité est beaucoup moins demandée qu'un clickodrome de configuration. C'est pourquoi je n'installe JAMAIS une distribution autre que Mandriva : personne ne m'a jamais demandé comment faire ça.

          Par contre, j'en ai moi-même ressenti le besoin sur ma machine de travail, où je voulais du logiciel ultra récent presque jamais cassé : Sid est mon amie depuis 4 ans, elle a déjà migré 2 fois de machine physique sans encombre!

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Zut! Je viens juste d'installer OpenSUSE 10.3 (CD KDE) :)

    Posté par . Évalué à 9.

    Qui est au deumeurant fort sympathique et même très agréable. Après un moins d'essai de Fedora/Ubuntu afin de trouver la distro sérieuse que je pourrais offrir à un nouveau venu dans le monde linux/libre, je dois dire que j'ai trouvé en OpenSUSE, LE système.

    Cela dit, j'ai bien eu un problème avec le WiFi (ipw3945) qui ne fonctionne pas avec des AP cachés. Peut-être est-ce résolu dans la 11.0.
    Mais à part ça, tout roule, support matos, suspend/hibernation etc...

    De plus, il offre un tas d'outils graphique de gestion du système très bien finis, ce qui est le bienvenu notamment pour le débutant, mais je découvre que même pour un vieux linuxien comme moi, c'est pas inintéressant.

    Et puis, enfin une distro belle, moderne, cohérente et qui fait plus qu'empaqueter des logiciels ou de gommer sous de la cosmétique le coeur d'une autre distribution. :)


    Après les retours de mon "cobaye" :) et de mon ressenti, je suis bien tenté de remplacer mon actuelle Archlinux pour OpenSUSE, car au final, j'en ai un peu marre de la bricole.

    Au délà de mes éloges, je trouve tout de même absurde d'offrir l'horrible KDE 4.0 beta ou FireFox 3 dans une version stable, sans doute la petite ombre au tableau.
    • [^] # Re: Zut! Je viens juste d'installer OpenSUSE 10.3 (CD KDE) :)

      Posté par . Évalué à -1.

      Ah oui zut !
      Repasse à Archlinux, suse=novell=c'est l'axe du mal :-)

      Comme le dit le site http://boycottnovell.com/ , "An invade, divide, and conquer Grand Plan".
      • [^] # Re: Zut! Je viens juste d'installer OpenSUSE 10.3 (CD KDE) :)

        Posté par . Évalué à 1.

        Je ne l'ai pas installé pour moi, mais pour un ami débutant ou plutôt pas pour un admin sys. :)

        Au lieu de boycotter, on n'a qu'offrir quelque chose d'aussi fini qui ne dépende pas d'une boîte, hein?
        Peut-être que si les 550 autres auteurs de distros et ainsi que leurs 500*n contributeurs réunissaient leur force pour se focaliser sur une ou deux distros, alors oui on aura de quoi faire.

        Et oui, c'est considéré comme une disperssion car ils dépensent leur temps et leur énergie à faire des paquets, entretenir des distros etc...

        Remarquez, ça ne me dérange pas, mais alors qu'on ne dise pas que Linux (hors OpenSUSE) est prêt pour le grand public, hein? ^_-
    • [^] # Re: Zut! Je viens juste d'installer OpenSUSE 10.3 (CD KDE) :)

      Posté par . Évalué à 3.

      Cela dit, j'ai bien eu un problème avec le WiFi (ipw3945) qui ne fonctionne pas avec des AP cachés

      Utilise le pilote libre iwlwifi.

      Le blob proprio d'intel est pourrave sur certain point. Le pilote libre n'est pas encore parfait, mais il évolue, lui.
      • [^] # Re: Zut! Je viens juste d'installer OpenSUSE 10.3 (CD KDE) :)

        Posté par . Évalué à 2.

        C'est ce que j'ai fait, le seul inconvénient notable, c'est qu'il ne supporte pas la sortie d'une mise en veille.

        A part le eeepc, on peut se gratter, hein? on est pas loin de la politique Apple :)
        ne prêtez pas attention, c'est gratuit comme remarque
    • [^] # Re: Zut! Je viens juste d'installer OpenSUSE 10.3 (CD KDE) :)

      Posté par (page perso) . Évalué à 2.

      Un point intéressant de la Suse, c'est le support des écrans tactiles.
      Dans YaST, on peut les configurer/calibrer simplement, alors que sur d'autres distros, même en compilant les drivers et en bidouillant xorg.conf, pas moyen.
      À l'installation, ils sont détectés automatiquement (au moins dans mon cas, un touchscreen 3M), sans avoir besoin d'installer les drivers dispos sur le site du constructeur : http://solutions.3m.com/wps/portal/3M/en_US/3MTouchSystems/T(...)
      Je vais peut-être me tenter le passage 10.3->11.0.

      À propos de mises à jour, je suis passé de la 10.0 jusqu'à la 10.3 (en passant par la 10.1 et 10.2) sans soucis à part quelques problèmes liés aux dépôts tiers, mais ça vient plus de ma méconnaissance de la Suse.
  • # Codec proprietaires?

    Posté par (page perso) . Évalué à 2.

    Y-a-t il moyen désormais d'installer -rapidement- les divers codecs multimédia proprios (DivX- MP3 - MP4 and co), avec un (vilain) paquage par exemple?

    J'avais voulu passer à Open Suse pour mon ordi qui me sert de station multimédia mais l'installation (laborieuses) des divers codec m'avait franchement rebutée...

    c'est dommage car j'ai trouvé la distribution vraiment très attrayante...
    • [^] # Re: Codec proprietaires?

      Posté par . Évalué à 2.

      Le système one-click devrait faire ton bonheur !
      Il permet de configurer les dépôts nécessaire et de faire l'installation de paquets ou méta-paquets (codecs, drivers propriétaires, ...) en seulement quelques clics (principalement en confirmant, un peu dans le genre "Suivant", "Suivant", "Suivant", "Terminer", mais avec des vraies explications sur ce qui va être fait et des vrais choix si tu le veux).

      Un petit lien, mais un moteur de recherche t'en donnera plus : http://dev.compiz-fusion.org/~cyberorg/2008/06/10/useful-ope(...)
    • [^] # Re: Codec proprietaires?

      Posté par . Évalué à 4.

      Packman est ton ami.

      http://packman.links2linux.org/
    • [^] # Re: Codec proprietaires?

      Posté par . Évalué à 3.

      Effectivement, cette histoire de codecs a été ma première prise de tête avec cette distro que je découvre depuis lundi.
      Il y a bien un truc qui te propose d’aller installer automatiquement des codecs… m’enfin proposer à des libristes ceux de Fluendo et seulement ceux-là, ça ne fait pas très sérieux. Le comble c’est quand on apprend que les codecs libres sont dans le dépôt… non libre ! (bon et finalement, c’est dans le dépôt packman qu’on trouve l’essentiel de ce qui manque).

      Enfin voilà, pour cet aspect-là, je préférais Ubuntu.
      Sinon globalement Opensuse est tout de même bien mieux léchée (enfin, par rapport à la catastrophe nommée Kubuntu en tout cas).
      • [^] # Re: Codec proprietaires?

        Posté par . Évalué à 2.

        Au fait, par libre j’entends ici distribué sous licence libre. C’est donc le cas de xvid, lame, x264, faad, ffmpeg, etc. (et pas seulement la famille Ogg et autres formats sans brevet, critère sans intérêt, pour moi, citoyen français)
        • [^] # Re: Codec proprietaires?

          Posté par . Évalué à 4.

          Justement, la plupart de ces codecs sont libres, mais pas partout (USA et Japon). Il ne sont donc pas dans les dépots de bases, mais bien dans les depots communautaires (qui s'activent en un clic).

          Aussi, les appli sans codec renvoient vers une page wiki, ou l'on trouve un lien vers Fluendo, et un lien vers la page du wiki communautaire (devrait-je dire "communautaire officiel" ?) qui dispose des liens One-click.

          L'utilisateur a donc le choix de payer des codecs s'il est américain ou japonais ou le choix de les installer gratuitement s'il ne l'est pas :)
          • [^] # Re: Codec proprietaires?

            Posté par . Évalué à 3.

            Justement, la plupart de ces codecs sont libres, mais pas partout (USA et Japon).

            Juste pour pinailler : ils sont libres partout au sens FSF. Par contre, ils enfreignent des brevets qui rendent leur utilisation illégale dans les pays qui reconnaissent ces brevets, ce qui n'est heureusement pas le cas en Europe.
    • [^] # Re: Codec proprietaires?

      Posté par . Évalué à 4.

      Dispo sur le wiki communautaire openSUSEm complément du wiki officiel (et dont j'ai oublié de mettre le lien.. ) :

      http://opensuse-community.org/1-click-collection
  • # bah c est pas si mal que ça finalement

    Posté par . Évalué à 3.

    dans mon nouveau boulot ,ça fait 3 mois qu on gère differents clients sous linux et notamment un gros gros dont toutes les machines sont sous suse.
    Moi qui ai toujours été gros fan de debian ,et qui vis avec RedHat (pas le choix,oracle oblige), eh bien ça a été une grosse surprise:
    -yast (en mode console ou graphique) marche vraiment pas mal, pour administrer la machine , ça nous permet d avoir une interface á la sam ou smit sous linux, et y a que suse qui le fasse (á quand un smit-like sur debian....oui je sais,je sais, si j etais moins flemmard,je le ferais moi même...).
    Le seul reproche, c est la lenteur d initialisation pour la gestion des paquets .Mais c est deja beaucoup plus rapide qu un yum ou up2date
    -pour un serveur,ça me semble un bon choix, d autant que je vois souvent des commentaires du genre,"oui mais avec cet distrib,j ai pas fait marché ma carte wifi" -> c est plutot un probleme de kernel ça que je sache.
    -pour un desktop, pourquoi pas ...
    voilou :)
    • [^] # Re: bah c est pas si mal que ça finalement

      Posté par . Évalué à 2.

      Pour la lenteur d'initialisation des paquets, j'avais essayé la beta de l'OpenSUSE 11, et déjà là, ça n'avait rien à voir avec la 10.3
      Primo, c'est bien plus rapide (pas encore au niveau d'apt, mais bon...).

      Mais surtout, il n'y a plus *qu'une seule* fenêtre, pas 36 popups l'un après l'autre qui te font perdre ton focus et qui t'obligent à suivre le chargement du gestionnaire de paquet.

      Ze truc gavant de la 10.3 : déjà que c'était lent, mais en plus, tu ne peux même pas te balader sur le web en attendant... Enfin résolu :-)

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: bah c est pas si mal que ça finalement

        Posté par . Évalué à 4.

        Pas encore au niveau d’APT ? Dans mon cas personnel, ça explose complètement APT ! Après faudrait voir les différents cas d’utilisation, pour une vraie comparaison.
        • [^] # Re: bah c est pas si mal que ça finalement

          Posté par . Évalué à 2.

          Ben perso, je le trouve toujours plus lent que APT, et ce dans les cas courant :
          * apt-get install
          * apt-cache search
          * apt-cache show
          * apt-get (auto)remove

          Remarque, c'est certainement parce que j'utilise APT en console et Yast en graphique :-/
          Je ne me suis pas encore penché sur son usage en texte, pour vraiment comparer.

          Mais attention, je ne reproche rien du tout au gestionnaire de paquets d'openSUSE, il vient de faire avec cette version un énorme bond en avant (au moins sur les perfs).

          Entre parenthèses, j'espère qu'il gère la suppression des dépendances inutiles (cf discussion plus haut), car sans ça, ça serait bien le seul point manquant par rapport à APT...

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: bah c est pas si mal que ça finalement

            Posté par . Évalué à 2.

            Et peut-être aussi que l’APT que j’utilisais était anormalement lent pour l’installation (j’ai toujours eu cette impression).
            Enfin voilà, maintenant je suis plutôt satisfait. Manque juste une recherche de type « find as you type », à la adept, dans yast. Peut-être problème de perf côté SUSE, pour les recherches ?
            • [^] # Re: bah c est pas si mal que ça finalement

              Posté par . Évalué à 3.

              D'ailleurs, j'ai eu l'occasion d'utiliser APT sous Fedora, et il est vraiment beaucoup plus lent que sous Debian.
              Donc il doit y avoir d'autres paramètres, comme les miroirs, ou autres.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: bah c est pas si mal que ça finalement

              Posté par (page perso) . Évalué à 1.

              En ligne de commande la recherche est très très rapide, donc j'imagine que ce genre de fonctionnalités pourrait être implémenté facilement.
      • [^] # Re: bah c est pas si mal que ça finalement

        Posté par . Évalué à 1.

        sur suse 10.3 on ne pouvait pas faire autre chose en installant ? tiens c'est nouveau ca, en quoi était t'on géné ? je suis curieux d'en savoir plus.
        • [^] # Re: bah c est pas si mal que ça finalement

          Posté par . Évalué à 2.

          Bon, c'est vrai que c'était pas pendant une installation en tant que tel, mais au lancement du gestionnaire de paquets. C'était les fenêtres d'avancement qui me gênaient : pour la mise à jour de chaque dépôt, il ouvrait une nouvelle fenêtre avec juste une barre de progression, qui prend le focus.
          Comme je trouve le chargement du bousin assez long, j'ouvre une page web pour patienter, mais à chaque dépôt, il reprend la main et s'affiche au dessus. Quand on est habitué à Synaptic, c'est vite énervant...

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Précisions demandés sur ZYpp, solveur booléen et Yast

    Posté par . Évalué à 4.

    Bonjour,

    Je ne suis pas sûr d'avoir bien compris les différences entre ZYpp et Yast.
    Si je considère OpenSuse, Mandriva et Debian, est-ce que les analogies suivantes sont bonnes ?

    gestionnaire de paquet bas niveaux - gestionnaire haut niveaux avec gestion automatique des dépendances - frontend graphique.

    OpenSuse : rpm - ZYpp - Yast
    Mandriva : rpm - urpmi - rpmdrake
    Debian : dpkg - apt-get - synaptic

    J'ai aussi du mal à bien saisir ce qu'est Yast : c'est juste pour configurer les paquets ou c'est une boite à outils de configuration du système, comme les draktools ?

    Enfin je n'ai rien compris au coup du "ZYpp couplé à un solveur booléen". J'imagine qu'on parle de résolution des dépendances là mais c'est le booléen qui me gène (je sais ce qu'est un booléen ...) : qu'est-ce qu'il y a derrière cette expression sibylline ?

    Merci beaucoup d'avance pour vos éclaircissement !
    • [^] # Re: Précisions demandés sur ZYpp, solveur booléen et Yast

      Posté par . Évalué à 4.

      OpenSuse : rpm - ZYpp - Yast
      Mandriva : rpm - urpmi - rpmdrake
      Debian : dpkg - apt-get - synaptic


      C'est tout à fait ça.

      Pour YaST, à la base c'est un "centre de contrôle" constitué de différents modules (comme drakeconf).

      Néammoins, le module package manager de YaST est usuellement appellé simplement "Yast" (c'est un raccourci).

      L'appellation exact devrait être "rpm - ZYpp - Yast package manager"

      Pour le solveur SAT, je ne peut que te renvoyer aux sources indiquées (si tu as le temps, c'est vraiment très intéressant).

      Grosso modo, ZYpp transforme les metadonnées en fichiers bianaires, plus rapide à lire (fichiers .solv), puis applique des règles booléennes pour la résolution. En résumé, c'est plus rapide, plus fiable, et ça consomme surtout moins de mémoire.
  • # question

    Posté par . Évalué à 3.

    autoremove d'apt désinstalle les dépendances du paquet en question, mais si un autre paquet installé dépend de ces mêmes dépendances, sont elles désinstallées ou apt vérifie bien si d'autres paquets en dépendent avant de les désinstaller ?
    • [^] # Re: question

      Posté par (page perso) . Évalué à 2.

      Quand tu demandes d'installer un programme, apt met une étiquette "installé volontairement" dessus. Il ne met pas cette étiquette sur les paquets installé via les dépendances.

      apt détecte comme paquet potentiellement non nécessaire tout les paquets ne possédant pas l'étiquette "installé volontairement" et dont aucun paquets installé volontairement ne dépend, de manière directe ou indirecte, paquet recommendé et suggeré compris. Tu peux désinstaller ces paquets via "apt-get [--purge] autoremove".

      Si un paquet ne possède pas l'étiquette "installé volontairement", mais que tu veux le garder quand même, tu fais "apt-get install monpaquet" et apt met l'étiquette "installé volontairement" dessus.

      Donc, pour répondre à la question, apt vérifie bien si d'autres paquets en dépendent avant de les désinstaller

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.