benoar a écrit 4229 commentaires

Il parlait de tout avoir dans le même espace d'adressage, je suppose. C'est quand même censé être le gros changement par rapport aux kernels monolythiques, et là, bah NT ne le fait même pas.

Il y a une différence entre des choses qui "existent" et que des gens passent (perdent ?) leur temps à bosser sur cette chose. C'est ça que tu n'as pas du comprendre.

MS balance des patchs (en fait c'est GKH qui l'a fait, d'où mon incompréhension qu'il s'étonne de leur non-intervention après), n'en a rien à foutre alors qu'ils sont "mauvais" : bah personne va se casser le cul à l'intégrer upstream. Tu veux obliger les devs à installer un Windows avec Hyper-V pour qu'ils débuggent le truc, bénévolement en plus ? Tu rêves.

Doucement, les ARM modernes ont une FPU ... http://en.wikipedia.org/wiki/ARM_architecture#VFP

OK, c'est aussi un appli. Mais si des applis comme mplayer ont aussi une sortie son "pulseaudio", c'est que pour moi il y a une lib/framework derrière.

Ensuite, si je veux pas que mes applis l'utilisent, bah je ne peux pas puisqu'il bloque la sortie alsa. Ma solution : killall pulseaudio.

Non, ce que je dis c'est que les applis qui utilisent un framework de son (gstream, xine) ou une couche d'abstraction de ces framework de son (Phonon) n'ont pas besoin d'être recodées.

Ma remarque, c'était : tu codes une fois le backend pulseaudio dans ton framework favori, et toutes les applis disposent à présent d'un contrôle de volume indépendant. Pas besoin, dans chaque appli, de recoder un slider machin, qui appelle les fonctions du framework de son qui vont bien etc, sans compter qu'un tel contrôle n'est pas forcément intégrable, par exemple pour les notifications du bureau. Avec pulseaudio, j'ai mon appli dans la barre des taches, je cliquouille, je peux diminuer le son des notifs qui est trop fort par rapport à la musique. Pourtant, aucun code spécifique au contrôle du volume dans knotify.
Ha ok, merci de l'explication, je ne l'avais pas compris comme ça (je parlais d'applis "simples" qui utilisent alsa/oss). Effectivement, dans ce cas là, c'est en gros avantage (quand ça marche ...)

Je n'ai pas d'asoundrc. Tout est par défaut, et ça marchait très bien avant que PA arrive.
Si quelqu'un me dit que ça marche bien dans une autre distro que Debian, je veux bien accepter que c'est l'intégration dans Debian qui est pourrie. Mais je ne vois pas grand chose qui marche pour l'instant, nulle part.

Pour les deux premiers points, ça ne marche pas chez moi en tous cas. Et je n'ai encore jamais vu quelqu'un en parler correctement, à part toi.
Alors, avoir un framework qui ne m'apporte rien et en plus fait déconner ce qui marchait bien avant, non merci (autant ceux qui apportent des trucs nouveaux en cassant un peu les anciens, pourquoi pas, mais là, non).

Sinon pour ta dernière remarque, on parlait de PA, pas Phonon, et tu disais :
Avoir un mixer par application sans le recoder dans chacune des applis, qui plus est centralisé ?
Ce qui est faux : il faut recoder les applications.

Laisse moi rire : ces fonctionnalités fonctionnent-elles actuellement ?
Pour le son en réseau, j'ai déjà mpd qui marche, merci.
Pour l'autre (un mixer par application) je ne l'ai jamais vu marcher (debian sid).
Et "sans recoder", excuse moi mais il me semble qu'il faut justement utiliser l'API de PA pour en profiter ...

Moi ce qui me casse les burnes avec PA, c'est qu'il empêche tout autre système de fonctionner en parallèle.

Quand tu as gstreamer, tu peux choisir de l'utiliser ou non pour lire une vidéo (genre utiliser directement mplayer).

Quand j'ai pulseaudio de lancé, il me bloque complètement les sorties alsa à toutes les autres applis. Alors qu'avant, plusieurs applis pouvaient se partager le périph alsa sans problème. Pourquoi ne peut-il pas juste faire comme les autres, au lieu de vouloir passer au dessus des autres ?

C'est le principe de base de tous les nouveaux frameworks : laisser la possibilité d'utiliser les anciens, ou cas où l'utilisateur en ait envie (ou que le nouveau framework en question lui casse les couilles : je suis d'habitude qqun qui accepte de tester quelques temps avant de jeter une appli (j'ai eu du mal avec gstreamer au début, mais aujourd'hui je trouve qu'il est vraiment très bien) mais la non, j'ai aptitude purge pulseaudio il y a deux jours parce que j'en avait marre d'avoir des merdes partout (genre mplayer qui n'arrive pas à utiliser PA, qui veut passer par alsa mais qui est bloqué par PA, et qui tombe sur OSS qui marchotte de temps en temps, je suppose à cause de PA : ça fait un peu trop pour un seul homme, donc bye bye PA)).

T'as une preuve pour la "tout de même fait par le hardware vers la toute fin du pipeline de traitement." ? Moi j'y crois pas. Le fakeRAID, ce que ça change niveau hard, c'est juste le BIOS. Le lien que t'as donné le dit aussi.
Et je pense qu'au contraire, c'est seulement le driver le facteur limitant. Après, c'est sûr que le softraid de linux est sûrement mieux travaillé que les différentes implém de fakeraid des constructeurs, mais comme je disais, en théorie (oui, la pratique, ça change beaucoup) il n'y a aucune différence.

GVFS (dans les versions récentes qui montent les périphs dans ~/.gvfs) utilise bien FUSE. C'est la moyen le plus évident de monter des périphs en userspace (comme son nom l'indique) et c'est bien pour ça qui l'ont utilisé.

Bon, c'est la "bonne" manière de faire, mais c'est clair que ça a mis du temps à venir.

Si tu t'intéresses aux affichages accélérés déportés, j'avais aperçu un jour qu'IBM se lançait là-dedans pour remplacer ses workstations haut de gamme (c'est dire qu'ils y croient ...). Ya des gros gros serveurs derrière et des tout petits terminaux pour les utilisateurs, qui permettent de faire de la grosse 3D sans problème (bon, j'ai lu que les infos marketing, mais ça avait l'air pas mal, vu qu'ils ne font plus de workstations POWER aujourd'hui). Ça s'appelle BladeCenter HC10 pour les serveurs, mais là je tombe que sur des 404 donc j'ai pas de lien à te donner.

Si, ils sont obligés s'ils diffusent leur module. Les "tolérances" ne sont pas normales et sont souvent suivies de procès ou de demande de mise en conformité. MS n'a jamais demandé de diffuser son code "avec le noyau", et pas non plus dans la branche officielle. C'est GKH qui l'a fait.
Faut arrêter de trouver des excuses de merde à ceux qui violent la GPL. Je le comprend d'autant moins sur un site comme linuxfr.

(pour infos, ceux qui veulent parler de nvidia, ils ont une glue en LGPL pour contourner ça).

Petit rappel : ce n'est pas entièrement un geste vertueux, mais juste une mise en conformité après que certains aient fait remarquer à MS qu'ils étaient obliger de publier leur code sous GPL (il y avait donc eu violation de la GPL), cf https://linuxfr.org//2009/07/23/25754.html

Donc ça ne m'étonne pas vraiment qu'ils n'en aient rien à foutre de le maintenir : ils ont été "contraints" de le libérer et ça leur a fait mal, donc ils ont dû arrêter de l'améliorer (voire pire, ne pas publier les sources des améliorations depuis ...)

PbPg a peut-être plus d'infos la dessus ?

Tiens, j'en ai une autre, avec un partage samba et des Ubuntu utilisant OpenOffice : chaque enregistrement sur le partage corrompt le fichier. Il faut enregistrer le fichier en local et le copier à la main pour que ça marche (et bien sûr, la "récupération" de OOo ne fonctionne pas, ça aurait été trop beau).

quant aux filtrages des fournisseurs ?
chez free je n'ai rien constaté de tel
Heu, ça fait longtemps que Free est soupçonné de ralentir (pas bloquer) tout ce qui est P2P.

et si FDN louent ses emplacements sur les DSLAMs des "gros" fournisseurs, il y a des chances que le filtrage soit le meme que si tu etais directement chez ce fournisseur, non ?
Le rôle du DSLAM c'est de "convertir" le signal cuivre ADSL en quelque chose de routable facilement et avec beaucoup de débit sur de grandes distance (en général, de la fibre), c'est tout. Après, un contrat de collecte, son principe c'est juste de transférer du traffic jusqu'à des machines du client (dans le sens où FDN est client de SFR/Orange) sans se soucier de ce qui se passe dessus. Certains clients font leur propre réseau IP qui n'a rien à voir avec Internet. Ce n'est donc pas forcément pour aller sur Internet, SFR/Orange n'a pas à foutre son nez dans ce qui passe la dessus : c'est un transporteur (neutralité, toussa ...). C'est une activité bien différente de la connexion à des IX et de l'infrastructure qui va avec (ce que fait FDN/Gitoyen).

- qui repondra aux majors via un service juridique (les "gros" fournisseurs n'ont probablement pas de service jurique)
Hahaa .... Le "service juridique" chez FDN c'est Benjamin, et ceux qui veulent participer ...

- qui filtre/trie les appels à la hotline avant de contacter le vrai fournisseur donc tu ne gagnes pas de temps entre le probleme et sa resolution, simplement tu passes moins de temps à le resoudre car c'est une entitée tierce qui s'en charge pour toi.
Déjà il n'y a pas de "hotline", quasi-uniquement du support par mail. Après, oui FDN s'occupe bien de ses abonnés, mais on aime bien aussi quand les gens font un peu d'effort pour nous aider à résoudre leurs problèmes.

J'ai l'impression que tu dis le contraire de ton autre commentaire ...
Et quels "goulots d'étranglement" ?! La suite de ta phrase peut aussi avoir deux sens. Les fautes de grammaire n'aident pas à la compréhension.
Le RAID semi-hard ce n'est que du raid soft au final, avec juste un format disque différent. Alors après c'est peut-être plus mal implémenté sous linux, mais en théorie il n'y a aucune différence de perf.

OK, donc pour le boot les deux sont pareil, c'est juste que pour le côté "orienté évènement", il n'y a que upstart qui le fait ... Merci.

Un Xorg par écran ce n'est plus possible depuis quelques temps, alors laisse tomber.
Tu as oublié un truc dans ta description : pilote libre ou proprio ? Vu tes problèmes, je suppose que c'est la seconde réponse ...
Vu que t'as une carte pas "super récente", je pense que le pilote libre pourrait très bien marcher. J'ai quasiment la même config (dual 20" sur un debian Sid avec une ATI HD3200 et pilotes libres radeon) et ça marche du tonnerre en suivant ça :
http://wiki.debian.org/XStrikeForce/HowToRandR12

Un peu plus d'infos sur ta carte (modèle) et ta config (xorg.conf) seraient les bienvenues.

C'est effectivement ça : insserv a été installé et j'ai fait la migration "automatiquement" (j'ai du aptitude purge certains vieux restes). Je n'avais pas activé le truc avec CONCURRENCY=... car je ne l'ai vu indiqué nulle part lors de l'upgrade ... bizarre (car en général tout est super bien indiqué, comme pour le passage à GRUB2, et même l'install d'insserv était super-claire).

Je l'ai ajouté, j'attend le prochain boot pour vérifier si ça va plus vite ...

Par contre, pour revenir à la question originale, quelle différence avec upstart ?

Ma Sid m'a récemment proposé de passer au "démarrage parallèle", ce que j'ai fait. Pourtant, je n'ai pas upstart d'installé sur mon système. Des infos ?

(GRUB2 est aussi arrivé en même temps au passage)

Alors, je ne jamais testé, mais le man dit que c'est effectivement une option qui répartit les LV sur plusieurs PV. Par contre, ça ne dit rien par rapport aux perfs.

Pour le doublement de débit, c'est toi qui l'a constaté ? Une URL ?

Ogg pour l'instant n'est pas supporte par ces differents DSPs
Je n'aime pas cette formulation, car je ne sais pas si t'as rien compris ou alors si tu veux dire cela : il n'existe pas de codec (d'implémentation) Theora pour ce DSP (qui est quand même _le_ DSP le plus connu au monde).

tu sais Nokia a meme les moyens de creer un DSP specifique a Ogg avec leurs moyens
Hahaha. C'est une blague ? Pourquoi n'ont-ils jamais fondu leurs puces "haut de gamme" (je dis ça pour éviter un malentendu sur leurs téléphones de base : je ne sais pas qui fait le chip dedans) et utilisent du ARM, et des DSP de chez TI ? Ce ne sont sûrement même pas eux qui ont codé le DSP ! Alors de là à en fabriquer un ...

faut revenir dans le monde reel, il faut que l'investissement en vaille la peine
Ça je suis un peu d'accord, c'était ma conclusion. Même si à la base, les DSP ont quand même été inventés pour baisser considérablement le coût de solutions de calcul intensif et d'éviter de créer ses propres ASIC spécifique. Admet que le coup est quand même très largement plus bas (je ne connais pas complètement bien le domaine, mais entre refaire une puce maison et coder un DSP, je pense qu'il y a facile un facteur 100).

quelle est le benefice de depenser du fric pour ecrire ce codec sur ce type de DSP vu que personne l'a fait avant ?
Je ne comprend pas cet argument. Tout le monde se bat généralement pour avoir la première implémentation afin de pouvoir la revendre aux suivants. Là tu parles que ça ne les intéresse pas d'être leaders, mais seulement suiveurs ...?
En plus, Theora étant un dérivé de VP3, qui a sûrement déjà été implémenté sur différents DSP, ça devrait leur faciliter la tâche.

a) Europe ou pas, Nokia et autres s'en foutent, ils visent le marche mondial, et a peu pres 50% du marche mondial c'est les USA, ils peuvent pas vivre sans eux
Bon là je partais en trip par rapport aux "vrais" libristes. Je sais bien qu'ils n'en ont pas rien à foutre.

b) Pour le kernel, ils savent qui est la pour le proteger (IBM, ...) et qui se plaint (MS). Pour Ogg, rien.
Argument intéressant. Mais bon, moi je peux imaginer plein de cas où on imagine des choses absolument horribles pour des implémentations de pleins de choses différentes. Je trouve l'argument du "OMG c'est trop dangereux" complètement débile quand il est exagéré à ce point là, et va même complètement à l'encontre de la manière dont les brevets devraient marcher (ha, tu va me faire la remarque sur le conditionnel ...) : de manière ouverte et sereine (oui, Bisounours, toussa). Et puis pour moi, ça reste exactement la définition du FUD.

c'est des entreprises, pas des humains
Bon, là on pourrait partir sur une réflexion philosophique de la dénaturation complète de ce qu'était l'entreprise à l'origine, et de l'aliénation des gens par ces "machines" dont on fait tout pour qu'ils ne se les ré-approprient pas. Mais je sens que ça va trop dériver.

Simplement le benefice tire de l'implementation ne vaut pour l'instant pas le cout et les risques, c'est tout simple.
Les "risques" .... Franchement, qu'ils soient honnêtes : "on n'en a rien à battre de votre codec à deux balles, nous le libre on s'en branle, ça ne nous rapportera pas grand chose". Mais non, fait que des gens trouvent de faux arguments de merde pour qu'ils puissent continuer à se dorer le blason sur le dos du libre ...

Haha. Le problème n'est dans aucun des deux points qu'il cite.

Le premier point montre sa méconnaissance du truc, c'est un DSP, ça se reprogramme quand ils veulent. Sauf qu'ils veulent pas ...

Le deuxième point est le troll habituel : les purs et durs n'en ont rien à foutre des brevets, d'autant plus en Europe. D'ailleurs, t'as l'habitude d'utiliser l'argument du plus petit dénominateur et de dire que le kernel est dans le même cas : personne ne sait s'il est couvert par des brevets ou non (MS veut rien montrer ...). Bref, dire que pour le Ogg Theora c'est super dangereux, c'est du FUD : ils utilisent déjà le kernel (et tout le reste, allons-y pendant qu'on y est)...

Bref, soyons honnêtes et ne penchons dans aucun des deux extrêmes : ils ont la flemme (= pas de $/€ à mettre dedans) d'implémenter Ogg Theora vu la base d'utilisateur, et la base de vidéos déjà publiées dans ce format. En plus, comme je l'ai supposé plus bas, c'est même pas eux qui ont implémenté le codec mais TI, c'est donc envers eux qu'on devrait se tourner (enfin, théoriquement ce serait bien le constructeur, mais vu la communication de Nokia avec la communauté Maemo, on peut toujours espérer ...)

[mode type="humour" degré="rigolo" variante="drôle"]
Ne prend pas ton cas pour une généralité
[/mode]

En dehors de ça, tu verras que le gars en question n'est quand même pas tout à fait au niveau des dirigeants qu'ont a l'habitude de connaître. Il est vraiment horrible au point que je me fais beaucoup de soucis pour certains projets depuis le rachat de Sun.