M a écrit 3002 commentaires

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

on parle de gcc, pas de g++, donc pas de c++.

De plus les commentaire a la C sont suporte dans le standard C99, donc pas de probleme...

Le probleme viennet plus de certaines magouilles tel que :

int i;
(char)i = 'c'

sur les vielles version de g++ (3.3-) c'etait pire, des oublis de << provoquait des internal errors...

Et ils ne pourraient pas faire "tout de suite" une version moins tolérantes, plutôt que changer un peu à chaque release ? Il y a déjà des projets qui ne compilent qu'avec un Gcc 2.XX ou 3.XX, s'il faut encore différencier entre gcc3.XX et Gcc 4.XX, j'imagine le casse-tête pour ceux qui font des distributions.
Si tout le monde respectait les standards et ne jouait pas avec certaines features, ca serait beaucoup moins problematique...

Par contre pour la comp binaire tu parle de quoi ?
Pour le C il me semble que ca pas changer depuis tres longtemps, pour le c++ ca commence a etre bien stabilisee...

Quelqu'un serait il quelle est la difference avec http://www.asterisk.org/(...) ?

c'est ce qui me semblait aussi avoir compris...
il me semble que j'avais vu ca sur /. (http://slashdot.org/article.pl?sid=05/04/07/1319259&tid=162&(...) )

tu devrais poser ta question sur la ml icewm, tu aurais plus de succes...

Pour mes cours je dois faire de l'assembleur motorola 68k, notre prof nous a indiqué deux programmes qui permettent de compiler et de debugger.

Tu veux dire que les programmes compile tourne sous windows ?

Le debugger serait aussi un emulateur ?

[ ] Autre: préciser ........
Elle est au fond du placard

C'est marrant il publie les sources apres que les drivers aient ete RE....

M'enfin c'est pas la premiere fois que via libere ces driver (cf carte graphique de portable) et si ca peu aider certains...

non...
Le tuner est different et puis ensuite tu recoit des donne compresse...

j'ai retrouve le lien : http://arch.debian.org/docs/linux/html/tlalinux.limitations.html(...)