Fedora 14, nom de code Laughlin, est enfin disponible au téléchargement après des mois de travail, accompagné d'un portail rénové aux couleurs de sa communauté. Quelles sont les nouveautés de Fedora 14 ?
Pour les utilisateurs du Bureau
Une multitude de nouvelles fonctionnalités pour les utilisateurs :
- libjpeg-turbo Charger et sauvegarder des images au format JPEG n'aura jamais été aussi rapide que sous Fedora 14 !
libjpeg-turbo est une implémentation optimisée qui divise par deux le temps de compression/décompression des images sur les machines disposant des jeux d'instructions MMX/SSE et un léger boost (de l'ordre de 25 %) pour les autres. libjpeg-turbo étant compatible ABI/API avec libjpeg, tous les logiciels peuvent en bénéficier sans réécriture, ni recompilation. Merci à Adam Tkac.
- Spice (Simple Protocol for Independent Computing Environments) fournit aux utilisateurs une expérience du bureau distant amélioré.
Celui-ci pose les fondations pour la prise en charge de l'accélération matérielle graphique, du chiffrement, du curseur « matériel », mais également de l'audio. Pour le moment, le support de Spice a été intégré dans l'hyperviseur Qemu/KVM et des pilotes pour les systèmes invités X11 et Windows (XP, Vista et 7) sont disponibles. Spice est une technologie libérée par Red Hat en décembre 2009 suite au rachat de Qumranet en 2008. Qumranet est également à l'origine de l'hyperviseur KVM intégré au noyau Linux. Merci à l'équipe virtualisation de Red Hat à l'origine de ce projet.
Bien évidemment GNOME 2.32, KDE 4.5 SC et XFCE 4.6.2 sont au rendez-vous
Pour les développeurs.
Les développeurs ont été particulièrement gâtés :
- Prise en charge de Milkymist Les développeurs pourront développer sur Milkymist, une carte de développement embarqué libre sur Fedora 14.
Merci à l'équipe du Fedora Electronic Lab.
- D Fedora 14 introduit la prise en charge de D, un langage de programmation système combinant la puissance et les performances de C++ et la productivité des langages modernes tels que Python et Ruby.
L'environnement est basé sur le compilateur LDC qui repose sur l'infrastructure LLVM et la bibliothèque standard Tango, d'autres bibliothèques sont disponibles (Mango pour le réseau, Derelict pour le multimédia, etc.) sur les dépôts standard ou le dépôt D. Merci à Jonathan Mercier.
- Mise à jour de Python 2 La version système de Python passe en version 2.7.
Python 2.7 facilite la migration vers Python 3.1 et constitue la dernière version majeure de Python 2.x. Merci à Dave Malcolm.
- GNUStep Un framework de développement pour le langage de programmation Objective-C.
Merci à Jochen Schmitt.
- Outils de débogage mémoire Le nouveau paquetage « gdb-heap » ajoute la commande « heap » à gdb qui permet d'analyser l'utilisation de la mémoire dynamique par un processus.
Merci à Dave Malcolm qui a développé cette fonctionnalité au sein de Fedora.
- Rakudo Star Une implémentation de Perl 6.
Perl 6 est la dernière itération du langage Perl qui fut à l'origine de nombreuses innovations des langages de programmation. Merci à Gerd Pokorra, Christoph Wickert et Marcela Mašláňová.
Mais également un environnement de développement Gtk3, un jeu enrichi de modules pour Python3 (Qt4), la disponibilité de PySide les bindings Python Qt développé par Nokia en LGPL, etc.
Pour les administrateurs systèmes
Et nous n'avons pas oublié les administrateurs systèmes :
- Une image Fedora 14 (AMI) sera disponible pour les utilisateurs du service de cloud computing EC2 d'Amazon, qui sortira en parallèle de la version « classique ». Merci à Justin M. Forbes.
- ipmiutil Fedora intègre un utilitaire de gestion de serveur IPMI amélioré avec ipmiutil. Merci à Andy Cress qui est également le mainteneur upstream du projet.
- virt-v2v facilite la migration des machines virtuelles Xen vers l'hyperviseur KVM.
- Un dépôt Virtualization Technology Preview permet de tester les derniers développements en matière de virtualisation. Merci à l'équipe virtualisation de Red Hat.
- Varnish a été mis à jour et apporte une meilleure mise à l'échelle ainsi que des nouvelles fonctionnalités de journalisation.
- Apache a été mis à jour et inclus un grand nombre de modules et mises à jour de sécurité.
- Systemd En dernier, mais pas le moindre, Fedora 14 intégre une tech preview de systemd, le système d'init nouvelle génération pour un démarrage plus rapide et une multitude de fonctionnalités avancées. Merci à Lennart Poettering qui est également le mainteneur upstream.
Et ce n'est qu'un début ! Des mises à jour de nombreux paquetages comme d'habitude seront disponibles dans Fedora 14. Une liste plus complète des nouvelles fonctionnalités intégrées à Fedora 14 est disponible sur :
http://fedoraproject.org/wiki/Releases/14/FeatureList Pour un tour rapide des fonctionnalités dans Fedora 14, visitez nos notes de versions abrégées :
http://fedoraproject.org/wiki/F14_one_page_release_notes Les notes de versions de Fedora 14 et divers guides disponibles dans différents langages sont à votre disposition sur :
http://docs.fedoraproject.org/ Les bogues connus de Fedora 14 sont répertoriés sur cette page :
https://fedoraproject.org/wiki/Common_F14_bugs
Il ne vous reste plus qu'à la télécharger. N'attendez plus ! Si vous mettez à jour depuis une version précédente de Fedora, référez-vous à :
http://fedoraproject.org/wiki/Upgrading Fedora a pris soin de faire de preupgrade une solution plus robuste et de corriger des bogues dans les précédentes versions de Fedora afin de faciliter la mise à jour vers Fedora 14.
Fedora Spins
Les spins Fedora sont des versions alternatives de Fedora, conçus pour divers usages avec une sélection d'applications ou personnalisations différentes. Ils sont disponibles à l'adresse :
http://spins.fedoraproject.org
Cela comprend les spins :
- Mobility MeeGo est un système d'exploitation et kit de développement pour les plateformes mobiles nouvelle génération, issu de la fusion des projets Moblin et Maemo (respectivement maintenu par Intel et Nokia).
- Sugar Un spin basé sur l'environnement d'apprentissage collaboratif Sugar.
- KDE Un spin utilisant KDE comme environnement de bureau par défaut.
- XFCE Un spin utilisant XFCE comme environnement de bureau par défaut.
Contribuez
Pour plus de renseignements sur les bogues connus, et des conseils sur la bonne manière de rapporter les bogues, veuillez vous référer aux notes de versions :
http://docs.fedoraproject.org
Il y a différentes manières de contribuer au-delà des rapports de bogues. Vous pouvez aider à traduire les logiciels et contenus, tester et faire des retours sur les mises à jour, écrire de la documentation, créer des graphismes, aider à promouvoir Fedora, empaqueter des logiciels libres pour les millions d'utilisateurs de Fedora à travers le monde. Pour commencer, visitez dès maintenant http://join.fedoraproject.org !
Fedora 15
Alors même que nous continuons à fournir des mises à jour pour améliorer Fedora 14, nous sommes déjà en train de développer notre prochaine version, Fedora 15 en parallèle, et ce depuis plusieurs mois déjà. Nous prévoyons une sortie à partir de fin avril 2011 : https://fedoraproject.org/wiki/Releases/15/Schedule
Aller plus loin
- Obtenir Fedora 14 (156 clics)
- DLFP : annonce Fedora 14 béta (10 clics)
- Portail fedoraproject.org (9 clics)
- Liste des fonctionnalités retenues (16 clics)
- Mise à jour de Fedora (12 clics)
- Documentation fedoraproject.org (11 clics)
# Youpi !!!
Posté par napster2core . Évalué à 3.
Si tu ne sais pas demande, si tu sais partage !
[^] # Re: Youpi !!!
Posté par Jimmy . Évalué à 10.
J'étais quand même moins zen avec yum pour une grosse màj comme ca, que sur mon autre bécane qui est passée tout en douceur de lenny (+backports +puredyne) à squeeze. Par exemple, il faut (fallait ?) 3 fois plus d'espace disque avec yum, car il ne fait pas la décompression et le nettoyage au fur et à mesure de l'installation des packages.
Tiens, c'est quoi le truc tout poilu qui vient de passer ?
[^] # Re: Youpi !!!
Posté par IsNotGood . Évalué à 2.
[^] # Re: Youpi !!!
Posté par zecrazytux (site web personnel) . Évalué à 6.
> supportée en utilisant uniquement Yum. Il FAUT passer par Anaconda qui est l'installeur
pratique.
[^] # Re: Youpi !!!
Posté par Adrien BUSTANY (site web personnel) . Évalué à 2.
[^] # Re: Youpi !!!
Posté par IsNotGood . Évalué à 1.
[^] # Re: Youpi !!!
Posté par nimnim . Évalué à 2.
[^] # Re: Youpi !!!
Posté par Albert_ . Évalué à 4.
Par rapport a ce qui a ete dit sur cette nouvelle:
- Yum c'est plus lent, cela s'ameliore mais c'est lent, au passage pisi qui est aussi en python va beaucoup plus vite...
- Yum ce n'est pas fait pour les upgrades de la distribution
- Yum ne gere pas les desinstallation vraiment proprement et laisse un gros bazard derriere lui.
Je ne vois pas trop les avantages de ce dernier par rapport a apt sauf les delta-rpm mais c'est plus le format que l'outil donc...
[^] # Re: Youpi !!!
Posté par Aurélien Bompard (site web personnel) . Évalué à 1.
[^] # Re: Youpi !!!
Posté par Albert_ . Évalué à 0.
[^] # Re: Youpi !!!
Posté par GeneralZod . Évalué à 6.
apt ne supporte que le format dpkg, apt4rpm est un portage réalisé par Conectiva. Ça n'a jamais été un projet bien supporté (Conectiva a préféré développé smart, le projet est resté longtemps sans mainteneurs), et niveau performances, il n'a rien à voir avec son parent (en 2006: yum était déjà 2x plus rapide et avant même le parseur de métadonnées en C).
L'intérêt de yum c'est son architecture extensible qui permettent son utilisation un peu partout dans l'infrastructure Fedora, ce qui aurait été plus difficile avec apt4rpm ou aurait nécessité de réécrire en grande partie l'outil.
Entre un fork foireux et un outil activement maintenu, le choix est vite vu.
[^] # Re: Youpi !!!
Posté par Albert_ . Évalué à 2.
L'intérêt de yum c'est son architecture extensible qui permettent son utilisation un peu partout dans l'infrastructure Fedora
Je dois avouer que je ne comprend absolument pas ce que tu racontes la.
[^] # Re: Youpi !!!
Posté par GeneralZod . Évalué à 6.
Pour l'utilisateur, ça permet une plus grande flexibilité, les plugins rajoutent des options de configuration, de nouvelles commandes.
Toi, tu ne vois peut-être pas l'intérêt mais ça n'est pas le cas des mainteneurs et de la plupart des utilisateurs.
[^] # Re: Youpi !!!
Posté par Albert_ . Évalué à 2.
[^] # Re: Youpi !!!
Posté par kowalsky . Évalué à -1.
[^] # Re: Youpi !!!
Posté par Steph . Évalué à 2.
J'aimerai bien voir des données factuelles, basées sur des benchmarks sérieux des dernières versions, qui puissent étayer cette affirmation.
Car il ne faudrait que ce qui a été vrai un moment devienne juste un poncif, une idée reçue.
Est-ce que apt gère les "delta-rpms" ou quelque chose d'équivalent, qui permet de gagner un temps considérable lors des mises à jours ?
[^] # Re: Youpi !!!
Posté par Spack . Évalué à 2.
[^] # Re: Youpi !!!
Posté par GeneralZod . Évalué à 3.
Rien qu'avec les options -C et --noplugins, je divise de 4 à 10 fois, le temps de recherche d'un paquet, donc au final, l'écart de performance entre yum et apt-* doit être très faible. J'ai même observé des cas où yum était même plus réactif qu'apt-get (cache récent, peu de plugins installés etc ...)
[^] # Re: Youpi !!!
Posté par barmic . Évalué à 4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Youpi !!!
Posté par BAud (site web personnel) . Évalué à 2.
vraie question : J'aimerai bien voir des données factuelles, basées sur des benchmarks sérieux des dernières versions, qui puissent étayer cette affirmation.
Car il ne faudrait que ce qui a été vrai un moment devienne juste un poncif, une idée reçue.
Notamment la place prise sur les miroirs lorsqu'il y a par exemple 5 mises à jour d'un paquet de OOo (au hasard) et le temps que cela prend d'effectuer le calcul de dépendances supplémentaires (côté client cette fois-ci).
[^] # Re: Youpi !!!
Posté par dinomasque . Évalué à 3.
Je suis également consterné par le temps qu'il lui faut pour installer plusieurs gros bidules.
Pour faire la "même chose" avec une Debian-like c'est beaucoup plus rapide.
Après si il faut passer du temps à comprendre le bousin et à réinventer son paramétrage par défaut pour obtenir des performances à peu près acceptables, c'est qu'il y a un très grave problème ...
BeOS le faisait il y a 20 ans !
[^] # Re: Youpi !!!
Posté par Albert_ . Évalué à 3.
Comme tu dis c'est soit problematique soit pas tres user -friendly et en contradiction avec les affirmations que apt c'est complique a cause de sa semantique.
Ce que j'ai pu voir aussi c'est que c'est lent juste pour faire un upgrade (l'equivalent de update pour apt) avec juste 3 repos. Alors ou c'est subjectif car je ne chronometre pas mais generalement la subjectivite est un bon indicateur de lenteur (malheureusement)
[^] # Re: Youpi !!!
Posté par cdeblesson . Évalué à 1.
Testé sur 2 machines différentes, (un core2 e4500 et un core i7 920QM) et la reconstruction des paquets d'après les deltas se traine à environ 500 Ko/s en pointe, ma connexion ADSL est plus rapide.
Je vote pour grâce à l'économie de bande passante et de ressources serveur, mais ça rame...
[^] # Re: Youpi !!!
Posté par popoi . Évalué à 2.
habitué à aptitude sur debian sid, j'ai essayé f13 pour "changer"
Certes, les delta-rpm m'impressionnent toujours autant de part la faible quantité à télécharger, mais après, houlala, qu'est ce que c'est lent! Et ça n'est pas compensé par le dl rapide des delta-rpms
J'ai quand meme tenu 4 jours :D (j'ai battu mon propre record avec yum)
On va voir avec fedora 14, l'espoir fait vire :)
[^] # Re: Youpi !!!
Posté par mathgl . Évalué à 1.
# question
Posté par Albert_ . Évalué à 2.
Ca marche sans probleme en rajoutant ce qu'il faut dans /etc/yum.repos.d mais c'est pas tres "user friendly".
Autrement dans les tests que j'ai fait avec une machine virtuelle ca semble pas trop mal. Lorsque j'aurai un peu de temps a perdre je tenterai l'installation pour de vrai.
[^] # Re: question
Posté par IsNotGood . Évalué à 3.
Typiquement, ça sera une url et le navigateur lancera automatiquement le programme qui va bien.
[^] # Re: question
Posté par Albert_ . Évalué à 3.
# Il faut vraiment que je change de distrib
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à -5.
libjpeg-turbo Charger et sauvegarder des images au format JPEG n'aura jamais été aussi rapide que sous Fedora 14 !
libjpeg-turbo est une implémentation optimisée qui divise par deux le temps de compression/décompression des images sur les machines disposant des jeux d'instructions MMX/SSE et un léger boost (de l'ordre de 25 %) pour les autres. libjpeg-turbo étant compatible ABI/API avec libjpeg, tous les logiciels peuvent en bénéficier sans réécriture, ni recompilation. Merci à Adam Tkac.
ça maintenant... c'est vraiment un truc qui me manque.... ou pas. Non mais franchement à part l'aspect technique qui peut être intéressant, qui aujourd'hui est intéressé par une lib qui charge/sauvegarde plus vite les JPEG ?
Alexandre COLLIGNON
[^] # Re: Il faut vraiment que je change de distrib
Posté par claudex . Évalué à 6.
Les gens qui vont sur le Web? Ceux qui ont un appareil photo compact?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Il faut vraiment que je change de distrib
Posté par Zenitram (site web personnel) . Évalué à 10.
- Images faisant plus d'1 Mo de nos jours
- Des centaines d'images dans un répertoire.
- création des thumbails.
Ben oui, la photo numérique est passée par la...
Bon, maintenant, en faire 3 lignes dans une annonce de sortie d'une distro entière, ça fait effectivement un peu peur sur le contenu de cette version...
[^] # Re: Il faut vraiment que je change de distrib
Posté par JoeltheLion (site web personnel) . Évalué à 4.
[^] # Re: Il faut vraiment que je change de distrib
Posté par duf . Évalué à 4.
[^] # Re: Il faut vraiment que je change de distrib
Posté par Zenitram (site web personnel) . Évalué à 1.
https://linuxfr.org/~hsyl20/30379.html
Car c'est la définition même de "un énorme changement qui casse tout' :).
[^] # Re: Il faut vraiment que je change de distrib
Posté par El Titi . Évalué à 4.
Alors là j'ai envie de poser une question mais je vais laisser à quelqu'un d'autre le soin de la poser à ma place
http://linuxfr.org//comments/926189.html#926189
[^] # Re: Il faut vraiment que je change de distrib
Posté par GeneralZod . Évalué à 2.
On a migré toute l'infrastructure de CVS à git ce qui a demandé un temps d'adaptation non négligeable pour bon nombre de contributeurs, on a mis en place, les dépôts personnels, il y a eu une refonte du portail, GNOME3 a été repoussé à 2011, pour un cycle d'à peine 5 mois. La note positive est que la composition des images a été nettement moins ardue que d'habitude pour la béta et la finale (pour laquelle, il n'y a eu qu'une RC du jamais vu pour Fedora).
Pour répondre à la critique, même en période de vaches maigres, Fedora ne se contente pas de mettre à jour les paquets et d'apposer un label "nouveau", il y a quand même quelques innovations, et Fedora 15 promet d'être beaucoup plus rock'n'oll.
[^] # Re: Il faut vraiment que je change de distrib
Posté par El Titi . Évalué à 1.
Pour répondre à la critique, ..., il y a quand même quelques innovations, ...
lesquelles à part les 2 que tu as cité.
Et encore:
Les images se chargent plus vite ma bonne dame et pis Kévin pourra vous aider tous les jours sans prendre le thé chez vous.
En conclusion quel intérêt pour un utilisateur de base à passer à la 14.
Ceci justifiait t'il une version ?
Le passage à Git, il s'en tamponne, la montée de version des langages et des outils de dev, ou d'apache pareil.
Vraiment je me demande ce qu'il y a de différent par rapport à la jolie critique pointée en lien si ce n'est un parti pris.
A moins que ce ne soit l'effet rolling release.
[^] # Re: Il faut vraiment que je change de distrib
Posté par Albert_ . Évalué à 1.
Apres Gnome n'evolue plus depuis longtemps (enlever des options est une evolution mais bon pas dans le sens attendu ici) et donc comme le dit un des fedoriens la prochaine release a de grande chance d'etre rock'n roll avec l'integration de gnome3. Je sens que soit l'on va bien rigoler car ca va casser comme KDE4 soit on va pleurer car Gnome3 sera comme Gnome2 avec encore moins d'options et un petit changement d'interface (gnome-shell le pendant des activites de KDE4 ou unity un windomaker like).
Avec un peu de chance la grande nouveaute de Gnome3 sera gimp2.8.
[^] # Re: Il faut vraiment que je change de distrib
Posté par El Titi . Évalué à 3.
Il y a pas mal de changement dans la partie KDE avec le passage a KDE 4.5.2. Les activites sont enfin utilisable, digikam passe a la version 1.4 avec pas mal d'amelioration (perso j'aime bien la fonction de recherche des photos suivant leurs emplacement geographiques) etc
Ca c'est de base dans KDE.
Ah mais attends j'ai ma réponse toute faite aussi:
"
Donc le meilleur atout du logiciel libre, c'est une distribution générique sans innovations ?
Le rôle premier d'une distribution est certes de fournir un ensemble cohérent de paquets mais également de faire avancer les choses.
"
La suite ici:
http://linuxfr.org//comments/926201,1.html
[^] # Re: Il faut vraiment que je change de distrib
Posté par Albert_ . Évalué à 1.
Si Fedora a voulu faire une sorte de LTS pour cette version pourquoi pas. Visiblement ca va casser du petit bois la prochaine version donc autant avoir une version pas trop ancienne vers qui pointer les utilisateurs.
[^] # Re: Il faut vraiment que je change de distrib
Posté par Albert_ . Évalué à 2.
[^] # Re: Il faut vraiment que je change de distrib
Posté par El Titi . Évalué à 3.
Vraiment ?
Ah oui, en effet, il met des balises pour prevenir
"""
<troll>Ou qu'il cherche encore desesperement quelques nouveautes permettant de combler les vides de sa depeche ! GNOME 2.32 et son ChangeLog negatif n'aide pas !</troll>
"""
http://linuxfr.org//comments/1170346.html#1170346
[^] # Re: Il faut vraiment que je change de distrib
Posté par GeneralZod . Évalué à 2.
[^] # Re: Il faut vraiment que je change de distrib
Posté par El Titi . Évalué à 3.
[^] # Re: Il faut vraiment que je change de distrib
Posté par GeneralZod . Évalué à 3.
Certes, la plupart des nouveautés de F14 n'intéressent pas le grand public mais la différence majeure avec la distribution que tu mentionnes est le public visé: Fedora cible un public technophile et sensible à la thématique libriste, Ubuntu le grand public.
Pour le public concerné, les nouveautés mentionnés restent pertinentes.
Pour revenir sur la fameuse critique que tu me reproches, je ne vois aucune contradiction. Notre créneau, c'est faire avancer les technologies libres, même si on a calé la voile, avec F14 le contrat est toujours respecté. Si on prétendait être les leaders du bureau (presque) libre et qu'on se contentait de mettre à jour les paquets pour certaines versions, je ne dirais pas mais ça n'est pas le cas (remarque qu'à force de les critiquer, Canonical a fini par se sortir les doigts du cul: le projet ayatana promet de réaliser tout ou partie des revendications de celle-ci même si il faudra attendre 2011 pour observer des changements concrets).
[^] # Re: Il faut vraiment que je change de distrib
Posté par WhiteCat . Évalué à 6.
Et d'ailleurs libjpeg-turbo et KDE SC 4.5 sont les 2 seuls trucs qui m'intéressent de près dans cette F14.
Et puis quand on peux améliorer les performances de son PC gratuitement je suis plutôt pour. Plutôt que d'acheter un Core i7...
# Comment font ils ?
Posté par maderios . Évalué à 1.
Exemple: Digikam-1.5, introuvable chez Debian, même en instable ou expérimental est pourtant bien présent dans la dernière Fedora.
http://www.digikam.org/drupal/node/539
https://admin.fedoraproject.org/pkgdb/applications/Digikam?_(...)
http://packages.debian.org/search?keywords=digikam&searc(...)
Idem pour KDE-4.5
"L'art est fait pour troubler. La science rassure" (Braque)
[^] # Re: Comment font ils ?
Posté par monde_de_merde . Évalué à 3.
En bien ou en mal, je ne juge pas.
[^] # Re: Comment font ils ?
Posté par IsNotGood . Évalué à 10.
* Contrairement à ce que dit tcourbon, tout n'est pas accèpté chez Fedora, il y a des règles. Pour être un mainteneur reconnu, il faut faire ses preuves. Si un paquet n'est pas maintenu ou mal maintenu, il est viré.
* Contrairement à Debian, Fedora a des obectifs raisonnables. Fedora ne permettra jamais toutes les combinaisons possibles de mise à jour avec Yum (mise à jour d'un système actif) car même si c'est possible, c'est trop casse couille et ça bride trop. Il y a l'installeur Anaconda pour ça (qui bosse sur un système inactif). C'est un peu contraignant pour l'utilisateur, mais techniquement c'est justifié.
* Fedora n'hésite pas à "tout casser". Il n'y a pas de "rolling distribution" chez Fedora. Une distribution est alpha (ça explose de partout), puis beta, puis rc, puis final, puis maintenu. Debian se fait chier avec testing, etc.
* J'y reviens, mais Fedora a des objectifs raisonnables. Certains font des propositions, raisonnables au premier abord, mais chiantes à maintenir. Fedora n'en veut pas, c'est viré. L'ambition technique de Fedora est d'avoir des solutions clean (même si ça prend du temps à être développé). Les solutions techniques de Fedora étant clean, elles se retrouvent chez les autres distributions. Il y a très peu de "bricolage sans avenir" chez Fedora. Il en faut, mais Fedora le tient à un niveau faible. Ainsi la "force de frappe" de Fedora est principalement dans le R&D (recherche et développement ; en upstream notamment) et pas dans la maintenance de bricolages (ce que fait beaucoup Debian).
* J'y reviens encore, Fedora est raisonnable. Fedora ne va pas forcker Firefox par exemple ni faire son propre système de détection de matériel.
Il y a toute une philosophie chez Fedora et beaucoup de pragmatisme (mais en restant libre). Ce n'est pas évident à comprendre, mais ça donne des résultats sur le long terme.
[^] # Re: Comment font ils ?
Posté par gnumdk (site web personnel) . Évalué à 5.
Tu te fous de notre gueule là ? C'est bizarre, j'ai pas eu souvent à bosser sur fedora, mais à l'époque de hotplug (du temps de devfs donc), y'avait un truc de merde qui s'appellait kudzu, qui à chaque boot mettait le bordel dans la conf réseau alors que y'avait rien à toucher et que hotplug avait fait son taf...
[^] # Re: Comment font ils ?
Posté par Aurélien Bompard (site web personnel) . Évalué à 2.
Kudzu, c'est effectivement un héritage de Red Hat 9, qui a été viré dès que possible (Fedora 9, ça a pris du temps à remplacer) : http://fedoraproject.org/wiki/Anaconda/Features/NoMoreKudzu
En tout cas tu ne le trouvera pas en F14.
[^] # Re: Comment font ils ?
Posté par rewind (Mastodon) . Évalué à 6.
[^] # Re: Comment font ils ?
Posté par ndv . Évalué à 0.
# 6 mois d'utilisation déjà
Posté par Spack . Évalué à 10.
Ce que j'aime :
- Les nouveautés. J'aime bien l'idée de Fedora de mettre en avant les nouveautés issues du monde des logiciels libres. On peut ainsi profiter des toutes dernières avancées et ne pas avoir l'air d'être à la traine.
- La stabilité. Bien qu'utilisant des logiciels assez jeunes Fedora 13 n'a pas trop planté. Certes j'ai eu des plantages de GNOME durant un transfert NFS ou un plantage de Flash dans Firefox qui fait planter tout Metacity et divers autres bugs mais dans une certaine mesure l'ensemble est positif.
- L'intégration. Tout est configuré dès l'installation. On dispose de pas mal d'outils pour configurer le système sans avoir besoin de la ligne de commande. On est averti de l'arrivée de nouvelles mises à jour, plymouth offre un écran de démarrage agréable, le pare-feu se configure en deux clics, on peut facilement envoyer un rapport de bug, l'outils se chargeant de télécharger les paquets qui vont bien, etc..
Du coup on passe son temps à vraiment utiliser son système plutôt que de passer des plombes dans la configuration de ce dernier.
Bien sûre ce n'est pas tout positif, parfois ça ne fonctionne pas. Par exemple, un NetworkManager qui se déconnecte de façon intempestive du Wifi après une mise en veille (ou qui refuse de se connecter) et où il faut ruser avec un déchargement de module et un redémarrage du service. Ou encore le bluetooth qui détecte les appareils mais ne va pas plus loin. Ou un pulseaudio vraiment trop intrusif...
Ce que je n'aime pas :
- Yum, et la gestion des paquets en général sous Fedora. Certes je clique sur un RPM et ça s'installe tout seul. Mais Yum comment dire ? C'est super lent, à chaque opération il faut qu'il jette un œil sur le net. Fedora m'espionnerait-il ? Il installe tout et n'importe quoi mais n'aime pas faire le ménage.
# yum install monSuperLogiciel
| Please wait while yum is sending your password to the Fedora team...
\ You don't ask for that but let me look for an update...
- Hum, what can I do now... Oh yes your software... Lets install it !
Installation:
monSuperLogiciel
monSuperLogiciel
dépendance1
dépendance2
dépendance3
dépendance4
dépendance5
Taille totale des téléchargement : 500 M
# yum remove monSuperLogiciel
| Oh you want to remove a software? Just a moment please I'm reading some news on LinuxFr...
Suppression:
monSuperLogiciel
Installed size: 0.5 M
PS: I let you look for the installed dependances, I've something to do on the net.
Je n'aime pas le fait que Yum veuille tout le temps se mettre à jour sans que l'on ne demande quoi que ce soit. Au moins que cela soit fait par une tâche cron mais quand je veux installer un logiciel j'aimerais que ça aille plus vite. De plus les dépendances sont laissées sur le système et les outils pour les retrouver sont vraiment inutiles.
Je n'aime pas non plus le update qui est en fait un upgrade.
La recherche de logiciels est chaotique. Yum affiche tout et n'importe quoi et on se perd dans les résultats.
Bref moi qui aime contrôler finement ce que j'installe sur mon système avec Yum c'est impossible. Au bout de 6 mois je suis bon pour une réinstallation complète.
Sur ce point vive APT !
- Le manque de paquets. Les paquets sont rares sur Fedora et en plus ils en refusent. Du coup il faut jongler entre les différents dépôts pas toujours très net. Si je veux éditer du MP3 sur Fedora, je ne peux pas avec les paquets du dépôt officiel. Audacity n'étant pas compilé avec le support du MP3.
- La mise à jour. Debian m'a habitué à juste changer un mot pour passer d'un système à l'autre. Sur Fedora, une mise à jour se traduit par la gravure d'un nouveau CD.
- Le panel GNOME. Ce n'est pas forcément lié à Fedora mais le panel GNOME me fatigue à toujours réorganiser les éléments qui le compose. Cela arrive surtout lorsque j'ai branché (ou débranché) un écran.
- La gestion du multi-écran. Encore une fois pas directement lié à Fedora mais j'utilise deux écrans au quotidien. Et malheureusement, cela n'est pas reconnu comme deux écran mais bien comme un seul grand écran. Cela se traduit par la perte d'une fenêtre ou du pointeur de la souris dans l'écran ayant la plus petite résolution.
Avec GNOME, il ne faut surtout pas déplacer les icônes du bureau sous peine de ne plus les revoir quand on débranchement le deuxième écran. En effet, GNOME positionne ses icônes de façon relative aux bords de l'écran. Donc si on déplace ceux-ci, leur position sera hors de notre écran principale lorsque l'écran secondaire sera débranché.
Et bien sûre, le support de la détection à chaud d'un nouvel écran. xrandr améliore la chose mais il est tant que dès que je branche mon écran que celui-ci soit configuré automatiquement.
Il y a sûrement des points positifs ou négatifs que j'ai oubliés mais le principal est là. Fedora reste cependant un système que j'aime utiliser. Certain point me font manquer Debian mais je vais donner une autre chance à cette nouvelle sortie avant de me décider.
[^] # Re: 6 mois d'utilisation déjà
Posté par Alkana . Évalué à 0.
pourquoi ne pas utiliser preupgrade ?
[^] # Re: 6 mois d'utilisation déjà
Posté par barmic . Évalué à 4.
C'est pas supporté ?
Si t'envoie un rapport de bug tu te fais envoyer bouler ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: 6 mois d'utilisation déjà
Posté par Sufflope (site web personnel) . Évalué à 2.
Je sais pas pourquoi il dit que preupgrade c'est à tes risques et périls vu que c'est LA solution recommandée pour mettre à jour une Fedora...
Ce qui est indiqué comme « si ça pète il te reste ta bite, ton couteau, et tes yeux pour pleurer » c'est un gros yum upgrade de porky après avoir modifié les dépôts. Ce qui est recommandé est preupgrade. Quant à graver le CD de la nouvelle version pour démarrer dessus et màj, OK ça doit marcher mais euh osef vu qu'il y a preupgrade (ou alors faut avoir du temps à perdre pour faire comme ça).
[^] # Re: 6 mois d'utilisation déjà
Posté par Adrien BUSTANY (site web personnel) . Évalué à 2.
c'est assez irritant parfois, mais tu peux utiliser l'option -C pour empêcher ça. Apt reste plus rapide, mais j'aime la flexibilité de yum (le fait de pouvoir mixer les releases facilement par exemple)
> Le manque de paquets
Ce que tu mentionnes (le non support du mp3) n'est pas lié à une paresse des packagers, mais à une décision morale de fedora. Si tu installes les dépôts rpmfusion, tu as accès à tous les paquets pour lire du mp3 etc. Peut être pas autant que debian, mais pas mal quand même.
> La mise à jour
Tu n'es pas obligé de graver un CD pour mettre à jour, preupgrade fait ça très bien depuis ton système existant.
> Le panel GNOME
En effet, pas lié à fedora du tout, fedora s'applique à livrer les logiciels aussi proches de l'upstream que possible. Donc le panel gnome qui sait pas bien gérer les changements de résolution, c'est la "faute" de gnome :)
> La gestion du multi-écran
Ceci dépend beaucoup de ta carte graphique. XRandr est supporté par les pilotes libres (intel, nouveau, ati etc.). Perso le hotplug marche tout seul quand je branche un écran sur ma carte intel. Si tu utilises le driver nvidia proprio... C'est à tes risques, sous fedora qui n'a pas choisi de le supporter.
[^] # Re: 6 mois d'utilisation déjà
Posté par Littleboy . Évalué à 7.
Plutot une decision technique de se conformer a la loi US et ignorer les pays ou la loi est moins contraignante. J'appellerais pas ca de la paresse, mais c'est un choix qui permet de simplifier la gestion du PR, de la distrib et des mirroirs.
Et le choix moral, quand ils signent des accords de licence pour certains brevets et payent leur detenteurs pour permettre la redistribution, c'est quand meme un peu du foutage de gueule.
La raison serait plutot que les codecs son et audio, c'est pas une priorite pour leur marche cible (les entreprises) et donc c'est idiot de claquer de la tune la-dedans. Quand c'est au niveau bases de donnees, la morale passe vite a la trappe...
Donc le panel gnome qui sait pas bien gérer les changements de résolution, c'est la "faute" de gnome :)
Mmmmmh, il me semble qu'une boite se felicitait il n'y a pas longtemps d'etre un des contributeurs majeurs a Gnome, mais je ne me souvient plus du nom. Ca va surement me revenir, mais il me semble que ca commence par un R.
[^] # Re: 6 mois d'utilisation déjà
Posté par Aurélien Bompard (site web personnel) . Évalué à 3.
Ce que tu décris est une décision légale, pas technique.
Fedora est une association administrativement située aux USA, il faut donc qu'elle en respecte la loi, c'est pas plus compliqué que ça.
> Et le choix moral, quand ils signent des accords de licence pour certains brevets et payent leur detenteurs pour permettre la redistribution, c'est quand meme un peu du foutage de gueule.
Bon, c'est bien beau de se moquer des pays où les brevets logiciels obligent à faire n'importe quoi, mais plutôt que de dépenser ton énergie ici tu devrait aller soutenir la Quadrature.
Pour ce qui est de Red Hat, on ne peut pas vraiment mettre en doute leur engagement contre les brevets logiciels (une petite recherche rapide te le confirmera). Ignorer les brevets logiciels, qui font partie de leur loi, ce n'est pas une méthode pour lutter contre (autant que le piratage de MS Office n'est pas une méthode pour lutter contre son monopole).
[^] # Re: 6 mois d'utilisation déjà
Posté par Littleboy . Évalué à 2.
Le rapport avec la phrase que tu cites au dessus?
Sinon, perso, la Quadrature et tout ce qui tourne autour, c'est pas pour moi (trop politise), et de toute facon, j'habite plus en France depuis un moment (ici les groupes de pression contre les brevets ont pas besoin de quemander pour pouvoir continuer a vivre).
(une petite recherche rapide te le confirmera)
Une recherche rapide te confirmera aussi qu'ils ont bien signe des accords de licence, en payant (on sait pas combien, c'est vire des copies des accords dispo au public) quand ca touchait a leur business. Ils avaient le choix de virer la fonctionnalite (comme il le font pour le MP3 et les codecs videos) et pourtant ils ont choisi de payer.
Je ne met pas en doute leur engagement contre les brevets logiciels, seulement leurs decisions qui varient selon que c'est important (on paye pour utiliser des trucs brevetes) ou pas (on vire tout) pour leur business, et donc la fragilite de l'excuse "c'est brevete" pour la non-fourniture de codecs MP3 & x264
[^] # Re: 6 mois d'utilisation déjà
Posté par Aurélien Bompard (site web personnel) . Évalué à 2.
Les brevets logiciels posent aussi un problème que tu n'as peut-être pas vu : s'il faut acquérir une licence (même pour 1 centime), ça bloque la redistribution, ce qui est contraire à la GPL (v2).
Avec les brevets sur le mp3 & co, on ne peut pas payer une fois (même une grosse fois) et couvrir non seulement les utilisateurs directs mais aussi ceux à qui ceux-ci auraient redistribué la version.
Le mode de fonctionnement des BL est complètement opposé à celui du LL, on n'y peut rien.
La seule chose que peuvent faire les distribs c'est :
- ne pas inclure le MP3, et proposer un mode de récupération légal (par exemple les codecs Fluendo, ou les codecs libres classique pour ceux en dehors des pays où les brevets logiciels ont cours)
- ignorer le problème, ce qui est tout à fait légal si on est domicilié en dehors de ces mêmes pays
Je ne connais pas cette autre histoire de brevets dont tu parles (la recherche rapide n'a rien donné), mais ce que tu disais au-dessus c'est que Red Hat a payé pour permettre la redistribution. On est donc pas du tout dans le même cas.
[^] # Re: 6 mois d'utilisation déjà
Posté par Littleboy . Évalué à 1.
Le mode de fonctionnement des BL est complètement opposé à celui du LL, on n'y peut rien.
Tu te contredit plus bas lorsque tu dis que Redhat a paye pour permettre la redistribution (ce qui est vrai).
A noter que ca ne concerne que le projet en question (plus ses ancetres et derives). Donc projet concurrent utilisant ces memes choses brevetees = baise.
Ca ne marche en effet que si la personne detentrice des brevets est prete a accepter un deal pour autoriser la redistribution (mais ca tu peux pas le savoir sans demander...)
Je ne connais pas cette autre histoire de brevets dont tu parles (la recherche rapide n'a rien donné)
"redhat patents settlement" dans Google.
Ca concerne JBoss et Redhat contre Firestar & Datatern (une analyse au hasard ici: http://www.groklaw.net/article.php?story=20080611191302741 )
Plus recemment, ils ont eu des problemes avec Acacia - oui, les memes contre qui ils avaient gagne la derniere fois - ( http://blog.internetnews.com/skerner/2010/10/red-hat-settles(...) ) et ont trouve un accord (et n'ont pas l'air de trop vouloir en parler...).
[^] # Re: 6 mois d'utilisation déjà
Posté par Aurélien Bompard (site web personnel) . Évalué à 2.
* Les détenteurs de brevets sur le mp3 ne veulent pas accorder de licence redistribuable. Donc déjà, là c'est mort pour les distribs concernées par les BL.
* Les licences sur les brevets achetés par RH, eux, permettent la redistribution : pas pareil du point de vue de la conformité GPL.
C'est plus clair là ?
Ensuite, comme tu le fais remarquer, ça ne couvre pas les autres entités qui utiliseraient les mêmes choses brevetées. Mais là, franchement, la seule solution c'est de faire sauter le brevet, ou de racheter la boîte. La vraie bonne solution étant de pousser pour abandonner les brevets logiciels, et là-dessus RH fait ce qu'il peut.
[^] # Re: 6 mois d'utilisation déjà
Posté par Antoine . Évalué à 3.
Radiola ? Ils ont contribué le bouton de réglage du volume, je crois.
[^] # Re: 6 mois d'utilisation déjà
Posté par Albert_ . Évalué à 3.
sauf que rpmfusion est tout casse ou en tout cas inaccessible...
[^] # Re: 6 mois d'utilisation déjà
Posté par IsNotGood . Évalué à 3.
"yum --cacheonly". Voir aussi /etc/yum.conf.
"yum makecache" pour mettre TOUT le cache à jour (par défaut yum ne met à jour que le nécessaire pour la tache qu'il a à réaliser).
Il installe tout et n'importe quoi
C'est un peu du pipo. Ce qui est installé est justifié même si ce n'est pas insdispensable. Par exemple, des images de fond ne sont pas indispensables. Yum (en fait quand on réalise un "yum groupinstall") installe les images de fond. Les utilisateurs s'attendent à avoir des images de fond par défaut sur leur système.
NB: Tu as peut-être parfois utilisé "yum groupinstall" (typiquement via anaconda). Les groupes sont un niveau supérieur du gestionnaire de paquet. Il y a aura des éléments non indispensable mais que les utilisateurs attendent. "yum groupinstall XFCE" installe un bureau typique XFCE, pas le minimum.
On remarquera que Fedora n'utilise quasiment pas les meta-paquets (c'est fait avec les groupes et ils sont assez peu nombreux).
Sauf spécifié (ou par un programme qui utilise yum), yum n'utilise pas les groupes.
Je n'aime pas le fait que Yum veuille tout le temps se mettre à jour sans que l'on ne demande quoi que ce soit.
C'est une question de sécurité. Beaucoup de distributions s'en foutent, pas du tout Fedora. Chaque fois que yum fait une opération, il le fait avec les mises à jour. Si une mise à jour est disponible, il peut y avoir un patch de sécurité, Fedora l'installe. Si un dépôt est cassé au niveau des dépendances, ça peut arriver mais ça reste très exceptionnel, c'est corrigé rapidement et yum remarchera comme prévu dans un ou deux jours. Il y a aussi "--skipbroken".
De plus les dépendances sont laissées sur le système et les outils pour les retrouver sont vraiment inutiles.
Il y a des outils pour ça, mais j'ai arrêté de les utiliser tant c'est "sans intérêt". Pour faire court, Fedora s'en fout des dépendances laissées et qui ne sont pas utilisées. Si ce n'est pas utilisé, ça ne doit pas déranger (sinon faire un rapport de bug). En passant, c'est ce fait que Windows 7 ; il installe tout, ça ne bouffe que de l'espace disque. Le BIG problème est comment savoir qu'une lib n'est vraiment pas utilisée ? Si tout est contrôlé par yum(rpm), ça peut encore aller. Mais il y a aussi le problème des greffons (chargement dynamique). Désinstaller une lib que yum (rpm en fait) ne croit pas utilisée peut casser un programme. Donc Fedora ne fait pas le forcing à ce niveau.
Je n'aime pas non plus le update qui est en fait un upgrade.
C'est effectivement discutable, mais c'est la politique de Fedora. Ce n'est pas le cas de RHEL (qui a les mêmes outils mais une autre politique).
Certains "défauts" de Fedora n'en sont pas vraiment. C'est une "politique". On y adhère ou pas, mais il faut au moins la comprendre.
[^] # Re: 6 mois d'utilisation déjà
Posté par gnumdk (site web personnel) . Évalué à 7.
C'est quand même fou, t'es un un peu le PBPG de RedHat, quoi qu'on puisse dire sur ton OS, c'est toujours faux, en fait, Fedora c'est farpait un peu comme Windows...
J'adore ma distrib mais des défauts elle en a, à commencer par son gestionnaire de paquet (qui parfois me donne envie de me taper la tête contre les murs)... Debian a le meilleur gestionnaire de paquets mais à d'autres défauts... Bref, rien n'est parfait, et surtout pas Fedora (le surtout c'est pour te faire bondir :p)
[^] # Re: 6 mois d'utilisation déjà
Posté par kowalsky . Évalué à 4.
Le truc c'est que quand tu suis le developpement d'un OS, tu comprends les choix fait par la distrib et ce qui parait stupide pour une personne non informé a un sens.
Typiquement le coup de la lib non utilisé, il explique le pourquoi du choix réalisé.
Et le coup du yum -C, c'est pareil.
Les differents choix de Debian doivent tous avoir une justification.
Je ne trouve pas qu'il fasse de la mauvaise fois (comme PBPG d'ailleurs)
[^] # Re: 6 mois d'utilisation déjà
Posté par mornik . Évalué à 3.
Il y a des outils pour ça, mais j'ai arrêté de les utiliser tant c'est "sans intérêt". Pour faire court, Fedora s'en fout des dépendances laissées et qui ne sont pas utilisées. Si ce n'est pas utilisé, ça ne doit pas déranger (sinon faire un rapport de bug). En passant, c'est ce fait que Windows 7 ; il installe tout, ça ne bouffe que de l'espace disque. Le BIG problème est comment savoir qu'une lib n'est vraiment pas utilisée ? Si tout est contrôlé par yum(rpm), ça peut encore aller. Mais il y a aussi le problème des greffons (chargement dynamique). Désinstaller une lib que yum (rpm en fait) ne croit pas utilisée peut casser un programme. Donc Fedora ne fait pas le forcing à ce niveau.
Heu en quoi la comparaison avec wIn7 est utile ? C'est la référence en matière d'OS ? Moi je trouve pas ça normal. J'aime les OS qui utilisent des gestionnaires de dépendances intelligent qui font bien le ménage. Sur debian quand je retire qqch il retire les dépendances non utilisées. ça mange moins d'espace, et c'est plus propre. Et en plus ça donne un côté plus fini.
A chaque annonce d'une nouvelle version de Fedora, il y a toujours un hic dans la nouvelle version : yum trop lent, et pas propre.
Dommage pour un truc qui veux être à la pointe de la R&D.
[^] # Re: 6 mois d'utilisation déjà
Posté par claudex . Évalué à 3.
Et ça évite de démarrer des services qui ne sont plus utilisés.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: 6 mois d'utilisation déjà
Posté par rewind (Mastodon) . Évalué à 5.
Oser dire que yum planté un ou deux jours à cause d'un dépôt pourri c'est acceptable, ça me fait franchement rigoler. Dire que désinstaller les dépendances non-utilisées ça peut casser des paquets, c'est se foutre de la gueule du monde (je détaille après). Dire que les défauts de Fedora sont en fait une politique, c'est ce qu'on appelle du ridicule achevé (surtout après avoir tant craché sur les supposés défauts des autres distribution).
Sur cette histoire de paquet et de greffons, il y a deux cas. Partons du problème d'un paquet A qui peut charger dynamiquement une lib d'un paquet B et un paquet C qui dépend du paquet B. Si B a été installé via C, c'est que l'utilisateur ne s'en servait pas pour A donc on peut désinstaller B si on désinstalle C. Si l'utilisateur se servait de B, il l'a installé directement et donc, quand C est désinstallé, B ne l'est pas. En tout cas, c'est comme ça que fonctionne apt et ça me semble être assez naturel. Il n'y a aucun problème. Donc Fedora (ou IsNotGood) se fout de la gueule du monde.
[^] # Re: 6 mois d'utilisation déjà
Posté par Aurélien Bompard (site web personnel) . Évalué à 4.
Attaque directe spotted. Restons clames SVP, le projet Fedora ne se fout pas de la gueule du monde (c'est assez dur à faire quand on y pense), et je pense qu'IsNotGood est sincère.
Ce que tu décris est arrivé relavitement récemment dans yum (2 versions de mémoire), avant on ne stockait pas si un paquet était installé sur demande utilisateur ou par dépendance.
Donc maintenant qu'on a l'info, le plugin dont on parlait peut avoir le comportement que tu décris (j'ai jamais essayé personnellement mais je crois que c'est comme ça que ça marche).
[^] # Re: 6 mois d'utilisation déjà
Posté par Spack . Évalué à 1.
Un autre exemple, imaginons que j'ai oublié d'enlever le proxy de la configuration de Yum. Il va essayer de se connecter au serveur sans succès et en essayer un autre. Le problème est qu'il est impossible de l'arrêter avec un simple ^C... Ou du moins il faut insister.
Je n'ai pas d'exemple en tête mais je me rappelle avoir vu Yum (sans groupinstall) installer des dépendances qui certes ont un rapport avec le logiciel installé mais dont la nécessité me met en doute...
Concernant la mise à jour, on peut en effet utiliser preupgrade mais ce n'était pas la politique de départ de Fedora et je sentais mon système tellement sale qu'il me semblait nécessaire de faire une installation toute fraîche.
En parlant d'installation, je viens d'installer la nouvelle sortie. Je télécharge donc le Desktop Live CD et clique sur Installer sur le disque. Je me retrouve de base avec pas moins de 1071 paquets installés dont plein de logiciels que je ne souhaite pas forcément comme un serveur HTTP ou autre.
Certes c'est plus simple pour l'utilisateur qui ne veut pas s'embêter et qui a tout sous la main tout de suite. Mais n'est-il pas possible de donner le choix à l'utilisateur sans pour autant délaisser les ceux qui ne veulent pas se poser de questions ? A aucun moment il ne m'a été demandé de choisir les logiciels que je voulais installer.
Je n'aime pas la nouvelle mode qui dit que puisque la taille des disques augmente, on peut se permettre de les remplir. De la même façon, on se retrouve avec des logiciels qui se traînent car de toute façon maintenant les PC ont suffisamment de mémoire...
[^] # Re: 6 mois d'utilisation déjà
Posté par Albert_ . Évalué à 2.
[^] # Re: 6 mois d'utilisation déjà
Posté par Albert_ . Évalué à 2.
Euh tu n'as pas pire comme exemple? Moi ca me pete les c.... de voir qu'une installation minimale d'un systeme me prend 10 Gigs sur mon disque dur. Non je ne considere pas cela comme etant un detail. Dire que je croyais que le libre essayait de corriger les mauvaises pratiques de ce genre de systeme...
[^] # Re: 6 mois d'utilisation déjà
Posté par IsNotGood . Évalué à 2.
On n'est pas obligé de graver une CD. Je ne vais pas expliquer les différentes possibilités ici.
M'enfin, graver un CD tous les 6 mois, ce n'est pas la mer à boire.
- Le manque de paquets. Les paquets sont rares sur Fedora et en plus ils en refusent. Du coup il faut jongler entre les différents dépôts pas toujours très net. Si je veux éditer du MP3 sur Fedora, je ne peux pas avec les paquets du dépôt officiel. Audacity n'étant pas compilé avec le support du MP3.
Fedora est (vraiment ; dans la pratique) libre.
RpmFusion répond à la majorité de ses problèmes : http://rpmfusion.org/
[^] # Re: 6 mois d'utilisation déjà
Posté par Emmanuel Seyman . Évalué à 1.
Le manque de paquets tient essentiellement dans le fait que Fedora (dans son aspect communautaire) est plus jeune que Debian (8 ans contre 17+). Le retard se comble petit à petit, de release en release.
[^] # Re: 6 mois d'utilisation déjà
Posté par Dev8 . Évalué à 1.
# yum install monSuperLogiciel
"yum --remove-leaves erase monSuperLogiciel" ? (ou forcer dans /etc/yum/pluginconf.d/remove-with-leaves.conf, de mémoire)Installation:
monSuperLogiciel
dépendance1
dépendance2
dépendance3
dépendance4
dépendance5
Taille totale des téléchargement : 500 M
# yum remove monSuperLogiciel
Suppression:
monSuperLogiciel
Installed size: 0.5 M
PS: I let you look for the installed dependances,
Je n'aime pas non plus le update qui est en fait un upgrade.
Ah tiens, marrant moi je me dis exactement l'inverse quand je passe d'une Fedora à un Ubuntu...
Mais Yum comment dire ? C'est super lent, [...]
Y'a pire : zypper sous openSUSE ! (j'aime bien mais j'ai dû installer yum en parallèle :p )
[^] # Re: 6 mois d'utilisation déjà
Posté par Albert_ . Évalué à 5.
Sauf que yum est bien plus recent que apt et franchement faire l'inverse de apt au niveau des commandes c'est vraiment pour dire "moi je fais pas pareil".
[^] # Re: 6 mois d'utilisation déjà
Posté par Aurélien Bompard (site web personnel) . Évalué à 2.
[^] # Re: 6 mois d'utilisation déjà
Posté par Albert_ . Évalué à 2.
[^] # Re: 6 mois d'utilisation déjà
Posté par Aurélien Bompard (site web personnel) . Évalué à 6.
En plus, APT c'est beaucoup de lignes de code, c'est pas si simple que ça en a l'air.
Tout ça c'est de mémoire, mais vu que le développeur a jeté l'éponge, et que c'était manifestement un bon (il a fait smart après), j'imagine que ça devait être particulièrement chiant à maintenir.
[^] # Re: 6 mois d'utilisation déjà
Posté par nimnim . Évalué à 6.
1. il était codé proprement (pas encore optimisé, mais bien structuré). On peut optimiser du bon code, c'est très difficile de maintenir du code rapide mais bordélique
2. il utilisait le moteur de résolution de dépendances de rpm au lieu d'utiliser un algo différent lors de la résolution réseau, et espérer que rpm soit d'accord à l'installation (apt-rpm). Cela a permis :
a. de reprendre l'existant rpm sans rupture (simple bon sens pour Red Hat qui était n°1 sur son marché
b. d'écrire des règles de packaging rigoureuses, claires et détaillées, puisqu'il n'y a aucune ambiguïté sur le moteur de règles à respecter (tout passe par librpm et que par librpm), ce qui a permis d'assainir et améliorer la qualité de la distribution en général
3. il était intégrable simplement dans les autres outils Red Hat (Anaconda est en python, comme son nom l'indique). C'est complètement invisible pour les utilisateurs, mais aujourd'hui tous les outils Fedora/Red Hat (Anaconda, PackageKit, la ferme de compilation, Spacewalk, Satellite, Cobbler j'en passe et des meilleures) font appel à l'infrastructure yum et ça marche très bien.
Yum est un choix qui s'est révélé plus que judicieux avec le temps. Red Hat n'avait pas besoin d'un client d'installation type apt-rpm (ils avaient déjà leur propre bouse, up2date qui a heureusement été abandonnée) mais d'une vraie brique d'infrastructure avec laquelle ils pourraient construire d'autres applications. Le yum vu par l'utilisateur est juste un frontal shell, c'est une toute petite partie de ce que yum fait pour Fedora.
D'ailleurs Suse/Novell (qui avait aussi besoin de construire des infras autour de rpm) a écarté comme Red Hat tous les clients apt-like de l'époque, et a fini par écrire le sien de zéro. C'est ce qui leur a permis ensuite de construire https://build.opensuse.org/
[^] # Re: 6 mois d'utilisation déjà
Posté par GeneralZod . Évalué à 3.
C'est surtout que la sémantique des commandes apt-get est pourrie pour la majorité des utilisateurs finaux:
update ==> mise à jour du cache | mise à jour du système
upgrade ===> mise à jour du système | passage à la version supérieure
dist-upgrade ===> passage à la version supérieure, ça reste cohérent avec les autres commandes
je trouve la sémantique yum plus logique:
makecache ===> mise à jour du cache (fait automatiquement avec un timeout configurable ==> pour la majorité des utilisateurs, c'est le comportement par défaut souhaitable)
update ===> mise à jour du système
upgrade (via un plugin officiel) ===> passage à la version supérieure
Pour le passage à la version supérieure, Fedora n'étant pas une rolling release, il est recommandé d'utiliser un assistant (soit l'installeur Anaconda ou preupgrade) pour gérer les éventuelles incompatibilités et nettoyer le système des paquets obsolète. Pour ceux qui utilisent yum, il y a différentes possibilités, soit utiliser le switch --releasever avec la commande update pour définir la version (ou bien installer le paquet fedora-release correspond ce qui revient au même), soit utiliser le plugin upgrade-helper qui ajoute la commande upgrade.
Par ailleurs, tu peux désactiver le rafraichissement automatique du cache dans la configuration de yum:
metadata_expire = never
La jeunesse de yum par rapport à apt-get n'est pas une raison pour suivre les "travers" de celui-ci. Zypper d'OpenSuSE a un comportement similaire, la principale différence est que le rafraichissement automatique du cache est désactivé par défaut (il faut rajouter l'option auto-refresh pour l'activer).
[^] # Re: 6 mois d'utilisation déjà
Posté par Albert_ . Évalué à 2.
- update : resynchronisation des fichier d'index repertoriant les paquets disponibles.
- upgrade : installation de la plus recentes de tous les paquets presents sur le systeme
- dist-upgrade : meme chose que upgrade en y ajoutant une gestion intelligente des changements de dependances dans les nouvelles versions des paquets.
tire du man apt-get
[^] # Re: 6 mois d'utilisation déjà
Posté par GeneralZod . Évalué à 2.
La sémantique est cohérente mais elle n'est pas intuitive pour un nouvel utilisateur. D'autant plus, si il n'a jamais utilisé de système unix-like, faut expliquer les concepts de paquets, dépôts, cache (ou index si tu préfères), etc ...
> tes definitions de ce quelles font me semble legerement fausse
bonnet blanc et blanc bonnet, c'est du pareil au même.
[^] # Re: 6 mois d'utilisation déjà
Posté par Albert_ . Évalué à 2.
Avec synaptic (le plus vieux GUI pour les systemes de packages) ou les nouveau trucs tel les software center les nouvels utilisateurs ont enormement d'outils pour tout faire sans ecrire une seul fois apt-get et depuis bien plus longtemps que l'existence de yum.
Niveau nouvel utilisateur il faudrait que vous ameliorer enormement les rajouts de depots car ce n'est absolument pas intuitif.
bonnet blanc et blanc bonnet, c'est du pareil au même.
Ah ouhais? et je te souhaite bon courage pour faire une mise a jour du systeme avec uniquement apt-get update.
[^] # Re: 6 mois d'utilisation déjà
Posté par GeneralZod . Évalué à 2.
On peut difficilement faire plus simple que de cliquer sur un lien qui installe un paquet qui configure tout aux petits oignons.
> et je te souhaite bon courage pour faire une mise a jour du systeme avec uniquement apt-get update.
gni ? de quoi tu parles ?
[^] # Re: 6 mois d'utilisation déjà
Posté par Albert_ . Évalué à 2.
Si c'est fournit car pour l'exemple au dessus (peoplefedora) je n'ai pas trouve le rpm pour.
gni ? de quoi tu parles ?
je te cite:
update ==> mise à jour du cache | mise à jour du système
[^] # Re: 6 mois d'utilisation déjà
Posté par houra . Évalué à 2.
Ce genre d'arguties me laisse pantois.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: 6 mois d'utilisation déjà
Posté par GeneralZod . Évalué à 2.
[^] # Re: 6 mois d'utilisation déjà
Posté par Altor . Évalué à 4.
installpkg --> installe
removepkg --> désinstalle
upgradepkg --> met à jour le(s) packet(s)
avec un rsync en tâche cron sur les miroirs …
Sinon pour les feignants il y a slackpkg :
slackpkg update --> mise à jour du cache
slackpkg install, remove, upgrade --> même comportement que les pkgtools
slackpkg upgrade--all --> mise à jour de tous les logiciels
slackpkg clean-system --> nettoie le système de tous les logiciels non officiels
Pour le passage à la version supérieure :
#Changer la version dans le fichier /etc/slackpkg/mirrors
slackpkg update
slackpkg install-new
slackpkg upgrade-all
slackpkg clean-system
Bref un système simple, robuste, rapide et où il n'y a aucun problème de dépendance :)
[^] # Re: 6 mois d'utilisation déjà
Posté par WhiteCat . Évalué à -1.
Sérieux, faire 2 commandes pour mettre à jour son système avec apt je vois pas l'intérêt. Qu'est ce que j'en ai à foutre qu'il y ai une mise en cache ? Je veux mettre à jour le système : "yum update" et on en parle plus. C'est quand même plus simple que 'apt-get update"... attente... "apt-get upgrade".
[^] # Re: 6 mois d'utilisation déjà
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: 6 mois d'utilisation déjà
Posté par jadfa . Évalué à 1.
Bon, la lenteur de yum ne m'a pas choqué (utilisateurs urpmi vous me comprendrez) mais le manque de paquets, déjà plus (incroyable le boulot fait par la communauté Mandriva à ce niveau d'ailleurs).
J'ai aussi été désagréablement surpris de découvrir qu'ils avaient adapté d'OpenOffice à leur sauce (ça m'a pas sauté aux yeux à l'install).
Une remarque aussi: les fichiers de conf ne font pas 300 lignes commentées par les draktools: ça peut aider à comprendre certains dysfonctionnements, mais ça oblige aussi à RTFM pour trouver les options manquantes: un mal pour un bien dans les 2 cas.
Ah j'allais oublier SE-Linux qui est encore plus casse-machin que msec AMHA.
PS: qui peut me dire comment on empêche package-kit de me re-proposer à chaque fois des updates non souhaitées?
# Pourquoi je n'ai jamais installé fédora.....
Posté par xavier dumont . Évalué à 2.
[^] # Re: Pourquoi je n'ai jamais installé fédora.....
Posté par daimrod . Évalué à 8.
environement graphique avec virtualbox n'est pas tres realiste sur la
dite ``reactivite'' ?
[^] # Re: Pourquoi je n'ai jamais installé fédora.....
Posté par Albert_ . Évalué à 2.
[^] # Re: Pourquoi je n'ai jamais installé fédora.....
Posté par gnumdk (site web personnel) . Évalué à 2.
Installe tout et n'importe quoi sur ta Debian, tu vas voir si ça va pas ramer...
ps: quand je parles services, je parles bien sur /etc/*.d mais aussi /usr/share/autostart
[^] # Re: Pourquoi je n'ai jamais installé fédora.....
Posté par morphalus . Évalué à 1.
# Spin Mobility / Meego
Posté par tape . Évalué à 3.
De plus, certains ont des difficultés pour utiliser Meego avec une installation en parallèle d'autres environnements de bureau.
[^] # Re: Spin Mobility / Meego
Posté par tuxrouge . Évalué à 1.
peut-on passer à l'interface mobli/meego depuis une fedora "classique"
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comme d'habitude n'upgradez pas sous virtual box....
Posté par gnumdk (site web personnel) . Évalué à 4.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comme d'habitude n'upgradez pas sous virtual box....
Posté par Renault (site web personnel) . Évalué à -1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.