> Tu oublies que d'après un des acteurs de Libre Office qui l'avait dit à l'époque, le probléme des assignations de copyright avait été réglé dans openoffice.
Les propos de Sophie Gautier que tu cites date de septembre 2008 soit plus de 6 mois avant le rachat de Sun par Oracle et 2 ans avant la création de la Document Foundation et LibreOffice. Sun disposait d'un capital confiance non négligeable auprès de la communauté libre, Oracle not so much ===> le résultat: fork.
> Tu oublies aussi que derrière libre office au rayon développeur, il y a Novell, qui pratique le copyright assignment aussi sur ses projets.
nuance: certains de ces projets, dont le fameux Mono qui cru
> Ben voyons, c'est la seule raison qu'a eu red hat.
Au départ, c'est un projet personnel de Lennart qui a intéressé pas mal de monde en dehors de la communauté Red Hat/Fedora (Debian, Mandriva, SuSE, ArchLinux etc ...). Ce que tu oublies de mentionner c'est que le mainteneur d'Upstart a été très peu disponible pour faire évoluer celui-ci ou faire de la revue de patchs et que Canonical renacle à permettre à des personnes externes à la société de co-maintenir le projet. Le mainteneur d'Upstart a lui-même reconnu que son absence du projet a indirectement contribué à la naissance de systemd.
Et contrairement à ce que tu sembles croire, les plus fervents défenseurs d'Upstart dans Fedora sont des gens de RH.
> Couper l'herbe sous le pied d'un concurrent ne leur est même pas venu à l'idée
Un concurrent qui perds de l'argent et qui ne réalise même pas 5% de leur CA ?
> En cherchant, on ne trouverait pas des projets concurrents à d'autres projets déjà lancés, que red hat a lancé malgré qu'il n'y avait pas de problèmes de licenses ou autres?
Peut-être, mais le mot d'ordre chez RH étant de favoriser les projets déjà existants et de travailler le plus possible en upstream afin d'éviter à soi mais également aux autres de réinventer la roue, je pense que t'auras du mal à trouver.
> J'aime bien cette mentalité manichéenne pleine de méchants et de bons, c'est comme dans un film.
Tu devrais arrêter les westerns :]
> Pourtant, dès que Mark leur a demandé , ils ont baissé leur froc.
Je demande à voir les sources ... Parce que dans les faits, ce serait plutôt l'inverse.
En 3 ans d'utilisation de PulseAudio, je n'ai jamais eu à le configurer sur *mes* machines, tout marche sortie de la boite ! Pourtant le slogan de Fedora n'est pas "linux to human beings" ;-)
L'assignation de copyright repose sur un principe fondamental: la confiance, et ce n'est pas moi qui le dit mais la FSF ! Je trouve légérement ironique de citer OpenOffice alors que LibreOffice et la Document Foundation ont été créés justement à cause du déficit de confiance vis à vis d'Oracle et Scilab qui pendant très longtemps n'était pas libre et dont le développement repose sur un consortium industriel.
Vu le passif de Canonical, je comprenne que certains ne leur accorde pas le même degré de confiance qu'à la FSF ou l'ASF.
Dans le cas d'upstart, l'assignation du copyright a indirectement encouragé la création du projet concurrent systemd qui aurait pu être évité à peu de frais.
> Ça ne peut de toute façon faire que de bien au projet grâce au nombre de nouveaux utilisateurs qu'ubuntu va leur apporter.
Rien n'est moins certain, pour PulseAudio, l'intégration foireuse faite par Ubuntu lui a apporté un grand nombre de détracteurs mais ça ne s'est bizarrement jamais concrétisé en rapports de bogues ou soyons fous des patchs pour corriger les problèmes de PA ou de cette passoire d'ALSA !
À mon avis, c'est une arme à double tranchant, soit Canonical s'investit dans le projet (développement, correction de bogues, tests, filtre les rapports etc ...) et là oui, ça serait extrêmement bénéfique pour le projet, soit Canonical attends que le travail soit fait et lache un gros paquet mal ficelé et tu peux être certain que Wayland va se trainer une sale réputation pendant des décennies.
Et vu l'avancement du développement de Wayland, crois-moi, si le père Shuttleworth est sérieux (et on espère tous qu'il l'est !), il a intérêt à se retrousser les manches et à ouvrir le porte-monnaie.
Le mainteneur de Wayland estime que la transparence réseau dépasse le cadre de celui-ci mais que rien n'empêche d'intégrer ce genre de fonctionnalités par dessus Wayland (hint: spice). De plus, il est prévu de pouvoir faire tourner un serveur X par-dessus Wayland ne serait-ce que pour la transition. http://wayland.freedesktop.org/architecture.html
> Ce projet a été démarré par un certain Kristian Høgsberg membre de l'Intel OSTC
Kristian Høgsberg est l'auteur d'AIGLX et un contributeur majeur de X.org. Là où ça commence à devenir hautement trollifère, c'est de voir qui était l'employeur de Kristian jusqu'à début 2010, et de la majorité des contributeurs.
Ça va troller sec, moi, je vous le dis !
En lisant le script, je remarque que les radii de l'ellipse sont très petits (1 pixel vu que par défaut, tu es en mode absolu). Comme l'origine du système de coordonnées du moteur de dessin de Qt est situé dans le coin gauche supérieur et que par défaut, tu es en mode aliasé, ça ne me surprends pas vraiment que l'arrondi soit visible dans ce coin et approximé sur les autres (fais un zoom avec une visionneuse d'image).
Je pense que tu comprendras mieux en lisant la doc à ce sujet. http://doc.trolltech.com/4.7/coordsys.html
Si je change cette ligne, j'ai un beau rectangle avec des coins arrondis
> clipPath.addRoundedRect(3, 3, 94 , 94, 20, 20, Qt.RelativeSize)
Rien n'oblige l'utilisateur à faire la mise à jour, F13 est supporté jusqu'à la sortie de F15 + 1 mois.
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).
En même temps, Fedora 14 arrive avec le protocole Spice, systemd certes pas encore par défaut (plus par frilosité qu'autre chose d'ailleurs) et pas mal de nouveautés pour les développeurs et administrateurs (le support officiel d'EC2 ça représente pas mal de boulot) qui font également partie de notre cible.
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.
Si on tient à comparer les performances brutes de yum et apt-*, il faudrait d'abord désactiver le rafraichissement du cache et le chargement des plugins qui peuvent ralentir le démarrage de yum.
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 ...)
Yum est utilisé par les utilisateurs mais également par les mainteneurs de la distribution. Tout les outils pour développer la distribution sont construit autour de yum (installeur, générateur d'images, serveurs de compilation, génération de chroot etc ...), il est important que l'on puisse rajouter facilement des fonctionnalités à yum.
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.
> Je ne vois absolument aucun probleme a la semantique de apt
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.
> si ce n'est ne pas reprendre une techno concurrente
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.
> franchement faire l'inverse de apt au niveau des commandes c'est vraiment pour dire "moi je fais pas pareil".
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).
> Je ne comprends pas la phrase alors, parce que je ne comprends pas comment ils peuvent en organiser une et n'y être pas très présents, tu peux préciser?
Canonical a hébergé une hackfest (février 2010) autour de l'ergonomie du bureau en général pas uniquement du Shell mais aussi les applications. L'historique du dépôt launchpad d'unity remonte jusqu'à octobre 2009 donc c'était déjà bien entamé à cette date-là.
Le Shell ne s'est pas construit en un jour, la première implémentation date de fin 2008 suite à une hackfest et le mainteneur McCann avait fait un appel au contributeur dès le début. En cherchant bien, tu verras que les racines du projet remonte encore plus loin (2007) suite à l'expérimentation de l'online desktop, Havoc Pennington parlait déjà d'utilisation javascript et l'introspection GObject pour construire le bureau.
Entre fin 2008 et la première version publique d'Unity (mai 2010 ?), Canonical a été absent du projet Shell, ni proposer une alternative ou bien remonter la moindre critique. Donc mettre sur le dos des délais ou des supposés problèmes techniques du Shell , la raison d'être du projet Unity me semble un peu léger. Par ailleurs, Unity souffre des mêmes défauts que le Shell: il nécessite des pilotes OpenGL performants (d'où le lanceur alternatif basé sur les EFL), l'utilisation de Compiz est plus problèmatique qu'autre chose (Compiz est bourré de hacks au point qu'ils sont en train de le réécrire complétement en C++).
Canonical a fait le choix de faire cavalier seul, c'est leur droit, mais à eux d'assumer leurs choix.
Je pense qu'ils ont su proposer une alternative crédible au Shell, mais à ce niveau, seul l'avenir nous dira si c'est un choix payant ou non.
le "temporairement" prête peut-être à confusion, mais c'est seulement le nom "classic GNOME" qui est temporaire, gnome-panel devrait être présent durant tout le cycle de GNOME3.
Tes nouvelles ne sont pas fraiches du tout, GNOME3 incluera un environnement (temporairement) nommé "classic GNOME", entre autre pour ne pas faire peur aux clients corporate qui ont formés leurs employés à GNOME2.
Faudra m'expliquer pourquoi la communauté KDE se plaint toujours de l'intégration merdique de KDE dans kubuntu (c'est ce qui ressort régulièrement sur le planet KDE)
Plus sérieusement, Canonical emploie 1 développeur KDE (Jonathan Riddell) pour travailler en collaboration avec la communauté KDE et non pas dans son coin. Forcément, ça et le fait que Canonical ne se vante pas en permanence d'avoir révolutionné KDE aide pour avoir des relations apaisées.
[^] # Re: faut arrêter de s'accaparer le projet fait par les autres
Posté par GeneralZod . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 3.
Les propos de Sophie Gautier que tu cites date de septembre 2008 soit plus de 6 mois avant le rachat de Sun par Oracle et 2 ans avant la création de la Document Foundation et LibreOffice. Sun disposait d'un capital confiance non négligeable auprès de la communauté libre, Oracle not so much ===> le résultat: fork.
> Tu oublies aussi que derrière libre office au rayon développeur, il y a Novell, qui pratique le copyright assignment aussi sur ses projets.
nuance: certains de ces projets, dont le fameux Mono qui cru
> Ben voyons, c'est la seule raison qu'a eu red hat.
Au départ, c'est un projet personnel de Lennart qui a intéressé pas mal de monde en dehors de la communauté Red Hat/Fedora (Debian, Mandriva, SuSE, ArchLinux etc ...). Ce que tu oublies de mentionner c'est que le mainteneur d'Upstart a été très peu disponible pour faire évoluer celui-ci ou faire de la revue de patchs et que Canonical renacle à permettre à des personnes externes à la société de co-maintenir le projet. Le mainteneur d'Upstart a lui-même reconnu que son absence du projet a indirectement contribué à la naissance de systemd.
Et contrairement à ce que tu sembles croire, les plus fervents défenseurs d'Upstart dans Fedora sont des gens de RH.
> Couper l'herbe sous le pied d'un concurrent ne leur est même pas venu à l'idée
Un concurrent qui perds de l'argent et qui ne réalise même pas 5% de leur CA ?
> En cherchant, on ne trouverait pas des projets concurrents à d'autres projets déjà lancés, que red hat a lancé malgré qu'il n'y avait pas de problèmes de licenses ou autres?
Peut-être, mais le mot d'ordre chez RH étant de favoriser les projets déjà existants et de travailler le plus possible en upstream afin d'éviter à soi mais également aux autres de réinventer la roue, je pense que t'auras du mal à trouver.
> J'aime bien cette mentalité manichéenne pleine de méchants et de bons, c'est comme dans un film.
Tu devrais arrêter les westerns :]
[^] # Re: j'approuve
Posté par GeneralZod . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 2.
Je demande à voir les sources ... Parce que dans les faits, ce serait plutôt l'inverse.
[^] # Re: C'est un nids à trolls !
Posté par GeneralZod . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 1.
[^] # Re: Et dans 6 mois..
Posté par GeneralZod . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 5.
[^] # Re: faut arrêter de s'accaparer le projet fait par les autres
Posté par GeneralZod . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 7.
Vu le passif de Canonical, je comprenne que certains ne leur accorde pas le même degré de confiance qu'à la FSF ou l'ASF.
Dans le cas d'upstart, l'assignation du copyright a indirectement encouragé la création du projet concurrent systemd qui aurait pu être évité à peu de frais.
[^] # Re: C'est un nids à trolls !
Posté par GeneralZod . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 3.
Rien n'est moins certain, pour PulseAudio, l'intégration foireuse faite par Ubuntu lui a apporté un grand nombre de détracteurs mais ça ne s'est bizarrement jamais concrétisé en rapports de bogues ou soyons fous des patchs pour corriger les problèmes de PA ou de cette passoire d'ALSA !
À mon avis, c'est une arme à double tranchant, soit Canonical s'investit dans le projet (développement, correction de bogues, tests, filtre les rapports etc ...) et là oui, ça serait extrêmement bénéfique pour le projet, soit Canonical attends que le travail soit fait et lache un gros paquet mal ficelé et tu peux être certain que Wayland va se trainer une sale réputation pendant des décennies.
Et vu l'avancement du développement de Wayland, crois-moi, si le père Shuttleworth est sérieux (et on espère tous qu'il l'est !), il a intérêt à se retrousser les manches et à ouvrir le porte-monnaie.
[^] # Re: Pas de transparence réseau ?
Posté par GeneralZod . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 5.
http://wayland.freedesktop.org/architecture.html
# C'est un nids à trolls !
Posté par GeneralZod . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 6.
Kristian Høgsberg est l'auteur d'AIGLX et un contributeur majeur de X.org. Là où ça commence à devenir hautement trollifère, c'est de voir qui était l'employeur de Kristian jusqu'à début 2010, et de la majorité des contributeurs.
Ça va troller sec, moi, je vous le dis !
# Les limites du moteur de dessin
Posté par GeneralZod . En réponse au message Qt: je comprend pas. Évalué à 10.
Je pense que tu comprendras mieux en lisant la doc à ce sujet.
http://doc.trolltech.com/4.7/coordsys.html
Si je change cette ligne, j'ai un beau rectangle avec des coins arrondis
> clipPath.addRoundedRect(3, 3, 94 , 94, 20, 20, Qt.RelativeSize)
[^] # Re: Il faut vraiment que je change de distrib
Posté par GeneralZod . En réponse à la dépêche Sortie de Fedora 14. Évalué à 2.
[^] # Re: Il faut vraiment que je change de distrib
Posté par GeneralZod . En réponse à la dépêche Sortie de Fedora 14. É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 GeneralZod . En réponse à la dépêche Sortie de Fedora 14. É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: Youpi !!!
Posté par GeneralZod . En réponse à la dépêche Sortie de Fedora 14. É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 GeneralZod . En réponse à la dépêche Sortie de Fedora 14. É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: 6 mois d'utilisation déjà
Posté par GeneralZod . En réponse à la dépêche Sortie de Fedora 14. Évalué à 2.
[^] # Re: 6 mois d'utilisation déjà
Posté par GeneralZod . En réponse à la dépêche Sortie de Fedora 14. É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 GeneralZod . En réponse à la dépêche Sortie de Fedora 14. É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: Youpi !!!
Posté par GeneralZod . En réponse à la dépêche Sortie de Fedora 14. É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: 6 mois d'utilisation déjà
Posté par GeneralZod . En réponse à la dépêche Sortie de Fedora 14. É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: Pourquoi C++ ?
Posté par GeneralZod . En réponse à la dépêche Qfacture - Release de la version 0.1. Évalué à 2.
[^] # Re: dommage
Posté par GeneralZod . En réponse au journal Vendredi: Enfin presque!. Évalué à 2.
[^] # Re: Participer à gnome-shell
Posté par GeneralZod . En réponse au journal Vendredi: Enfin presque!. Évalué à 3.
Canonical a hébergé une hackfest (février 2010) autour de l'ergonomie du bureau en général pas uniquement du Shell mais aussi les applications. L'historique du dépôt launchpad d'unity remonte jusqu'à octobre 2009 donc c'était déjà bien entamé à cette date-là.
Le Shell ne s'est pas construit en un jour, la première implémentation date de fin 2008 suite à une hackfest et le mainteneur McCann avait fait un appel au contributeur dès le début. En cherchant bien, tu verras que les racines du projet remonte encore plus loin (2007) suite à l'expérimentation de l'online desktop, Havoc Pennington parlait déjà d'utilisation javascript et l'introspection GObject pour construire le bureau.
Entre fin 2008 et la première version publique d'Unity (mai 2010 ?), Canonical a été absent du projet Shell, ni proposer une alternative ou bien remonter la moindre critique. Donc mettre sur le dos des délais ou des supposés problèmes techniques du Shell , la raison d'être du projet Unity me semble un peu léger. Par ailleurs, Unity souffre des mêmes défauts que le Shell: il nécessite des pilotes OpenGL performants (d'où le lanceur alternatif basé sur les EFL), l'utilisation de Compiz est plus problèmatique qu'autre chose (Compiz est bourré de hacks au point qu'ils sont en train de le réécrire complétement en C++).
Canonical a fait le choix de faire cavalier seul, c'est leur droit, mais à eux d'assumer leurs choix.
Je pense qu'ils ont su proposer une alternative crédible au Shell, mais à ce niveau, seul l'avenir nous dira si c'est un choix payant ou non.
[^] # Re: dommage
Posté par GeneralZod . En réponse au journal Vendredi: Enfin presque!. Évalué à 2.
[^] # Re: dommage
Posté par GeneralZod . En réponse au journal Vendredi: Enfin presque!. Évalué à 2.
[^] # Re: Participer à gnome-shell
Posté par GeneralZod . En réponse au journal Vendredi: Enfin presque!. Évalué à 7.
Plus sérieusement, Canonical emploie 1 développeur KDE (Jonathan Riddell) pour travailler en collaboration avec la communauté KDE et non pas dans son coin. Forcément, ça et le fait que Canonical ne se vante pas en permanence d'avoir révolutionné KDE aide pour avoir des relations apaisées.