M a écrit 2996 commentaires

Apres le fait de pouvoir breveté tout et n'importe quoi, je pense que la duree de validite des brevets est un vrai probleme.

20 ans c'est beaucoup trop long a l'echelle de l'informatique ou du moins tant qu'elle sera en pleine evolution.

Enfin je trouve le cout des brevets relativement cher pour les particuliers-PME si l'on veut proteger son invention partout dans le monde, et c'est surtout les grosses boites qui en profitent, mais ce probleme est aussi present pour les brevets non-logiciel....

Mieux : utilise a sortie numerique de ton lecteur de cd, ca evitera la perte par conversion digital-analogique-digital.

bref c'est relou cette histoire.

Apres les majors s'etonnent que les gens preferent les telecharger sur le net..

L'«évangéliste technique en chef » pense que le principal problème vient de la taille du code, pas du pouvoir de Sun dans le développement d'OpenOffice et précise que toutes les contributions sont les bienvenues.

Ben oui c'est ca de vouloir faire une usine a gaze qui reinvente tout(widget, ...) et qui n'est pas modulaire...

Apres c'est sur que ca doit pas etre evident de comprend le code, mais en plus s'il faut ceder son code a sun, faut pas trop s'etonner du nombre actif de develo...

et tu la trouve ou la prise de courant ?
Un portacle comme son nom l'indique c'est fait pour etre portable (donc pas de prise forcement a cote...)

tu l'alimentes comment ton pont ?

ca revient à faire un make install barbare
heu tu peux choisir le repertoire d'installation et meme l'installer sur ton $HOME.

Donc c'est de la faute des utilisateurs s'il casse leur distrib...

ben pourtant :

Unichrome X
C'est le driver 2d X

Unichrome XvMC
C'est l'extension de decompression hardware X, puis ensuite y a une liste de patches pour que differents lecteurs puissent en profiter.

Unichrome DRI
C'est pour la 3D

J'aime bien l'argumentaire tres pousse sous linuxfr...

Pourtant je crois que les personnes qui ont critique ogg doivent s'y connaitre beaucoup que vous au niveau du multimedia...

Quand a la question des brevets, le fait qu'il n'y ai aucune reponse est eloquant : tout le monde pense que c'est bon et on va pas pousse question trop loin, on pourrait en trouver...

mouai deja qu'en esence + payage ca depasse largement le prix d'un billet de train, je pense que ca changera pas grand chose.

La voiture c'est bien que qd on est charge ou beaucoup...

Ben la news est fausse alors...
Les moderos sont pas censer ce genre d'info ?

je sais pas, par contre sur le projet unichrome tu as des implementations libres...

En plus ils utilisent l'etension XvMc de X plutot que des lib pas standard...

y a un truc que je pige pas : a une epoque on pouvait changer la langue en telechargeant un xpi, la je vois que dans la pluspart des cas il propose le binaire complet, pourquoi ?

Les codes ainsi libérés ont été placés sous licence GPL (avec des variantes selon le mode de distribution dans le cas de XGI).

Sur la page unichrome on peut lire :
These drivers were released by VIA, upon request, under MIT license. We keep this in our CVS for reference only. Please DO NOT USE this directly.

Ils ont donc changer la license de leur driver ?

Sinon c'est quoi qui est exactement sous gpl ?

Parceque si c'est les drivers 2d, ca veut dire qu'ils ne seront jamais integre directement dans Xorg qui a une license se raprochant de la bsd...

idem pour le dri...

Qu'aporte de plus les drivers de via par rapport a ceux developper par le projet unichrome ?

Sur leur page on peut lire :

Recent VIA releases (CLEXF40040 and CLEXF40047) contain files with non-free licenses. The code offered by VIA can no longer be considered open source and the offending files have been removed.

Qu'en est-il ?

Sinon c'est pas nouveau, via avait deja libere des piolotes pour les cartes graphique de portable (savage) dans le passe.

De plus c'est bien beau de liberer des pilotes mais il ne faut pas oublier que sans spec on est souvent limite (le degree depend de la doc du code, des fonctionalites qu'il couvre, de la genericite de l'acces au materiel)...
Sur la page de dri on peut lire pour ces via :

The basics can be deduced from the driver_lite source from VIA. Its a fairly generic "queue up the vertices and fire" type chipset and the most noticable thing about it appears to be the lack of hardware clipping. When its not doing fallbacks performance seems comparable to the onboard intel stuff but its not radeon grade.
De plus les anciens pilotes liberer par via etait assez obsolete : utilisation d'une vielle version de mesa, ... On avait l'impression qu'il voulait s'en debarasser et laisser le boulot a la communaute.

L'inverse est aussi vrai (carte intel) avec les specs, mais avec peu de developpeur le support n'avance pas tres vite.


Sinon des nouvelles du projet qui consistait a creer une carte graphique developpe dans l'esprit open source ?

PS : pour xgi j'ai lu dans certains commentaires que les pilotes ne concernait que la 2d, et qu'il n'apportait rien de plus que des drivers open source deja existant.

pour la recherche, c'est avec / (comme dans vim)
comme sous mozilla aussi

dans l'autre mode, je crois qu'il doit rechercher que les liens

et comment avec tous les brevets logiciels qui trainent peux tu etre sur qu'il n'y a aucun brevet qui touche de pres ou de loin ogg ou vorbis ?

Ensuite autant le vorbis est pas mal, autant le ogg c'est un conteneur relativement pourris :
- interdependance avec les codecs (les commentaires, info sur le flux sont propre au codec...)
- pas moyen de generer des timestamps simplement
- overhead assez important
Plein d'autre point : cf la ml de ffmpeg ou il y a un debat sur le meilleur format il y a quelque temps...

ben sous mozilla, bouton du milieu pour ouvrir rn arriere plan et ctrl + tab pour naviger dans les tabs (meme pas besoin de clické)...

Horreur ce dimanche, j'ai raté mon train... on avait un billet plein tarif à 36¤ et un billet tarif réduit Prem's à 30¤ ... (déjà tu parles d'une réduction, c'est assez misérable 6¤ comme réduction, sur un aller-retour pour deux personnes à 120¤ !)
ben c'est pas de ma faute si tu sais pas choisir ta destination : moi j'ai eu des prems a 25 ¤, alors que le plein tarif etait dans les 65 ¤...

c'est pas nom plus de ma faute si tu sais pas lire les conditions avant d'acheter...

Au passage j'ai eu l'occasion de jouer avec et j'ai pas trouve l'api vraiement genial :
- pas de methode seek, tout passe par un read, du coup si on veut faire un truc un peu optimiser (c'est deja assez lent comme ca), une des premiere chose qu'on fait dans le read c'est de regarder si on a fait un seek
- pas moyen de preciser forcer un blocksize pour l'ecriture/lecture. Du coup on doit passer par des buffers intermediares/se prendre la tete qd on commence/fini au milieu d'un block
- pas de reel gestion de cache : par default fuse lit par page, du coup on lit beaucoup, on attend que le buffer se vide, on relit beaucoup, ce qui peut parfois entraine des delai lors de la lecture sur des medias lent.

Je dis pas que soit doit forcement etre implementer dans le noyau, mais au moins la lib fuse pourrait proposer des solutions generiques pour eviter d'avoir a coder plus de glue generique que le reste...

Tu peux aussi regarder du coter de NX freeNX pour le login a distance : je crois qu'il ont des clients windows et le son/montage samba devrait passe (j'ai pas teste non plus)...
Ca devrait etre aussi beaucoup plus fluide.

C'est quoi l'interet, xorg marche tres bien sous windows, y a meme un livecd pour windows qu'il l'a (je n'ai plus le nom, mais c'etait fait par des indiens).

Ben c'est portable c'est que t'affiche pas la bonne valeur : ce que t'as voulu modifier c'est le premier octet et pas l'entier.

Donc si t'as char *p = px; et t'affiche le contenu de *p ca sera le meme...

Bon reprenons :
Imaginons que j'ai une zone de memoire contenant des donnees :
la taille coder sur 1 octet,
l'info y est coder sur 2 octets
l'info z est coder sur 4 octets

int *i = debut de la zone memoire
(char)*i = taille;
(uint16)*i = htons(y);
*i = htonl(z);

Bon apres tu utilise une structure packed si les champs sont fixe, mais c'est pas toujours le cas. La sol propre est de declarer 3 pointeur, un pour chaque type...

pas forcement : (char) *i, ca revient a declarer char *p = i;
Apres vu que t'ecris qu'un octet ca sera la meme chose sur toute les archi, puis si tu ecris par par block de 32 bits (c'est bien pour ca qu'on avais choisi un int*) alors tu peux toujours utiliser des macro du type cpu_le32, htonl qui te fond la conversion suivant les archi...

D'ailleur si cela avait avoir avec la portabilite ca ferait longtemps que ca serait corrige dans certaines distributions multi-archi.