Joie !

J'étais en train d'écrire une superbe classe permettant de lancer plein de jobs sur la grille quand... PAF!
Je tombe sur une fenêtre de KDE-Apps qui parle d'un greffon pour KTextEditor permettant d'avoir un certain
nombre des raccourcis clavier d'emacs dans n'importe quelle appli KDE.

Je sens que je vais me mettre sérieusement à Kate, Kile et surtout... KDevelop.

Je n'ai pas encore testé la bête dans tous les détails, mais ça m'a l'air que du bon pour l'instant !
Des gens qui l'ont essayé ?

http://www.kde-apps.org/content/show.php?content=21706

> Lire le journal (9 commentaires, moyenne: 3,3).

Apres ce titre pompeux (et faux: la couche graphique est par-dessus GNU/Linux), entrons dans le vif du sujet.
Comme ecrit dans differents journaux, X.org va bientot fournir les versions X11R7 et R6.9 de l'implantation du serveur X.
De plus, on a vu de ci de la differentes idees pour rendre X, plus hype, plus eye-candy, plus in... plus mieux visuellement quoi.
Parmi toutes les idees qui ont le vent en poupe, celle qui revient le plus souvent (enfin il me semble), c'est d'utiliser une couche OpenGL pour le rendu des fenetres : j'ai nomme Xgl[1].

Et bien Mr Jon Smirl, apres s'etre rendu compte tout et n'importe quoi etait raconte sur la toile, s'est fendu d'un joli article[2] long de plusieurs pages.
Si vous voulez vous instruire, c'est par la.

[1] http://www.freedesktop.org/wiki/Software_2fXgl(...)
[2] http://www.freedesktop.org/~jonsmirl/graphics.html(...)

> Lire le journal (23 commentaires, moyenne: 4,6).

Bonjour journal,

Juste pour dire que la RC0 de X.org 6.9 (ainsi que son pendant modulaire, j'ai nomme 7.0) est sortie :
http://xorg.freedesktop.org/X11R6.9-RC0(...)
http://xorg.freedesktop.org/X11R7.0-RC0(...)
D'ailleurs cette "nouvelle" n'est pas tres fraiche[1], puisque cela date de debut Aout.
Il est a noter aussi que Debian est sur le point d'integrer cette version, en tout cas David Nusinow y travaille [2]...

Et puis aussi amarok 1.3 :
http://amarok.kde.org(...)
Une rapide traduction du changelog du site :

# Recherche d'informations a propos des artistes sur Wikipedia
# Barre de controle repensee
# Integration de KNewStuff : telechargement automatise de scripts et de themes
# Integration du moteur de HelixPlayer.
# Nouveau brouteur de playlist.
# Support des fichiers Cue
# Ajout du mode de playlist "Dynamic" (gnii? kesse-ke-ce?)
# Support de la base de donnees PostgreSQL.
# Amelioration de l'interface DCOP pour les scripts
# Ajouts de visualiseurs de spectre [dans la fenetre playlist]
# Support Podcast.


Voila qui devrait occuper ce long week-end du 15 Aout...

[1] http://www.livejournal.com/users/gravityboy/17763.html(...)
[2] http://www.livejournal.com/users/gravityboy/18138.html(...)

> Lire le journal (11 commentaires, moyenne: 5,4).

En ces temps de glandouille et d'oisiveté, il est très dur d'occuper ses matinées (par définition très courtes en vacances) et après-midis.

Voilà pour toi cher public : Lemmings sur le web dans ton navigateur favori !

http://193.151.73.87/games/lemmings/(...)

Et en bonus pour les amoureux des Lemmings et des Legos, une petite vidéo :
http://www.uni-koblenz.de/~soma/lego_lemmings.avi(...)

> Lire le journal (11 commentaires, moyenne: 3).

Salut journal,

Juste pour te dire que X.Org dans Debian, ça arrive[1] ! (à point pour qui sait attendre :P )
Pour des problèmes d'upload (ou téléversement/télé-envoiement-de-fichiers-sur-un-serveur-distant/.../) les .debs ne sont pas sur le repository officiel. D'autant plus qu'avec le prochain déménagement des ftp-master, la situation aurait pu être inextricable voire instable (oui... je brode un peu).

Donc ça se passe ici :
deb http://people.debian.org/~dnusinow/xorg(...) ./

Par contre, il faut bien dire que ces paquets devraient être uppés dans experimental (avant d'être reversés dans unstable) : à bon entendeur...
Un debianneux averti en vaut 2.

[1] : http://www.livejournal.com/users/gravityboy/14794.html(...)

> Lire le journal (23 commentaires, moyenne: 2,5).

Je n'ai pas vu de journal dessus, alors je m'y colle...
Donc voilà la Knoppix 3.9 est sortie[1,2] le 2 juin.

Au menu :
- Kernel 2.6.11.10
- KDE 3.4 (packagé grâce à Alioth[3])
- OpenOffice 2.0 BETA (seulement en anglais et allemand)
- synchronisation avec les paquets de Sid
- mise à jour des paquets spécifiques à Knoppix
- sans doute d'autres choses (mais pas de X.org)...

A noter que ce sera sans doute la dernière Knoppix distribuée sous cette forme.
En effet, il semblerait que la prochaine (la 4.0) devrait être distribuée sous une forme "Light" (un simple CD) et sous une forme "Maxi" (un gros DVD qui devrait inclure les paquets de développement).

Voilà.

[1] : http://www.knoppix.org(...)
[2] : http://knoppix-fr.org/index.php(...)
[3] : http://alioth.debian.org(...)

> Lire le journal (10 commentaires, moyenne: 4,9).

Vu sur NewsForge[1].

Le projet GPLFlash[2] reprend du poil de la bête et attend ses nouveaux développeurs de pied ferme !
En effet, lorsque Macromedia avait distribué un binaire pour GNU/Linux sur les architectures 32-bits, cela avait ralenti le développement (doux euphémisme) de GPLFlash.

Cependant, avec l'identification par la FSF[3] d'avoir un équivalent libre de la technologie Flash comme une nécessité pour la communauté, on peut en effet espérer que des développeurs vont s'y intéresser (en tout cas, maintenant le projet est plus visible : je n'en avais encore jamais entendu parler jusqu'à aujourd'hui !!).

D'ailleurs, GPLFlash2 est lancé et devrait à terme permettre de lire les "vidéos" Flash-6 et -7...

Que du bon en perspective !

[1] : http://software.newsforge.com/software/05/05/24/1754207.shtml?tid=1(...)
[2] : http://gplflash.sourceforge.net/(...)
[3] : http://www.fsf.org/news/free-java-and-flash.html(...)

> Lire le journal (7 commentaires, moyenne: 3,4).

Ayé, il est sorti[1]...
Au programme, quelques (!) corrections de bogues[2] et la disponibilité de Klax[3] le live-cd de KDE.

A noter la correction d'une fuite de mémoire lors de la réouverture de PDFs dans KPDF (c'était assez énervant, en effet...)

Voilà, pas grand chose d'autre à dire : KDE poursuit son petit bonhomme de chemin.

[1] : http://www.kde.org/announcements/announce-3.4.1.php(...)
[2] : http://www.kde.org/announcements/changelogs/changelog3_4to3_4_1.php(...)
[3] : http://ktown.kde.org/~binner/klax(...)

> Lire le journal (19 commentaires, moyenne: 2,8).

La prochaine release de X.org sera modulaire[1,2,3].
En fait on aura 2 releases pour le prix d'une : la 6.9, qui sera toujours sous la forme que l'on connaît (à savoir un bon gros arbre monolithique) et la 7.0 qui devrait avoir exactement le même contenu que la 6.9, mais qui aura l'attrayante propriété d'être allée faire un tour chez nos "amis" autotools.

C'est en effet ce qu'il y a dans les cartons de X.org pour réaliser la transition.
On ne va pas rappeler (tous) les avantages d'une modularisation (barrière plus basse pour les nouveaux arrivants, possibilité de ne travailler que sur un tout petit morceau du code sans gêner trop de monde et sans avoir à connaître trop du reste du monde,...) mais il est aussi intéressant de connaître tous les désavantages.
La plupart des développeurs X.org sont bien habitués à Imake et pour eux la transition va sans doute être un peu douloureuse (en fait comme toute transition, hein). Il fallait donc attendre (ou être sûr) qu'il y aurait assez de devs maîtrisant suffisamment les 2 (Imake+autotools).
De plus, et au début tout du moins, certaines architectures seront mises de côté lors de la transition s'il n'y a pas assez (ou pas du tout) de développeurs pour assurer la transition (et réaliser les changements nécessaires).
Enfin, il faut bien voir que les autotools sont extrêmement "version dépendants" et que certaines plateformes n'auront pas *la* version qu'il faut... Sans parler des dépendances cachées qui peuvent être introduites lors de l'autodétection (pendant le ./configure) quand le gentil développeur (GD) vérifie que tout compile (et tourne) comme prévu. (Leur stratégie pour contrer cela, c'est de spécifier très exactement les dépendances dans le build-script... Moi je leur conseillerais bien CMT[4] à la place :)

Apparemment, il y a eu une vraie démarche qualité la-dessus, ou en tout cas une vraie réflexion et un vrai travail préparatoire. La casse devrait donc être très limitée.

Pour finir sur les développements, j'ai découvert qu'il semblerait que les gens bossent sur un hotplug pour X11[5] : c'est pas la classe ça ?!

A noter que le dernier snapshot en date est labellé "xorg-x11-6.8.99.7" :
Bye-bye 6.8 !
Hello 6.9/7.0 !!

[1] : http://wiki.x.org/wiki/ModularizationWorkingGroup(...)
[2] : http://wiki.x.org/wiki/ModularizationProposal(...)
[3] : http://wiki.x.org/wiki/ModularizationDevelPlan(...)
[4] : http://www.cmtsite.org(...)
[5] : http://wiki.x.org/wiki/XInputHotplug(...)

PS: non, je n'ai pas trouvé de date de sortie... Même s'il est à peu près sûr qu'il y aura une 6.8.3...

> Lire le journal (11 commentaires, moyenne: 3).

Sur KernelTrap[1], on fait état d'une nouvelle avancée du développement de GNU/Hurd et plus particulièrement de son "portage" sur L4.

Apparemment, Neal Walfield n'a pas chômé puisque maintenant le coeur du gestionnaire de mémoire virtuelle est terminé.
La prochaine étape est donc d'écrire les interfaces d'entrée/sortie entre les "clients" et les systèmes de fichiers.
On pourrait donc voir venir très prochainement un pilote IDE :)

[1] : http://kerneltrap.org/node/5123(...)

> Lire le journal (8 commentaires, moyenne: 3).

Je moulais nonchalamment sur mon petit aKregator, lorsque je suis tombé sur un article de KernelTrap[1].
Cela a immédiatement attiré mon attention, surtout après le magnifique troll de première page d'il y a quelques temps sur le processus qualité dans le logiciel libre.

Donc voilà de quoi il est question : un nouveau projet a été mis en place sur SourceForge : kerncomp[2]
Il a pour but de détecter les défauts dans les configurations par défaut de différents noyaux, appliquer divers patchs et afficher les résultats de la compilation et enfin ceux de la simulation[3] du démarrage de ce noyau tout frais.

Ce projet a débuté grâce aux gens de Gelato[4] pour tester les compil's pour IA64.

Pour résumer (et pour paraphraser un commentaire posté sur KernelTrap), c'est TinderBox[5] pour le kernel.

Voilà : avis aux amateurs...

[1] : http://kerneltrap.org/node/5112(...)
[2] : http://kerncomp.sourceforge.net(...)
[3] : http://www.gelato.unsw.edu.au/kerncomp(...)
[4] : http://www.gelato.unsw.edu.au/(...)
[5] : http://www.mozilla.org/projects/tinderbox/(...)

> Lire le journal (3 commentaires, moyenne: 2).

En lisant LWN.net[1], je suis tombé sur la road-map de la prochaine Ubuntu[2]. Enfin plus exactement, ce qu'ils aimeraient bien mettre dedans...
C'est assez fourni dites donc :
- gcc-4 + LSB3.0 + glibc-2.3.5 [3]
- zeroconf
- bluetooth
- meilleure auto-configuration de X.org
- de la VoIP (en utilisant shtoom: marrant comme nom)
- Xen (ils ne disent pas quelle version)
- Migrer un max de services/programmes depuis le kernel en user space : EarlyUserspace[4]

A noter une "LaptopMission"[5] : pour que les portables IBM, Toshiba, Dell et HP "just work" avec Ubuntu.

Et pour finir un petit mot sur les plans pour Kubuntu[6]. Là aussi, du boulot en perspective...
Déjà arriver à compiler KDE avec gcc-4, ça va sûrement nécessiter un soupçon de lignes de code.
Ils veulent aussi améliorer les outils de configuration (genre Kynaptic et Kapture) et toujours coller au plus près du SVN de KDE (comprendre avoir toujours la version la plus stable et la plus récente : KDE 3.4.x si pas de version 3.5 prête pour la sortie).

Tout ça pour Octobre 2005...
S'ils arrivent à faire tout ça et qu'ils en remontent une grande partie vers Sid, on devrait pouvoir faire chauffer l'apt-get.

[1] LWN.net http://lwn.net/Articles/135432/(...)
[2] RoadMap http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals(...)
[3] Toolchain http://udu.wiki.ubuntu.com/ToolchainRoadmap(...)
[4] EarlyUserspace http://udu.wiki.ubuntu.com/EarlyUserspace(...)
[5] LaptopMission http://udu.wiki.ubuntu.com/LaptopMission(...)
[6] http://udu.wiki.ubuntu.com/KubuntuRoadmap(...)
[7] shtoom http://divmod.org/projects/shtoom(...)

> Lire le journal (32 commentaires, moyenne: 3,9).

Vu sur KernelTrap[1] : une interview avec Marcus Brinkmann, le mossieur de Hurd/L4.
On y apprend (traduction de l'introduction sur KernelTrap) :

Marcus Brinkmann est un developpeur des projets GNU/Hurd et Hurd/L4 (qui visent a creer un micro-noyau, une alternative au noyau monolithique Linux). Il a recemment ecrit le code permettant pour la premiere fois l'execution de programmes sous Hurd/L4.
Dans cette nouvelle interview[2,3], il repond aux questions sur l'architecture du Hurd, le support des pilotes, la securite, les performances des micro-noyaux et bien d'autres festivites.
Il donne egalement son avis sur la philosophie du libre ainsi que sur les brevets logiciels. On apprend de plus comment il a appris a programmer sur un Commodore 64 lorsqu'il etait a l'ecole primaire [NdT: et ben, si ca c'est pas du geek :P]
Pour finir, il explique comment les developpeurs experimentes peuvent aider le projet Hurd sans oublier de donner quelques pistes a propos du futur du Hurd, qui semble tres prometteur apres ces nouveaux developpements [NdT:passage a L4].


L'interview est assez longue mais vraiment tres interessante.

[1] http://kerneltrap.org/taxonomy/term/59(...)
[2] http://portal.wikinerds.org/brinkmann-interview-mar2005(...)
[3] http://portal.wikinerds.org/files/brinkmann-interview-mar2005.pdf(...)

PS : le correcteur ne connait pas "Hurd" ;)

> Lire le journal (4 commentaires, moyenne: 5).

Ca y est, Xorg le sheriff de l'espace est reviendu.
Cette fois en version 6.8.2.

Toujours pas de schedule pour un eventuel R7.

http://wiki.x.org/wiki/XorgReleasePlan(...)
http://wiki.x.org/wiki/X11R682ReleasePlan(...)
http://x.org/X11R6.8.2(...)

> Lire le journal (10 commentaires, moyenne: 4,4).

Salut journal,

Je sais qu'on est sur LinuxFr mais je voudrais quand même savoir un peu ce que c'est le Hurd, quels sont ses avantages, ses inconvénients, que mange-t-il a midi, s'il a eu une enfance difficile... Bref je veux tout savoir.
Pourquoi ? Parce que j'ai lu ça : http://linuxfr.org/comments/517501.html#517501(...) et je dois dire que ça m'a assez enthousiasmé... Donc j'ai commencé a RTFMer un peu. Et je vais donc te livrer mes pensées et remarques.

J'ai commencé mon périple sur HurdFr.org [1] et cette page [2] a attiré mon attention, plusieurs points essentiels sont expliqués. Bon c'est bien mais pour avoir une vision plus synthétique, je suis allé faire un tour sur Wikipedia [3,4,5] où j'ai appris les différences entre micro-noyaux, noyaux monolithiques et autres exo-kernels.

Ensuite je suis tombé sur L4[6], Pistachio[7], Fiasco[8] et L4Linux[9].
Et c'est là que j'ai décroché... Quelles sont les différences ? Leur performances ? Leur (possible) avenir ?

Mais avant qu'un bonne âme n'éclaire ma lanterne, il faut que je pose une question : moyennant les baisses de performances qui a priori devraient apparaître avec l'utilisation d'un micro-noyau, pourquoi est-ce que l'utilisation d'un L4Linux qui (si j'ai bien compris) permet de faire tourner un Linux sur un noyau L4, n'est pas plus répandu ?
Avec toutes les capacités promises par Hurd... Ça me fait une sorte de fussoir de voir tout ce potentiel inexploité !

Pour finir, je me demande si l'avenir de Linux n'est pas le Hurd. Je m'explique : il me semble que le modèle de développement de Hurd est plus robuste que celui de Linux. Je crois sincèrement que celui de Linux commence à atteindre ses limites (en tout cas je pense qu'il n'est pas trivialement scalable). De plus, j'aime bien l'idée d'avoir un noyau en C++ (L4), mais c'est vraiment parce que j'ai un a priori favorable pour ce langage (note à ceux qui sont en train de sortir leur appeau à troll sur les langages de progs : je ne dénigre, ni ne fais l'apologie d'un langage en particulier, je dis juste que c'est ma préférence personnelle... Ensuite savoir si c'est le choix le plus judicieux pour un noyau... )

Bon je te laisse journal, je vais essayer de m'installer une Debian GNU/Hurd (m'en fous qu'il n'y ait pas de son sur mon serveur perso :P )


Hurd me voilà !


[1] HurdFr : http://www.hurdfr.org(...)
[2] Doc : http://www.hurdfr.org/index.php?page=pages/doc/strategie(...)
[3] Wikipedia En : http://en.wikipedia.org/wiki/Hurd(...)
[4] Wikipedia En : http://en.wikipedia.org/wiki/Microkernel(...)
[5] Wikipedia Fr :http://fr.wikipedia.org/wiki/Hurd(...)
[6] L4 : http://os.inf.tu-dresden.de/L4/(...)
[7] Pistachio : http://l4ka.org/projects/pistachio(...)
[8] Fiasco : http://os.inf.tu-dresden.de/fiasco(...)
[9] L4Linux : http://os.inf.tu-dresden.de/L4/LinuxOnL4(...)

> Lire le journal (65 commentaires, moyenne: 3,2).

Salut journal,

L'autre jour, j'ai commencé à regarder un peu ce que pouvait faire KDevelop.
Je trouve que c'est très bô, bien pensé et tout et tout. Mais un gros reproche tout de même (enfin, pas imputable directement à KDevelop) : y'a pas de look and feel à la (x)emacs (enfin faut dire que le look est pas très important ;).

Je sais (enfin j'ai cru comprendre) que pour çà, il fallait implémenter un KPart pour emacs...
Y a-t-il des gens au courant d'un tel projet ?
Après une rapide discussion avec mon ami google, j'ai vu des mails[1,2] qui dataient un peu (2002) et qui parlaient de faire d'abord un port QT, mais depuis rien...

Des infos, quelqu'un ?

[1] http://list-archive.xemacs.org/xemacs-beta/200205/msg00188.html(...)
[2] http://list-archive.xemacs.org/xemacs-beta/200205/msg00192.html(...)

> Lire le journal (0 commentaire).

Dans le KDE-CVS digest d'hier [1], il y avait une intéressante rétrospective (voire un résumé) de ce qui s'est passé et (presque) décidé a la (star)aKademy (*) concernant le futur du serveur de son de KDE.

Lors de la news sur l'aKademy, le problème du son sous KDE avait été évoque. Votre dévoué serviteur avait d'ailleurs demandé quelques explications[2].

D'ailleurs l'aKademy m'avait permis de découvrir d'autres serveurs [de son,multimédias] que, en vrac, GStreamer[3] ou aRts : MAS[4] et NMM[5].

Je m'étais alors demandé quelles seraient les orientations prises dans le futur.
A priori, le remplaçant le plus avancé pour aRts (et donc celui qui serait logiquement choisi) est GStreamer.
Le seul problème est qu'il y a deux problèmes :)
- il est (quoi qu'on en dise) plutôt orienté GNOME (et ça hérisse un peu les devs de KDE, enfin c'est mon sentiment)
- il repose sur la glib, et du coup il faut des wrappers et autres bindings C++ pour le manipuler depuis KDE (c'est ma compréhension de tout cela, et j'atteins rapidement mon niveau d'incompétence)

La seule conclusion sûre : on savait ce qu'il n'y aurait pas dans KDE 4 (aRts) mais pas ce qu'il y aurait.

D'après les liens qui sont donnés dans le CVS-Digest, il semblerait que celui qui obtiendrait le plus de faveurs serait NMM.
Mais MAS n'a pas dit son dernier mot et il a des arguments de poids : principalement, il est 'supporté' par X.org [6]
Par contre : pas de module ALSA (bigre!) et pas de support d'OGG (re-bigre!).
Note : au contraire de ce que dit CVS-Digest : il y a bien un repository CVS accessible par le commun des mortels.

Personnellement, je suis assez fan de NMM. C'est du beau C++, il y a moyen de se faire plaisir avec tous les outils a disposition, même pour le programmeur du dimanche que je suis (ex: CVSWeb, Doxygen, de la doc en veux-tu en voila,... )

Bon ce n'est que mon avis, mais s'il y a des gens plus éclairés dans la salle, je suis preneur.

PS : un thread[7] intéressant sur une comparaison entre les différents protagonistes

(*) : C'était trop tentant, désolé :P

[1] : http://cvs-digest.org/index.php?newissue=sep242004(...)
[2] : http://linuxfr.org/comments/463964.html#463964(...)
[3] : http://gstreamer.freedesktop.org(...)
[4] : http://www.networkmultimedia.org(...)
[5] : http://www.mediaapplicationserver.net(...)
[6] : http://www.x.org(...)
[7] : http://www.mediaapplicationserver.net/public-mhonarc/mas-devel/msg0(...)

> Lire le journal (12 commentaires, moyenne: 3,4).

Vu sur la mailing liste debian-news[1].
On en avait parlé récemment sur linuxFR[2], mais apparemment ça se confirme : cdrecord est sur la mauvaise pente.

Jose Carlos Garcia Sogo noticed[3] that Jörg Schilling has added a non-modification clause to a file within the cdrecord[4] distribution which renders the package non-free since this is in direct conflict[5] with the GNU General Public License[6].

Que cdrecord soit mis dans non-free ne m'aurait pas trop inquiété (pour cdrecord, j'entends), il y a bien mozilla qui devrait y faire un tour si je ne m'abuse, mais que la license de cdrecord entre en conflit avec la GPL, et là c'est une toute autre histoire : d'ailleurs certains prétendants pointent le bout de leur nez[7].

Une nouvelle saga à la XFree/X.org ?


[1] http://lists.debian.org/debian-news/debian-news-2004/msg00038.html(...) : l'annonce sur debian-news
[2] http://linuxfr.org/comments/460188.html#460188(...) : on en parle sur linuxFR
[3] http://www.tribulaciones.org/blog/computers/software/cdrecord-licen(...) : le blog de Jose Carlos Garcia Sogo
[4] http://packages.debian.org/cdrecord(...)
[5] http://weblogs.mozillazine.org/gerv/archives/006193.html(...)
[6] http://www.gnu.org/copyleft/gpl.html(...)
[7] http://icculus.org/burn/(...)

> Lire le journal (15 commentaires, moyenne: 2,3).

Salut mon journal,

En octobre de cette année, le CERN (Centre Européen de Recherche Nucléaire [1]) va souffler sa 50ième bougie. Bon, c'est sans doute aussi excitant que de savoir que Tim Berners-Lee a été anobli par la reine [2,3], mais je pense que ça mérite d'être mentionné.
Alors je me suis amusé à faire une petite recherche de "CERN" sur linuxfr et d'après les divers résultats que j'ai eu il semblerait qu'on en parle seulement (ou principalement) lorsqu'un nouveau record de débit entre SLAC[4] et CERN est établi [5], ou alors lorsqu'il casse sa tirelire pour un 'petit' cluster[6,7].

Je trouve que c'est assez décevant.
Le CERN c'est bien sûr (et avant tout, enfin lorsqu'on est sur un site web) le berceau du web, c'est-à-dire du protocole http. Preuve s'il en fallait, que la recherche fondamentale en physique des particules sert réellement à quelque chose, même dans la vie de l'homme de la rue.
Mais c'est aussi un formidable réservoir de bibliothèques libres et de qualité. Un exemple : la CERNlib[8], écrite en FORTRAN77 et toujours très utilisée (bon ok, plus trop maintenant... mais quand même quoi).

Quelles sont à ton avis mon cher journal, les raisons pour lesquelles les bibliothèques et les applications développées par le CERN ne sont pas plus répandues, utilisées et encensées ?
J'ose avancer que c'est parce qu'elles ne sont pas connues.
M'aideras-tu, cher journal, à les faire reconnaître ?

Aller, première leçon : SEAL[9].
SEAL (Shared Environment for Applications at LHC) est un projet de l'IT du CERN, écrit en C++ qui fournit l'infra-structure logicielle, les fondations d'un environnement de travail ainsi que les bibliothèques et outils nécessaires à l'ensemble des expériences LHC (i.e.: les expériences de physique des particules).

Là, cher journal, tu te dis : "et alors? Qu'est-ce que j'en à *** ?!"
Et humblement je te répondrais : et http?

SEAL regroupe en fait 5 grands axes de développement :
o Foundation Libraries : abstraction et isolation du système, outils de compression, entrée/sortie, ...
o Math Libraries : une bibliothèque mathématique pour la régression linéaire, définition ds fonctions trigo, ajustement de données, algorithmie (FFT, equa.diffs. interpolation...)
o Dictionary : sans doute le truc le plus intéressant, cela permet d'augmenter les capacités (limitées) du C++ d'introspection, de reflection : en gros du RTTI (Run time type information). De plus grâce au projet LCGdict, on peut créer (relativement) aisément des bindings python de classes C++.
o Framework : une implémentation d'un système de plugins (pardon, de greffons)
o Scripting Services : un ensemble de bindings python vers différentes bibliothèques et services. Un truc à surveiller : PyBus, qui expérimente python comme l'équivalent logiciel d'un bus hardware (des spécialistes dans la salle?)

Voilà cher journal, t'ai-je seulement donné envie d'y jeter un coup d'oeil ?
Et si je te dis que tout ceci est distribué sous GPL ? Ahah, je le savais :)

PS: au fait tu l'auras peut-être compris cher journal, mais je bosse un peu dans le monde de la physique des particules, et au vu des différentes maladresses et approximations que j'ai pu faire, je ne suis pas informaticien :)

Les références :
[1] : http://public.web.cern.ch/public(...)
[2] : http://linuxfr.org/~crevetor/14607.html(...)
[3] : http://www.theinquirer.net/?article=17259(...)
[4] : http://www.slac.stanford.edu(...)
[5] : http://linuxfr.org/2003/10/17/14298.html(...)
[6] : http://linuxfr.org/2003/02/26/11506.html(...)
[7] : http://linuxfr.org/2003/04/14/12075.html(...)
[8] : http://wwwasd.web.cern.ch/wwwasd/cernlib/(...)
[9] : http://seal.web.cern.ch/seal(...)

> Lire le journal (3 commentaires, moyenne: 1,3).

Bonjour cher journal,

Je voulais savoir si par hasard tu connaissais CMT.
Je ne te cache pas que, moi, je le trouve vraiment sexy !
A quoi çà sert me diras-tu, toujours si prompt à me poser des questions si à propos :)

Et bien il ne fait pas le café mais te permets d'en économiser des tasses et des tasses : il relègue le makefile que tu confectionnes d'habitude amoureusement et pendant de longues heures, au rang des antiquités.

Il te permet, cher journal, de gérer les dépendances entre différents packages d'un projet, les visualiser graphiquement,...
Il est interfacé à CVS, permet de générer de la documentation doxygen, lancer des tests de régression, faire de la compilation en parallèle....

Voilà cher journal, je voulais te faire découvrir cet outil.
Il est vrai que je n'en connais pas d'autre... Mais comme c'est développé avec les neuros du contribuable, il me semble normal d'en faire profiter.
A noter qu'il est distribué sous CeCILL.

Un autre gros avantage : sa nécessaire pérennité, et l'assurance qu'il soit maintenu au moins pendant 10 ans (temps pendant lequel les expériences de physique des particules au CERN [1] prendront des données).

[1] : http://public.web.cern.ch/public(...)

> Lire le journal (1 commentaire, moyenne: 2).