liberforce a écrit 4744 commentaires

C'est toujours les mêmes quoi. En plus je sais pas pourquoi 7-zip arrive toujours en tête, parce que franchement, au niveau ergonomie, il suxe des mamans ours...
En plus, sur la page de don, le don minimum est de 20$. Si tu continues, en plus c'est 20¤ ! Je trouve ça un peu cher pour un outil aussi basique, aussi utile soit il.

Par contre effectivement, le comparatif sur le site de 7-zip monte que la compression est très bonne en général:
http://rlwpx.free.fr/WPFF/comploc.htm

Pourquoi ce format, ouvert qui plus est, n'est dans ce cas pas plus répandu ? Même dans le monde du libre on ne le voit guère, au profit du tar.gz et tar.bz2, pourtant moins bons on dirait...

Ça a même déjà commencé...
http://blogs.gnome.org/xan/2007/07/17/epiphany-webkit/
http://blogs.gnome.org/xan/2007/07/24/if-you-see-the-buddha-(...)

http://linuxfr.org/2006/08/28/21259.html

Et d'autres liens en vrac:
http://linuxfr.org/2006/04/20/20698.html
http://linuxfr.org/2006/12/15/21775.html
http://linuxfr.org/2005/04/28/18839.html

C'est le problème des brevets: une fois qu'ils sont dans la règle du jeu, tu n'as pas d'autre choix que de breveter à tout va, pour te protéger. Tu penses sincèrement qu'il aurait mieux valu que ce brevets soient déposés par des sociétés qui se foutent complètement du libre ? Ç'aurait été pire encore.

Non, le meilleur moyen, c'est ce que fait IBM: breveter à gogo, comme les autres, histoire d'occuper le terrain et éviter que les autres ne brevettent avant toi. Ensuite, en n'autorisant que les projets open source à pouvoir utiliser librement ces brevets, tu casse le système de brevets. Ceux qui veulent continuer à faire du proprio continuent de raquer, et ceux qui font du libre peuvent exploiter ces brevets sans crainte.

On ne fait pas de scandale pour QT qui est sous licence multiple: si tu veux faire du libre avec, c'est gratuit, par contre si tu veux faire du proprio avec, c'est payant. Je pense que ce modèle est un des meilleurs qu'on puisse proposer en ce moment, car il favorise le logiciel libre.

Après on peut dire "qu'est ce qui se passe si IBM retourne sa veste ?". Bin ils n'en ont pas trop intérêt, sinon leur image en prendrait un grand coup, et puis IBM a quand même un vieux compte à régler avec Microsoft...

http://www.jamendo.com/fr/album/4670/
C'est le moment d'écouter la n°2 ;-)
http://www.jamendo.com/get/track/id/track/audio/play/38024

T'as oublié un q dans tes couilles ^_^

Fais une dépêche !

Dans le goatse !

Chez moi au douzième clic ça commande une pizza pepperoni...

Oui, après une 2005 LE et une 2006 en demi teinte, la 2007 a amené pas mal de progrès, et la 2007.1 n'a fait que les confirmer.

Avec la 2007.1, plus de troll sur les mises à jour soit disant payantes, tout le monde a eu le droit à l'applet de mise à jour. De même, les dépots contenant du soft non libre, et disponibles auparavant uniquement pour la version commerciale ont été ouvert et sont depuis disponibles pour tout le monde.

Moi aussi leur volonté d'homogénéisation du desktop linux me plait bien, donc plus il y aura de choses upstream et plus tout le monde en profitera. Qu'on ait plus du "ça marche avec la distro x mais pas avec la distro y". On peut aussi dire que compiz fusion a montré que c'est plus facile d'avancer ensemble que côte à côte :-)

Dans ce cas la communauté OpenSolaris assure ce boulot, non ? C'est peut être idiot ce que je dis, mais je ne connais pas trop le monde Solaris.

Pourquoi, c'est RMS qui écrit la doc dans ce cas là ? :-)
Plus sérieusement, c'est pas parce qu'un truc devient ouvert qu'il y a plus de doc. Tu peux trouver facilement de la doc pour Windows, et difficilement pour certains projets libres. L'un n'a donc rien à voir avec l'autre.

pour sortir un journal assez complet, je me suis finalement fait devancer...
Alors voici le processus dans l'ordre:

Les idées issues de la communauté:
http://wiki.mandriva.com/en/Development/Ideas/Mandriva_2008

Les spécifications techniques détaillée des améliorations:
http://wiki.mandriva.com/en/Development/Ideas/Technical_spec(...)

Une synthèse des spécifications techniques:
http://wiki.mandriva.com/en/Releases/Mandriva/2008.0/What's_(...)

De plus, après son nouveau wiki, Mandriva est en train de migrer son bugzilla, qui il faut le dire, était un goulot d'étranglement incroyable. Le fait de lister tous les packages disponibles pour y choisir celui qui auquel se rapporte un bug était d'une lenteur infinie. Vincent Danen s'y attèle:
http://linsec.ca/blog/index.php?/archives/133-New-bugzilla-i(...)

Le nouveau bugzilla est actuellement en test (inutile donc de raporter des bugs dessus, ils seraient perdus):
http://bugzilla.linsec.ca/

Certaines évolutions sont le résultat direct des possiblités ouvertes par Powertop, disponible depuis le kernel 2.6.21. Par exemple, l'applet d'état du réseau, net_applet, faisait un polling qui réveillait le kernel. Celui ci sera supprimé.
http://wiki.mandriva.com/en/Development/Ideas/Technical_spec(...)

Mandriva contribue aussi upstream, on l'oublie trop souvent. Ainsi l'envoi upstream des modifications de pm-utils, et de la base de détection de périphériques (PCI IDs) est au programme, pour éviter de dupliquer inutilement les efforts entre chaque distribution.
http://wiki.mandriva.com/en/Development/Ideas/Technical_spec(...)
http://wiki.mandriva.com/en/Development/Ideas/Technical_spec(...)

Mandriva sait aussi prendre ce qu'il y a de bon ailleurs, par exemple la gestion udev dans le cas de Fedora:
http://wiki.mandriva.com/en/Development/Ideas/Technical_spec(...)

...Ou bien (peut être, la proposition n'a pas encore été acceptée) un outil d'installation de codecs "à la Ubuntu". Celui ci permet l'installation de codec non redistribuables dans certains pays, car soumis au DMCA (US) ou à l'EUCD (europe) - merci les brevets logiciels.
http://wiki.mandriva.com/en/Development/Ideas/Technical_spec(...)

Côté son, l'heure a sonné de changer le système tout pourri de serveurs de son sous Linux. Des alternatives sont à l'étude pour KDE3, KDE4 et GNOME. Ce dernier pourrait bien remplacer esd par PulseAudio.
http://wiki.mandriva.com/en/Development/Ideas/Technical_spec(...)

De même, les derniers pilotes audio OSS seront remplacés s'ils ont une alternative ALSA.
http://wiki.mandriva.com/en/Development/Ideas/Technical_spec(...)

Donc à priori on peut dire que cela devrait être un bon cru, GNOME 2.20 et KDE 3.5.7, avec une version preview de KDE4, kernel 2.6.22, Xorg 7.3 avec XrandR 1.2, disponibilité de compiz-fusion, fin de la migration complète aux menus XDG.

Bref: ils ont du boulot ! :-)

Ah, et je te recommande refaire un peu le point sur le fonctionnement de l'allocation mémoire et les pointeurs. Là j'ai l'impression que tu vas un peu trop vite en besogne. C'est pas méchant hein, mais c'est bien de bien maitriser le langage avant l'API.

Reposte ton code quand tu auras quelque chose, je te filerai un coup de main.

Hum... Quel est l'intérêt d'un B-tree par rapport à une table de hachage dans ce cas ? Tu peux faire une table de hachage contenant tes listes de paquets correspondant à ta connnexion.
http://developer.gnome.org/doc/API/2.0/glib/glib-Hash-Tables(...)

Si l'ordre d'arrivée des paquets est important, tu peux même utiliser les files.
http://developer.gnome.org/doc/API/2.0/glib/glib-Double-ende(...)
L'avantage est que tu peux rajouter un élément à la fin en temps constant. Tu n'as pas besoin de parcourir la liste entière pour rajouter cet élément à la fin. En tout cas vu ce que tu veux faire, c'est la solution que j'adopterais, à moins qu'il n'y ait une bonne raison (que je ne vois pas) pour utiliser un B-tree...

Hum... Tu es sûr que c'est bien une liste que tu dois utiliser ? Tu es sûr que ce n'est pas juste un nouveau noeud dans le btree ? Sinon, pour les listes, oui la GLib en a: GSList pour les listes simplement chainées, et GList pour les listes doublement chainées. Pour connaitre tous les types d'éléments fournis par la GLib, regarde la doc: http://developer.gnome.org/doc/API/2.0/glib/glib-data-types.(...)

Mais qu'est ce que tu essaie de faire au juste ?

Ah, pour les g_slice_*, ce n'est intéressant que si tous les objets ont la même taille. Donc si tu veux allouer/désallouer plein d'objets de 15000 octets, c'est ce qu'il faut utiliser. Mais là dans ton cas, vu que la taille des données est variable, ce n'est pas indiqué: autant ne stocker que ce dont tu as besoin.

GArray est fait pour stocker plein d'objets de taille fixe, pour ne pas avoir besoin d'allocation dynamique. Pour toi ce n'est pas possible, car tes objets ne font pas tous la même taille. Tu pourrais dans ce cas utiliser GPtrArray qui est fait pour stocker un pointeur vers des données (que tu allouerais dynamiquement), mais dans ce cas aussi, tu perds la taille de tes données.

Conclusion: si tu veux pouvoir accéder à tes données sans risquer d'aller lire en dehors des limites du buffer où elles se trouvent, tu dois utiliser une structure qui contient:
- la taille de ton buffer
- un pointeur vers ton buffer de données

Tu peux le faire à la main, c'est simple, mais si tu n'as pas envie de te prendre la tête, tu utilise une GString, qui le fait à ta place . Si tu la crées avec g_string_new_len, tu peux spécifier la taille de tes données, et dans ce cas là, la chaine à copier est autorisée à contenir des caractères '\0'. Ton code ressemblera alors à :
value = g_string_new_len(m->payload, m->data_len);
g_tree_insert(Storing_B_Tree, key_one->str, value);

Tu accèdes ensuite à ton buffer avec value->str et tu en connais la taille grâce à value->len. Avec ça tu ne consommes juste ce qu'il faut de mémoire, pas plus, et connais toujours la longueur de tes données.

Quoi, tu voudrais dire que dans "Alias", ils ont recompilé échelon avec CMake ?
~~~~> [ ]

Ah, en plus pour copier tes 52 octets, tu en lis 1500 (donc que tu lis n'importe qui dans la mémoire).

Pourquoi utilises tu un GArray si c'est pour y mettre un seul élément ? Fais juste un g_new/g_new0, ou mieux, un g_slice_alloc/g_slice_alloc0.

Wouah, ça a l'air compliqué son métier :-)

News très claire et très bien rédigée, il fallait bien ça vu les nouveautés dont regorge à chaque version le noyau !

http://wiki.mandriva.com/fr/Accueil
http://wiki.mandriva.com/fr/Choisir_la_bonne_version

.