GeneralZod a écrit 2316 commentaires

Le compilateur, le framework de base sont libres, c'est disponible dans le SVN. En revanche, les APIs spécifique à MonoTouch sont closed source et sans code externe à Novell.
Unity un framework destiné aux jeux (propriétaire) propose depuis longtemps un SDK iPhone utilisant le compilateur AOT, de nombreux jeux basés dessus sont même disponible dans l'AppStore.

Le nom a été choisi d'après Grand Central Station une gare ferroviaire New-Yorkaise, c'est accessoirement la plus grande au monde.
C'est pas si mal choisi, l'analogie entre la gestion des trains et celles des threads est frappante: ordonnanceur/gare, files/voies, tâches/trains, nombre limité de voies/threads disponibles etc ... Je ne sais pas si c'est mégalomane, mais j'y verrais plutôt l'ambition de faire de GCD le framework de programmation concurrente la plus efficace possible.

En tout cas, c'est l'une des plus élégantes.

J'ai posté une dépêche, il y a un peu plus d'une demi-heure. Quelques précisions :
* En fait, libdispatch est "auto-suffisante", la partie implémentée dans Xnu permet d'optimiser la gestion des threads.
* GCD n'étends pas la syntaxe des langages de la famille C mais s'appuie sur une extension les blocs (une implémentation des closures, notion importée du Lisp). D'ailleurs C++0x offre un concept proche avec les expressions lambdas.
http://en.wikipedia.org/wiki/Closure_%28computer_science%29

GCD est un framework de programmation concurrente intéressant, moins moche qu'OpenMP, moins compliqué que TBB (l'absence des lambdas joue pas mal dans cette "complexité") limité au C++, j'espère vivement que GCC se dépêche de nous proposer les blocs afin d'en profiter, libdispatch devrait pas être difficile à porter, LLVM étant disponibles dans toutes les bonnes distributions.

Mouais, vu le court délai, ça m'étonnerait que ce soit la raison principale des performances de GCC 4.4 même si ça doit aider.

En règle général, quand un logiciel marche bien, on ne le crie pas sur tout les toits.
Mais pour revenir sur le post de MrTom, il se plaint principalement de la consommation excessive de CPU, c'est un problème connu mais qui ne concerne pas tout le monde (ie: PA tourne comme un charme sur la plupart des netbooks du marché), quant à Aaron Seigo, il utilise une OpenSuSE mutante et se plaint principalement du non fonctionnement d'applications propriétaire à la con (Lennart Pottering s'est fait chier à corriger la plupart des applications libres pour garantir leur bon fonctionnement avec PA avant la sortie de Fedora 8, malheureusement, il ne peut pas faire des patchs binaires pour Skype), pour le billet sur Mandriva, il est bourré d'inexactitudes et date de janvier 2008, j'ose espérer que Mandriva n'est pas assez frappadingue pour utiliser 21 mois après PA si c'est aussi pourri que ça.

Si les gens qui se plaignaient de PA faisaient un peu plus de rapports de bogues et moins de billets pour cracher sur PA ...
La réalité, c'est que la pile audio de GNU/Linux est un tas de merde comparé à ce qui se fait sous OS X ou pire Microsoft. Beaucoup de problèmes attribués à PA sont souvent des bogues existants dans Alsa et les pilotes, des bogues souvent contournés par les applications mais jamais corrigés.

C'est surtout de l'hypocrisie.
On peut être reconnaissant pour les efforts fournis, mais c'est du logiciel libre, baby !
Passer la main à d'autres, c'est le rôle d'un mainteneur de LL quand il abandonne un projet (désintérêt, manque de temps, décés, transformation en loup-garou, etc ...), ça fait partie du cycle de la vie.
Sinon, on n'avancerait jamais, c'est valable pour le logiciel libre comme dans First Life ...

> En general les developpeurs dans une entreprise ne codent pas ce qu'ils veulent.

C'est un projet R&D destiné à écrire des APIs pour des appareils mobiles.

> Nokia ne contribue pas.

Les backends Gstreamer, Quicktime et DirectShow se sont écrits tout seuls ?

> Phonon est au point mort en ce moment (nouveau mainteneur, Kretz n'a plus le temps)

alors, si le mainteneur n'a plus le temps, il dégage et laisse sa place à un autre.

> C'est moi l'auteur du journal.

J'ai bien dit "billet", pas du journal. Si tu préfères, c'est l'employé de Nokia qui s'est emballé parce que rien n'est fait.
Le journal en lui-même est conforme aux standards du site.


> Ce n'est pas encore fait, mais l'objectif est plutot clair :

Encore une fois, c'est une affirmation faite par un des développeurs et non pas par Nokia.
QtMobility est un jeu d'API destinés aux appareils mobiles et plus particulièrement aux système WinCE, Symbian et Maemo.
http://labs.trolltech.com/page/Projects/QtMobility
Certes, il est probable que QtMobility soit intégré plus tard, mais sous quelle forme (dans une édition "tout-en-un", dans une édition " mobile") ? Est-ce que ça remplacera effectivement Phonon ? Pour le moment, le "Phonon-killer", il casse pas trois pattes à un canard, le temps qu'il soit utilisable, Phonon aura bien évolué mais ça tu le sais probablement mieux que moi.
C'est un projet R&D et de l'aveu du mec, ils n'ont même pas de roadmap.
"Un jour, on va l'inclure dans Qt comme c'est prévu pour les autres projets Mobility. Comme QtMobility Multimedia entre en concurrence avec Phonon, on en éliminera un".
Le mec, il bosse sur QtMobility Multimedia, forcément, il espère que son bidule éliminera l'autre truc. Si tu demandes aux mecs qui bossent sur Phonon chez Nokia, ils te diront le contraire. Vu l'avancement du projet, rien n'est joué.

> si tout se passe comme prevu, un hypothetique Qt 5 ne contiendra plus Phonon mais QtMobility Multimedia a la place.

Faudra qu'il surpasse Phonon d'abord, mais d'ici là, on a le temps de voir venir.
Et si c'est vraiment mieux, de quoi peut-on se plaindre après tout.

> Pour info je connais tres bien Phonon, je l'utilise et je contribue au code.

Raison de plus, pour ne pas faire paniquer les foules.

Sauf si tu fais partie des premiers employés de Canonical, tu n'as pas pu utiliser la No Name Yet avant fin août 2004 donc au mieux ça fait 5 ans et moins de 2 semaines.
On va pas pinailler plus longtemps sur une petite blagounette. :o)

> C'était absolument pas prêt à être utilisé, mais comme c'est hype et que tout le monde en parle, les distros se sont fait un devoir de l'intégrer le plus vite possible.

ça fait presque 2 ans que j'utilise Pulseaudio quotidiennement et ça marche très bien. Pulseaudio existe depuis près de 5ans (avant, ça s'appelait Polypaudio) et avait pour objectif de remplacer l'immonde esound que tout le monde semble avoir oublié.
Au bout de 5 ans de développement, fallait bien se lancer. Là, où je suis d'accord c'est que beaucoup de distributions l'ont intégrés trop rapidement (notamment Ubuntu qui a fait n'importe quoi), pas étonnant que PA se traine une sale réputation souvent injustifié.

Actuellement, PA est *fonctionnel*, il y a encore des détails à régler comme la conso CPU sur certaines machines mais globalement, c'est un pas en avant vers un meilleur desktop.

Et en plus, il utilise iPoT, la première release d'Ubuntu date d'Octobre 2004. ;)
> ubunteros depuis plus de 5 ans

> Ils ont discuté avec Riverbank mais si l'auteur original ne veut pas changer de license, il n'y a pas 36 milles solutions...

L'autre solution, c'était que Nokia arrête d'être pleure-pain et allonge un peu plus de monnaie.
Phil Thompson était ouvert à un changement de licence tant que ça lui permettait de gagner sa vie. Qt n'est passé en LGPL qu'après le rachat par Nokia, parce que Qt n'est pas la principale source de revenu de Nokia, alors PyQt c'est la principale source de revenu de Riverbank.

> Nokia a vraiment tres tres mal communiqué sur ce coup la, ils sont en train de braquer les devs de Phonon contre eux :/

Nokia n'a rien communiqué, ce sont des développeurs sur leurs blogs.
1. l'API multimédia est une API bas-niveau sur laquelle pourra s'appuyer Phonon. Les deux APIs ne sont pas en concurrence.
2. l'API multimédia est encore en cours de gestation
3. le concurrent de Phonon est l'API QtMobility Multimédia qui reposera sur l'API précédente.
QtMobility est un projet R&D pour définir des APIs communes pour les applications mobiles (Windows CE, Symbian, Maemo). Et cette API ne fait pas partie de Qt 4.6
L'embarqué est une cible majeure pour Nokia (c'est même la raison même de l'acquisition de Trolltech), or Phonon et ses backends ne sont pas adaptés aux mobiles. D'où l'arrivée d'une nouvelle API bas-niveau qui permettra d'accèder aux périphériques bas-niveau (chip audio, caméra etc ...), de développer des applications multimédias nécessitant plus de performances (ie: VoIP), et d'une API haut-niveau pour le playback.

L'auteur du billet s'est "emballé":
* rien ne garantit que QtMobility sera intégré à l'édition "Desktop" de Qt.
* Phonon est maintenu pour toute la durée de vie de Qt4. Et M. Ettrich estimait dans une interview que la prochaine réécriture de Qt n'aurait pas lieu avant 2012.
* Phonon est maintenu par KDE, Trolltech se synchronise régulièrement sur leur branche et maintient quelques backends. On peut envisager que Phonon ait une existence séparé de Qt, techniquement, ça se fait très bien.

> On dirait qu'il y a un amalgame, je opencl est difficile entre autre, donc ca va être dur pour nvidia.
Non, il est dit que le GPGPU c'est difficile et que l'arrivée de nouvelles solutions basés sur la convergence CPU/GPU sensées être plus faciles pourraient lui damer le pion.
Certes ce sera difficile pour nVidia mais il y a d'autres raisons qui n'ont pas été évoqués.


> Bien sauf que nvidia n'utilise pas opencl et ses cartes graphiques se codent en C
Faux, nVidia a participé activement à la conception d'OpenCL (qui s'inspire de CUDA) et compte bien le supporter. Les pilotes et le SDK (basé également sur LLVM/CLang comme celui d'Apple) sont disponibles depuis environ 6 mois via un programme de béta.
Au passage, le langage propriétaire de CUDA comme OpenCL se base sur C99 plus des extensions et un jeu d'API. Si OpenCL est difficile, ben C avec CUDA l'est tout autant

http://www.nvidia.com/object/cuda_opencl.html

Tegra est une puce tout-en-un, mais pas Ion. Ion c'est avant tout un chipset comportant un GPU (9400GM), c'est également le nom d'une plateforme structurée autour de ce chipset et d'un CPU Atom, ainsi tu peux acheter des carte mère Ion.

> ... Je me dit que la firme Nvidia a encore de beau jours devant elle...
Mouais, Intel cherche à révoquer la licence accordé à nVidia pour produire des chipsets à destination de ces CPUs. Si Intel gagne sa bataille judiciaire, tu peux dire adieu à Ion & cie.

http://www.zdnet.fr/actualites/it-management/0,3800005311,39(...)

En parrallèle, Intel essaie de s'assurer que nVidia ne puisse jamais obtenir une licence x86.
Quand AMD a "cédé" sa licence x86 à Global Foundries (une société partagée externalisant la partie production), Intel a menacé de faire révoquer la licence en question sous prétexte qu'elle ne respectait pas l'accord liant AMD à Intel. Évidemment, Intel n'aurait jamais révoqué la licence qui entrainerait inévitablement les foudres de l'UE et du département d'Etat US pour pratiques anti-concurrentielles. Le but de la manoeuvre était d'éviter le "partage" de la licence à travers Global Foundries. De plus, la licence AMD est non-transférable depuis longtemps, le cas GF est toléré à cause de la participation d'AMD (environ 30% des actifs et 50% des voix au CA)
http://www.brighthub.com/computing/hardware/articles/29783.a(...)

Reste la licence Cyrix détenu actuellement par Via. C'est plus incertain, Intel a dénoncé la licence, mais Via détient 3 brevets cruciaux qui leur ont permis de négocier un accord il y a quelques années. Un accord qui très probablement rend la licence non transférable.

Si nVidia freine des quatre fers contre la convergence CPU/GPU, ce n'est pas pour des raisons techniques, ils savent le faire mais pour des raisons économiques.
Si la convergence CPU/GPU se confirme, on peut être sûr d'une chose: l'avenir de nVidia est entre les mains d'Intel.

CentOS a une vraie communauté derrière, c'est supporté par la quasi-totalité des dépôts tiers (EPEL, rpmforge etc ...), les développeurs CentOS ne se contente pas de recompiler RHEL, ils participent activement à la vie de la distribution.

Certes Oracle Linux est très intéressant pour les clients d'Oracle mais pour les restes du monde, c'est anecdotique.

> son travail est plus difficilement maintenable parce qu'il est moins disponible pour travailler dessus que quelqu'un qui est employé pour travailler spécifiquement dessus.

Ça me semble pas très convainquant comme argument.
Le modèle collaboratif de Linux permet justement de s'affranchir de ce genre de détails.
Il n'y a pas qu'un seul spécialiste des ordonnanceurs, de nombreuses parties du noyau sont maintenus par des personnes qui n'en sont pas les auteurs originaux.
Vous imaginez le merdier si pour chaque pièce de code du noyau, il n'existerait qu'une seule et unique personne capable de la maintenir ?
Le problème de la disponibilité est un faux problème si CK fait faux-bond, un autre prendra sa place. À moins que son ordonnanceur soit tellement génial/abscons que personne puisse le comprendre, je ne vois pas pourquoi ça ne serait pas le cas. Où alors, faut se faire à l'idée que Linus n'est pas immortel ...

Si l'ordonnanceur de CK n'a pas été retenu, c'est soit les alternatives étaient supérieures, soit pour des raisons plus mesquines.

J'en profite pour remercier linuxfr ainsi que les éditions diamond sans oublier Mark Shuttleworth. ;-)

En même temps, faut pas pousser la charrue avant les boeufs.
Pour pouvoir passer au tout 64bits, y a quelques trucs à régler:
* portage des pilotes: y a quasiment rien de fait.
* finir le portage des dernières applis carbon en cocoa.
* ne pas brusquer les propriétaires de machine à base de core duo qui ne supportent pas le long mode. Les dernières machines commercialisés datent d'août 2007 (sans compter les machine vendues via le refurb).

La transition 32->64bits va durer encore longtemps, mais c'est un gros pas qui a été franchi.
Snow Leopard est une transition, on s'est débarassé du passé (PPC, Classic, Rosetta, Carbon, etc ...), les fondations sont là (Cocoa, les CoreAPI, OpenCL, LLVM, etc ...)
L'abandon total du 32bits se fera avec la 10.7 voire la 10.8 selon la durée séparant Snow Leopard de son futur successeur.
En comparaison, Windows est encore à la traine, et quant à GNU/Linux, si le gros du boulot a été fait et que depuis un certain temps, toutes les machines en vente sont équipés de CPU x86_64, les utilisateurs rechignent encore à installer une distribution x86_64.
C'est compréhensible du fait que l'utilisateur de base a du mal à voir le gain qu'il peut en tirer, contrairement à la précédente transition 16->32 bits.

La raison est simple, le manque de testeurs.
On a beaucoup d'utilisateurs qui préfèrent attendre 2/3 semaines avant de mettre à jour, le temps de résoudre les derniers glitches. Glitches qui le plus souvent auraient pu être résolu *avant* la release si plus de testeurs s'étaient manifestés.
Pour y remédier, la nomenclature a été revue et le nombre de milestones simplifiés (alpha/beta/RC). Le freeze des traductions a lieu avant la bêta, les fonctionnalités avec la bêta, et le cycle est ponctué de Bug days.
Bien entendu, si la qualité n'est pas satisfaisante, la sortie sera retardée.

N'étant pas développeur web et que tu apprécies Python, je te recommande Pylons ou Turbogears (Turbogears2 repose sur Pylons).
Bien que Django soit un formidable framework web, il a l'inconvénient d'utiliser ses propres composants (ORM, template engine, etc ...) contrairement à Pylons et TG qui réutilisent des briques existantes et plus aisément remplaçables (ORM: sqlalchemy, template: genshi, mako, sécurité: authkit, repoze.who etc ...), ce qui permet de mutualiser un peu plus les connaissances pour des domaines autre que le web.
À mon avis, c'est un léger inconvénient pour les développeurs qui ne font du web que par intermitence, mais si tu as un bon feeling avec Django, ça ne doit pas t'empécher de le choisir.
Sinon, les outils de développement sont agréables (paster, débogueur, etc ..). Si tu cherches un framework plus light, il y a Werkzeug qui est pas trop mal.


Quant à PHP, je n'avais quasiment pas touché depuis PHP4, entre-temps, les versions 5.2 et 5.3 offrent un cadre de développement correct .
PHP n'est pas à négliger, ça reste un langage côté serveur très performant, il y a aujourd'hui pléthore de frameworks modernes permettant de faire des trucs pas trop mal chiadés. Les hébergements sont également moins chers, selon ton cahier des charges, ça peut jouer.

D'ailleurs Ubuntu One sera intégré à Ubuntu 9.10. http://www.ubuntu.com/testing/karmic/alpha3#Ubuntu%20One%20f(...)
Moi, ce qui me chiffonne, ce n'est pas tant l'intégration du service dans la distribution [1], mais qu'un service propriétaire utilise le nom d'une distribution supposé être communautaire et pro-libre.

À vos trolls, prêts ? partez !


D'ailleurs, une partie de la communauté Ubuntu (dont Corey Burger et B. Mako Hill)
https://bugs.launchpad.net/ubunet/+bug/375345
https://bugs.launchpad.net/ubunet/+bug/375272
Pour résumer:
* d'un point de vue légal, Canonical étant propriétaire de la marque a le droit d'appeler Ubuntu son service de stockage.
* Canonical contredit ses propres conditions d'utilisations de la marque Ubuntu http://www.ubuntu.com/aboutus/trademarkpolicy qui dénie le droit d'utiliser celle-ci pour des services commerciaux. Ils ont le droit mais ça n'est pas du meilleur effet.
B. Mako Hill a souligné que le choix de Canonical Ltd au lieu d'Ubuntu Ltd a été la décision la plus sensée qu'ait eu Canonical, distinguant le projet communautaire de la société.
* un désaccord total entre les contributeurs et les employés de Canonical qui s'amusent à fermer/réouvrir les bogues.
* le peu de poids que la communauté possède face à Mark Shuttleworth qui en gros dit "J'ai pris la décision, je vous emmerde" ou bien "C'est bon pour Canonical donc pour Ubuntu". Les citations précises:
--> there's no upside to a naming contest - the name is settled. what would be useful is a broader discussion of boundaries in the area of services rendered from the cloud to the desktop Je vous emmerde en bref.
--> i don't agree with the sentiment that this is a major issue - there are already so many cases of linkage between free software on the desktop / server and semi/completely proprietary cloud services, that i don't accept that canonical should be held to a different standard Notez bien la mauvaise foi dont fait preuve Mark S., personne ne se plaint de l'intégration de u1 dans Ubuntu, mais d'une utilisation mal approprié de la marque Ubuntu.
Le débat lors d'un meeting irc:
http://irclogs.ubuntu.com/2009/06/02/%23ubuntu-meeting.html

Si on excepte ses légions de fanboys, Mark S. a un gros problème de communication avec la communauté. Une fois, sa décision prise (sans consulter nullement la communauté), il est sourd à tout débat, et il encore plus difficile de lui faire changer d'avis.
Son comportement est totalement puéril que ce soit avec son projet à la con de synchronisation des distributions, ses notifications (avec le fameux Notification Bikeshed Summit), ou bien lorsqu'il prétend à tort qu'aucun argument valable pour changer le nom d'U1 n'a été présenté.

Personnellement, ça me rappelle l'époque de RedHat Linux et des premières Fedora où certes la communauté était associé au développement de la distribution mais privé d'un droit de regard sur les décisions importantes.
Aujourd'hui, ni Mandriva, ni RedHat, ni même Novell ne se permettrait un comportement pareil avec leurs communautés respectives. On notera que ses 3 distributions n'ont jamais regretté le fait d'abandonner tout ou partie du pouvoir décisionnel à la communauté, voire le résultat a dépassé leurs espérances.
Paradoxalement, Ubuntu n'existerait pas sans Mark S. mais il est également son plus gros problème avec ses lubies et son caractère de merde.
Il serait temps qu'il se mette un peu en retrait, laisser le plus diplomate Jono Bacon s'occuper seul des relations avec la communauté et lâcher un peu plus de pouvoir décisionnel à la communauté.


[1] Comme Fabien B. l'a souligné le client est libre, tant que le service n'est pas activé par défaut, ça ne pose pas plus de problèmes que les clients pour d'autres services web propriétaires tels que flickr, gmail, etc ...

> C'est que tu ne sors pas assez :p
Soit tu connais une personne qui affirme à tout le monde que gmail et autres web googleries sont libres, soit tu as lu un peu trop vite. ;-)

À l'heure actuelle, je ne crois pas qu'on puisse récupérer toutes les données associés à un projet même si le principal y est.
Néanmoins, des APIs sont fournies et le code disponible, donc à moins que Canonical s'amuse à utiliser un fork spécifique de Launchpad, ce dont je doute, ça devrait être possible.
Ce serait ironique que Launchpad un outil sensé faciliter la communication inter-projet ne soit pas capable de permettre de transférer/synchroniser un projet entre deux instances de la forge.

Je ne confonds rien mais toi tu as mal compris.
Novell édite SLED (aka SuSE) qui se base sur OpenSuSE, le même Novell qui est à l'origine de Mono (ou plus exactement Ximian racheté par Novell).
Donc à la rigueur, si on doit accoller le troll Mono à une quelconque société c'est Novell, à une distribution OpenSuSE ou bien son alter-ego commercial SuSE Linux Entreprise Desktop avec je te l'accorde un peu de mauvaise foi. Mais qui dit troll dit mauvaise foi. ;-)

Mono c'est pas propre à Ubuntu, à la rigueur Novell/(Open)SuSE ;-)