Christophe Lucas a écrit 205 commentaires

Bah, pour ma part je ne trouve pas que le choix de Java (en tant que langage) soit un mauvais choix. Je vois déjà venir les moinsages à la pelle ;-)

En effet, Sun fournit une large part de développeurs à ce projet libre et qu'une large part de leurs développeurs sont très compétents en Java, cela paraît relativement logique que leur choix les ait conduit vers Java pour coder des parties d'OOo.

Maintenant, j'admets que Sun peut avoir volontairement fait le choix de Java pour son côté obscur...

Néanmoins, si la possibilité d'utiliser GCJ comme JRE pour utiliser les fonctionnalités Java d'OOo est avérée et prouvée, alors vive Java... Sinon aie aie aie :-(

Wow!:!! En effet, c'est extraordinaire ca :-) Comment créée un organisme par une volonté politique qui peut servir ensuite ses propres intérêts mercantiles :-(

Et le coup du statut de diplomate c'est la cerise sur le gâteau, j'en reviens pas !! :-(

La commission européenne peut-être ???

Ok je => [] ...

Bah alors je pense que la lecture de : http://lwn.net/Articles/129914/(...) et surtout GCJ 4 enhancements est fortement conseillé. Tu soupconnes bien :)

Face au changement de politique de la société BitMover, il est intéressant de constater la vitesse à laquelle l'équipe de développement du noyau a créé un nouvel outil et l'a rendu utilisable pour continuer le travail et sortir de nouvelles versions.

Oui c'est interessant, mais BK est a des années lumiere de git. Faut pas non plus croire qu'on developpe un outil avec autant de features que BK, comme ça en 3 semaines, meme avec les meilleurs developpeurs du monde.


Euh je ferais juste une petite remarque : git n'est pas à l'heure actuelle un SCM, alors comparer des choses qui ne peuvent l'être n'a aucun sens. Donc dire : BK vs git est infondé. git est une bonne base pour développer un SCM, voilà tout.

Cf : http://lwn.net/Articles/130865/(...)

Bonne journée,

< pub>
D'ailleurs, pour ceux que ca intéresse de bosser sur des drivers 3d libres, il y a une mailing list (dri-devel sur sourceforge) et un channel irc #dri-devel sur freenode.
< /pub>


Pour ceux que tout cela intéresse :
http://wiki.duskglow.com/index.php/Open-Graphics(...)

De plus, l'article d'un des concepteurs d'OpenGraphics dans GLMF explique bien tout ce que bknight introduit dans son précédent post.

Bonne journée,

Salut,

A titre de curiosité, qui crée les certificats concernant la carte Sesam Vitale ?

Euh je ne suis pas un maceux, mauis vu l'environnement de dev, je ne pense pas, enfin j'aimerais réellement me tromper :)

Oui, je sais et je suis entièrement d'accord avec toi, sur le fait que ce n'est pas juste un choix sur les performances, mais aussi sur la manière de travailler que cet outil (bitkeeper et son successeur) procure aux développeurs du noyau.

Mais je citais cela :

Larry noted that Linus tried monotone, but a simple import of flat files without versioning information took 2 hours, far too slow.


C'est bien que les performances entre monotone & cie et Bitkeeper sur ce genre d'opérations et donc d'autres sont loin d'être les même (Ce qui rejoins mon précédent post disant que je n'étais pas vraiment sûr que : Subversion et Arch sont tout à fait à même d'être utilisé pour remplacer BK (même s'ils manquant encore des fonctionnalités)).

Maintenant, je souhaite fortement qu'un projet libre soit aussi performant et puisse prendre la relève de bitkeeper et aussi que cette histoire serve de leçons.

Finalement, ce n'est peut-être pas une aussi mauvaise nouvelle que ça.

Sur le fond je suis tout à fait d'accord avec toi. Ce sera flou un moment, mais bon ils y arrivaient avant, il y arriveront bien un moment le temps de trouver ou développer un autre logiciel de versionning.


L'équipe de développement du kernel va être un peu embétée pendant un moment car certains développeurs vont devoir se passer du client BitKeeper non commercial.

Mais on peut espérer que le développement du Linux kernel passe sur un système de gestion de version libre et open-source : Subversion et Arch sont tout à fait à même d'être utilisé pour remplacer BK (même s'ils manquant encore des fonctionnalités). D'ailleurs certains devs comme Andrea Archangeli utilise déjà des passerelles BK - CVS - Subversion pour leur dev et s'en sortent très bien.

En revanche, je n'ai aucune idée des performances de logiciels tels Subversion , Arch sur 311Mo de sources. Alors de là à affirmer que ces logiciels s'en sortiront tout autant que Bitkeeper ... Je te laisse l'affirmer.


Cela permettra aussi que d'autres projets open-source suivent cette voie car à l'heure actuelle, difficile de faire bouger les gens pour ne plus utiliser l'antique CVS.

Alors là je suis tout à fait d'accord.

Un autre bon poisson, enfin j'espère :
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html(...)


Work on Xen has been supported by UK EPSRC grant GR/S01894, Intel Research, HP Labs and Microsoft Research.
For further details contact xen-admin@lists.sourceforge.net.

Tu veux un bon poisson d'avril :
http://www.application-servers.com/(...)

Regardes la seconde news :)

Oups je croyais que le grand maitre Jedi des BSD serait parmi nous :-(

Désolé...

Soit :
http://lwn.net/Articles/2.6-kernel-api/(...)

Et le LDD3 :
http://lwn.net/Kernel/LDD3/(...)

Bonne lecture...

Suis bien d'accord ! Je ne loupe pas non plus une occasion de donner ma voix à ce qui me semble le plus juste, néanmoins le vote d'aujourd'hui ne se traduit presque jamais dans les faits demain :-(

Alors que faire... comme tu dis.

La dernière fois, nous nous sommes un peu heurté sur un autre thread, mais là je n'ai malheureusement rien de mieux que dire : "aux armes citoyens!" et d'acquiesser ce que tu dis.

Librement (bof bof bof :-()

Mais de rien très cher maintenant t'approche pas trop quand même ;-)

MDR !!

Allez amuses toi bien avec UML...

UML a été intégré au noyau dans la version 2.6.9.

Une petite documentation :
http://www.rotomalug.org/article.php3?id_article=78(...)

Bien le bonjour chez vous ;)

Bonjour,

J'ai bien compris merci et je sais très bien ce qu'est un cache TLB. Maintenant, si préciser réellement ce qui fait une traduction d'adresses virtuelles en adresses physiques est un crime, j'aurais peut-être dû me taire !
La phrase d'origine laissait penser que c'est le cache TLB qui fait cette traduction, je voulais juste souligner cela.

Bon bah je retourne apprendre à lire et => [].

Euh, c'est pas vraiment le TLB qui fait la traduction d'adresses virtuelles en adresses physiques. C'est la MMU :-) Le TLB est comme son nom l'indique un cache permettant de trouver plus rapidement l'association pages virtuelles-pages physiques.

D'ailleurs au passage, le code gérant le TLB sur architecture PPC a été revu.

Bonne journée les gens...

Euh, je pense qu'il manque tout de meme dans la description des changements apportés à cette release, le patch permettant d'utiliser des tables de pages à 4 niveaux permettant d'utiliser pleinement les architectures 64 bits.

Voilà, mes deux cents ;-) et je => []

Involontaire pour être franc, mon subconscient doit associer jolie demoiselle et danger de se faire duper !!! ;-)

C'est pour le brésilienne que tu veux partir ou pour le job ;) ????

ok ok !! je => []...

Non non c'est ce point là le plus important du FOSDEM pour Alan:

FOSDEM - What do you expect from your FOSDEM talk?
Alan Cox - A lot of hard questions. [...] "I hope the beer is good."

Ok je => []

Salut,

Si je ne m'abuse, le patch a été sorti pour le noyau 2.6.10, donc s'il se base sur un 2.6.9, c'est rapé. Néanmoins, si cela est un prérequis pour la sortie de la RHEL4, alors je pense que M. Alan Cox ou quelqu'un d'autre a du stabiliser ce patch.

<sct@redhat.com>
[PATCH] ext3: online resizing

The patch below adds online resize capability to ext3 based on Andreas
patch for 2.4 and fixed up by Stephen.

The patch also removes s_debts:

s_debts is currently not used by ext3 (it is created, destroyed and checked
but never set). Remove it for now.

Resurrecting this will require adding it back in changed form. In existing
form it's already unsafe wrt. byte-tearing as it performs unlocked byte
increment/decrement on words which may be being accessed simultaneously on
other CPUs. It is also the only in-memory dynamic table which needs to be
extended by online-resize, so locking it will require care.


Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Au passage, c'est dommage pour eux vis à vis des performances :

<cmm@us.ibm.com>
[PATCH] ext3 block reservation patch set -- ext3 preallocation cleanup

Cleans up the old ext3 preallocation code carried from ext2 but turned off.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

<cmm@us.ibm.com>
[PATCH] ext3 block reservations

rbtree implementation and other changes From: Stephen Tweedie <sct@redhat.com>
contributions From: Badari Pulavarty <pbadari@us.ibm.com> and probably me.

This is the ext3 block reservation patch. It improves the layout of ext3
files by establishing, for each inode, reserved areas of the disk in which
only that file can allocate blocks. Those reserved areas are managed in an
rbtree, via the in-core inode.

It's a bit like ext2 preallocation only stronger in that it can span
already-allocated blocks, including the per-blockgroup inode tables and
bitmaps.

The patch fixes ext3's worst performance problem: disastrous layout when
multiple files are being concurrently grown.

It increases the size of the inode by rather a lot. A todo item is to
dynamically allocate the `struct reserve_window_node', so we don't need to
carry this storage for inodes which aren't opened for writing.

The feature is enabled by mounting with the "reservation" mount option.
Reservations default to "off".

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Bien le bonjour chez vous :-)