genesis83 a écrit 78 commentaires

C'est très variable, combien de fois peut-on lire que la distribution xxx fonctionne sur son ordinateur et pas la distribution yyy ?

Par exemple : http://www.pcinpact.com/actu/news/50542-hp-dv2-neo-linux-7.h(...)
- Ubuntu 9.04 KO
- Mandriva 2009.1 RC2 KO (à voir avec la finale)
- Fedora 11 OK

Alors pourquoi y a t-il aussi peu de véhicules avec une boîte de vitesse automatique ? Je ne connais pas le pourcentage exact mais il ne doit pas être bien élevé (quelques % tout au plus), alors que l'option est disponible sur quasiment tous les modèles.

Pour rester dans le domaine de l'informatique, Firefox est beaucoup plus complet et personnalisable qu'IE, ça ne l'empêche pas de gagner des parts de marché.

Thunderbird se meurt, c'est peut-être aussi (surtout ?) parceque les alternatives, quelque soit l'OS, sont nombreuses et de qualité.
Alors faut-il "sauver" à tout prix Thunderbird ?

> Ce n'est pas le cas de smartrpm ni de apt (ou synaptic ?).

C'est vrai je viens de jeter un coup d'oeil, effectivement.

>> d'où l'intérêt des epochs.

> C'est un autre problème.

Ce n'est pas un autre problème. On peut avoir une mise à jour qui diminue la version, mais uniquement si c'est une mise à jour voulue.
C'était pour illustrer le fait que le scénario qui consiste à proposer un vieux paquet non sûr est impossible en pratique, en tout cas avec yum/urpmi.

> Le mirroir fait un "downgrade" (pour annuler la mise à jour). Yum refusera d'installer le vieux paquet. Il refuse par défaut tout downgrade.

Comme tout les gestionnaires de paquets que je connais, d'où l'intérêt des epochs. C'est pour ça que quand l'auteur dit un paquet n'expire jamais, en pratique il expire à partir du moment où une révision supérieure du paquet est installée.

Maintenant le problème ne peut se poser que dans le cas d'une prise de contrôle au long cours d'un miroir. Une bonne pratique serait (je ne sais pas si c'est fait) que chaque distribution lance une vérification périodique de ses miroirs officiels, ce ne serait pas bien compliqué à mettre en oeuvre.

Tu pourrais donner des détails sur le fonctionnement d'auto-apt en pratique ?
De ce que j'en comprend, je pense que ça n'aurait aucun intéret dans un système rpm étant donné les dépendances sur fichiers.

> Non, par contre, ce qui est dur, c'est d'avoir un logiciel en version N+1 ou N+2 sans avoir > à upgrader l'ensemble de la distrib. Aujourd'hui, pour avoir Wesnoth 1.6 sur une ubuntu, > ben il faut passer en dehors de la distrib. avec tout les risques que cela comporte.

> la solution : rolling release. ok. ben, c'est pas pour tout le monde quand même.

Ou passer sous Mandriva, Wesnoth 1.6 est dans les backports de la 2009.0. Sans certitude je pense que ça doit être possible sous OpenSuse avec son système de build service.

> Un ancien collègue, pourtant pro-Mandriva, a même basculé son poste sous Ubuntu pour rester cohérent.

Cohérent avec quoi ? La cohérence c'est de passer sous Ubuntu ?

Au niveau des paquets source c'était autour de 7500 pour Fedora (à confirmer) et autour de 10000 pour Mandriva.

> je n'ai jamais vu un drakemachin ailleurs que chez mandriva

Faudrait enlever tes oeillères : Pclinuxos, Caixa Magica...

> Je dis simplement qu'ils se sont très longtemps basé sur les RPM de Red-Hat pour faire leur distribution.

Qu'il y ait des paquets importés et modifiés bien sûr, mais regardes le nombre de paquets source de l'un et l'autre...

Quel est le rapport avec l'UE ? De toute manière au niveau de l'UE, comme grosse distribution hormis Mandriva et Mint...

> La 2009 spring fournit toujours Xen (je doute qu'il y ait un support Xen dans le noyau).

$ urpmq -af kernel-xen
kernel-xen-2.6.18.8-xen-3.3.1-2mdv-1-2mdv2009.1.x86_64
kernel-xen-devel-2.6.18.8-xen-3.3.1-2mdv-1-2mdv2009.1.x86_64

> Il est indiqué le passage à virt-manager, mais il n'y est pas dans la rc1. Il y a virtualbox. >Notons qu'il y a libvirt. Mais libvirt "tout nu", c'est un peu dure d'utilisation. Par contre il y a >virualbox...
>A ce demander si c'est une release candidat.
>Sûr qu'on doit trouver virt-manager dans contrib. Mais c'est virtualbox qu'il y a dans main. >Il est moins suprenant que j'ai eu des problèmes lors de mon test puisqu'il a été fait avec >kvm.

Effectivement virt-manager est dans contrib : et alors ? Les deux dépôts sont activés automatiquement.

C'est vraiment critiquer pour critiquer, il aurait été dans main tu aurais trouvé autre chose...

Tu as testé la cooker pour voir ce que ça donne en pratique ? C'est encore la meilleure façon de se faire vraiment un avis.

Effectivement, c'est visiblement une de leurs options, j'étais passé à côté.

"Comme Mandriva va passer à upstart" : tu as une source pour ça ? J'en ai jamais entendu parler...
Sur speedboot, s'il permet de se loguer plus vite, c'est quand même globalement bénéfique au temps de boot "grub -> desktop 100% utilisable". D'ailleurs il me semble que les dev RedHat ont dit penser à ce genre de code quand Mandriva a sorti les détails sur bootspeed.

D'un autre côté une RC avec un noyau en RC quasi final, c'est assez logique aussi vu que la distribution se cale sur les développements upstreams.
Après c'est vrai qu'à ce niveau là chaque distribution ou logiciel a sa propre politique.

C'est quand même plus que du sponsoring.
Tu connais beaucoup de cas où c'est le "sponsor" qui annonce officiellement la sortie de ce qu'il sponsorise ?

On est d'accord, créer et partager. C'est avec le partage que Canonical semble avoir un problème...

Ne pas distribuer les sources pour se protéger de toute concurrence; c'est exactement le raisonnement des entreprises qui font du propriétaire.
C'est un choix, mais après il ne faut pas être hypocrite.

Si pour toi (et pour eux) faire du libre c'est donner son slip, alors tu ne fait que confirmer ce que je dis...

"Certains morceaux ne seront toutefois pas de la partie puisque beaucoup trop lier au mode de fonctionnement de Canonical ( celle-ci n'ont pas clairement été désignée....)."

Le libre c'est bien qu'en il s'agit de bénéficier du travail des autres ou de faire du marketing, mais sorti de ça ils ont une mentalité complètement opposée au libre...

Il me semblait que la seule différence entre une version LTS et une version classique était la durée du support, comme le disaient certains contributeurs ?
Ca a changé ou c'est juste une posture destinée à se lancer des fleurs "regardez comme on est bon" ?

Sinon je suis d'accord avec l'auteur de la dépêche.

Bonjour, je trouve ça étrange de trouver étrange l'intégration d'une version stable à la place d'une version de développement, qui ne dispose pas de versions compatibles pour tous les plugins, dans une distribution qui se veut grand public.
Autant pour une distribution visant les "power users", cela pourrait se comprendre, autant dans ce cas de figure cela aurait été un choix très contestable et risqué.

Certain, c'est utilisé par urpmi depuis la 2007.0 ou 2007.1 je crois, en tout cas je l'ai utilisé dans des paquets depuis la 2008.0.
J'ai jeté un coup d'oeil, et à priori c'est implémenté dans rpm depuis 2005.

Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.

Bah si c'est leur position, je trouve ça ridicule, s'il ne veulent pas d'un Suggest: xxxx, ils n'ont qu'à pas le mettre dans leur spec. A ce moment là il faudrait qu'ils suppriment complètement la gestion des dépendances, certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.

Certain, c'est utilisé par urpmi depuis la 2007.0 ou 2007.1 je crois, en tout cas je l'ai utilisé dans des paquets depuis la 2008.0.
J'ai jeté un coup d'oeil, et à priori c'est implémenté dans rpm depuis 2005.

Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.

Bah si c'est leur position, je trouve ça ridicule, s'il ne veulent pas d'un Suggest: xxxx, ils n'ont qu'à pas le mettre dans leur spec. A ce moment là il faudrait qu'ils suppriment complètement la gestion des dépendances, certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.