GeneralZod a écrit 2316 commentaires

> Franchement, pour monsieur tout le monde, ca sert à quoi?
To 3nl4rg3 sa desktop experience. Avec PA, tu peux configurer le volume pour chaque application, tu peux rediriger facilement le son sur une autre machine, d'autres applications sont possibles comme baisser automatiquement le volume de toutes tes applis quand tu reçois un appel par VoIP, à switcher automatiquement la sortie audio quand tu branches un casque etc...
C'est peut-être "gadget", mais ça revient à se remettre au niveau des OS propriétaires communs sur le desktop.

Tu n'en vois pas l'intérêt ou n'a pas l'utilité c'est ton droit, mais j'en ai marre de lire sur les forum (fedora y compris) des messages où pour n'importe quel problème (qui parfois n'ont rien à voir du tout avec l'audio), on te fait désinstaller PA. Le plus agaçant, c'est ceux qui n'ont pas utilisé PA depuis plus d'un an et qui après se permettent de dire "PA saidlamerde, gnagna".

> Et pour pulse audio, c'est partout pareil, c'est une bouze infame
Une bouse uniquement sur les distros qui savent pas configurer correctement PA. Hein, PA a des problèmes mais nettement moins que feu aRts et ESound qu'il remplace.


> qui s'est étendu sur l'ensemble des systèmes depuis sa création
La première distribution a avoir installé PA par défaut c'est Fedora 8 fin 2007 et ça fonctionnait parfaitement. Les autres distributions ont suivi 6 mois plus tard avec plus ou moins de bonheur. La palme de l'imbécilité revenant à Ubuntu qui a foutu PA (ça mérite même pas le terme intégration) dans la 8.04 avec une configuration foireuse non testée, sans même consulter le mainteneur upstream (le fameux Lennart Poettering).
PA est né en 2004 sous le nom Polypaudio, il est pas sorti de nulle part et au bout de 4 ans, il était peut-être temps de l'intégrer au bureau.


À un moment, faut se sortir les doigts du cul, PA n'est pas parfait, son mainteneur est aussi aimable qu'un roulier texan assis sur un banc d'oursins, mais dans l'ensemble c'est une amélioration substantielle de la pile audio du bureau GNU/Linux.
Au lieu de pleurnicher et de le désinstaller au premier pépin *sans chercher plus loin*, faites l'effort de faire remonter les bogues. Sans compter que bon nombre de bogues attribués à PA sont des bogues propres aux pilotes Alsa, ou dû à des hacks pour contourner les-dits bogues.
"J'ai pas de son" ==> vlan, vire PA, "mon nordinateur est lent" ==> vlan, vire PA, "j'installe la distro XYZ" ==> VIRE PA !!!!

Sorti le 10 octobre, ça présente la distribution communautaire CentOS dérivée de RedHat Entreprise Linux qui est assez populaire niveau serveur. Il y a deux DVD d'installation x86 et x86_64.
J'ai acheté le numéro sadi, les articles sont pertinents et agréables à lire, les sujets bien choisis. Le numéro cible l'aspect serveur CentOS (LAMP, vftp), la configuration. J'ai noté un article sur une utilisation desktop de CentOS, un domaine où ne s'attend pas vraiment à trouver CentOS, qui tort un peu les idées pré-conçu.

Le seul bémol: le prix des Linux Identity (presque 10€), sachant que les auteurs sont payés au lance-pierre, ils pourraient faire un effort. :/

> Si je résume Mono c'est en gros .net mais pas vraiment, mais avec des trucs en plus. Je vois de moins en moins l'intérêt.
Enfin, là, tu ne vois que ce qui t'arrange.
Mono implémente la totalité de .Net 1.1/2.0, pour .Net 3.0/3.5 (la 3.5 c'est un ajout de nouvelles bibliothèques), la partie normalisé est terminée (CLR, langage C#) et on entame le support de C# 4.0, pour les bibliothèques, ben certaines sont plus diffciles à implémenter comme WPF.
Évidemment, il y a des bogues d'implémentations, mais c'est pareil pour les JVM commerciales ou bien les implémentations libres de Java.

Quant aux trucs en plus, ce sont des bibliothèques qui offrent des fonctionnalités supplémentaires et/ou une meilleure intégration à d'autres systèmes.
Une application WinForms, c'est pas ce qui s'intégre le mieux à un bureau Mac ou GNOME. J'ai gardé de bons souvenirs de Mono/Gtk# sans jamais toucher à .Net.

> Écrire une application qui soit portable de Mono vers .net est inversement est donc juste impossible dans ces conditions.

Une application Mono est portable vers .Net sans problèmes, la quasi-totalité des bibliothèques spécifiques à Mono sont portables sur .Net sauf bien évidemment celles qui sont limités à une plateforme comme par exemple Cocoa#.
La portabilité d'une application .Net vers Mono sur Windows ne pose pas trop de problèmes, mais les développeurs .Net en bon développeurs windows codent comme des porcs et la portabilité vers d'autres plateformes est pas automatique (merci les P/Invoke principalement).
Mono propose des outils pour justement détecter les problèmes de et portabilité en amont avec Gendarme et surtout MoMA.
http://www.mono-project.com/Gendarme
http://www.mono-project.com/MoMA

Je suis pas développeur web mais niveau performances pures, côté serveur, php garde une bonne avance. Mais avec WSGI on arrive à de très bonnes performances (mod_wsgi, CherryPy). TG, Django sont utilisés dans des sites à fort trafic sans problèmes.
Après d'autres facteurs rentrent en compte, l'architecture, les composants utilisés, mais également le temps de développement/maintenance.

Pour te donner un exemple, le moteur de template utilisé par défaut dans TG1.1/2.0 (et dans Trac) Genshi est environ 10 fois plus lent que Mako (défaut de Pylons) ou Jinja2. Or pour la plupart des applications, c'est secondaire. Le fait que les templates Genshi sont du xml directement affichable dans un navigateur web et par la même facilite la collaboration avec des graphistes est très appréciés.
Là où ça devient intéressant c'est que selon tes besoins, Pylons ou TG te permettent de sélectionner les composants les plus appropriés.

http://genshi.edgewall.org/wiki/GenshiPerformance
http://www.makotemplates.org/
http://chrismoos.com/2008/01/27/genshi-vs-mako/

> Est-ce que les connexions bdd sont gérées avec des pools de connexion comme c'est le cas avec des serveurs J2EE ?

Pour les connexions aux bases de données, l'ORM SQLAlchemy gère effectivement les pools de connexions (http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/pooli(...) Tu peux également taper directement dans la base de données avec l'api Python DB-API 2.0, même si la plupart des pilotes le gère (pyscopg2, mysqldb etc ...) le pooling n'est pas requis mais il y a des modules qui pallient à ce problème.
Voilà comment faire avec Pylons/TG2
http://wiki.pylonshq.com/display/pylonscookbook/Using+the+DB(...)


On ne l'a pas évoqué dans la discussion mais si tu as vraiment besoin de grosses performances, tu peux utiliser des frameworks plus petits comme werkzeug ou CherryPy.
C'est moins prémaché mais tu peux utiliser les mêmes composants (templates, ORM, authentifications). J'ai beaucoup aimé werkzeug qui est très simple et que j'explorerais un peu plus dès que j'aurais le temps. :o)

Effectivement, Impressive couplé à Beamer permet d'arriver à un résultat "pro" mais c'est loin d'égaler la simplicité d'utilisation de keynote pour le grand public.
Avec quelques efforts, le résultat est vraiment "impressive" donc je plusse.

http://impressive.sourceforge.net/

> mono est assez loin d'avoir implementer tout .Net me semble t'il
Grosso modo, Mono 2.4 implémente tout .Net 2, par défaut mcs compile en C# 3.0 et la prochaine version verra arrivé C# 4.0 et le support complet de LINQ. Pour le framework 3.0/3.5, c'est plus compliqué, une partie est intégrée dans Mono, l'autre est implémenté par le projet expérmental Olive (WPF, WCF). Bien évidemment, il y a quelques bogues mais c'est utilisable en production.

Pour ASP.Net, Mono implémente la version 2.0 et intégre même le machin MVC de Microsoft.
D'après les retours, le support d'ASP.Net dans Mono est correct, c'est même utilisé dans des produits professionnels comme Grasshoper.


> mono ne serait pas en retard d'une generation par rapport a l'implementation microsoft?
ça dépends, au niveau du support du langage et du compilo, Mono se débrouille pas trop mal. Parfois, ils implémentent des trucs avant Microsoft comme les generics.
C'est surtout au niveau du framework que ça pèche, ils sont pas très nombreux et Microsoft ne leur facilite pas la tâche avec une conception pas multiplateforme-friendly.
Mais ça ne concerne que la pile de compatibilité avec Microsoft, Mono offre en parrallèle un jeu d'API tout aussi riche si ce n'est plus.
Quand je développais en Mono, je n'ai jamais eu besoin de taper dans la pile Microsoft, même aujourd'hui, il n'y a guère que System.Query (LINQ) qui pourrait éventuellement m'intéresser et encore ...

Le site de Chi-X tourne sous IIS et ASP.Net mais le site de marketprizm tourne sous Apache et une distribution GNU/Linux.

Do you Mono ?
Mono supporte (Open)Solaris sur x86, x86_64 et Sparc, c'est une éventualité mais peu probable.

Il a intérêt à garder Mandriva, il connait déjà la distribution et n'a pas envie de trop s'investir dans l'administration. De plus, c'est pour en faire un petit serveur et une utilisation multimédia, donc Mandriva sait faire ça sans problème.
Vu l'utilisation de la machine, perso, je mettrais le serveur dans un chroot/machine virtuelle ou au minimum utiliserais SELinux pour protéger le service.

La différence c'est que l'existence des formats microsoft dans OOo et de Samba sont pour des raisons d'interopérabilité.
Microsoft n'est pas vraiment amical envers le libre et maintient un discours ambigu au sujet de Mono. La situation juridique de Mono ne s'est réellement éclairci que grâce à OIN qui dispose d'un portefeuille de brevets suffisamment conséquent pour faire réfléchir deux fois Microsoft avant de s'attaquer directement à ce projet.
On notera que ça vaut également pour Samba et dans une moindre mesure Linux.


Je n'ai jamais compris la haine viscérale que certains ont envers Mono, mais vu les discussions houleuses que l'accord Novell-MS a généré, crois-moi la position de Mono dans la plupart des distribution tiens à très peu de choses.

Va sur uspto.gov, fais une recherche sur les brevets appartenant a Microsoft, tu enleves les ~500-1000 que Microsoft a "offert" au libre, et tu regardes les milliers qui reste.

Oups, Microsoft a offert le nombre faramineux de *0* brevets au libre ... Ils n'ont même pas pris la peine de clarifier leur position vis à vis de Mono, à croire qu'ils prennent à malin plaisir à maintenir des propos ambigüs à ce sujet.
Sans le parapluie OIN, Mono serait devenu persona non grata dans la majorité des distributions suite à l'accord Novell-Microsoft.

Pour rigoler, on devrait comparer le nombre de développeurs qu'IBM et Microsoft paient pour faire du logiciel libre, le fric dépensé sur des projets libres, la stratégie adoptée vis à vis du libre, de la publicité générée autour du libre (ou plutôt du FUD dans le cas de Microsoft, Get the facts ou les éructations de Monkey boy Ballmer) etc ... Après on s'étonne encore de la différence de traitement.

Si on se replace dans le contexte de l'époque.
- Java pas libre, GCJ/GNU Classpath inutilisable
- progression de .Net dans l'éducation et plus timidement en entreprise
- le besoin répété des développeurs d'un langage de plus haut niveau pour GNOME
Fournir dès le départ une implémentation plus ou moins compatible d'un environnement amené à devenir populaire (ne serait-ce que par la puissance marketing de Redmond), c'était un joli coup.
On évite de se retrouver dans la même situation qu'avec Java (à la sortie de Java6, GCJ était presque compatible Java 1.4), on parvient à intéresser un certain pourcentage de développeurs .Net à des plateformes libres avec des bibliothèques innovantes et le multiplateforme. Ça a permis à bon nombre de développeurs de faire des applications desktop sympas comme Beagle, Banshee, Diva, Tomboy
Même la FSF avait sa propre implémentation avec Portable.Net qui est décédé faute de pouvoir suivre la cadence infernale de Mono.


Aujourd'hui, Java est libre, on a Vala, .Net peine encore à s'imposer notamment côté serveur. Forcément, Mono est moins intéressant. Depuis que le consortium OIN protège Mono, on n'a pas vraiment de raison de craindre quoique ce soit malgré l'accord infâme de Novell.

> Cette remarque est valable aussi pour un passage à Pylons.
Justement quitte à casser la compatibilité, autant explorer d'autre pistes. C'est vraiment la convergence de visions des deux équipes sur ce que doit être un framework web moderne qui a fait ce choix.
Quant à CherryPy3/TG1.5, une discussion est ouverte mais rien n'est décidé. Vu la tendance, c'est très peu probable (d'où un fork Gearshift). le projet a très clairement affirmé que TG2 constituait l'avenir, TG1 est destiné uniquement aux applications déjà en production.


> la force de TG est l'interchangeabilité des composantes. Il semble que le couplage TG2.0/Pylons soit fort

Mis à part le coeur de TG2 en l'occurence la partie contrôleur (ici Pylons), tout est interchangeable, les ACLS, l'authentification, le moteur de template, l'ORM, les widgets etc ...
sinon, ce serait plus un framework mais un bric à brac. :]
L'autre question que j'anticipe, c'est quel est l'intérêt par rapport à un Pylons brut de décoffrage ? Pylons offre trop de choix, Routes (le dispatcheur d'url) trop compliqué. TG2 t'offre un environnement par défaut utilisable hors-de-la-boite avec la possibilité d'utiliser tes composants préférés. D'ailleurs, TG2 a été très bien accueilli par la communauté Pylons parce que cela répondait aux besoins de certains développeurs.

Par rapport à Django, même si ça évolue, l'intérêt de TG c'est de minimiser la courbe d'apprentissage. Tu peux réutiliser la plupart des connaissances acquises dans d'autres projets.
Django est plus orienté CMS et gestion de contenu, ressemble plus aux autres frameworks web et conviendra plus aux développeurs web.
Alors que TG s'adresse plutôt à un public de développeurs Python chevronnés par son côté plus pythonnique, utilisation de constructions avancés (gestion des urls par des décorateurs comme CherryPy), WSGI (Mark Ramm de TG2 a créé une polémique à ce sujet lors du dernier DjangoCon) concept inexistant chez Django sensé favoriser l'interopérabilité entre les frameworks web python.

Voici le point de vue d'un développeur Django
http://www.biologeek.com/django,traduction,web-frameworks/co(...)

J'apprécie et respecte beaucoup les deux personnages, le premier pour avoir lancé le mouvement libriste (et il aura toujours ma reconnaissance pour cela), le second pour être un fouteur de merde qui fait avancer les choses (GNOME, Mono, etc ...).
Mais j'ai trouvé cette gueguerre ridicule, même si je trouve que Stallman a raison d'être sur la défensive, sa tirade sur les méfaits de CodePlex et la présentation de MDI comme d'un traitre digne d'être pendu était fendarde. Il a le fond mais pas la forme qui va avec.
Stallman n'est clairement pas un communiquant, il est trop sérieux, manque cruellement de dérision pour se permettre des discours aussi durs. Les gens ne comprennent pas le personnage et à fortiori son discours qui passe dès lors pour extrêmiste. Je recommande la lecture de son autobiographie qui est passionnante pour comprendre qui se cache derrière le petit Richard Matthieu Stallman.
http://fr.wikisource.org/wiki/Free_as_in_Freedom

La réponse de MDI n'est guère mieux, on le sent au bord de l'explosion.
C'est un trolleur-né, il a lancé les trolls Gtk+/Qt, KDE/GNOME, Mono, sa proximité avec Microsoft considéré par bon nombre de libristes comme le Mal absolu agace.
Il sait pertinent qu'il agace, mais il ne peut pas s'empêcher de jetter de l'huile sur le feu. Mais contrairement à d'autres trolleurs professionnels, il a le bon goût de faire avancer les choses.

Stallman a récompensé MDI dans le passé, maintenant, le fils prodigue a trahi, il veut le fesser, c'est puéril, comique. :o)

Bonne question :o)
Premièrement, le passage de CherryPy 2 (utilisé dans TG 1.0/1.1) à CherryPy 3 est impossible sans casser la compatibilité.
Deuxièment, TG est né de la volonté d'utiliser les meilleurs composants existants et d'en faire un framework web cohérent sans être monolithique et familier aux développeurs Python.
Un des objectifs de TG2 était le support de la norme WSGI[1] principalement pour une meilleure interopérabilité avec les autres projets. Certes CherryPy 3 convenait parfaitement, mais le choix de Pylons (Paste à l'époque), s'est fait à cause de l'affinité naturelle des 2 projets et des équipes[2] au point d'évoquer une fusion des projets[3].


Mark Ramm est un des développeurs principaux de TG.
[1] http://compoundthinking.com/blog/index.php/2009/02/04/wsgi-a(...)
[2] http://compoundthinking.com/blog/index.php/2007/07/09/turbog(...)
[3] http://compoundthinking.com/blog/index.php/2007/03/05/mergin(...)

En même temps, ça reste une version majeure, Et vu le nombre de sites utilisant TG1, ça reste une nouvelle importante. Les deux branches vont coexister pendant un bon bout de temps, donc l'arrivée de TG 1.1 était plutôt attendu. :)
http://docs.turbogears.org/1.0/SitesUsingTurboGears

Ça se tient. Aujourd'hui, si tu dois créer une nouvelle application, il est fortement recommandé d'utiliser TG2 sur laquelle se porte la majorité des efforts.
Néanmoins, le seul passage de CherryPy à Pylons casse la compatibilité et le rends le portage d'applications complexes plus délicat.
En gros, TG 1.1 est là pour les sites déjà en production et leur faciliter la transition (même choix par défaut que TG2).
Quant à la 1.5, c'est en discussion, doit-on passer à CherryPy3 ce qui casserait la compatibilité avec TG 1.0/1.1/2.0 ? Il y a déjà un fork qui le fait, doit-on encore plus faciliter la transition de TG 1.1 vers TG 2.0 ? notamment en supprimant les API dépréciés etc ...

Pourquoi pas ?
Les "petites" distributions ne sont pas en reste, j'ai bcp apprécié mon temps sous Slackware. D'ailleurs, ça me rappelle une autre distribution orienté KDE Mepis qui bien avant Ubuntu avait pour ambition de fournir un bureau neuneu-proof avec un certain succès.
Enfin, Fedora Linux n'est pas édité par RedHat mais par la communauté Fedora, du moins la communauté a bcp plus de poids que dans les deux autres distributions soutenues par les deux autres mastodontes.

Fedora est certes orienté GNOME, mais il existe un spin KDE géré par le groupe d'intérêt KDE.
Le KDE proposé est un KDE vanilla toujours à jour, et les développeurs KDE semblent apprécier le boulot du SIG KDE.
http://fedoraproject.org/wiki/KDE

Mais si tu veux mon avis, OpenSuSE est la distribution qui intégre le mieux KDE.

Ils constituent en général une bonne source d'information surtout si ils sont récents.
Avec du matos type tuner TV dont les composants matériels varient très souvent y compris au sein d'un même modèle (linuxtv est complétement à la rue), on n'a pas trop le choix.

Mon dernier achat, c'est un dongle usb TerraTec Cinergy T USB XXS, j'ai juste eu à récupérer le firmware contenu dans le driver winmerde fourni avec. Donc si vous achetez du matos qui marchent bien, n'hésitez pas à laisser des commentaires pour les camarades.

> Sur la liste de Beagle, ils mentionnent aussi Tracker, apparemment le choix de Ubuntu, mais ils disent que Tracker ne marche tout simplement pas.

Although I think Beagle is still for the moment ahead of
Tracker in terms of core user functionality, Tracker has a vibrant
development community backed by open source companies whereas Beagle's
is completely stagnant and bordering on nonexistent Joe Shaw

T'as mal compris, J. Shaw dit juste que Beagle est plus avancé que Tracker mais alors que Tracker est activement maintenu, Beagle quant à lui stagne.
Pour avoir utilisé Beagle puis Tracker, je peux t'affirmer que Tracker fonctionne parfaitement donc pas d'inquiétude à ce sujet.
Effectivement, Beagle n'est pas spécialement bloated, excepté au moment de l'indexation mais c'est un problème commun à tout les indexeurs que ce soit Spotlight, Google Search, Tracker & cie (et encore, on peut configurer le service d'indexation pour ne pas prendre trop de ressources) mais force est de reconnaitre que Tracker est plus lite.

La partie gérant le rendu des polices n'a pas été libéré (brevets kodak toussa etc...), IcedTea/OpenJDK l'a remplacé avec du code provenant de GNU Classpath qui utilise freetype.
D'un côté, t'as les bogues propre à Sun Java : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6761856
De l'autre, Mandriva utilise probablement la version "patent-free" de Freetype, donc le rendu des polices est un peu moins joli (ça dépend des polices aussi).
Chose incompréhensible même par le développeur de Freetype, Debian (?) et Ubuntu continuent à distribuer la version "patent-infringing" alors que par défaut c'est désactivé.

http://freetype.org/patents.html

C'est déjà un début.
http://www.swaroopch.com/notes/Vim_en:Table_of_Contents

> un IDE sous linux qui soit utilisable, pas trop lourd et qui supporte une majorité de langages
un GNU/Emacs bien configuré, mais ça demande pas mal de temps pour arriver à une configuration "productive" et la courbe d'apprentissage est ardue. Mais le résultat est imbattable.

Vu que c'est basé sur un framework libre, j'ai pensé que ça pouvait être intéressant. De plus, entre la fondation Codeplex et MonoTouch, ces derniers temps, MDI cartonne dans le troll de compétition, à croire qu'il fait exprès. :-)
Après, je comprendrais que l'équipe refuse la dépêche parce que c'est bordeline mais c'est mieux que de ne rien proposer du tout. ;-)