là, t'exageres ...
il y a au moins 30 guis différents pour piloter MPD ...
Je dis pas que y'a pas de GUI pour MPD, je dis juste qu'à part utiliser la ligne de commande je ne vois aucun intérêt à MPD, puisque dans tous les cas tu as une GUI.
oui ;-), et bouffe 150mo, et du cpu, uniquement pour jouer du son, et proposer 3 pauvres boutons vitaux .... c'est démesuré
(n'as tu pas ces boutons sur ton clavier multimedia ?!)
Raaah mais tu comprends rien :) Même avec MPD il te faut une IHM et 150 Mo et gnagnagna. C'est exactement pareil ! Et toi tu me dis que c'est démesuré... Ben moi je te répond que c'est encore plus démesuré d'avoir un protocole client serveur en local EN PLUS de l'ihm.
n'as tu pas ces boutons sur ton clavier multimedia ?!
Gnome a des signaux multimédia par défaut, il est pas compliqué de configurer une appli pour les utiliser, comme le fait très bien Muine d'ailleur, je capte pas ta remarque.
si t'écoutes des albums de suite, par exemple, toutes les heures tu devras aller dans l'interface pour changer d'album.... pendant 1h, l'appli qui tourne en arrière-plan, et bouffe 150mo, ne sert à RIEN !
...
Déjà utiliser une appli qui bouffe 150 Mo de RAM pour lire du son, y'en a pas beaucoup.
Ensuite je vois pas le rapport avec client/serveur, rien n'empêche l'utilisateur lambda de laisser tourner le client IHM et d'avoir le même problème, comme rien n'empêche la version monolithique de désallouer les ressources utilisées pour l'IHM quand elle est minimisée et dans le systray. Ca n'a strictement rien à voir avec le modèle client/Serveur. Au contraire, avec ton modèle où je suppose tu t'amuses à relancer ton client graphique systématiquement, ca risque d'être plutôt "lourd" à charger systématiquement. Ou alors c'est que l'appli était resté en mémoire, auquel tu bouffes toujorus autant de mémoire.
t'auras une grosse appli qui tourne juste pour faire du son ?! et proposer 3 boutons ?!
Mais qui te parle d'une grosse appli ? Muine c'est petit, c'est simple :)
ne prefererait elle pas appuyer sur la touche STOP de ton clavier multimedia, pour arreter la musique ?!?
Elle pourrait si mon clavier avait un bouton stop. Ma télécommande a un bouton stop, elle peut l'utiliser si ca l'amuse, mais le fait est qu'en règle générale elle préfère fermer la fenêtre (peut être parcque al télécommande est jamais là où t'es :) )
Je pinaille, mais tu pinailles aussi ;-)
on aime bien pinailler ...
Je pinaille pas, tu passes ton temps à me dire que seul le modèle client/Serveur est intelligent, et tu ne me montres strictement rien qui a un rapport avec le modèle client/serveur, toutes les critiques que tu fais peuvent être faites à ton modèle, et inversement.
Sous nux, je suis content d'avoir trouver un concept encore plus novateur, plus logique ...
Je le répète : ca n'a strictement rien de novateur, et si aucun autre lecteur ne propose cela c'est bien que c'est loin d'être révolutionnaire et d'apporter des avantages.
Je le répète : pour l'utilisateur lambda, c'est pas du tout logique. Sa musique va continuer à tourner alors que l'utilisateur ne verra plus d'ihm !!
je ne pourrai pas me permettre d'avoir une grosse appli monopolisant mes pauvres ressources ;-)
Ca n'a rien à voir avec ton trip client serveur. T'utilises pas de gui dans ce cas, mais c'est un autre problème.
Mais j'admet très bien qu'il existe des amaroks, muine, banshee, rhythmbox et autres grosses interfaces ... mais c'est démesuré, je trouve
T'as déjà essayé Muine ? Nan parcque t'arrête pas de parler de "grosses interfaces" et de "150 Mo de mémoire"...
dans le sens, t'es obligé de lancer un process/gui, qui va bouffer 150mo en memoire, pour jouer un simple mp3 ?!?
Désolé, on n'a pas tous envie d'utiliser la console pour jouer des mp3. Faut bien lancer une IHM à un moment ou un autre pour jouer de la musique, et celle-là t'es censé la regarder. Ces IHM te facilite la recherche de musique, te fournissent des informations comme la pochette de l'album, les paroles ou encore la bio de l'auteur. Ces IHM sont donc tout à fait utile.
Si l'IHM te dérange, tu diminues la fenêtre, et hop pour Muine par exemple, l'appli se met dans la zone de notification avec les boutons vitales play/pause/next.
Le serveur, c'est la fonctionnalité, c'est lui qui joue, et qui occupe si peu de ressources pour faire la zic, et il se pilote par moults interfaces, c'est tellement logique ...
C'est logique pour toi informaticien, mais pas pour l'utilisateur Lambda ! Tu prends une appli existante comme Rhythmbox, tu lui appliques ton modèle "client/serveur", ca changera rien au fait que ton client sera toujours lancé et bouffera toujours autant de mémoire ! L'utilisateur voudra en effet par moment aller consulter l'interface, pour changer de morceau, choisir un autre album, etc.
Quand à la liste de tes fonctionnalités, à part la diffusion à distance de flux (ce qui pour moi n'a pas beaucoup d'intérêt, je préfères lire directement ma zik sur mon ftp), je ne vois rien du tout qui ne soit pas possible avec une appli classique, le fait que ce soit client/serveur n'apportant strictement rien du tout.
et tout ça, que je sois sous X, en console, en ssh/http distants.
Vi c'est tellement user-friendly tout ca... Mais tant mieux, y'a des applis pour tous les goûts, pour tous les types d'utilisation ! Le fait est qu'il n'y a pas un modèle plus "logique" qu'un autre, j'estime ne pas être un utilisateur "lambda" et je peux utiliser mpd en ligne de commande, mais je préfère 1000 fois lancer Muine, et pouvoir accéder à tous moment à l'IHM. Et ma copine est bien contente que la musique se coupe quand elle ferme l'application.
Faut pas te fier aux apparences... Rien ne t'empêche de prendre des "object" en entrée et sortie, plus générique tu meurs. Ah oui et tu peux aussi lire et écrire des "string" pour retrouver le comportement habituel. Bref, c'est pareil que sous Unix, mais en mieux.
Avec le recule, on se rend compte que c'est en fait rare (20% dans les faits ?). donc, chaque objet est spécifique.
Tu confonds un peu tout et n'importe quoi là :)
Ce qui a été vendu comme réutilisable, c'est toute l'informatique depuis les débuts, les pipes Unix étaient censé être la solution miracle pour connecter des briques, maintenant c'est plutôt les composants, ce à quoi tu devais sans doute vouloir faire allusion.
Quand tu parles d'un objet, je suppose que tu veux parler d'une classe. Ben dans les faits les classes sont très souvent réutilisées, ne serait-ce qu'au sein d'un même programme.
Maintenant je n'ai qu'un conseil à te donner : essai Monad si t'as la possibilité (je sais WIndows gnagnagna), et tu verras comment il ont fait le grep.
Sauf que là c'est une cafetière qui fait frigo, grille pain et four à micro-onde. Elle est clairement orientée multimédia, est capable de se connecter à un réseau Windows pour lire films, musique, y'a une télécommade, etc. Bref un vrai MediaCenter.
La réalité du succès de cette xboite va reposer sur le nombre de gogo qui sont pret à payer 400-700 euros pour accéder à un pc bridé qui ne sert qu'à jouer
Le prix de base c'est 300 euros, et pour ce prix là ca te fait un MediaCenter très très bon marché. Les gogo c'est ceux qui vont achter les dizaines de jeux.
je sais. Donc celui qui reçoit l'objet doit connaitre son interface. Donc, tu limite vachement les possibilités de pipe.
D'où l'intérêt : tu sais ce que tu attends, et tu peux le traiter beaucoup plus facilement. Avec XML, il y a juste à connaitre le xml.
Et tu te retrouves avec le même problème qu'avant : tu ne sais pas ce que tu vas trouver entre les balises. XML tout seul ca sert à rien, un document XML sans schéma ou DTD associé est pas plus exploitable qu'un fichier texte. Et la DTD/Schéma correspond en gros à l'interface d'un objet, bref sa définition.
Bref l'XML n'apportera strictement rien, à part peut-être une lourdeur dans les flux, sans parler du fait que le XML est très mal approprié à un contexte de flux, le programme traitant la sortie d'un tel flux devant attendre une éventuelle balise fermante avant de traiter le contenu.
De plus la solution de MS se base sur .NET, bref tu peux très bien récupérer un "object" et faire de l'introspection dessus si t'as envie de découvrir ce qu'il y a dedans sans connaître au préalable l'interface.
Mais les objets fournissent trop de possiblité de se mettre dedans. ?
Avec son shell Monad, Microsoft a en partie mariée les 2 mondes : les outils en ligne de commande lisent et pondent des objets typés.
il y a une sacré différence entre ce qu'est MPD et ce qu'est Gstreamer.
Je sais bien, comme je l'ai précisé, il ya 2 solutions : faire une lib (gstreamer) ou faire un serveur (MPD), forcement dans la première solution la musique s'arrête quand tu fermes l'appli :)
mais il me semble que le projet mono phare, dans le monde musical est banshee ...(n'est pas un fork de muine ?!)
Oué mais je préfères Muine pour le moment. Et Mono ou pas, j'ai pas trouvé mieux à mon goût sous Gnome :-p
e serait tellement mieux si ces interfaces, utilisait le serveur de son MPD, qui lui même utiliserait gstreamer comme tuyaux vers l'audio ...
Mouais pas forcement. Ca commence à faire lourd là, on a un serveur qui parle à gstreamer qui parle au serveur de son qui parle au hardware...
L'utilisateur lambda, il y connait kedal de ces détails clients/serveurs, pour lui quand il ferme l'appli il veut que la musique s'arrête. Pour moi le paradigme client/Serveur n'a d'utilité en règle générale que s'il y a un réseau ou plusieurs utilisateurs(programmes) en local.
Un serveur de son est utile, parcque plusieurs utilisateurs peuvent jouer de la musique en même temps. Un serveur de musique en local, je vois tout de suite moins l'intérêt. C'est un peu ce qui arrive au serveur X, celui-ci avait tout son intérêt auparavant, quand les terminaux X étaient légion, mais aujourd'hui c'est plus un boulet qu'autre chose... alors je sais pas lequel est dépassé :)
Dans tous les cas c'est un choix d'architecture, je ne vois absolument pas où est l'avantage d'avoir un serveur comme MPD en tant qu'utilisateur et pas plus en tant que développeur. Le modèle client lourd n'est pas du tout dépassé.
Comparé aux clients lourds que sont rhythmbox, muine, amarok et cie ?! y a pas photo ...
Euh, c'est idiot ce que tu dis... tous ces logiciels sont pour la plupart des frontend à GStreamer ou autre Xine. Rien ne les empêcherait d'être des frontend à MPD. Mais l'idée est là, que ce soit sous forme de serveur ou de lib, il y a une séparation fonctionnelle et une interface autre qu'une simple entrée/sortie standard.
qui regarde son player quand il joue un morceau ?! ;-)
Ben faut bien choisir à un moment ou un autre ce que tu veux écouter, et rien ne vaut une interface épurée et simpliste comme Muine :)
Par contre il est vrai que le java ne correspondait pas à 100%, mais microsoft voulait l'adapter
Enfin au final c'est quand même un peu ce qu'ils ont fait :)
C'est pas le principe de base d'Unix, ça?
Si mais ce principe était parfaitement adapté y'a 20-30 ans, et il ne l'ai plus en partie aujourd'hui. Un truc qui fait une seule chose et qui la fait bien, OK. Mais ca c'est pas vraiment le propre d'Unix. Une grosse particularité d'Unix c'est le trip des "pipes", il y a une époque où l'on croyait quon construirait des logiciels fabuleux (et complexe, loin d'être simple) justement en chaînant les programmes grâce aux pipes. Du coup on se retrouve avec des programmes comme cdrecord, prévus pour marcher en ligne de commande, avec une entrée et une sortie standard. Ben dans le cadre actuel, et peux ceux qui réalise des IHM c'est tout simplement affreux, pénible, pas performant, bref c'est nul :)
Heuresement les choses évoluent, et les outils en ligne de commande sont enfin parfois vus pour ce qu'ils sont : une simple IHM comme une autre, qui ne fait pas le boulot. Le boulot il est dans une lib, une lib partagée avec des méthodes, des types, des classes, etc., bref quelque chose d'infiniment plus friendly qu'un traitement de chaîne de caractères sur une redirection de pipe pour communiquer avec un soft en ligne de commande.
Le principe de séparer les responsabilités n'est pas du tout le propre d'Unix, il est présent partout dans l'informatique. La méthode "ala Unix" à base de pipe et redirection est périmée, le modèle actuel c'est plutôt la programmation objet, on un objet fait une chose et une seule et la fait bien.
Ensuite Koffice n'a jamais pretendu (Pascal Fremy dementira peut etre) avoir implemente TOUT le format OOo pour le moment...
C'est pas là le problème, le problème vient du fait qu'il y a des lacunes sémantiques dans le format OpenDocument, et KOffice ne peut se contenter d'implémenter OpenDocuement, même intégralement et de manière exacte, il peut quand même il y avoir des problème d'interpérabilité.
Et non le format MS documents ne pouvait pas etre utulise par OOo vu la licence qui empeche toute implementation de ce format dans un projet open source!!!
D'où l'intérêt de ce journal qui précise justement qu'il y a des changements dans la politique de Microsoft.
Silicon : "Ensuite, pour inciter les développeurs à travailler avec ses formats de fichiers, Microsoft modifiera la licence, s'engageant ainsi à ne pas attaquer les développeurs."
NetEconomie : "Quant à la licence qui sera appliquée sur son format Office XML, Microsoft lance un message fort à la communauté 'open source', puisque Microsoft Office Open XML sera proposé gratuitement sous une licence du même type que celle d'OpenDocument, à savoir que Microsoft s'engagera à ne pas poursuivre un utilisateur."
Alors la il va falloir m'expliquer pourquoi tu continues a promouvoir une technos MS fait par MS pour MS windows...
Mono n'est pas compatible avec ActiveX/COM et n'a pas été fait pour Windows. Mono est juste une plateforme compatible avec .NET, question d'interopérabilité. Maintenant va engueuler tous les mecs qui font la promotion de OpenOffice.org, c'est vrai quoi, ils font un produit compatible avec MS Office, c'est mal (TM).
Celui du foutre du binaire dedans afin de rendre impossible aux autres suites office d'ouvrir le format "ouvert" MS??????
Si jamais tu trouves un seul fichier Office Open XML avec un morceau de binaire qui cache de l'information nécessaire à l'interopérabilité tu m'appelles gros malin.
Oué effectivement l'exemple précédent n'était pas pertinent. Cela dit c'est pas plus portable, tu es obligé d'avoir un code différent sous Linux et Windows, les extensions de bibliothèques étant différentes. Avec Mono tu il mappe automatiquement la référence de bibliothèque sur un .dll sous Windows, un .so sous Linux, etc. Bref, pas de code spécifique selon la plateforme.
Gary Edwards, un membre du comité technique de l'OASIS en avait même fait référence à plusieurs reprises
Ils auraient mieux fait de se pencher sur le format qu'ils "standardisaient", notamment sur les nombreuses lacunes sémantiques du format OpenDocument plutôt que de FUDer comme des porcs.
Ca n'a rien à voir, ce que tu me montres c'est l'interopérabilité COM/ActiveX sous Windows. Comme dans tous les langages de script sous Windows. Bref, rien à voir avec un simple appel de méthode dans une lib qui exporte un API en C quelconque.
Je pense que les langages ne supportant pas ça sont plus rares que ceux qui les supportent ;)
Sauf que en C# c'est intégré dans la syntaxe, et ca permet d'invoquer directement une lib native sans wrapper nécessitant un langage intermédiaire comme dans la plupart des langages. Je ne connais aucun autre langage qui permette cela de manière portable.
[^] # Re: ...
Posté par TImaniac (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 2.
il y a au moins 30 guis différents pour piloter MPD ...
Je dis pas que y'a pas de GUI pour MPD, je dis juste qu'à part utiliser la ligne de commande je ne vois aucun intérêt à MPD, puisque dans tous les cas tu as une GUI.
oui ;-), et bouffe 150mo, et du cpu, uniquement pour jouer du son, et proposer 3 pauvres boutons vitaux .... c'est démesuré
(n'as tu pas ces boutons sur ton clavier multimedia ?!)
Raaah mais tu comprends rien :) Même avec MPD il te faut une IHM et 150 Mo et gnagnagna. C'est exactement pareil ! Et toi tu me dis que c'est démesuré... Ben moi je te répond que c'est encore plus démesuré d'avoir un protocole client serveur en local EN PLUS de l'ihm.
n'as tu pas ces boutons sur ton clavier multimedia ?!
Gnome a des signaux multimédia par défaut, il est pas compliqué de configurer une appli pour les utiliser, comme le fait très bien Muine d'ailleur, je capte pas ta remarque.
si t'écoutes des albums de suite, par exemple, toutes les heures tu devras aller dans l'interface pour changer d'album.... pendant 1h, l'appli qui tourne en arrière-plan, et bouffe 150mo, ne sert à RIEN !
...
Déjà utiliser une appli qui bouffe 150 Mo de RAM pour lire du son, y'en a pas beaucoup.
Ensuite je vois pas le rapport avec client/serveur, rien n'empêche l'utilisateur lambda de laisser tourner le client IHM et d'avoir le même problème, comme rien n'empêche la version monolithique de désallouer les ressources utilisées pour l'IHM quand elle est minimisée et dans le systray. Ca n'a strictement rien à voir avec le modèle client/Serveur. Au contraire, avec ton modèle où je suppose tu t'amuses à relancer ton client graphique systématiquement, ca risque d'être plutôt "lourd" à charger systématiquement. Ou alors c'est que l'appli était resté en mémoire, auquel tu bouffes toujorus autant de mémoire.
t'auras une grosse appli qui tourne juste pour faire du son ?! et proposer 3 boutons ?!
Mais qui te parle d'une grosse appli ? Muine c'est petit, c'est simple :)
ne prefererait elle pas appuyer sur la touche STOP de ton clavier multimedia, pour arreter la musique ?!?
Elle pourrait si mon clavier avait un bouton stop. Ma télécommande a un bouton stop, elle peut l'utiliser si ca l'amuse, mais le fait est qu'en règle générale elle préfère fermer la fenêtre (peut être parcque al télécommande est jamais là où t'es :) )
Je pinaille, mais tu pinailles aussi ;-)
on aime bien pinailler ...
Je pinaille pas, tu passes ton temps à me dire que seul le modèle client/Serveur est intelligent, et tu ne me montres strictement rien qui a un rapport avec le modèle client/serveur, toutes les critiques que tu fais peuvent être faites à ton modèle, et inversement.
Sous nux, je suis content d'avoir trouver un concept encore plus novateur, plus logique ...
Je le répète : ca n'a strictement rien de novateur, et si aucun autre lecteur ne propose cela c'est bien que c'est loin d'être révolutionnaire et d'apporter des avantages.
Je le répète : pour l'utilisateur lambda, c'est pas du tout logique. Sa musique va continuer à tourner alors que l'utilisateur ne verra plus d'ihm !!
je ne pourrai pas me permettre d'avoir une grosse appli monopolisant mes pauvres ressources ;-)
Ca n'a rien à voir avec ton trip client serveur. T'utilises pas de gui dans ce cas, mais c'est un autre problème.
Mais j'admet très bien qu'il existe des amaroks, muine, banshee, rhythmbox et autres grosses interfaces ... mais c'est démesuré, je trouve
T'as déjà essayé Muine ? Nan parcque t'arrête pas de parler de "grosses interfaces" et de "150 Mo de mémoire"...
[^] # Re: ...
Posté par TImaniac (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 2.
Désolé, on n'a pas tous envie d'utiliser la console pour jouer des mp3. Faut bien lancer une IHM à un moment ou un autre pour jouer de la musique, et celle-là t'es censé la regarder. Ces IHM te facilite la recherche de musique, te fournissent des informations comme la pochette de l'album, les paroles ou encore la bio de l'auteur. Ces IHM sont donc tout à fait utile.
Si l'IHM te dérange, tu diminues la fenêtre, et hop pour Muine par exemple, l'appli se met dans la zone de notification avec les boutons vitales play/pause/next.
Le serveur, c'est la fonctionnalité, c'est lui qui joue, et qui occupe si peu de ressources pour faire la zic, et il se pilote par moults interfaces, c'est tellement logique ...
C'est logique pour toi informaticien, mais pas pour l'utilisateur Lambda ! Tu prends une appli existante comme Rhythmbox, tu lui appliques ton modèle "client/serveur", ca changera rien au fait que ton client sera toujours lancé et bouffera toujours autant de mémoire ! L'utilisateur voudra en effet par moment aller consulter l'interface, pour changer de morceau, choisir un autre album, etc.
Quand à la liste de tes fonctionnalités, à part la diffusion à distance de flux (ce qui pour moi n'a pas beaucoup d'intérêt, je préfères lire directement ma zik sur mon ftp), je ne vois rien du tout qui ne soit pas possible avec une appli classique, le fait que ce soit client/serveur n'apportant strictement rien du tout.
et tout ça, que je sois sous X, en console, en ssh/http distants.
Vi c'est tellement user-friendly tout ca... Mais tant mieux, y'a des applis pour tous les goûts, pour tous les types d'utilisation ! Le fait est qu'il n'y a pas un modèle plus "logique" qu'un autre, j'estime ne pas être un utilisateur "lambda" et je peux utiliser mpd en ligne de commande, mais je préfère 1000 fois lancer Muine, et pouvoir accéder à tous moment à l'IHM. Et ma copine est bien contente que la musique se coupe quand elle ferme l'application.
[^] # Re: ...
Posté par TImaniac (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 2.
[^] # Re: ...
Posté par TImaniac (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 4.
Tu confonds un peu tout et n'importe quoi là :)
Ce qui a été vendu comme réutilisable, c'est toute l'informatique depuis les débuts, les pipes Unix étaient censé être la solution miracle pour connecter des briques, maintenant c'est plutôt les composants, ce à quoi tu devais sans doute vouloir faire allusion.
Quand tu parles d'un objet, je suppose que tu veux parler d'une classe. Ben dans les faits les classes sont très souvent réutilisées, ne serait-ce qu'au sein d'un même programme.
Maintenant je n'ai qu'un conseil à te donner : essai Monad si t'as la possibilité (je sais WIndows gnagnagna), et tu verras comment il ont fait le grep.
[^] # Re: Il fallait s'y attendre...
Posté par TImaniac (site web personnel) . En réponse au journal Quand MS rate la marche avec sa XBOX 360. Évalué à 1.
[^] # Re: Il fallait s'y attendre...
Posté par TImaniac (site web personnel) . En réponse au journal Quand MS rate la marche avec sa XBOX 360. Évalué à 5.
# CQFD
Posté par TImaniac (site web personnel) . En réponse au journal Les systèmes bases de données orientées objets. Évalué à 10.
[^] # Re: Il fallait s'y attendre...
Posté par TImaniac (site web personnel) . En réponse au journal Quand MS rate la marche avec sa XBOX 360. Évalué à 4.
Le prix de base c'est 300 euros, et pour ce prix là ca te fait un MediaCenter très très bon marché. Les gogo c'est ceux qui vont achter les dizaines de jeux.
[^] # Re: ...
Posté par TImaniac (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 4.
D'où l'intérêt : tu sais ce que tu attends, et tu peux le traiter beaucoup plus facilement.
Avec XML, il y a juste à connaitre le xml.
Et tu te retrouves avec le même problème qu'avant : tu ne sais pas ce que tu vas trouver entre les balises. XML tout seul ca sert à rien, un document XML sans schéma ou DTD associé est pas plus exploitable qu'un fichier texte. Et la DTD/Schéma correspond en gros à l'interface d'un objet, bref sa définition.
Bref l'XML n'apportera strictement rien, à part peut-être une lourdeur dans les flux, sans parler du fait que le XML est très mal approprié à un contexte de flux, le programme traitant la sortie d'un tel flux devant attendre une éventuelle balise fermante avant de traiter le contenu.
De plus la solution de MS se base sur .NET, bref tu peux très bien récupérer un "object" et faire de l'introspection dessus si t'as envie de découvrir ce qu'il y a dedans sans connaître au préalable l'interface.
[^] # Re: ...
Posté par TImaniac (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 2.
Avec son shell Monad, Microsoft a en partie mariée les 2 mondes : les outils en ligne de commande lisent et pondent des objets typés.
# mouais
Posté par TImaniac (site web personnel) . En réponse au journal La blague du jour.... Évalué à 1.
"écrivez à l'arc, envoyez des sious" (ou l'inverse)
[^] # Re: ...
Posté par TImaniac (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 2.
Je sais bien, comme je l'ai précisé, il ya 2 solutions : faire une lib (gstreamer) ou faire un serveur (MPD), forcement dans la première solution la musique s'arrête quand tu fermes l'appli :)
mais il me semble que le projet mono phare, dans le monde musical est banshee ...(n'est pas un fork de muine ?!)
Oué mais je préfères Muine pour le moment. Et Mono ou pas, j'ai pas trouvé mieux à mon goût sous Gnome :-p
e serait tellement mieux si ces interfaces, utilisait le serveur de son MPD, qui lui même utiliserait gstreamer comme tuyaux vers l'audio ...
Mouais pas forcement. Ca commence à faire lourd là, on a un serveur qui parle à gstreamer qui parle au serveur de son qui parle au hardware...
L'utilisateur lambda, il y connait kedal de ces détails clients/serveurs, pour lui quand il ferme l'appli il veut que la musique s'arrête. Pour moi le paradigme client/Serveur n'a d'utilité en règle générale que s'il y a un réseau ou plusieurs utilisateurs(programmes) en local.
Un serveur de son est utile, parcque plusieurs utilisateurs peuvent jouer de la musique en même temps. Un serveur de musique en local, je vois tout de suite moins l'intérêt. C'est un peu ce qui arrive au serveur X, celui-ci avait tout son intérêt auparavant, quand les terminaux X étaient légion, mais aujourd'hui c'est plus un boulet qu'autre chose... alors je sais pas lequel est dépassé :)
Dans tous les cas c'est un choix d'architecture, je ne vois absolument pas où est l'avantage d'avoir un serveur comme MPD en tant qu'utilisateur et pas plus en tant que développeur. Le modèle client lourd n'est pas du tout dépassé.
[^] # Re: Il fallait s'y attendre...
Posté par TImaniac (site web personnel) . En réponse au journal Quand MS rate la marche avec sa XBOX 360. Évalué à 3.
http://www.pcinpact.com/actu/news/Des_problemes_de_crash_iso(...)
# ca dépend peut être des filières
Posté par TImaniac (site web personnel) . En réponse au journal Les stagiaires en grève !!!. Évalué à 2.
Perso stage DESS d'informatique sur Rennes, tout le monde avait un salaire (à ma connaissance).
[^] # Re: ...
Posté par TImaniac (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 3.
Euh, c'est idiot ce que tu dis... tous ces logiciels sont pour la plupart des frontend à GStreamer ou autre Xine. Rien ne les empêcherait d'être des frontend à MPD. Mais l'idée est là, que ce soit sous forme de serveur ou de lib, il y a une séparation fonctionnelle et une interface autre qu'une simple entrée/sortie standard.
qui regarde son player quand il joue un morceau ?! ;-)
Ben faut bien choisir à un moment ou un autre ce que tu veux écouter, et rien ne vaut une interface épurée et simpliste comme Muine :)
[^] # Re: ECMA ?
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft, doc et standard. Évalué à 2.
Enfin au final c'est quand même un peu ce qu'ils ont fait :)
[^] # Re: ...
Posté par TImaniac (site web personnel) . En réponse au journal Langages pour desktop. Évalué à 7.
Si mais ce principe était parfaitement adapté y'a 20-30 ans, et il ne l'ai plus en partie aujourd'hui. Un truc qui fait une seule chose et qui la fait bien, OK. Mais ca c'est pas vraiment le propre d'Unix. Une grosse particularité d'Unix c'est le trip des "pipes", il y a une époque où l'on croyait quon construirait des logiciels fabuleux (et complexe, loin d'être simple) justement en chaînant les programmes grâce aux pipes. Du coup on se retrouve avec des programmes comme cdrecord, prévus pour marcher en ligne de commande, avec une entrée et une sortie standard. Ben dans le cadre actuel, et peux ceux qui réalise des IHM c'est tout simplement affreux, pénible, pas performant, bref c'est nul :)
Heuresement les choses évoluent, et les outils en ligne de commande sont enfin parfois vus pour ce qu'ils sont : une simple IHM comme une autre, qui ne fait pas le boulot. Le boulot il est dans une lib, une lib partagée avec des méthodes, des types, des classes, etc., bref quelque chose d'infiniment plus friendly qu'un traitement de chaîne de caractères sur une redirection de pipe pour communiquer avec un soft en ligne de commande.
Le principe de séparer les responsabilités n'est pas du tout le propre d'Unix, il est présent partout dans l'informatique. La méthode "ala Unix" à base de pipe et redirection est périmée, le modèle actuel c'est plutôt la programmation objet, on un objet fait une chose et une seule et la fait bien.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 2.
[^] # Re: MS-XML et clé binaire
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft, doc et standard. Évalué à 1.
C'est pas là le problème, le problème vient du fait qu'il y a des lacunes sémantiques dans le format OpenDocument, et KOffice ne peut se contenter d'implémenter OpenDocuement, même intégralement et de manière exacte, il peut quand même il y avoir des problème d'interpérabilité.
Et non le format MS documents ne pouvait pas etre utulise par OOo vu la licence qui empeche toute implementation de ce format dans un projet open source!!!
D'où l'intérêt de ce journal qui précise justement qu'il y a des changements dans la politique de Microsoft.
Silicon :
"Ensuite, pour inciter les développeurs à travailler avec ses formats de fichiers, Microsoft modifiera la licence, s'engageant ainsi à ne pas attaquer les développeurs."
NetEconomie :
"Quant à la licence qui sera appliquée sur son format Office XML, Microsoft lance un message fort à la communauté 'open source', puisque Microsoft Office Open XML sera proposé gratuitement sous une licence du même type que celle d'OpenDocument, à savoir que Microsoft s'engagera à ne pas poursuivre un utilisateur."
[^] # Re: ECMA ?
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft, doc et standard. Évalué à 3.
Mono n'est pas compatible avec ActiveX/COM et n'a pas été fait pour Windows. Mono est juste une plateforme compatible avec .NET, question d'interopérabilité. Maintenant va engueuler tous les mecs qui font la promotion de OpenOffice.org, c'est vrai quoi, ils font un produit compatible avec MS Office, c'est mal (TM).
Celui du foutre du binaire dedans afin de rendre impossible aux autres suites office d'ouvrir le format "ouvert" MS??????
Si jamais tu trouves un seul fichier Office Open XML avec un morceau de binaire qui cache de l'information nécessaire à l'interopérabilité tu m'appelles gros malin.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 2.
[^] # Re: MS-XML et clé binaire
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft, doc et standard. Évalué à 3.
http://blogs.msdn.com/brian_jones/archive/2005/10/04/477127.(...)
En règle gténéral : voir les problème d'interprétation et d'interopérabilité entre OOo et KOffice avec le format OpenDocument.
[^] # Re: MS-XML et clé binaire
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft, doc et standard. Évalué à 3.
Ils auraient mieux fait de se pencher sur le format qu'ils "standardisaient", notamment sur les nombreuses lacunes sémantiques du format OpenDocument plutôt que de FUDer comme des porcs.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 2.
[^] # Re: A si tu compares a C/C++, forcement...
Posté par TImaniac (site web personnel) . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 2.
Sauf que en C# c'est intégré dans la syntaxe, et ca permet d'invoquer directement une lib native sans wrapper nécessitant un langage intermédiaire comme dans la plupart des langages. Je ne connais aucun autre langage qui permette cela de manière portable.