Troy McClure a écrit 2213 commentaires

Si on ajoute comme contrainte "une équipe capable d'établir un consensus avec suffisament d'autorité sur l'ensemble des utilisateurs de l'audio sous linux" (mme michu, les "pro", ceux qui veulent lire des flux 5.1 ou juste que leur gnome fasse "prout" quand il affiche un dialogue d'erreur), il n'y a plus personne, alors qu'il faudrait un benevolent dictator dédié à l'audio.

Dernièrement sur la ml Jack il y a eu quelques trolls d'envergure qui ont mis ça en évidence:
- integration de dbus dans Jack (pour piloter le demon via dbus): impossible car une partie de la communauté hait dbus -- discussions sans fin, menace de fork, posts un peu degoutés des developpeurs principaux de jack sur l'impossibilité de se mettre d'accord sur une ligne de conduite.
- annonce de RealtimeKit par l'auteur de pulseaudio (pour une possible utilisation par jack): impossible car une partie de la communauté hait pulseaudio (normal ça utilise dbus), posts un peu dégoutés des dev principaux de jack parce qu'ils n'ont pas du tout été inclus dans les discussions qui ont précedé la création de rtkit par redhat (normal tout le monde a bien trop peur des trolls de jack.audio.devel et linux.audio.devel), et qu'ils croyaient que le probleme de la gestion des droits temps-réél était un probleme déjà réglé (en gros redhat a changé d'avis)

En fait linux est même en train de "perdre" jack , puisqu'il est désormais disponible aussi bien sous MacOS que sous Windows et qu'il est activement développé sur ces deux plateformes. Peut etre que le côté trolleur et casse-couilles de la communauté audio sous linux n'y est pas totalement étranger..

un autre son de cloche (c'est par l'auteur de pulseaudio):
http://0pointer.de/blog/projects/guide-to-sound-apis

extrait de son commentaire sur pourquoi OSS4 est mauvais selon lui:

OSS4 does a lot of signal processing (resampling, mixing) in the kernel. That is a big no-no, it's verboten in the Linux world. The kernel is supposed to include drivers, not processing algorithms. In its current form OSS4 would have exactly zero chance to even be considered by the Linux kernel people. If you'd rip out all the mixing, resampling, conversion, remapping then not much would be left of OSS4, except that a slightly updated OSS3 API. Then, the driver support in ALSA these days is actually much better than OSS4 since a lot of hw manufacturers nowadays work with the Linux community to improve the in-kernel drivers. OSS4 doesn't have that advantage. The ALSA people work well together with the rest of the kernel people, the OSS people absolutely don't. Then, the fact that the OSS API is a kernel API is one of the biggest issues, due to its ioctl-caused awkwardness and the impracticability to virtualize. It's also not extensible. Let's say I wanted to add DRC to the mixing code: I'd have to code that in kernel space -- and floating point calculations aren't even allowed in kernel space! It's just the wrong place to do these processing tasks in the kernel. Also on Linux interfacing with FireWire or Bluetooth audio happens in userspace and can thus never be covered by OSS4. And let's not even touch RAOP or UPnP audio devices! And this list goes on and on and on. There are so many fundentamental issues with OSS, it's an endless list. OSS4 is not just the worse system, it's a fundamentally wrong system. (At least on Linux. On niche Unixes different requirements apply)

y'a moué

sur mon desktop (mobuntu jaunty) radeon 3470 et pilote fglrx fonctionne (pendant 12h en moyenne avant le premier plantage, et a condition de ne pas utiliser de kernel realtime, et de ne pas faire d'hibernation ou de suspend to ram). Le pilote radeon tout court ne marche pas, et radeonhd fait de belles rayures verticales

Et oui on est en 2009 et on a toujours les même problemes qu'en 1999 :'( Enfin quoique je me souviens qu'à l'époque au moins je n'avais pas de plantages intempestifs du serveur x ou du noyau. La même machine sous vista tient plusieurs mois sans planter, car elle arrive à recuperer les crashes du pilote ATI. Sur ce coup-là je crois que microsoft a eu le nez creux

En même temps il ne faut pas se sentir obligé d'utiliser en permanence toutes les features du c++ (d'autant que comme tu le dis il y a déjà pas mal de pièges dans le c++ "traditionnel"). En je crois qu'aujourd'hui encore la majorité du code c++ pondu quotidiennement c'est plutot du c++ à papa bien tranquillou avec des classes, des fonctions virtuelles, de la stl mais pas (ou peu) de templates ou de surcharges de l'opérateur virgule. Les templates sont très utiles pour construire des briques de base (par ex la stl, boost, etc), mais au-delà ils deviennent moins préponderants.

Faut juste arriver à passer le plus vite possible le court moment de délire qui se produit quand on comprend la puissance des templates et qu'on essaye de faire executer la moitié du programme par le compilateur :) (en sacrifiant des poulets pour qu'il inline le reste comme il faut)

maintenant faut que tu lui fasses un test similaire avec du whisky ! (pour tous les gens qui ne boivent que du whisky 42 ans d'age parce qu'en dessous vraiment ça se sent que c'est pas pareil)

c'est le ld des binutils, le même que sous linux, mais avec une cible differente (PE-COFF à la place de ELF)

et si tu merges tous les libs statiques interdependantes en une seule avec un ar bien placé ça ne linke pas plus vite ?

juste pour pinailler: les scripts de ld ne sont pas des scripts shells, mais des scripts ld http://sourceware.org/binutils/docs-2.19/ld/Scripts.html

Pourtant grace à la magie du JIT ça devrait aller encore plus vite que du x86 natif, je ne comprends pas.

L'hérésie c'est la façon dont les traitements de texte sont utilisés : à savoir sans aucune séparation du fond et de la forme.

Tu parles de latex là, non ?

faire payer le support pour twitfactory ? t'es sérieux ?

http://ardour.org/node ?

A combien serait le traffic si il n'y avait pas eu cette loi (en utilisant le surpuissant outil statistique qu'est la regression linaire): 90Gbit/s
A combien est le traffic aujourd'hui, trois mois après l'inauguration de la loi: 60 GBit/s
la pente est la même sur les deux morceaux. La loi a reduit le traffic de 30Gbit/s . C'est quand même dur de dire le contraire.

ah oui c'est aussi ce qu'ils disent ici aussi:

http://www.numerama.com/magazine/13227-La-loi-anti-piratage-(...)

Bonjour la mauvaise foi, faut quand même être bien gonflé pour dire que le traffic n'a pas été affecté par cette loi !

C'est clair, déjà qu'on ne sait plus que faire de toutes ces applis java qui foisonnent en pagaille sur le desktop linux

il y a compatibilité sur les fonction "C". Pour tout ce qui est c++, 0 compatibilité le name-mangling the gcc et msvc n'ont rien à voir (ainsi que la gestion des exceptions, etc)

l'autre raison c'est que sauf cas particulier (genre besoin de beaucoup de ram) un build 64-bit n'apporte rien sous windows puisque les applis 32-bit fonctionnent très bien, contrairement à linux ou il faut faire l'effort d'installer les paquet "ia32-libs-*" et où les utilisateurs ont souvent des attitudes très tranchées "ouin je veux un systeme 100% 64-bit"

en 1 minute ? j'ai du mal à y croire, t'es sur que t'as pas des caches qui recuperent le resultat de compiles precedentes ?

le truc c'est qu'entre les deux oreilles y'a un cerveau qui fait un boulot de fou pour identifier les sources sonores et les localiser en fonction
- des retards et volumes relatifs de ce qui parvient aux deux oreilles
- d'un filtrage different du son par le lobbe des oreilles en fonction de la position de la source pour differencier ce qui vient de devant et de derriere
- de l'experience pour estimer la distance de la source, en fonction de son volume, et du filtrage passe-bas que subit le son en voyageant dans l'air
- des micro mouvements de la tete, qui aident vachement eux aussi
- et surement plein d'autres choses

Pour reconstituer fidelement un champ acoustique dans une zone qui ne soit pas reduite à un point, faut mettre plein plein d'enceintes: http://en.wikipedia.org/wiki/Wave_field_synthesis

> Si je me trompe pas, numpy utilise par exemple BLAS et LAPACK.

Et pourtant ils (les devs de numeric numarray numpy) ont eu l'idée tordue de choisir l'ordre "C" (row major) par défaut pour les matrices denses (qui n'a aucun interet puisque les tableaux multi-dimensionnels du C ne servent à rien) plutot que l'ordre "FORTRAN" (qui a l'interet justement d'etre celui utilisé par toutes ces libs et de nombreuses autres). J'ai jamais compris pourquoi.

il y a Fortress qui est basé sur les concepts de Fortran

waou ça fait rever ! les concepts en question c'est le goto , les fichiers sources tout en majuscules et les noms de fonction et de variable limités à 6 caractères avec typage implicite en fonction de la première lettre ?

(on notera que les concepteurs de fortran 77 avaient déjà résolu le problème des fuites de mémoire, et cela sans utiliser de gerbage collector -- ces gens là étaient vraiment des visionnaires)

Vous êtes comme les autres vous refusez d'affronter la vérité nue: windowmaker est immensement populaire et il le jour (proche) où tous les linuxiens utiliseront windowmaker sera celui où on pourra enfin dire "Oui linux est prêt pour le desktop, oui j'y étais j'ai vu ce jour, oui je kiffe les dockapps"

mmm c'est pas con !

une propriété interessante des disques durs est que quelque soit leur taille, il finissent progressivement par se remplir de diverses conneries:
t'as un disque de 40Go ? au bout d'un an il est plein
t'as un disque de 1To ? au bout d'un an il sera plein