GeneralZod a écrit 2316 commentaires

> Et dire que je croyais que le but de Mozilla était de promouvoir les standards…
Les standards ouverts, c'est même écrit sur le site de Mozilla.
H264 c'est un standard industriel qui est tout sauf ouvert !

http://guides.mozilla.org/Web_standards

Il faut savoir mettre un terme au maitre ! Palsambleu, qu'il s'occupe de la grand-mère et laisse le code aux développeurs !

plus rapide que de taper le chemin à la main ? le temps de lancer nautilus, j'ai déjà fini et ouvert mon fichier téléchargé dans l'application kivabien !

> Firefox n'a aucun brevet à payer avec les nouvelles conditions du consortium (logiciel gratuit)

L'emphase se suffit à elle-même, comme d'habitude, tu nous sors la même soupe pour défendre l'indéfendable.

Le file chooser Gtk te permet directement de taper le chemin de l'exécutable (avec même l'autocomplétion)

moi, je mets /usr/bin/xdg-open pour tous et on n'en parle plus

> On a récemment embaucher des gens pour bosser sur l'intégration à Unity
Et GNOME Shell ?

C'est principalement un retrait stratégique. le "retard" pris par la sortie de Maemo6/MeeGo a causé beaucoup de tort à Nokia: est-ce que Nokia est capable de rivaliser avec les "nouveaux venus" dans le marché smartphone (iOS, Android etc ...) ? les atermoiement autour de Symbian, les demi-échecs du N900 puis N8 (dû essentiellement à l'absence de politique claire de Nokia sur les smartphones !)
Ça signifie juste que Nokia est en train de préparer un gros lancement et qu'ils veulent faire monter le buzz. Les dernières APIs seront disponibles pour permettre aux développeurs de sortir leurs applications à temps, mais le look'n'feel final de MeeGo restera "secret" jusqu'à ce que Nokia obtienne un résultat satisfaisant.

Certes, les deux projets s'influencent mutuellement mais côté G-S ça s'est limité à l'aspect graphique (et encore Unity a pas spécialement innové). En terme de fonctionnalités et d'ergonomie, ça n'a pas tellement évolué par rapport au premier whitepaper de Mccann (mi 2009).

> c'est plutôt GNOME-Shell qui avait copié des idées de Unity plutôt que l'inverse...

Faudra pouvoir m'expliquer comment GNOME Shell aurait copié Unity alors que les premiers sketches de G-S date de 2008 (les premiers commits date de fin 2008) alors que ce dernier remonte pas plus loin que début 2010 (mi-2010 pour la première version publique).

En revanche l'inverse est avéré, Unity s'est fortement inspiré de G-S et s'en écarte par endroit (la philosophie derrière Unity n'étant pas la même que G-S, c'est un peu normal)

Au contraire, je pense que la stratégie de Canonical sur le long terme semble se clarifier.
Le rapprochement qui semble s'opérer avec Nokia notamment sur la gestion du multitouch (le mainteneur de utouch Duncan McGregor est *très* intéressé par Qt Quick), le portage d'Unity2D sur Qt/QML, ça met la puce à l'oreille.
http://blog.qt.nokia.com/2010/12/22/my-new-years-resolution-(...)
http://www.webupd8.org/2011/01/unity-2d-qt-now-available-in-(...)

Il est fort probable qu'à long terme, le bureau Unity repose sur Qt et un sous-ensemble de la plateforme GNOME. C'est une stratégie qui peut être payante sur le long terme, Canonical s'intéresse beaucoup aux "opportunistic developers" c-a-d les développeurs qui veulent écrire des petites applications vite fait (bien fait ?) officiellement les hobbyistes mais on peut envisager les pisseurs de code en entreprise. Qt a une doc complète ET cohérente, un environnement de développement intégré complet, la portabilité a peu de frais et cerise sur le gateau, les roadmaps de Nokia et Canonical convergent.
En plus, avoir un bureau différent, entièrement maitrisé par Canonical est une excellente façon de se démarquer du lot.

Les structures de données sont limités, pas de sûreté de type (tout est stocké dans une chaine, les listes sont des chaines séparés par un ";" ce qui n'est pas sans poser problème), la syntaxe est parfois boiteuse (définir une fonction par exemple).

Certes, pour un DSL, c'est pas trop mal foutu mais parfois un langage plus évolué (python, lua ou même javascript) faciliterait bien la vie des développeurs.

Depuis la version 2.6, ce n'est plus nécessaire et il existe une variable spéciale pour l'activer sur CMake 2.4.x.

Même si ça fait un peu doublon sur certains aspects, c'est tout à fait possible.
Par contre, les générateurs constituent un cas particulier, il vaut mieux les développer en C++ (typiquement, une classe qui hérite de cmGlobalGenerator), sinon, ce n'est pas maintenable à long terme. C'est pas bien compliqué, CMake est très architecturé et le code source extrêmement bien documenté (tu peux générer une doc doxygen de l'API relativement à jour).

Le seul point négatif de CMake est son langage de script pourrave, ajouter un nouveau langage, le support d'une bibliothèque est super simple parce qu'on dispose déjà des commandes qui vont bien. C'est pas forcément le cas pour écrire un générateur.

inclus dans la norme Posix ça devrait suffire pour considérer que c'est nativement disponible sous *nix ?

Scons est à la fois un moteur de production comme GNU Make et un système de production de haut-niveau comme autotools ou CMake qui gère les dépendances, la portabilité etc ...

Par rapport à CMake, il a l'avantage de reposer sur un langage de script complet et flexible (Python/ersatz utilisé par CMake), de former un ensemble cohérent (CMake est un générateur de projets) mais il a un défaut majeur par rapport à GNU Make, il gère horriblement mal la parallélisation des tâches.
Waf me semble plus à même dans la même catégorie de rivaliser avec Make, il gère mieux la parallélisation (donc nettement plus rapide), une API plus familière aux Pythonistas et une configuration plus souple. Le projet est plus dynamique que Scons, mais un peu brouillon (beaucoup de changement d'APIs)

Personnellement, même si je préfère l'approche Scons/Waf, j'ai fait le choix de CMake pour les raisons suivantes principalement pour le fait qu'il soit self-contained, très rapide (le jour et la nuit par rapport à Scons), et qu'il dispose d'une large collection de modules pas loin de rivaliser avec autotools. Certes, CMake a un langage de script pourri (mais simple), certes, c'est un générateur de projets mais GNU Make est un composant éprouvé, CMake suppléant à ses défauts, ça en fait une solution tout à fait acceptable dans un cadre industriel ou libre.

Jenkins est enfin débarassé du pouvoir de nuisance d'Oracle (comprendre verrouiller le développement de la partie libre pour vendre au prix fort leur merde privatrice) et Google se débarasse du nids de guêpes H.264.

OpenNebula est également sous licence Apache, la principale différence est que c'est un projet issu de la recherche européenne et pas d'un consortium industriel américain.
De plus, la première version publique d'OpenNebula précéde de 3 ans le tout jeune Nova, donc le premier a l'avantage de la maturité

Le développement de virt-manager tourne certes au ralenti, mais c'est dû au fait que la roadmap de virt-manager est tributaire de celle de SPICE sur lequel les efforts se concentrent.
D'ailleurs, SPICE a été intégré dans virt-manager fin décembre (avec le viewer).

> soit des soluces qui ne sont pas vraiment compatibles avec libvirt (opennebula,convirt,ovirt).
Pour autant que je sache, openNebula et ovirt utilisent libvirt et permettent d'intégrer n'importe quel infrastructure existante de virtualisation accessible via libvirt.

Je ne sais pas ce que Red Hat livre effectivement dans RHEV mais les outils utilisés comme libvirt et guestfish disposent de wrappers java qui marchent pas trop mal.

même ceux qui bossent chez canonical ?

Archipel ?

parce que c'est pas microsoft qui les seede déjà ?

Si tu considéres que Pylons en est un à la base et que repoze.bfg est encore plus petit oui.
Plus petits, tu as (l'excellent) Flask ou à la rigueur web.py mais en deçà, c'est des boites à outils (werkzeug, cherrypy etc ...)

> c'est que Django a une communauté.

Pylons/TG aussi.

> c'est précisément parce qu'ils ne passent pas leur temps à changer de plateforme technique
La force de Django est de proposer effectivement un framework cohérent donc plus facile à apprendre, une documentation centralisé etc... mais c'est également sa plus grande faiblesse.
* les composants Django pris séparément sont pas toujours au niveau de la concurrence, je pense entre autre au Django ORM (une bouze extrêmement limité comparé à SQLAlchemy ou Storm) ou au module d'authentification.
* la difficulté à utiliser un composant tiers comme un autre ORM ou moteur de templates.
* c'est quasiment le seul framework web Python qui ne supporte PAS la norme WSGI ! Je ne parle pas de la capacité à être servi par un serveur WSGI mais de la possibilité de chainer les middlewares. Django se prive de la possibilité d'utiliser des composants éprouvés notamment pour l'authentification, le caching etc ... Certes, il y a les apps (l'équivalent côté pylons/TG serait plus ou moins les widgets du projet ToscaWidgets qui est en retrait par rapport aux Django Apps) pour permettre la réutilisabilité du code, mais ça reste un mécanisme limité.
* quelques bizarreries: gestion des settings
* aucune attention porté aux performances qui ne cessent de diminuer au fur et à mesure des versions, si je veux un site qui monte en échelle (genre Sourceforge), je peux oublier Django.
* la communauté Django est très active et amicale, les core developers not so much ...

Je pourrais faire une liste aussi longue pour Pylons/TG, tout ça pour dire que le choix d'un framework web python n'est pas aussi évident.
Si je suis un développeur web qui souhaite proposer à ses clients des sites riches avec un TTM le plus réduit possible, je m'orienterais naturellement vers Django, je suis un développeur Python chevronné mais qui n'a pas forcément fait du web, je m'orienterais vers Pylons/TG qui me permettra de réutiliser mes connaissance, je veux un framework minimaliste, j'utiliser un micro-framework (ie: Flask/Jinja2, web.py, repoze.bfg, etc ...) ou même une boite à outils comme werkzeug !

> c'est précisément parce qu'ils ne passent pas leur temps à changer de plateforme technique, à fusionner ou forker dans tous les sens.

Les fusions ont toujours été soigneusement réfléchies et résultent toujours d'une convergence des roadmaps des développeurs. Pourquoi réinventer la roue à chaque fois ?
Mis à part le passage de TG1 -toujours maintenu actuellement- à TG2, il n'y a pas plus d'incompatibilités lors des changements de versions chez Pylons ou TG qu'avec Django.
Dans le cas de Pyramid:
* porter une application Pylons à Pyramid ça va de "rien à faire" à "quelques changements mineurs qui peuvent être automatisés". Un outil de migration est prévu d'ailleurs.
* pour les applications repoze.bfg, mis à part le changement de nom et une réorganisation des modules, y a rien à faire.
* j'ai ouï dire qu'il a fallu moins d'une journée pour avoir un prototype fonctionnel de "TG3" et qu'une application TG2 pouvait tourner quasiment sans modifications dessus.
Certes, le schéma de migration de Django est certainement mieux contrôlé, mais rien de catastrophique non plus. De plus, les fusions permettent justement de limiter ces problèmes.
Quant aux forks, ils sont assez peu nombreux et pour la plupart confidentiels.

> pas d'avoir une architecture top-moumoute avec des composants décentralisés et des buzzwords hérités du monde Java.

Même si Pyramid est un lointain descendant de Zope à travers repoze.bfg (c'est bien, ça va donner matière à troller lors des afpyros), la réputation de lourdeur que se traine Zope ne se justifie plus du tout pour les composants repoze issus de la restructuration de Zope en middlewares WSGI.