Sebastien a écrit 537 commentaires

codé par un mec de Kde

Un peu de respect quand même ;)
Ce gars là c'est Stephan Kulow, release manager de KDE...

Je crois qu'ils veulent le(s) remplacer par un truc à eux : unsermake[1].

Après une rapide lecture de la page, ce que j'en conclus c'est qu'ils veulent un peu plus rationaliser et factoriser le processus de compilation : regrouper les options de compilation dans un seul (gros?) Makefile.
Moins de Makefile disséminés un peu partout dans l'arborescence.

C'est quand même dommage de réinventer la roue avec unsermake : il y a déjà CMT[2] qui existe (quoi je ne vous ai pas encore parlé de CMT? Mais si regardez mes derniers journaux...) et qui est bien dimensionné pour les gros projets.

[1] http://www.kde.me.uk/index.php?page=unsermake(...)
[2] http://www.cmtsite.org(...)

Des packages sont déjà disponibles pour Gentoo, Arch Linux, SuSE RedHat... sinon il vous reste toujours l'option konstruct.


Et sous Debian il ne faut pas oublier les packages disponibles sur alioth :

deb http://pkg-kde.alioth.debian.org/kde-3.4.0/(...) ./

Je me suis laisse dire que ces paquets etaient maintenus par des devs de KDE donc bon, ca devrait etre relativement serieux (pas teste, pas taper).

On peut ruser en meme temps[1] :

deb http://pkg-kde.alioth.debian.org/kde-3.4.0/ ./

[1] http://dot.kde.org/1111015993/1111044421/1111050837

J'utilise en effet les noyaux pre-compiles, cette possibilite m'avait donc effleure :)
Je me suis meme demande si ce n'etait pas une "race condition" dans l'ordre des chemins donnes a hotplug pour charger le firmware (/lib/firmware, /usr/lib... etc...).

Apres un petit coup d'oeil aux sources (la premiere fois que je regardais les sources d'un module pour le noyau, et ben... je prefere pondre du C++ :P), j'en ai conclu que le probleme venait de l'appel a la fonction request_firmware (linux/firmware.h). J'ai arrete la mes investigations, sentant que j'atteignais rapidement mon niveau d'incompetences.

Je n'arrive plus a retrouver les liens vers les 2 pages qui m'ont fait dire que c'etait soit un bug d'udev/hotplug soit un probleme avec la taille (4K maintenant ?) des pages du noyau (bon la c'est clair, je suis arrive a mon niveau d'incompetence)...

Et bien comme je l'ai dit, ca marchait impec' pour moi aussi, jusqu'a recemment (28 Fevrier pour etre exact).

Apres l'apt-get de cette date la, le noyau ne reussit plus a charger le firmware du module a tous les coups (chose qu'il faisait avant).
Et comme lors de cet apt-get, la version du paquet ipw2100 n'a pas ete changee, c'est bien autre chose (comme je le laissai entendre dans mes pistes pour expliquer ce probleme ;)

Ou sinon l'installation du module s'est faite sans le moindre accroc pour moi aussi (et la configuration n'a guere ete plus ardue).

Ceci dit, avant d'essayer d'autres distributions dans un autre mode que "je regarde sous qemu", j'attendrais de voir ce que ca donne avec la nouvelle politique de releasing de Debian-etch.

Debian propose d'installer xorg au lieu de xfree86 à l'install ?
Mouahahaha :D

xorg sera dans Debian apres que Sarge soit sortie, et ce n'est pas un troll ou une autre vile parole acerbe. C'est comme ca.
La raison vient de la maniere dont les paquets descendent de version de Debian en version de Debian :

experimental-->SiD-->Testing(Sarge)-->Stable(Woody).

J'ai cru comprendre que si les gens s'amusaient a inserer des paquets x.org dans SiD, ils risqueraient de se retrouver dans Sarge, ce qui embeteraient un poil les gens de la Debian X-strike force qui s'occupent de la stabilisation des paquets xfree86 de Sarge depuis maintenant pas mal de temps. Un peu comme les gens (qui s'occupaient de la stabilisation de KDE 3.2) ont fait la gueule lorsque KDE 3.3 est arrive dans Sarge bon gres mal gres parce que ca avait ete insere dans SiD (disons qu'on leur a un peu force la main, meme si le Sarge release manager a tape du poing sur la table pour faire valider KDE 3.3 pour Sarge)...

J'espere que c'est clair... En me relisant, j'ai pas trop l'impression (la pertinence en jugera).

Ben moi ces derniers temps je suis un peu decu...

Je dois dire que j'etais content au debut d'avoir a mettre les mains dans le cambouis pour que ca marche.
Mais des fois... on aimerait bien que ca "juste marche".

Il faut dire aussi que mon "serveur" (comprendre la machine qui a la connection ADSL) etait sous SID, et apres divers petits problemes avec (au choix, dans le desordre et pas forcement un seul a la fois) hotplug, udev et mon modem speedtouch usb (houuu qu'elle est jolie ma raie manta verte) je suis viendu sous testing.

Ensuite, avec mon portable sous SiD, j'ai jamais eu trop de problemes. Sauf recemment, mon module ipw2100 (wireless centrino) qui se monte 1 fois sur 2,3,4... (j'ai cru comprendre que c'etait ou bien une interference avec la taille des pages 4K ou bien un bug udev).
La c'est quand meme un peu plus enervant. (Et je tiens a dire que rien ne me fera passer sous Ubuntu/Gnome, mais que j'attends une Tubunktu ;) stable).

Pour resumer, je ne renie pas mon experience de Debianiste. J'ai appris beaucoup de choses avec et grace a Debian.
Mais je (et ca n'engage que moi) trouve que sur le long terme, une SiD, c'est relativement usant.
Apres, c'est aussi de ma faute, hein (utilise testing/stable, une autre distrib)... Et sans doute qu'avec plus de dexterite ou de connaissances je pourrais resoudre tous les problemes en 1 clin d'oeil.

En fait mon gros probleme, c'est que je suis atteint (depuis tout petit deja) de versionnite aigue : je ne peux pas me coucher avant d'avoir fait mon petit aptitude update && aptitude dist-upgrade :P

Voila, mes 2cts.

Ben je crois qu'il faudrait augmenter la taille autorisee pour le coredump :
ulimit -c unlimited

(ma vie: l'appli sur laquelle je travaille peut me pondre des fois des cores de 50Mo voire plus, donc bon... Ton ulimit me semble un peu limite ;)

T'as qu'a les mettre sur l'afs de l'in2p3 :)

[ eh! copaiiin de la Chouffe des Ardennes - cuvee 2003 ;) ]

Ils ont rien vu d'ailleurs lors de la super explosion je sais pas quoi fin décembre dernier?

Non il y avait un camion qui passait sur un ralentisseur a 3kms, et juste a ce moment la. C'est vraiment pas de bol. :P


arf... ils sont gonflés quand même! 23 collisions primaires/evts et ils espèrent voir des vertex déplacés à angle polaire < 200 mrad avec leur détecteur!

Hmmm... Un monsieur d'LHCb peut-etre ? :)


Tu m'étonnes qu'il y ait plus personne et que tout le monde se casse en astro et cie (qui a dit matière molle?).

Moi j'ai plutot entendu parle de l'astrobazar ;)

Bah...
C'est pour faire vendre.
C'est sur que ca fait plus rever de parler de dimensions supplementaires, de micros trous noirs et d'espace de de Sitter que de parler de SUSY ou de technicouleur.

Et puis dire que l'on cherche le graviton ca devait[1] s'inscrire parfaitement dans le contexte du documentaire lorsque l'on parle d'unification des forces...
Cela dit, ca aurait ete plus juste de dire que Ligo[2] et Virgo[3] ont ete construits pour decouvrir cette particule messagere.
De toute maniere, dire que le LHC a ete construit pour le Higgs et decouvrir de la SUSY, c'est aussi, d'une certaine maniere, assez reducteur :)
Il suffit de voir les groupes de travail dans ATLAS : Higgs et SUSY bien sur, mais aussi le groupe Top, Extra-dim, B-physique, ...

Donc a moins de declamer haut et fort (tout) le livre blanc (Technical Design Report) d'Atlas, il y a fort a parier que l'on va froisser les susceptibilites de diverses personnes impliquees dans ce projet (qui, pour certaines d'entre elles, y prennent part depuis 15ans...)

[1] je n'ai pas encore vu le docu en question.
[2] http://www.ligo.caltech.edu/(...)
[3] http://www.virgo.infn.it/(...)

Comme le but de la finalite finale c'est d'etre didactique a tendance pedagogique avec un soupcon de main(s) dans le cambouis, je suppose que je vais repondre a cote de la plaque mais bon...

Pour la partie sur les Makefiles, il y existe deja un outil qui fait ca (plutot bien je trouve) : Configuration Management Tool (CMT[1] pour les intimes).

Il gere les dependances cycliques entre differents paquets d'un gros projet.
On peut definir et appliquer des actions (genre une action doc, une action check pour les tests unitaires,...)

On peut aussi lui passer n'importe quelle commande shell qui sera appliquee dans tous les paquets qui dependent d'un certain paquet.
Et il aussi interface a un RCM (CVS pour l'instant mais SVN pointe le bout de son nez).

Last but not least il est sous CeCILL et sa maintenance est garantie pour 20 ans (le temps que les experiences de physique des particules qui l'utilisent s'arretent de leur belle mort).
Code avec vos sous (enfin ceux qui paient des impots ;)

[1] CMT http://www.cmtsite.org(...)

C'est moi ou bien il y aurait comme une nouvelle dynamique dans le projet GNU/Hurd ?

Alors je suis peut-etre biaisé parce que je viens juste de m'y intéresser (c'est chouette le nombrilisme) ou que je traine sur linuxfr et sur hurdfr...

En tout cas c'est une nouvelle sympathique :)

Un regret cependant : que l'auteur n'ait pas voulu choisir entre Gnome et KDE.
C'est pas bien grave, ca tient quand meme sur un CD :P

C'est du python ca ? :P

Sans doute, mais en meme temps c'etait pas gagne vu que sur Le Monde, il y a 3 boutons pour plussoyer.
Ce qui est autrement plus difficile qu'avoir juste a choisir entre pertinent et inutile :)

En meme temps, l'absence de preuves n'est pas la preuve de l'absence... :)

En gros, c'est (pour le moment?) indecidable.

- HS -
scanf... ce serait pas pour le forum d'a cote (Programmation.c) ?
Il me semblait que les gourous du C++ utilisaient un bon vieux std::stringstream des familles :)

Si jamais KDE passe a dbus, on pourra aussi se passer enornment de X.

Ah ?
Je savais pas. (Ou en tout cas je n'avais pas vu ca sous cet angle).
Tu peux developper s'il te plait ?

Oula, toi tu n'as pas la positive attitude de notre chère Lorie nationale. Tu es vraiment trop dans la negative attitude.

Ou sinon, aurais-je l'extrême arrogance de te faire remarquer que Rome ne s'est pas faite en un jour ? :)

En moulant sur KernelTrap, je suis tombe sur un commentaire qui pointait vers un site[1] qui retrace rapidement l'historique de Hurd/L4.
Sans grande pretention, mais plutot informatif.

[1] http://portal.wikinerds.org/gnu-hurd-l4-first-program(...)

Yep... C'est vraiment le genre de truc pour lequel un torrent ferait plus que l'affaire.

Ah ! et puis pour les trolleurs en tout genre :
http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xh(...)

et enfin, l'annonce officielle (qui est en train de se faire /.-er) :
http://www.x.org/XOrg_Press_Releases/X11R6.8.2.html(...)

Bon... je suppose qu'il faudra se contenter de ceci :

http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd-l4/TODO#dirlist(...)

Personnellement je suis contre les ASSERT en mode "production" (lire: hors phase de debogage).
Normalement, ton programme ne doit pas planter.

La programmation par contrat c'est bien (enfin je trouve que c'est bien), mais le end-user (il fallait que je case un buzzword ;) lorsqu'il se retrouve avec un programme qui plante avec un sybilin
__FILE__:__FUNCTION__:__LINE__ : assertion m_data.empty() failed
... ca lui fait une belle jambe.
Je prefere de loin gerer ca via un try/catch.

Mes 2 centimes.