IsNotGood a écrit 5009 commentaires

> Je n'imagine rien, je constate.

Ok, pas de problème.
Mais la page d'accueil à gcc 4.4, le dernier problème a été réglé et il y a une branche 4.5. Il ne va pas falloir des plombes pour avoir une annonce officielle.

Mais le problème est : es-ce que je dois dire que Rawhide utilise gcc 4.4 ou 4.3 (ou rh-4.4 histoire d'ajouter (ou enlever) de la confision) ?
Avec quoi est compilé Rawhide selon toi ?

Les applications du bureau peuvent utiliser Mono (par exemple Tomboy) et être des applis Gnome. Mais Gnome (la plateforme) ne dépend pas de Mono. Au pire on peut dire que le bureau par défaut de Gnome dépend de Mono.
Mais tu n'auras pas nautilus ou le panel ou libgnome écrit en C# par exemple. Seulement des applis utilisateurs. Un développeur Gnome de la plateforme Gnome n'utilise jamais C# (*). Une développeur d'applis Gnome ne sera jamais dans l'obligation d'utiliser C#. Il le fait s'il le veut.

(*) sauf pour réaliser les bindings, mais ses derniers dépendent de la plateforme et non l'inverse.

C'est bon, on connait ce discours...

L'annonce de ton journal est positive pour le libre (la licence précédante était horrible). Mais il m'est d'avis qu'il ne faut pas se limiter aux licences. Si ce qui vient d'être libéré est "self-contained" et ne demande que des éléments déjà aprouvés (par exemple OIN, FSF, etc), il n'y a pas de problème (supplémentaire) à les utiliser.
C'est une réponse de ce type que j'attendais...

> il est tout à fait possible de se passer de Tomboy et donc de Mono.

Je fais systèmatiquement un "yum remove mono-core" après une installation :-)

> il n'est pas prévu de faire dépendre Gnome de Mono

Ni de Java.
Gnome propose des bindings qui sont officiellement supporté (python, C++, java, C#, autre ?).
C'est un choix de language pour les applis, pas pour la plateforme Gnome qui reste en C (voire avec des bouts de C++ ?).
Icaza avait "milité" pour faire de .Net la plateforme de Gnome, ça n'a pas du tout marché. Il n'a pas insisté.

> Et je les ai toujours lu...

Et je ne les ai toujours pas lu...

> Désolé j'utilise KDE le manque de cohérence de Gnome m'a toujours profondément embetté...

Très bien utilise KDE. Je ne vois pas le problème.
Maintenant prend le problème des distributions.
Par exemple c'est (ou c'était ?) epiphany le navigateur Gnome. Fedora l'a utilisé un temps par défaut et maintenant c'est FF.
Il y a KDE dans Fedora, mais c'est toujours OOo par défaut même pour KDE.
NB : ce n'est pas un choix Red Hat, c'est un choix du groupe bénévole qui s'occupe de KDE dans Fedora.
Etc.

S'engager dans une voie qui boffe des ressources délirantes pour au final ne pas être utilisé...
D'un point de vu logiciel libre, c'est du "gaspillage" d'énergie. M'enfin, le logiciel libre n'empêchera jamais ce "gaspillage", peut-être que Koffice va roxer des ours etc. L'histoire n'est pas écrite. Mais Gnome ne veut pas faire sa suite, ni son navigateur (ou son moteur de rendu), etc. Il y a déjà suffisament de boulot.

Lorsque j'ai répondu à patrick_g, j'avais lu ça : http://live.gnome.org/ThreePointZero/Plan
Mais pas :
http://live.gnome.org/GnomeZeitgeist
http://live.gnome.org/GnomeShell

Et je les ai toujours lu...

Je sais qu'il y aura GnomeZeitgeist dans Gnome 3, mais je ne sais pas ce que c'est...
Je ne le sais que vaguement.

Il y avait encore les anciennes API.
Par exemple un programme qui utilise l'api esd marche très bien avec PA.
Ça ne sera plus le cas pour Gnome 3.

> Cela a t'il pour autant nécessité un changement de version? Cela a t'il provoqué un changement de version pour autant?

Non car il y a compatibilité ascendante. Il n'y aura plus compatibilité ascendante pour Gnome 3 (par définition).

> Mais alors il est sorti ou pas ?

Il est sorti.
http://gcc.gnu.org/ (il est ici)
Ou pas :-)

Il manque ça pour qu'il sorte : http://www.gnu.org/licenses/gcc-exception.html

Imaginons qu'il n'est pas encore sorti, il ne va y avoir de boulversement à sa sortie officielle.
NB : Fedora a utilisé gcc-4.4 (nommé ainsi car probablement du cvs ; donc des sources officielles) avant que gcc-4.4 ne soit annoncé officiellement (ni sur http://gcc.gnu.org/ ).
Je n'ai pas envis de vérifier ces détails, car c'est des détails :-)

Tu trouveras l'historique (et les sources) de gcc dans Fedora ici :
http://koji.fedoraproject.org/koji/packageinfo?packageID=40
NB : gcc 4.4 a été utilisé pour compiler tous les sources vers le 15 mars.

> Sauf que si c'est M$ qui fil des sources couvertes par des nouveaux brevets, on aura du mal à faire jouer l'antériorité.

La licence MS-PL permet l'utilisateur des brevets (de MS pour ces sources). M'enfin, il faut toujours une vérification attentive et ne compte pas sur moi pour donner une garantit même si la licence me parait correcte.

Le problème ici est qu'il faudrait un expert .NET/ASP/je-ne-sais-quoi pour dire si utiliser ses trucs n'amène pas à utiliser d'autres trucs qui posent problèment.

Si tu veux faire une suite bureautique pour Gnome, pas de problème, fait là.
Mais elle sera dans Gnome si "elle vaut le coup". Si avoir OOo est mieux, ben il y aura OOo. Et dans ce cas mieux vaut se concenter sur le portage de OOo. C'est aussi fait pour FF (par exemple l'organisation des menus est (légèrement) différente de Windows). J'approuve ce type de démarche, qui à mon avis ne va pas encore assez loin.

Haha.
Ce sont des bricoles.
Pour info, Fedora est passé à gcc 4.4 qui est à peine sorti.
Pour contre le passage à Gnome 3, les développeurs d'applis vont le sentir passer.

> Ce qui me fait peur c'est la phrase "it would be an error to do GNOME 3.0 without any big user-visible change".

Prise isolément ça fait peur.
Mais (désolé de citer tout ça) :
There were thoughts that GNOME could stay with the 2.x branch for a very long time given our solid development methods, but that it was not the future that our community wants to see happening. Because of lack of excitement. Because of lack of vision.
...
Let's first diverge a bit and discuss the general impression that GNOME is lacking a vision.
If you look closely at our community, it'd be wrong to say that people are lacking a vision; but the project as a whole does indeed have this issue.
...
But during the 2.x cycle, with our six months schedules, it appeared that everything (community, development process, etc.) was just working very well, and as the vision got more and more fulfilled, the long-term plans became less important as we focused on polishing our desktop. But we've now reached a point where our next steps should be moving to another level, and those next steps require important decisions. This is part of what the Release Team should do. Please note that Release Team members don't have to be the ones who have the vision; we "just" have to be the voice of the community.
...
Our community has historically been strong on the development side, but we have always struggled to promote GNOME. That's because this is certainly no easy task. Our user base has however grown significantly since our project started, and we failed to recruit people that could have helped here. GNOME 3.0 is an opportunity to change this and attract contributors that can help forge the communication around the GNOME project. The promotion of the project is definitely part of what makes a good release
...
One common issue that often came up when discussing how to promote GNOME was that promoting the desktop as a whole is difficult. But there's no need to do that. We can instead focus our messaging around the GNOME experience: the basic GNOME experience simply is the GNOME Shell

C'est dans ce contexte qu'il faut comprendre la phrase. Ce n'est pas faire un changement seulement à cause d'un numéro.
Je ne dis pas que tu as tord sur les changements proposés (je ne connais pas les changements qui sont prévus pour Gnome 3).

> st-ce que un nettoyage des vieilleries mérite vraiment un changement de version majeure

Ça mérite un changement de version majeure.
Une API obsolète est une API qui est toujours là. Avec le passage à 3.0, l'API n'y sera plus, c'est une incompatibilité majeure, ça justifie le changement de version majeur.

> Je pense que tu es passé par le lien http://www.codeplex.com/aspnet

Exact.

S'il y a un fichier license, pas de problème.
Mais j'ai suivi les liens du blog et c'est une autre histoire.

NB : je ne connais pas vraiment Gnome 3.

> il n'y a que des changements incrémentales sans cassure de compatibilité.

Mais au bout d'un moment il faut de débarraser des vieilleries.
Tu prépares avec 2.x (l'api est là, mais il y a des warnings), tu vires dans 3.0.

Quand je demande à downloader ASP.NET MVC, ça ne dit pas que c'est une licence MS-PL.
Il n'y a pas de fichier licence dans le paquet.
Extrait de la licence alors que je demande à downloader :
(B) Patent Grant- Subject to the terms of this license, the Licensor grants you a non-transferable, non-exclusive, worldwide, royalty-free patent license under licensed patents for reference use.
Bref, c'est à fuire comme la peste.

Je n'ai pas vérifier les autres paquets. Mais comme toujours, l'enfer est dans les détails avec MS.

> je pense qu'un peu de notion d'histoire de libvirt ne ferait pas de mal; a la base libvirt ce n'est pas du tout une lib multi-hypervisor. a la base c'est la reponse redhat pour permettre de controller Xen (API haut niveau), pendant que d'autre essayait de mettre en place une solution native dans xend (a base de xmlrpc).

C'est vrai, mais dès l'origine libvirt était prévu pour être multi-hyperviseur.

> Seulement arrive KVM (et les autres solutions de virt), et redhat changeant de fusil d'epaule

Mouais... Red Hat propose à ses clients ce qu'il lui semble le mieux (dans le logiciel libre). Tout le monde ou presque va faire pareil où est déjà en train de le faire.
En passant, c'est aussi un choix upstream.

> en une lib multi hypervisor.

C'était dès l'origine une lib multi-hyperviseur.

> Quant a la contribution des gens de libvirt dans qemu/kvm elle est relativement minimal,

Je ne vois pas le problème. Les développeurs de libvirt développent libvirt. S'ils font plus, tant mieux.

> Par example les gens de libvirt se sont interfacé avec la console qemu qui n'est pas sensé etre scripté, mais est une interface humaine. Presque a chaque changement de messages d'erreurs ou de format, on se retrouve avec les gens de libvirt se plaignant que ca va tout casser.. au lieu d'avoir designe une "console" scriptable en parallele (retournant un format qui puisse etre parser) avec la console humaine.

Si tu veux critiquer qemu, critique qemu mais pas libvirt. Libvirt n'est pas responsable de tous les maux de la terre.

Globalement je trouve rigolo ceux qui descendent une solution alors qu'il n'y a pratiquement rien d'autre...

Dans le même registre, mais beaucoup plus rigolo :
http://www.osnews.com/story/21238/OSNews_Goes_Open_Source

> Le fait que cela soit repandu ou standard ne prejuge en rien de sa qualite.
>
> Je suis rassure que les gens de Ielo aient ecarte libvirt, ca montre qu'ils savent voir au dela du hype.

Le fait que les gens de lelo aient écarté libvirt, ne préjuge en rien qu'ils savent faire les bons choix.
Ils font bien dans le "hype", la virtualisation est "hype". Dans ce "hype", ils ont pris ce qu'il y a de plus "hype" : kvm.

> C'etait une piece importante de la strategie de RH et lui a permis de changer de solution de virtualisation sous-jacente (de xen a kvm).

Oui, mais pas seulement. Quand libvirt a été fait, personne ne savait qu'il y allait avoir kvm. Le pire ici n'est pas libvirt, mais xend qui a voulu tout faire à la fois en étant lié à une seule techno... Kvm est un remplaçant de Xen. Mais il y autres solutions de virtuailisation qui ne sont pas des remplaçants de Xen et ont leur place. Par exemple les conteneurs. Ce n'est pas actuellement la priorité de Red Hat, mais ces derniers ne sont morts. Un datacenter pourrait combiner OpenVZ et KVM.

> Mais cela reste amha une usine a gaz fragile qui n'exploite que le plus petit commun denominateur. Un design clean a partir de zero pour un produit qui ne tente pas d'utiliser plusieurs hyperviseurs ne me parait pas idiot.

Faire Xend, Kvmd, OpenVZd, etc...
Pas sûr que ça donne plus de qualité.
Quelques soit le système de virtualisation il y a des points communs. Le stockage, l'installation, la migration (à chaud ou froid), l'affichage, la sécurité/authentification, etc.

> remarquer qu'il y a des outils simples fait par des admins pour des admins qui marchent bien (genre kvmctl

Qui ne gère pas l'accès à distance, la création de vm, etc, etc.

> Cela dit, comme le nom de leur groupe l'indique, ce sont surtout des gens qui font des prototypes qui passent ensuite souvent en prod tels quels

Faut bien faire des prototypes. et.redhat.com n'est pas un groupe spécifique de personne qui ne font que ça.
Il y a des développeurs de libvirt, func, etc. L'idée est qu'il y a des solutions qui ont plus de sens lorsqu'elles sont couplées avec d'autres. L'idée est aussi de donnée plus de lumière à des solutions qui semblent prometteuses selon Red Hat.

> Ce faisant, ils ont tendance a privilegier le quick and dirty et non un design propre/sain.

Le kvmctl que tu donnais était du quick and dirty. Et ça ne voulait pas être plus.

> [une pile de reproche plus ou moins valable]
> Alors, oui, ils contribuent, mais leurs choix ne sont pas forcement les meilleurs.

Ils l'ont fait. Au premier jet rien est parfait et un programme est toujours en développement.

> D'autre part, ils n'ont pas la main-mise sur qemu (ils n'ont meme pas d'acces en ecriture au repo pour l'instant) donc rien n'empeche les gens de Ielo/LO ou des contributeurs externes de rajouter des fonctionnalites.

Oui, et c'est très bien. Je ne vois pas problème ici, au contraire.

> Oué mes questions concernaient NiftyName pas EC2 :)

J'avais l'impression que tu ne connaissais pas aws. Bizarre, j'étais resté sur l'impression de ton premier commentaire.

> le modèle est beaucoup plus séduisant

C'est séduisant ça ? => http://channel9.msdn.com/pdc2008/ES01/

Le peu que j'ai regardé d'Azure était l'"enfer". Par exemple il y avait une vidéo sur comment configurer un poste pour utiliser Azure et c'était passablement compliqué.
L'excuse : c'est du beta.
Es-ce un truc pour développeur ?

> ca se place à un niveau d'abstraction supérieur.

Je me méfis beaucoup de MS, mais il n'empêche qu'ici je crois qu'Amazon n'a pas de soucis à se faire...

Metacity est simplet ? Pas de problème, il va s'étoffer :
http://blogs.gnome.org/metacity/2009/04/01/squib-of-the-day-(...)

Recherche de prio-art dans les binaires (c'est prometteur) :
http://lwn.net/Articles/326670/

Un mode privé pour Empathy (indispensable) :
http://resiak.livejournal.com/60614.html

La montée récente des failles de sécurité des navigateurs crée des risques énormes. Conséquence ? Les gens utilisent Lynx évidemment :
http://news.netcraft.com/archives/2009/04/01/deluge_of_brows(...)
Les plus parano utilisent telnet (1 %). Avec https ?

http://tuxradar.com/content/ubuntu-rewrite-linux-kernel-usin(...)

Je ne l'avais pas oublié, je ne savais pas que c'était un vrai poisson :-)