Sebastien a écrit 537 commentaires

- une boîte mystère se cache derrière tout ça
J'ai trouve : s'il y a une surprise a l'interieur alors c'est forcement un Kinder Surprise :P

Et comme tout bon prof de maths il se plaçait dans un cadre mathématique solide et consistent et pouvait dire que si on a à notre disposition assez de temps pour regarder si la craie monte au plafond, un temps au minimum infini, alors on pourra voir la craie monter au plafond.

Mais pour cela, il faut quelqu'un qui ait du temps (un fonctionnaire ?;), et il faut un temps infini.
Pour la première hypothèse, on peut trouver quelqu'un (si c'est bien payé).
La deuxième est nettement plus hasardeuse : qui peut m'affirmer/me-démontrer dans la salle que l'univers est éternel ? :P

Ca dépend de la définition de la probabilité que tu utilises (à savoir : fréquentiste ou bayesienne ?).

Un fréquentiste te diras qu'un événement de probabilité 0, aura une fréquence d'apparition de 0 sur 100 tirages (ensuite il y a le problème de savoir l'erreur sur cette affirmation).

Un Bayésien te donne juste sa confiance en le fait que tel ou tel évènement se produise.

Donc à mon avis pour ce genre d'évènement (un muon cosmique qui traverse un transistor, communique la bonne énergie au bon electron pour le faire sauter de niveau d'énergie au "bon" moment) qui est somme toute assez rare (à l'abri de notre bonne vieille atmosphère, et assez loin de toute source de radiations), il vaut mieux accompagner toute probabilité d'une bonne dose de "niveau de confiance" que l'on veut bien lui associer.

Voilà, c'était juste la petite minute de quadri-pilo-sectomie...

Les serveurs jabber perdent en stabilité quand les conditions se dégradent.
...
Pour certains fournisseurs je n'ai aucun espoir, ils sont trop occupés à promouvoir leurs propres systèmes de chat, même si ils utilisent les bases de jabber ...

Ca n'a sans doute rien a voir avec la choucroute, mais j'ai vu recemment que jabber etait utilise dans une floppee de softs autour du middleware pour la Grille : LCG[1], ou Grid3[2] d'ailleurs.

[1] http://lcg.web.cern.ch/LCG(...)
[2] http://www.ivdgl.org/grid2003(...)
[3] WindMill http://www-hep.uta.edu/windmill(...)
[4] Capone http://grid.uchicago.edu/capone(...)

Je ne peux que me dire que ca va servir a ameliorer la stabilite des serveurs in fine.

Ca me fait penser...
C'en est ou de la migration officielle ?
J'avais cru comprendre qu'il ne fallait pas compter sur un X.org dans Debian avant la sortie de Sarge (qui a dit c'est pas pour demain ?!?)...

Quelqu'un aurait de plus amples informations ?
Je suppose que maintenant que le 'packaging' a ete fait par Ubuntu, ca devrait peut-etre faciliter-la-vie/forcer-la-main aux devs de la Debian X-strike force [1]

D'ailleurs, en googlant un peu j'ai vu que le dernier commit relatif à xorg/debian remontait quand meme au 7 octobre[2].

[1] : http://necrotic.deadbeast.net/xsf/XFree86/NEWS.xhtml(...)
[2] : http://lists.debian.org/debian-x/2004/10/index.html(...)

Il y aurait aussi 2-3 trucs intéressants sur les CVS-digests qui résumaient ce qui s'était dit lors de l'aKademy d'août 2004.

NMM : http://cvs-digest.org/index.php?issue=oct12004(...)
MAS : http://cvs-digest.org/index.php?issue=sep242004(...)
GStreamer : http://cvs-digest.org/index.php?issue=oct152004(...)

Bonne lecture.

PS: et puis peut-etre ca aussi :
https://linuxfr.org/~bins/15448.html(...)

Première fois en java, merci netbeans et eclipse qui marchent très bien avec une superbe complétion. Au final, il m'aura fallu 6-7 heures de programmation pour comprendre le code existant [...]

Moi je rajouterais quand meme aussi : merci le forum de linuxfr :P
Il faut rendre a cesar, etc...

https://linuxfr.org/forums/18/4875.html(...)

Ok, merci pour tes renseignements.
Le probleme du compilateur ne se pose pas vraiment (gcc3.2 et on devrait passer le tout a 3.2.3 pour le support de SLC3[1]).

Donc ca me conforte dans mon idee. Je vais cependant jeter un petit coup d'oeil a libsigc++.

Grand merci.

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

Ok, je vois (et comprends) ton point de vue.
Ca se defend (d'ailleurs tu le fais ;)
Personnellement, je trouve l'aspect viral tres interessant. Il protege les developpeurs et la communaute du libre.

Si on bloque certaines actions, ça supprime simplement des libertés, non ?
Bien sur dit comme ca... Mais, il me semble que la liberte de tous s'arrete a la liberte des autres (reformulation libre d'une phrase que quelqu'un a surement mieux dite avant moi).

En fait, ce que je n'aime pas c'est que pour beaucoup libre = gpl alors que c'est fau[x].
Tout a fait d'accord avec toi.

...mais je pense que c[e] n'est pas une solution réellement viable...
Je pense au contraire qu'elle est tout a fait viable dans un "bise-nesse modele" du tertiaire ou d'une societe de services.

Mais je ne vais pas me crisper. Ce qui m'avait juste fait tiquer c'etait le 'pas totalement libre'.

mais elle n'est pas totalement libre
Gnii ?
Tu peux developper s'il te plait ?

http://oumph.free.fr/textes/logiciels_libres_isima_20041014.pdf(...)

Je connaissais pas cette kernel map. C'est vraiment zoooli.
Ca me fait un peu penser a un truc pour les petits nenfants :

Ou est Charly/Tux ? (Indice, regarde au centre pauvre moule ;)

En fait ce qu'il manque c'est qu'il soit complétement en user-space.
Et ca c'est plus ou moins réalisé par usplash (le "bootsplash" d'Ubuntu).

Dans la mailing-list debian-desktop, ils ont en parlé. Ils avaient commencé à développer leur debsplash (qui est pret, mais pas encore public), basé sur fbsplash. Mais comme je le disais plus haut, le gros probleme (d'après ce que j'ai compris) c'est que (pratiquement?) tout se passe en kernel-land (ou disneyland, je sais plus, c'est l'un des dux). Donc il y aurait toujours un problème d'intégration à chaque nouvelle version, du noyau, et, je suppose, du [deb-fb-boot]splash.

A priori, la meilleure méthode pour avoir un joli démarrage graphique, c'est de contribuer à usplash :
http://www.ubuntulinux.org/wiki/WartyWarthogUsplash(...)

Et c'est normal puisqu'il y a mieux : CMT
http://www.cmtsite.org(...)

L'url ca doit plutot etre ca :)
http://www.icefox.net/kde/tests/report.html(...)

Mais c'est vrai que ca a l'air interessant.
Dans le soft sur lequel je bosse, il est recommande dans les regles de programmation de toujours soumettre dans le package dont on est l'auteur un petit test des classes et algorithmes developpes. Ainsi, a chaque build de la release (et aussi pour chaque nightly) on a les resultats des differents tests.
Ca utilise du CppUnit et aussi 2-3 scripts python pour les tests RunTime...

Ben je dirais qu'il y a certainement deja quelques outils (generiques) qui existent deja, genre valgrind et kcachegrind.

Il me semble d'ailleurs que Linus en (les problemes sus-evoques) est conscient, et qu'il est justement en train de bosser sur un outil de verification de code (il me semble cependant que c'est assez Linux-oriente).

Je souhaite autant de longévité au noyau Linux que Fortran77 dans le monde scientifique, mais il faut bien se rendre à l'évidence que le C ne sera pas toujours la panacée.
Il faut bien se rendre à l'évidence qu'un jour ou l'autre un langage (objet ou pas, mais je pense que la prochaine génération sera objet) détrônera le C. Même pour écrire un noyau. Et le plus tôt Linux aura amorcé sa conversion/migration ou en tout cas "l'infrastructure" la permettant, mieux ce sera.

if ( "Soyons fou" == mode ) {
Ce qui serait classe c'est que pour chaque bout de code du noyau, il y ait une compétition "génétique" darwinienne entre plusieurs algos écrits en différents langages. On aurait alors les meilleurs des meilleurs des meilleurs (citation tirée (et adaptée) de : "Clerks, employés modèles" ).
}//! end "Soyons fous"

C'est pour çà qu'à mon avis dire "le C y a pas mieux pour les noyaux" et se cantonner à cette vision étriquée et statique, c'est faire preuve d'un manque total d'anticipation et de recul sur l'Histoire du code au travers des ages ;)

Bien sûr, Linux n'est pas une fin en soit, et peut-être que dans 10 ans un nouveau noyau libre codé dans un langage de la mort qui tue les mamans ours par brouettes entières le supplantera. Mais si Linux veut vivre jusque là, il me semble nécessaire qu'il y ait aussi de l'innovation au niveau du langage utilisé pour le coder.

En conclusion, il est bien sûr évident que cette querelle du C VS C++ est stérile puisqu'elle s'apparente à la séculaire bataille des Anciens contre les Nouveaux (cf les cours de phranssais de 1ère) dont les philosophes des Lumières ont la paternité (en (très très) gros, déjà à leur époque ils disaient : la jeunesse fout le camps, ce sont tous des cons, et leurs enfants disaient la même chose d'eux :). Il ne faut donc pas épiloguer plus que de raison.

LCG, un outil qui facilite la gestion de la Gentoo

C'est marrant, LCG, moi je croyais que ca voulait dire LHC Computing Grid [1]
[1] http://lcg.web.cern.ch/LCG(...)

Ma contribution principale restant les 18 mois que j'ai passé à contribuer à KDevelop.


Parfait, un KDevelop-gourou doublé d'un connaisseur en emacs (impressionnante liste de petites extentions au passage)...
Moi je commence à me tater pour *essayer* d'implémenter un mode d'édition à la emacs pour KDevelop.
Du haut de ton expertise, qu'elle serait à ton avis la meilleure stratégie : définir quelques KParts pour Kate/KDevelop (j'entends par là, utiliser Kate tout en surchargeant quelques unes de ses fonctionnalités pour qu'elles ressemblent à celles d'emacs) ou bien carrément essayer de faire un emacs-Qt (tâche monstrueuse s'il en est)?

Bah, c'est quand meme rapide le python. Et puis avec un peu de profiling, on peut détecter les parties les plus lentes et les réimplémenter en C[1].

Et comme ils le disent dans l'intro/FAQ :

In its current implementation, Python's execution is not nearly as fast as most languages traditionally used in OS development. However, this is a problem of the implementation, not the language itself. The decision to use Python was actually made after considering the creation of a new language to address frustrations with existing languages. Thus, developing a faster Python implementation remains a future goal of Unununium.

Unununium is not alone in the quest for a faster Python. Future implementations of the standard interpreter are planned to include more agressive optimization throughout. Psyco is a promising program which compiles Python bytecode to native code. Pyrex compiles a subset of Python to C.


Et puis il y a plein de projets visant à améliorer les performances de ce langage (ouvert et très réactif, tout comme les dévs, d'ailleurs).

[1] http://www.wag.caltech.edu/home/rpm/python_course/Lecture_5.htm(...)

Ben la prochaine génération hyper hype de la mort qui tue de noyaux complétement objet :
à savoir unununium [1].

Ou sinon, dans la plus pure tradition du noyau bien de chez nous : isaacos[2].

Mais pour une plus grande discussion philosophique pour occuper les grandes soirées d'hiver je m'efface devant [3] (attention, troll-inside).

[1] http://unununium.org(...)
[2] http://isaacos.loria.fr(...)
[3] http://linuxfr.org/~moqui/15652.html(...)

Et puis on ne devient pas développeur debian en claquant des doigts, ils ont meme quasiment trop de monde, et il faut se faire parrainer pour pouvoir entrer.


Trop de monde ?
Quel projet/distribution/etc peut se targuer d'avoir trop de monde ?
Se faire parrainer n'est pas une selection mais une aide pour le nouvel arrivant dans le monde du packaging debian.

J'ai entendu dire (a la conf de B.Sibaud [1]) que le documentaire sur les brevets logiciels (qui avaient ete maintes fois repousse et deprogramme) [2] devrait etre diffuse le 5 Novembre.

Quelqu'un pour con/infirmer ?

[1] http://linuxfr.org/2004/10/11/17397.html(...)
[2] http://linuxfr.org/~Titoxx69/15449.html(...)

Juste un lien[1] et une remarque : forum est ton ami.

[1] : http://linuxfr.org/forums/29(...)

Ca me fait penser : est-ce que quelqu'un a un[des] bon[s] tutorial[aux] pour gdb ?

Moi j'ai ca [1], mais si quelqu'un a mieux...

C'etait le moment "echange tes marque-ta-page", un moment offert par le W3C (mais rendu possible par le CERN).

[1] : http://www.dirac.org/linux/gdb/(...)

Ouais, c'est a cause du marasme economique, avant il avait droit a 100 balles et un Mars.