TImaniac a écrit 6420 commentaires

dans le sens ou je pense que chacun à le droit de s'exprimer comme il le sent
Ca tombe bien, le vote est un moyen d'expression, qui sur LinuxFR ne fait que "cacher par défaut" un commentaire jugé inutile, mais qui peux toujours être lu, ce n'est donc pas de la censure.
Ensuite rien ne t'empêche de mettre le seuil des commentaires visibles à -2 par exemple, t'auras l'impression que personne n'est censuré.

L'intérêt n'est pas seulement de "blacklister" les chieurs, mais surtout de "trier" les commentaires pertinents. Quan dil y a 100 commentaires dans une dépêche on est content d'aller jeter un coup d'oeil directement sur les commentaires avec une note >=5-6, qui sont en général les plus représentatif de l'avis général, argumentés, ou rigolos.

Oui et ?
Ta phrase ne dit strictement rien. Elle cite par exemple les magnétoscope et lecteur/enregistreur de DVD, et le tableau du document reste toujours aussi clair, associé à un micro-ordinateur avec carte TV, ces éléments qu'il soient équipés d'un tuner ou non, c'est "non taxable".

d'un côté si t'a une FreeBox même relié à un pc doit payer la redevance
Ah bon pourquoi ?
D'après leur tableau, en assimilant la freebox à un magnétoscope possédant un tuner, avec un micro-ordinateur équipée d'une carte TV je suis "non taxable".
(cf tableau page 58)

Au lieu d'affirmer bêtement quelque chose il pourrait être utile de lire le journal, voir de lire le lien fourni dans le journal.
On y trouve une référence à un document officiel, qui indique clairement page 58 :
Micro-ordinateur avec carte TV : non taxable.

uh, si tu t'imagines que Free va envoyer deux flux MPEG2 différents sur ta ligne téléphonique
Non mais 2 flux MPEG4 par contre oui. Cf Freebox v5.

Muine
http://muine.gooeylinux.org/

Dis donc, le truc de Windows ne va pas du tout. Moteur graphique obligatoire.
Rien à voir. Le prochain Windows, Vista, tu ne seras pas obligé d'installer le moteur graphique. C'est pas pour autant que c'est un serveur comme X11.

Avoir une couche graphique intépendante du noyau est une très bonne chose.
Tout à fait. D'où les modifs dans le prochain Windows. Mais c'est pas pour autant qu'il faut en faire un serveur comme X11.

Bref, ne nous écartons pas du débat initiale :)

je suppute alors aussi, que tu dois être très fortement contre le principe du serveur X11 ... utilisé à 95% en local ...
Je comprends son architecture initiale, où il y avait une forte proportion d'utilisateurs de terminaux X. Mais tout le monde s'accorde à dire que le serveur X11, innovant à son époque, a une architecture aujourd'hui totalement dépassé dans un contexte d'utilisation local.
On en arrive à des lourdeurs comme lancer plusieurs serveurs X pour avoir plusieurs sessions graphiques sur la même machine.
De plus le modèle ala Windows (moteur graphique intégré) montre clairement que l'absence de protocole client/Serveur n'est pas un obstacle, rien n'empêche d'avoir une application serveur tierce qui soit capable de rediriger une session sans avoir la lourdeur du protocole client/serveur en local : vnc, bureau à distance, etc.

C'est un peu la même vision que j'ai pour la musique :
une application tierce faisant serveur, mais dédiée au streaming. En local pas de client/serveur.

Bref : utiliser client/serveur que quand c'est justifié.

Comme toutes ces applications font qqchose en commun ... n'y aurait il pas moyen de capitaliser ?!
Tout à fait d'accord avec cette idée.

Plutôt que de réinventer pour chaque player, la gestion d'une librairie, la production du son etc ...
Euh, y'a une autre manière de créer une base commune que le serveur (qui par son principe n'apporte que le côté multi-client) : la bibliothèque.
GStreamer résoud une bonne partie du problème, en 3 lignes tu joues un mp3.
Pour la gestion d'une base de données virtuelle de mp3, c'est un autre problème : il y a déjà des bases existantes, le véritable problème c'est que chacun y va de ses propres idées, ses propres variantes qui réponde exactement à ses besoins. Sous Windows la bibliothèque de WindowsMediaPlayer est accessible à tous les programmes, sans qu'il y est pour autant de protocole client/serveur.

En tout cas une chose est sûr : ce n'est absoluement pas à la même appli qui fourni les capacité multimédias de s'en occuper, bref, c'est pas à GStreamer, mais à une autre bibliothèque dédiée, voir au système de fichier (comme je l'ai expliqué avec les futurs systèmes de fichier ala WinFS). Communiquer avec la couche multimédia de l'OS et gérer une base de fichiers avec métadatas sont 2 boulots totalement différents.

Je pensais que t'avais compris l'intérêt de séparer l'interface du moteur ....
Tout à fait, mais ajouter le protocole client/serveur entre les 2 n'a pas que trop peu d'intérêt, et après tests, surtout des inconvénients.

?!? ... je t'ai montré une interface mpd qui imitait l'interface de muine, à s'y méprendre, et une autre qui reprennait celle de rhythmbox ..
tu n'es pas crédible ...
Je parlais de suffisant dans le sens où j'en ai rien à cirer de l'apport du protocole client/serveur. Moi ce que je veux d'abord, c'est que ca marche.

Visiblement tu sembles entêté avec le protocole client/serveur, pourtant je n'arrête pas de te montrer qu'on peut avoir exactement le même principe avec la séparation programme/bibliothèque, le même niveau de réutilisation, sans la lourdeur du protocole client/serveur.

Client/serveur, s'il n'y a pas plusieurs clients ou aucune utilisation à distance n'a aucun intérêt, c'est le principe même de tous protocoles clients/serveur. Pour le reste y'a les bibliothèques.

Mais bon la plupart des programmes me donne raison, les serveurs multimédias ne sont jamais utilisé en local mais pour diffuser sur un réseau où il y a plusieurs clients (bref là où le protocole client/serveur est utile).

Mais faire tous les relevés c'est pas compliqué, ce qui va être chaud c'est de faire les calculs en temps réel.
Mais bon vas-y, fait le le système temps réel puisque ca a l'air si simple ! La SNCF te remercieras jamais assez !

Oué alors va falloir commencer par faire le relevé topographique de tout le parcours, avec altitude et tout le tintouin.
Mettre tout ca dans la machine.
Enregistrer tous les horaires du train, le tout en temps réel, le trafic évoluant en permanence en fonction des aléas.
Concevoir un modèle capable d'ancticiper la vitesse relative du train en fonction de tous ces paramètres, y compris les paramètres extérieur, et bien entendu faire en sorte que ce modèle fonctionne en temps réel.
Puis bien entendu programmer ce modèle, avec des méthodes relativement formelles pour garantir leur bon fonctionnement.
Au final ca te coûtera une fortune tout ce joli système. Ils ont peut être tout simplement fait leur calcul, et ca coûte moins cher de payer un conducteur.

C'est pas parcque un ordinateur pourrait le faire, que c'est techniquement possible, que c'est financièrement rentable.
La technologie c'est gentil mais ca coûte cher, et quand le but c'est de faire des économies...

c'est que tu travailles toujours en local sur ta machine.
Ben oui comme 90% des utilisateurs lambda de Gnome. Et pour eux Muine ou autre Rhythmbox est largement suffisant et visiblement beaucoup plus fonctionnel que MPD. VOilà, comme je l'ai déjà dis, MPD peut être utile dans certaines situation (à distance, et encore je l'ai dis je boufferai sans doute moins de ressources avec un pauvre serveur ftp), mais MPD n'est pas du tout plus "révolutionnaire" que Muine & Co. TOut ça pour rappeler qu'à la base je critiquais les propos indiquant que le modèle monolithique était "dépassé" et que MPD c'est LA solution.
Et les quelques tests que j'ai effectéavec MPD m'ont largement conforté dans mon idée :)

Pour moi la solution idéale c'est pas MPD, c'est plutôt un système de fichier qui soit une base de donnée multimédia, un peu comme ce que compte faire MS avec son WinFS ou ce que fond chaque application de musique dans leur coin (bibliothèque de musique à la winamp, à la iTunes, etc.)

Avec bien sûr partage sur réseau le tout sur un MediaCenter :)

Mais en même temps ce n'est pas le chauffeur qui change unilatéralement de direction suivant le temps.
Pas de direction, mais il sera mieux apprécier quand il faut couper les moteurs pour économiser de l'énergie, et tu prends pas la même décision avec le vent dans le dos que de face.

Ce n'est pas lui qui décide des horaires et qui tient compte du traffic
Tout à fait, mais c'est autant de paramètre dont il faut qu'il tienne compte pour choisir les moment d'accélération, etc.

LE chauffeur né décide pas des paramètres extérieur, sa mission est avant tout d'optimiser au maximum la consommation d'énergie de la machine, couper les moteurs dans les descentes, savoir à quel moment les remettre, etc.

Non c'est pas si simple que ca, car aucun trajet n'est identique, il y a de nombreux critères dont il faut tenir compte, comme le trafic, les horaires prévus, les aléas du terrain, la météo (vent, pluie), la charge du train, etc.
Y'a trop de critère pour avoir un modèle calculable en temps réel.

Euh, je vais prendre une super source d'information, à savoir Capital sur M6 (désolé), mais ils ecpliquaient très bien le position des conducteurs de TGV :
De leurs compétences à savoir "gérer" les montées et descentes du tracé dépend très fortement la consommation du TGV.
Alors oui, les TGV sont automatisés (ils s'arrêtent tous seuls en cas de problèmes), oui le taf du conducteur est pépère, mais il faut de nombreuses années d'expérience et une bonne connaissance du trajet. Cela permet à la SNCF de faire de grosses économies d'énergie électrique, il est donc tout à fait normal qu'elle "remercie" ces précieux collaborateurs pour ce qu'ils apportent.

Il suffit pourtant de lire !
Le sous-titre du communiqué de presse de Free parle clairement de couplage de lignes.
Effectivement je sais pas lire désolé :)

Free parle dans son communiquer de l'utilisation de la technologie ADSL2+
NOn ils disent utilisé l' F-ADSL basé sur l'ADSL2+. L'ADSL2+ est lui même basé sur l'ADSL et pourtant l'ADSL2+ n'est pas une multiplication des lignes téléphoniques.
JE ne sais pas du tout à quoi correspond ce F-ADSL mais prétendre qu'ils n'ont fait que multiplier les lignes téléphoniques ca n'est fondé sur rien du tout.

laisse encore un peu de temps à mpd et ses interfaces ... et tu verras
c'est vraiment le concept excellent ....
Bof, je te l'ai dis, au final Muine me convient très bien, j'ai besoin de rien en plus !
Et puis tu oublies un détails, tu dis que mpd c bien tu peux fermer le client et bouffer moins de ram, ben moi je te répond, quand tu fermes muine, y'a plus de ram du tout de bouffée contrairement à mpd ;)

C'est relatif à ta collection, si t'as une "petite collection"
BOf je suis pas sûr du tout. Il m'a pas bouffé plus avant et après que j'ai mis 3000 chansons. Et puis t'auras exactement le même problème avec MPD, sauf que MPD il te les bouffera en permanence puisqu'il tourne tout le temps ;)

vas-y, tente un coup ! tu y trouveras forcément ton bonheur ...
ET dis toi bien que l'interface de muine greffé sur mpd, c tout à fait possible !
Pour moi ca n'a aucun intérêt, Muine c'est simple, ca marche, ma télécommande marche, ma copine aussi. Je demandes rien d'autre moi :) Et puis quand je coupes la musique je veux pas d'un daemon qui tourne pour rien :-D

FAit gaffe à tes calculs de mémoire... LEs applications bien conçues sont conçues pour tirer partie de la mémoire disponible... si y'a plein de ram, il est normal qu'ils en utilisent plus si cela va améliorer les perfs, la réactivité, etc. Dans le cas des applis Mono comme Muine ou Banshee, le Garbage collector ne passera par exemple que quand nécessaire, pour éviter de bouffer des ressources proc inutilement.
BRef, ec qui est inquiétant c'est une appli qui bouffe 100 Mo de RAM alors que y'en a que 128 au total et qui fait swapper le disque comme un porc.

car apparemment tu ne connaissais pas ...
En fait j'avais déjà utilisé dans un passé lointain parcque justement j'aimais bien l'idée, mais depuis j'en suis revenu :)

SI SI SI, mpd gère une libraire, avec les tags mp3 et tout le tintouin !
Où ca où ca ? Nan parcque je l'ai vu scanner mes mp3, il me propose d'effectuer des recherches, mais je ne l'ai pas vu me proposer ma liste d'albums. Où alors je suis aveugle. Si je veux tous les albums de BRMC je fais quoi ?

tout pareil ! instantanné !
Bon ben alors tu vois bien que c'est pareil :)
TIens si ca t'amuses, Muine fait aussi serveur en quelque sorte puisqu'il écoute D-Bus.


ça, c un autre problème ! et il doit être situé entre la chaise et le clavier ;-)
Oué entre le clavier et la chaise du développeur. Nan parcque bon mpd ne pas proposer de config par défaut, glurp qui arrive pas à se connecter au serveur et qui a un bouton config qui fait rien et gmpc qui n'est pas configuré par défaut pour aller chercher le fichier de conf de mpd et qui n'est pas configuré par défaut pour se connecter... Franchement ils ont tout fait pour que par défaut ca marche pas.
Et pourtant je suis pas un newbie, je savais qu'il fallait télécharger un serveur, un client, lancer le serveur en ligne de commande, ajouter un fichier de conf dans ~/.mpd, modifier ce fichier pour qu'il trouve mes mp3, qu'il fallait que j'ajoutes un dossier playlists pour qu'il râle pas, un dossier jesaisplusquoi pour la même raison, puis lancer le client, configurer le foutu client qui n'était pas foutu de se configurer tout seul, bref... Désolé mais je comprends pourquoi mpd n'a aucun succès et que son modèle client/Serveur n'a aucun succès, c'est un truc de geek, fait par des geeks pour des geeks.

Muine, tu lances, tu glisses le dossier de ton album sur l'ihm, et ca marche. Je bouffe peut être 35-15 = 20 Mo de ram en plus, mais je trouves que ca vaut le coup :)
Et puis je penses qu'il sera assez facile de démontrer que ce "surpoid" vient en grande partie du runtime Mono ;)

J'en utilise un supplémentaire que quand je lance The Gimp en fait :)

BOn alors déjà :
Muine chez moi c'est 51 Mo en mémoire avec 3000 chansons et affichage instantané des albums :
http://pascalfresnay.free.fr/divers/muine2.png
Ah oui : dont 15 Mo partagés, donc tu peux ne pas en tenir compte. Soit au final 35 Mo ouaouh.

Quand à mon expérience de mpd+glurp :
étape 1 :
f***ng .conf de merde !
étape 2 :
glurp : impossible de se connecter au serveur
...
étape 3 :
gmpc :
Raaaah faut aller dans config et cliquer sur connecter au serveur !
Oups j'ai fermé l'appli et toujours la zik (réflexe désolé)
killall mpd.

Conclusion : l'utilisateur lambda n'arrivera de toute façon jamais à ce servir de mpd.
Ensuite mpd ne gère pas braiment de base de donnée de mp3, il se contente d'indexer une arborescence.
Muine il scanne les tags, il organise par album, par auteur, etc. Ca prend nettement plus de ressources. Et tout est instantané : un click dans la barre de notif et hop j'ai l'interface pour sélectionner un album.

Enfin bon voilà, tout ca pour le fun, mais ca n'a toujours rien à voir avec ton trip client/Serveur, rien n'empêche de faire en sorte que Muine décharge l'ihm quand il est dans la zone de notification. Ca c'est plutôt des problèmes de gestion de ressources par les programmeurs. Chez Muine ils ont préféré la réactivité et la simplicité. CHez MPD : je sais pas ca marche pas. Ca doit être le côté révolutionnaire.

- muine/rhythmbox = 80mo (moitié moins que ce que j'avançais, désolé)
- mpd = 13mo *3 + gui 13mo (quand lancé)

Il est bizzare ton muine :) Pour rhythmbox je sais pas.
Enfin si la GUI de mpd prend que 13 Mo, ca n'a strictement rien à voir avec le modèle client/serveur. C'est une question de codage. Maintenant tes ihm ne doivent sûrement pas faire la même chose. Faut bien voir que Muine par exemple scan ton disque dur à la recherche de nouveaux morceaux de musique, va cherché sur internet la liste des pochettes, etc. Bref ils bossent.

Remarque avec le XSL on peut faire apparaitre la notion d'heritage mais il est bien vrai que l'encapsulation ...
Non non, tu ne pourras pas dire que ton fichier XML contient la représentation d'un objet qui hérite d'un autre objet, même avec XSL :)

Using XML as an Object Interchange Format
Oui tu peux représenter un objet sous la forme d'un arbre de données, donc en XML, c'est ce que font beaucoup de monde. De la même manière que tu peux représenter un objet avec des tables relationnelles, ce que font tous les outils de mapping relationnel/objet.
En étant encore plus large, on peut même dire qu'une suite de caractères Unicode peut représenter un objet...

Il y a 1000 manière de formatter les DONNEES d'un objet, voir sa description, mais c'est pas pour autant que la notion d'objet est utilisé par l'outil utilisé. Dans ce journal on parle justement de SGBD qui gère les objets en natif.

Enfin un truc qui pourra te faire plaisir : SQL Server est capable d'enregistrer des fichiers XML en plus des tables relationnelles ;)

Si le XML n'est pas une approche objet des representations des données ...
Absolument pas.
http://fr.wikipedia.org/wiki/Programmation_orient%C3%A9e_obj(...)

XML c'est de la structuration en arbre de données. Il n'y a aucune notion d'héritage, d'encapsulation, etc.