M a écrit 2988 commentaires

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.

d'ailleurs le systeme de cache de slashdot doit etre ecrit en perl si mes souvenird sont bon.

non je pense qu'il etait dans l'esprit multisesions ou tu n'ecrasse rien (normal puisque ca marche aussi sur des cd non reinscriptible) et tu continue d'ajouter des sesion a la suite et tu peux supprimer des fichiers en ne les mettant pas dans la nouvelle toc (du moins c'est ce que je suppose).

oui c'etait un prog externe (j'ai jamais dis le contraire)

5 ans c'est pas si veux que ca.

l'exemple etait un peu stupide, mais si t'as plutot
int *i;

alors avec (char)*i = 'c' tu ecris que 1 octet en memoire
et avec *i = 'c' tu ecris 4 octets ( c est transforme en int)

si si ca libere l'espace : autrement y aurait aucun interet au machin : ca serait un vulgaire multisession...

Faut dire que sur le coup linux a beaucoup de retard la dessus, ca marchais parfaitement sous windows il y a plus de 5 ans (sous linux y a encore des pb avec des dvd par exemple).

Aujourd'hui avec les clefs usb, vu la lenteur du machin ca devient plus tres interessant...

PS : sous windows on pouvait meme faire mieux : on pouvait compresser le volume et qd on mettait le disque sur une nouvelle machine qui ne supportait pas le format, on voyait une sesion du cd qui contenait un README avec les executable pour lire le machin (je sais pas tres portable...)

Je comprends bien le problème, mais ce que je demandais, c'est pourquoi les changement apportés entre Gcc 3 et Gcc 4 n'ont pas été fait "tout de suite" pour la version 3.

Pour laisser le temps aux developpeurs de corriger les pb :
gcc 3 : attention : use of cast expressions as lvalues is deprecated
gcc 4 : error: invalid lvalue in assignment