benoar a écrit 4238 commentaires

Arrête ton char, quand tu veux des infos, t'as déjà réussi à en avoir. Si tu t'intéraissais un minimum au problème, je pense que tu pourrais avoir des infos. Si tu viens ici, c'est que tu t'intéresses un peu au libre, non ? Ça t'intéresses pas toute cette histoire de code MS sous GPL ?

Communications privées ... là on parle quand même de la politique de maintenance d'un module kernel pour linux dont MS a demandé l'inclusion upstream (d'après ce que GKH dit, après tu peux peut-être contredire, mais alors c'est que t'as des informations ...), un truc plutôt public. Si ce n'est pas un minimum connu dans la boîte, c'est que pour moi il y a anguille sous roche, et qu'ils préparent peut-être un plan foireux. Ou alors c'est qu'ils n'en ont rien à foutre, ce qui corroborerait ma thèse.

Oui, pour moi, faire un montage non prévu à la base pour le système, par un utilisateur, sans trop de difficulté, je trouve que FUSE est bien. Même si on peut faire "mieux" en ayant un système de hotplug bien prévu, mais bon, il y a des cas où c'est difficile (montages réseau, etc).

À noter que cette solution garde l'ancienne stack ATA. C'était juste pour info (il ne me semble pas qu'il soit possible de nommer les disques /dev/hdX avec libata, à moins de jouer avec udev).

Rho putain, l'autre qui comprend rien, qui nous fait un homme de paille, un coup de parano, la totale quoi. Tu te relis des fois ?

Pas plus que de permettre l'intégration de drivers propriétaires. Et pourtant les mécanismes existent...
Le rapport avec la choucroute ? Tu répondais à (je suppose) :
C'est quand même pas le soucis des devs du noyau de faire tourner Linux sur un hyperviseur propriétaire ?!
Ce n'est donc pas plus leur souci de maintenir un truc bâclé. Ils font avec MS comme ils font avec n'importe qui : si tu fais pas d'effort, t'es pas inclus upstream. Point.

Et propriétaire ou non, ce n'est pas trop la question à mes yeux.
Nous non plus, puisque ce dont on parle est sous GPL ...

Xen (avant Citrix, depuis j'avoue être paumé) a longtemps fait/proposé des modifications dans le noyau sans pour autant qu'elles soient intégrées à la branche officielle.
Oui très bien. MS peut très bien le faire aussi, hein, personne ne leur empêche. Mais "ils" ont demandé l'inclusion upstream, il y a quelques règles à respecter (qui sont les mêmes pour _tout le monde_, je répète).

A ce compte là, les "devs du noyau" ne sont pas là pour faire tourner quoique ce soit. Ils pourraient d'ailleurs faire des trucs dans leur coin, sans communiquer.
Là forcément tu vas commencer à énerver ton interlocuteur. Ce n'est pas en se foutant de la gueule des gens qu'on fait avancer le débat. Alors après t'étonnes pas que tu t'en prennes dans la gueule.

Ce n'est pourtant pas ainsi que ça fonctionne. A croire que ce n'est pas ce qu'"ils" veulent (en supposant que les "devs du noyau" parlent d'une seule voix) mais qu'ils souhaitent plutôt offrir le maximum de services aux applications (au sens très large). Etonnant non pour un système d'exploitation...
Oui, je suppose que c'est ce qu'ils souhaitent aussi. Mais il ne faut pas non plus les prendre pour bobonne, il y a certaines règles à respecter, qui sont édictées depuis la nuit des temps dans la doc. Le formatage du code c'est la base de la base, déjà.

Essaye de comprendre un peu les rapports de force avant de t'envoler comme ça.

OK, merci pour le support quand même, même si c'est HS ;-)
J'attend que PA revienne par une dépendance (parce qu'à mon avis ça va arriver un jour ...) avant de m'y relancer, quand même.

En tous cas je trouve que tu mérites une fortune sur celle-là, elle m'a beaucoup fait rire.

"proprement séparée en modules" ça me fait quand même beaucoup penser à linux, mais bon je ne connais pas exactement le système de MS. Les "personnalitys" je ne sais pas trop ce que c'est, mais ce serait une sorte de contrôle d'accès niveau kernel ? Effectivement linux n'a pas ça, mais si tout est dans le même espace mémoire, on pourrait imaginer pas mal de choses pour le contourner ...

Bah, il a quoi alors comme avantage d'un micro-kernel ?

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.