Hank Lords a écrit 241 commentaires

Tu veux dire qu'on ne peut pas avoir un produit de bonne qualité qui ne restreint pas nos liberté ?

Salut godflesh,

Tu peux faire un plugin vlc qui demande a amarok (a l'aide de dcop) le fichier qu'il est en train de lire et le balance a la freebox.
Ou bien un plugin amarok qui relance un vlc avec la ligne de commande qui va bien a chaque changement de fichier (bof).

Ou encore faire un plugin shoutcast a amarok qui envoie a un serveur icecast sur lequel est connecté vlc (euh oui c'est lourd !)

Ou encore faire un plugin amarok qui envoie le flux directement a la freebox.
Dans ce dernier cas, il faut que tu mettes ton mp3 dans un flux MPEG-TS (bonne chance pour trouver de la doc la-dessus). Si ce n'est pas un mp3, la freebox ne saura pas le lire et il faudra transcoder en mp3 avant.

Dans tous les cas, tu ne peux pas recuperer le flux binaire audio de amarok avec leur systeme de plugin, tu peux connaitre le fichier lu et la position (en secondes) a l'aide de dcop.

Je pense que la solution la plus facile niveau programmation est celle avec icecast.

Bonne chance :-)

De plus le firmware libre rockbox ( http://rockbox.org ) a été porté très recemment sur le X5.

J'ai testé, ça marche assez bien, et l'installation est facile.
Il reste des petits bogues. L'interface est assez 'crue' et moche mais reste accessible. La gestion des playlist est agréable (beaucoup plus que sur le firmware d'origine).
Par contre on ne peut plus lire les vidéos, mais il parait qu'on peut lire les fichiers audio .mpc en plus des nombreux formats deja supportés (je n'ai pas de mpc pour tester).

Donc beaucoup de bonnes choses, en plus du fait que ce soit libre (GPL).

Once in a while we hear from vendors out of the blue, and they offer us hardware and software without us having to ask. It is happening more -- mostly from Asian hardware manufacturers eager to have their hardware supported by all systems. On the other hand, American companies in particular are becoming increasingly insular, and sometimes we think twice before wasting our time trying to contact them. As a result, our support for a few high-end or very new American products is lagging, because there just isn't documentation available. That is a problem, but it should not be overstated, because 99% of the world is buying these Asian products. For instance, Asian 802.11 vendors accounted for perhaps 1% of the market five years ago, but within a year or two the market is likely to be split between Intel (because of how they tie their wireless chipset into their laptop Centrino brand) and the Asian vendors, such as RAlink and Zydas.

Je trouve ça plutot encourageant : d'une part, il existe des constructeurs qui ont une politique d'ouverture et d'autre part cela leur profite vu qu'il voient leurs parts de marché s'envoler.

Donc le libre, ou au moins les spécifications ouvertes (dans le monde du hardware on n'en est pas encore au niveau du logiciel libre) est payant et des gens s'en rendent compte.

Le fait que ce soit des asiatiques qui pratiquent cette ouverture et que les américains y soient très réfractaires est à mon avis un très mauvais signe pour cette industrie américaine. Ils ont encore un avantage historique mais il se réduit d'année en année.

Quant à l'Europe... j'imagine que si Théo ne les mentionne pas c'est qu'ils sont virtuellement absents de cette industrie :-(

J'espère me tromper.

Bon puisque ca trolle, trollons :-)
D'un coté on a Openbsd, sous licence BSD réputée 'permissive' et qui permet d'être réutilisée dans des logiciels proprio.
De l'autre on a Linux, protégé par la licence GPL, qui empeche la réutilisation dans du code non libre, dont le mouvement instigateur se veut le défenseur intransigeant des logiciels libres.

Maintenant du coté de l'attitude des developpeurs :
- Linux autorise les drivers binaires et est laxiste quant à l'implémentation de certains qui sont semble-t'il non-réutilisable dans d'autres projets par le fait qu'ils sont complètement obscurs (le drivers ethernet nvidia mentionné ici).

- Openbsd, fait pression sur les fabricants de materiel pour avoir des drivers libres, refuse les drivers binaires, se force à opérer à un reverse engeneering complexe et long dans certains cas (toujours ce fameux nvidia) et ceci contre la volonté du constructeur.

Je pense que par leur attitude, openbsd a un comportement beaucoup plus profitable au libre en général. Et ça n'est absolument pas lié à la licence de leur projet.


PS: bon j'avoue, la GPL ça roxor :-)

Ah mais peut-être :-) Mais là tout le monde part en troll GPL/BSD, mais ce n'est pas du tout le propos de theo de raadt.
Il ne se plaint pas que son code s'est fait proprioifié, il se plaint que Sun a refusé de financer la venue de certains developpeurs de OpenSSH a leur conférences sur l'interoperabilité des protocoles (SSH y compris) alors que Sun utilise du code dérivé de OpenSSH. Ca s'inscrit dans son 'coup de gueule' sur le financement de Openbsd.

Et dans cette histoire particulière, la licence du logiciel d'origine n'importe pas.

Si OpenSSH était sous licence GPL, le problème serait le même. Personne n'interdit d'utiliser/de revendre un logiciel en GPL ou BSD sans donner un sou en retour.
Un des principes du libre est de permettre ces pratiques, mais en aucun cas de les généraliser.

Il n'y a rien de nouveau à ça, c'est l'utilisation courante des brevets de nos jours.

Pour moi ce n'est pas comme ça qu'on se sert d'un brevet défensif : Il peut y'avoir un procès , brevet ou pas, anteriorité ou pas. L'interet du brevet est comme monnaie d'échange.

Si une entreprise fait un procès pour violation de brevets, c'est qu'elle utilise une technologie proche, donc qu'elle risque elle-meme tout autant de violer tes propres brevets. Donc à partir de là, il y'a des alliances, des pactes de 'non-agressions', etc. Mais tout ceci n'est possible que si tu as un moyen de pression : posséder des brevets.

C'est un des problèmes les plus importants des brevets : ils concentrent la technologie et surtout le droit de l'utiliser dans les mains de quelques grosses entités qui ont les moyens de se constituer des portefeuilles de brevets suffisants.

Il s'agit d'une carte de developpement. Il y'a dessus un FPGA (une puce reprogrammable) au lieu d'un ASIC (une puce pas reprogrammable, mais plus rapide et moins chere). Le public visé, outre les developpeurs de la carte finale sont des gens qui font de la R&D dans les cartes graphiques.
D'où le prix élevé pour une carte graphique : ce n'est pas une carte graphique mais une plateforme de developpement.

Quant à la carte finale, elle sera probablement plus chere et moins performante que les monstres de chez ATI et Nvidia, au moins pour les premières versions.

Je rajoute qu'il y'a un dépot svn ici (qui parait bien vide pour le moment) : https://svn.suug.ch/repos/opengraphics/main

Il semble qu'il y ait le code de gestion du bus PCI (en verilog), dans le dossier 'pci' et sous licence LGPL.
Je ne pense pas qu'ils en soient à un stade plus avancé, ils doivent probablement attendre les prototypes de la carte pour continuer (je n'ai pas suivi le projet, ce n'est qu'une supposition).

C'est vrai qu'on n'a pas besoin du code vhdl pour faire de bons pilotes, une bonne documentation (datasheet, etc) est plus utile. Mais on peut tout de même esperer d'un projet visant a faire une carte graphique libre, que celle-ci soit libre. Donc avec toutes les parts du design.

De toutes façons d'apres la FAQ, ils ont l'intention de donner le RTL du FPGA puis de l'ASIC en GPL puis en LGPL après le début de la production.

http://wiki.duskglow.com/tiki-index.php?page=FrequentlyAsked(...)

1. *I heard this card may use a FPGA, are we going to get the 'source' for what is on the FPGA also?*


YES.

There are three different sets of "source code" that will be available.

* Source code to device drivers: All device driver code (including BIOS) written for the OGP will be released under MIT and BSD licenses. These licenses allow code to be used freely in open source and in proprietary software, without the "viral" nature of the GPL, as long as copyright notices are retained.

* The closest equivalent that hardware designs have to "source code" is called RTL. We use a C-like language called Verilog that describes circuit paths that will be laid out in the FPGA and ASIC chips. The RTL for the FPGA-based product (a prototyping and development board) is already being released under LGPL (dual).

* RTL for the ASIC will be released under GPL (dual). There will be a time-delay on some parts (to deal with investor concerns over the $millions necessary to invest in fabrication), but once the investment is recouped, the code will be released. (We need a law firm to escrow the RTL for us, pro bono.)

Le vrai challenge est donc le financement du projet.

C'est pas ça qu'il a dit. Il a dit qu'il était contre la peine de mort parce que il avait eu une éducation chrétienne.

Il n'a pas dit que seul des chretiens pouvait etre contre la peine de mort, ni que tous les chretiens etaient contre la peine de mort.

C'est toi qui fait des amalgames.

C'est 128k pour la version 'haut-débit'.

Et le flac (compression audio sans pertes).

Je n'y crois pas trop.
Je n'y connais pas grand chose en loi, mais d'après mon bon sens ces amendements ne sont pas encore valables : Déjà ça m'etonnerait qu'ils aient été publiés au journal officiel, ensuite le "délit" commis l'a été avant le vote de cette loi qui n'est évidemment pas rétroactive.

Itanium est "réellement" 64 bits.

Mais AMD64 est la technologie hybride de AMD, l'équivalent de EMT64. La plupart des processeurs (desktops et serveurs) vendus aujourd'hui par AMD sont des "AMD64" y compris les opterons.

Entiers, virgules fixe : c'est pareil :-)

J'ai acheté un X5L il y'a 6 mois chez mp3-player.de également et j'en suis très content jusqu'à maintenant.

Il a une grande autonomie, il lit les ogg (et les flac) et il fait usb host. De plus il n'a pas besoin d'un logiciel supplémentaire pour transferer les fichier, c'est du mass storage normal, donc rien de plus transparent sous linux.

Merci pour vos explications, c'est plus clair maintenant.

La video et l'audio sont envoyées en udp car le protocole est plus adapté : on a davantage besoin de l'aspect temps réel que de l'intégrité des données. Or en udp, on ne peut pas ouvrir un canal bidirectionnel vers un serveur comme pour le http (qui utilise le tcp), car l'udp impose qu'il n'y ait pas de canal justement. Donc on est obligé de transferer des ports sur la passerelle du client pour que le serveur puisse envoyer ses données. Il y'a deux ports : un pour la vidéo et un pour l'audio.
D'autre part le client transmet des données de controle au serveur à l'aide du protocole rtcp (généralement sur udp).

Une autre solution serait d'utiliser un proxy qui comprenne le rtp/rtcp comme proposé par niol. Celui-ci installé sur la passerelle agirait comme relai : il se comporte comme un client pour le serveur rtsp et comme un serveur pour le client (enfin comme un proxy normal quoi !)

Mais j'ai une autre question : est-ce que si 2 pc se connectent à la freebox pour recevoir le même flux (la même chaine), le flux de données est-il envoyé 2 fois ou une seule fois en multicast ? (Je ne sais pas meme pas si on peut faire du multicast en ipv4, je sais que c'est possible en ipv6)

J'utilise personnellement la première option (utiliser est un grand mot, je dirais plutot 'verifier que ça marche' ) : je redirige vers un port pour chaque machine.

Les dernières versions svn de vlc incluent une nouvelle option qui permet ça : '--rtp-client-port'

Je me demande a ce propos pourquoi ce protocole (alors j'ai pas bien compris quel était le nom du protocole : rtp, rtsp, etc...) a besoin de se connecter a la machine cliente : on aurait pu faire comme avec http : des clients qui se connectent a un serveur sur un port défini (80) et toutes les données (requète réponses) qui passent dedans.

Il y'a QtRuby qui devrait sortir bientot normalement, en version qui fonctionnera sous linux, *BSD, Max OS X et windows.
http://www.kdedevelopers.org/node/1686

euh ca marche pas ici, wget m'envoie balader.

Pfff... mais où ai-je ma tête :-) Oui effectivement c'est de cet article dont je parlais. (Je m'étais relu pourtant !)

J'ai trouvé ce commentaire de Arstechnica à ce propos, c'est assez interessant. Ca parle du pourquoi de cette décision et de comment elle s'inscrit dans l'actualité des fabricants de processeurs.