Moi aussi ça m'a intrigué mais c'est ce qu'il y a de plus éprouvé sur le marché (et la solution pour laquelle il y a le plus d'expertise)...
En effet : ne serait-ce pas un peu une espèce de gros saut dans le vide de se marrier avec SCons ?
Je veux dire que pour un gros projet comme X.org, faut être sûr de ce que l'on fait et pas prendre le "premier remplaçant" venu qui va enterrer automake et consort.
Et puis une fois modularisé, ce n'est "que" le mécanisme de build qui change. Hum. Enfin, sur le papier.
Prendre SCons ou unsermake à ce stade de leur développement me semble un peu prématuré quand même, non ?
Je suis globalement d'accord, sauf qu'un planning ce n'est pas forcément mettre absolument des dates et des noms en face de ces dates avec des deadlines strictes.
Un planning ça peut aussi être juste une liste de tâches, avec accessoirement un nom en face et une estimation du temps que cela prendrait si un développeur à temps plein était dessus.
Ensuite, je suis complétement d'accord sur le fait que si même dans le LL on ne peut pas avoir une certaine flexibilité sur les dates... (Mais heureusement Debian est là pour montrer l'exemple :P )
Moi quand je vois des graphiques réalisés avec Excel(TM), généralement je me méfie : ça ne sent pas le professionnalisme scientifique... (mais ça n'engage que moi)
Pour les gens vraiment sérieux, et plutôt que d'utiliser un code MonteCarlo dont on ne sait d'où il sort, il vaut mieux utiliser Geant4[1] qui est issu de la physique des particules. Lui au moins il est testé, le source est disponible ainsi que les protocoles de tests et les résultats.
J'opine du chef.
Ne serait-ce que pour soigner son image (sans jusqu'à aller écrire un bouquin sur comment et quand pouvoir utiliser la marque Hurd), il me semble qu'il serait utile d'avoir une page récapitulant ce que l'on peut faire (Hurd-Mach et Hurd-L4), ce que les devs sont en train de faire, ce qu'il reste à faire, etc...
Une opération de communication au sens le plus noble du terme.
C'est sûr qu'il y a déjà tout d'écrit dans les différents README et TODO éparpillés sur le CVS. Mais c'est pas super pratique pour avoir une vision globale de ce qui se passe dans le microcosme du Hurd. Et... non, éplucher toute la mailing-liste n'est pas non plus une solution super satisfaisante.
De plus, je suis sûr que ça faciliterait le travail d'intégration des nouveaux arrivants : un truc un peu plus user-friendly que le : read the sources, Luke.
Après ma thèse, j'aimerais bien m'y mettre, mais je sens déjà que ça va être coton (et ce que je veux dire par là c'est que je sens que ça va être plus coton qu'il me semble que cela devrait/pourrait être).
Là tu ne prends en compte que le caractère ondulatoire de la lumière.
Il ne faut pas oublier qu'en théorie des champs (ainsi qu'en quantique) tout objet possède la fascinante propriété d'être à la fois onde et particule : c'est la dualité onde-corpuscule.
La formule du dessus est juste mais néammoins incomplète :
E^2 = p^2c^2 + m^2c^4.
Et pour un photon, m^2 = 0. En d'autres termes (et pour montrer que moi aussi je peux embrouiller les gens) il n'existe pas de référentiel dans lequel le photon est au repos ( == toute l'énergie est stoquée sous forme de masse).
Cependant, j'ai une autre théorie sur les sabres lasers. Si c'étaient vraiment des sabres lasers :
- il faudrait qu'ils soient tout le temps en mouvement dès qu'ils sont mis sous tension, ou sinon on violerait le principe du dessus ;)
- les photons, une fois émis par le manche continueraient leur course jusqu'à l'infini (et au-delà)
- et pour finir, il n'y a pas d'interaction photon-photon (QED est une théorie abélienne), donc 2 lames de sabres lasers se traversent sans coup férir !!
Conclusion, les sabres lasers ne sont pas faits de photons.
Je pense qu'ils sont faits de gluons. En effet, les gluons sont soumis à QCD qui elle est une théorie non-abélienne (mais renormalisable, donc c'est bon on est sauvés) donc il existe des intéractions gluon-gluon.
D'ailleurs de récents travaux prédisent la formation de boules de gluons.
En plus les gluons sont les messagers de l'interaction forte dite de couleur (Quantum ChromoDynamics), d'où l'existence de sabres de différentes couleurs :P
D'ailleurs l'amateur averti remarquera que les sabres ont toujours une couleur dominante plus un reflet d'une autre couleur. C'est la un caractère propre au gluon qui a une charge de couleur (R,V ou B) ainsi qu'une charge d'une anti-couleur (R-barre, V-barre et B-barre).
Par contre, on ne sait toujours pas si les gluons ont une masse.
Désolé je n'ai fait que déplacer le problème, mais c'est souvent ça la recherche : on résoud un problème pour s'apercevoir qu'en fait le problème était ailleurs...
Bon en meme temps, pour que la compilation passe, il suffit de rajouter :
static bool setDefaultDevice( const QString&, const QString& );
static bool setSetupPreferredAudioDevicesCount();
static unsigned int getNbMixerDevices();
static QStringList getMixerDeviceList();
dans le header $DOWNLOAD/sound/AudioDevice.h
Soit dit en passant, ca m'étonnerait qu'AudioDevice fasse quoi que ce soit d'intéressant pour le moment... L'implémentation est... comment dire? hum... Le doux euphémisme qui me vient à l'esprit c'est que c'est une implémentation "fill in the blanks" :)
Ceci dit, je suis complétement d'accord sur le fait que les tests sont utiles.
Par contre, je ne suis pas complétement certain que les petits projets en tireraient le même bénéfice...
C'est quand même une lourde infrastructure à mettre en place. Cependant, c'est sûr qu'une fois mise en place, on n'y touche plus et on teste !
Enfin, ça serait bien d'integrer dmix d'alsa (comme mandriva ?), car les questions du genre "totem fonctionne mais pas xmms" sont légion sur les forums ubuntu.
Par contre, il faut bien voir que déplacer des traitements en espaces utilisateurs, ça donne uniquement une illusion que ça aille plus vite
Exact.
Je n'ai pas une connaissance arcanique du processus de démarrage, des runlevels et autre init.d/runit/simpleinit donc je ne sais pas à quel moment du démarrage on peut raisonnablement dire "bon maintenant on est en espace utilisateur, 90% des tâches noyau ont été réalisées" et donc être moins sensibles aux "kernel lock".
Cependant, si les tâches sont parachutées dans l'espace utilisateur, n'est-ce pas ensuite plus facile de paralléliser tout ça ? (En faisant abstraction des capacités différentes de chaque gestionnaire de démarrage vis à vis de la parallélisation).
PS: message à caractère subliminal... micro-noyau, HURD, L4...
Oui-oui, mais dans les faits ca revient à virer le maximum de trucs qui se font dans le noyau, et de les mettre en userspace...
Je suppose que c'est parce qu'optimiser les temps de chargement à l'intérieur du kernel est très hasardeux (stabilité+sécurité?) et donc que le temps passé dans le kernelspace est difficilement compressible.
De plus, comme tu en as moins à charger, t'as plus rapidement la main, non ?
(Je sais pas, je pense à voix haute)
Y a-t-il un endroit où un gars de KDE aurait recensé tous les problèmes, astuces et autres incantations vaudoues qu'ils ont du accomplir pour réaliser leur migration ? (Éplucher les mailing-listes ne m'emballe pas des masses, mais s'il faut en passer par là)
Une migration de cette taille ne s'est sûrement pas passée sans heurts (1 mois de décalage entre la lettre d'intention (1 Avril) et la date effective) et j'aurais donc voulu avoir accès à cette expertise...
PS: mon ami google me donne juste des pointeurs vers comment se servir de SVN pour les commits de KDE...
J'ai cru voir passer un Juin-2006 pour KDE4 et Septembre/Octobre-2005 pour KDE 3.5.
Mais les dates ne sont pas encore fixées, même si c'est sur qu'il va falloir attendre que Qt4 se stabilise pour pouvoir sereinement baser une release de KDE dessus.
Cependant, le développement pour KDE4 a débuté : wouhou ! (Cf blog d'Aaron Seigon).
En effet, kdelibs a été compilé avec Qt4 : c'est le commencement du début.
Par contre je n'ai trouvé aucun tag ni aucune branche KDE4-dev ou quoi que ce soit d'approchant sur le SVN de KDE...
Hummm...
C'est en effet un concept intéressant, je n'avais pas vu toute la portée de ma suggestion.
Je ne saurais que trop encourager toute initiative ressemblant à ta suggestion.
Cependant, un doute subitement m'étreint : est-ce que la jupette avec le T-shirt (et quelques tâches de café/bière/soda), la barbe de geek et les jambes non-épilées de geek ça ne jurerait pas un petit peu ?
Bon... Apparemment, on est sur la bonne voie, meme si c'est pas encore tout a fait ca.
Sur la page du nombre de bogues bloquant pour la sortie de Sarge, il y a marque 79 apres le petit week-end prolonge que tout bon geek aura passe a corriger des bogues...
On n'est pas tres loin de l'estimation ~60-70 donnee dans l'annonce sur la mailing-liste...
Aller, haut les coeurs !
Si on y croit, on peut l'avoir cette Sarge.
(Si on peut pas deboguer, au moins on peut encourager ;)
[^] # Re: autotools ?
Posté par Sebastien . En réponse au journal X.org et la modularisation. Évalué à 4.
En effet : ne serait-ce pas un peu une espèce de gros saut dans le vide de se marrier avec SCons ?
Je veux dire que pour un gros projet comme X.org, faut être sûr de ce que l'on fait et pas prendre le "premier remplaçant" venu qui va enterrer automake et consort.
Et puis une fois modularisé, ce n'est "que" le mécanisme de build qui change. Hum. Enfin, sur le papier.
Prendre SCons ou unsermake à ce stade de leur développement me semble un peu prématuré quand même, non ?
[^] # Re: SmartEiffel
Posté par Sebastien . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Ça m'a l'air tout bonnement très intéressant cette petite gâterie compilatoiresque.
Doc ?
Parce que [1] date quand même un petit peu, non ?
[1] : http://smarteiffel.loria.fr/papers/oopsla97.pdf(...)
[^] # Re: Avancement futur?
Posté par Sebastien . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 4.
Un planning ça peut aussi être juste une liste de tâches, avec accessoirement un nom en face et une estimation du temps que cela prendrait si un développeur à temps plein était dessus.
Ensuite, je suis complétement d'accord sur le fait que si même dans le LL on ne peut pas avoir une certaine flexibilité sur les dates... (Mais heureusement Debian est là pour montrer l'exemple :P )
[^] # Re: Interaction laser matière vivante
Posté par Sebastien . En réponse au journal Les lames des sabres laser ont-elles une masse ?. Évalué à 3.
Moi quand je vois des graphiques réalisés avec Excel(TM), généralement je me méfie : ça ne sent pas le professionnalisme scientifique... (mais ça n'engage que moi)
Pour les gens vraiment sérieux, et plutôt que d'utiliser un code MonteCarlo dont on ne sait d'où il sort, il vaut mieux utiliser Geant4[1] qui est issu de la physique des particules. Lui au moins il est testé, le source est disponible ainsi que les protocoles de tests et les résultats.
Ou sinon, pour voir de jolies images [2,3] :)
[1] http://geant4.web.cern.ch/geant4(...)
[2] http://lpsc.in2p3.fr/tep/fichiers/SemDAPNIA.pdf(...)
[3] http://geant4-tt.web.cern.ch/geant4-tt/TTpictures.htm(...)
[^] # Re: Avancement futur?
Posté par Sebastien . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 8.
Ne serait-ce que pour soigner son image (sans jusqu'à aller écrire un bouquin sur comment et quand pouvoir utiliser la marque Hurd), il me semble qu'il serait utile d'avoir une page récapitulant ce que l'on peut faire (Hurd-Mach et Hurd-L4), ce que les devs sont en train de faire, ce qu'il reste à faire, etc...
Une opération de communication au sens le plus noble du terme.
C'est sûr qu'il y a déjà tout d'écrit dans les différents README et TODO éparpillés sur le CVS. Mais c'est pas super pratique pour avoir une vision globale de ce qui se passe dans le microcosme du Hurd. Et... non, éplucher toute la mailing-liste n'est pas non plus une solution super satisfaisante.
De plus, je suis sûr que ça faciliterait le travail d'intégration des nouveaux arrivants : un truc un peu plus user-friendly que le : read the sources, Luke.
Après ma thèse, j'aimerais bien m'y mettre, mais je sens déjà que ça va être coton (et ce que je veux dire par là c'est que je sens que ça va être plus coton qu'il me semble que cela devrait/pourrait être).
[^] # Re: E=mc²
Posté par Sebastien . En réponse au journal Les lames des sabres laser ont-elles une masse ?. Évalué à 4.
Ah non, mon oreillette me dit que c'est Groucha qui dit ça...
Et puis d'abord, c'est le gluon du trou. (Les autres ne parlent pas, c'est bien connu)
[^] # Re: E=mc²
Posté par Sebastien . En réponse au journal Les lames des sabres laser ont-elles une masse ?. Évalué à 10.
Il ne faut pas oublier qu'en théorie des champs (ainsi qu'en quantique) tout objet possède la fascinante propriété d'être à la fois onde et particule : c'est la dualité onde-corpuscule.
La formule du dessus est juste mais néammoins incomplète :
E^2 = p^2c^2 + m^2c^4.
Et pour un photon, m^2 = 0. En d'autres termes (et pour montrer que moi aussi je peux embrouiller les gens) il n'existe pas de référentiel dans lequel le photon est au repos ( == toute l'énergie est stoquée sous forme de masse).
Cependant, j'ai une autre théorie sur les sabres lasers. Si c'étaient vraiment des sabres lasers :
- il faudrait qu'ils soient tout le temps en mouvement dès qu'ils sont mis sous tension, ou sinon on violerait le principe du dessus ;)
- les photons, une fois émis par le manche continueraient leur course jusqu'à l'infini (et au-delà)
- et pour finir, il n'y a pas d'interaction photon-photon (QED est une théorie abélienne), donc 2 lames de sabres lasers se traversent sans coup férir !!
Conclusion, les sabres lasers ne sont pas faits de photons.
Je pense qu'ils sont faits de gluons. En effet, les gluons sont soumis à QCD qui elle est une théorie non-abélienne (mais renormalisable, donc c'est bon on est sauvés) donc il existe des intéractions gluon-gluon.
D'ailleurs de récents travaux prédisent la formation de boules de gluons.
En plus les gluons sont les messagers de l'interaction forte dite de couleur (Quantum ChromoDynamics), d'où l'existence de sabres de différentes couleurs :P
D'ailleurs l'amateur averti remarquera que les sabres ont toujours une couleur dominante plus un reflet d'une autre couleur. C'est la un caractère propre au gluon qui a une charge de couleur (R,V ou B) ainsi qu'une charge d'une anti-couleur (R-barre, V-barre et B-barre).
Par contre, on ne sait toujours pas si les gluons ont une masse.
Désolé je n'ai fait que déplacer le problème, mais c'est souvent ça la recherche : on résoud un problème pour s'apercevoir qu'en fait le problème était ailleurs...
[^] # Re: Dépêche ?
Posté par Sebastien . En réponse au journal Nouvelle avancée de Hurd/L4. Évalué à 2.
Par contre comme je ne suis pas très à l'aise sur certains details, il faudra sûrement qu'un expert Hurd-L4 corrige mes imprécisions et contre-sens.
[^] # Re: Mouais
Posté par Sebastien . En réponse au journal Alternative à Skype. Évalué à 4.
SVN commit: [2 weeks] tanguy_k "Thread implementation corrected"
Bon ben, bonne continuation :)
Et surtout ne pas hésiter à faire un journal/article dès que ça se précise...
[^] # Re: Mouais
Posté par Sebastien . En réponse au journal Alternative à Skype. Évalué à 4.
static bool setDefaultDevice( const QString&, const QString& );
static bool setSetupPreferredAudioDevicesCount();
static unsigned int getNbMixerDevices();
static QStringList getMixerDeviceList();
dans le header $DOWNLOAD/sound/AudioDevice.h
Soit dit en passant, ca m'étonnerait qu'AudioDevice fasse quoi que ce soit d'intéressant pour le moment... L'implémentation est... comment dire? hum... Le doux euphémisme qui me vient à l'esprit c'est que c'est une implémentation "fill in the blanks" :)
Mais bon c'est une beta, hein.
[^] # Re: Plus d'infos sur Wengo
Posté par Sebastien . En réponse au journal Alternative à Skype. Évalué à 3.
Ou sinon, comme d'habitude : clair, net, précis : sharp (comme dirait notre ami Cantona) !!
[^] # Re: et les autres ?
Posté par Sebastien . En réponse au journal Tests de régression pour Linux. Évalué à 3.
http://ltp.sourceforge.net/tooltable.php(...)
Ceci dit, je suis complétement d'accord sur le fait que les tests sont utiles.
Par contre, je ne suis pas complétement certain que les petits projets en tireraient le même bénéfice...
C'est quand même une lourde infrastructure à mettre en place. Cependant, c'est sûr qu'une fois mise en place, on n'y touche plus et on teste !
Mes 2 centimes de paroles de comptoir...
[^] # Re: Noyau
Posté par Sebastien . En réponse au journal Ubuntu - The Breezy Badger. Évalué à 3.
http://udu.wiki.ubuntu.com/LinuxKernelRoadmap(...)
On y apprend qu'ils veulent le 2.6.12 compilé avec (au moins) gcc-3.4, et que c'est fait pour le 2.6.12-rc.
Ensuite, ils veulent essayer des pre-releases avec gcc-4.0(.x).
Voilà voilà.
[^] # Re: Des outils de config ?
Posté par Sebastien . En réponse au journal Ubuntu - The Breezy Badger. Évalué à 2.
Je crois qu'ils en ont conscience : cf [1]
[1] : http://udu.wiki.ubuntu.com/AudioInfrastructure(...)
[^] # Re: EarlyUserspace?
Posté par Sebastien . En réponse au journal Ubuntu - The Breezy Badger. Évalué à 5.
Héhé : kernel 3.0.0 = Hurd-1.0
Vite je me cache, mais avant :
On n'atteint pas la perfection lorsqu'il n'y a plus rien à ajouter mais lorsqu'on ne peut plus rien enlever.
[^] # Re: EarlyUserspace?
Posté par Sebastien . En réponse au journal Ubuntu - The Breezy Badger. Évalué à 3.
Il y a plusieurs possibilites :
- le truc de Gentoo[1] (je me suis laisse dire qu'il gerait bien les dependances)
- runit[2] ?
- le truc de Seth[3]
[1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&c(...)
[2] http://smarden.org/runit1/(...)
[3] http://www.gnome.org/~seth/blog/The_80s_live_on_in_my_soul(...)
[^] # Re: Noyau
Posté par Sebastien . En réponse au journal Ubuntu - The Breezy Badger. Évalué à 6.
En effet mais pour plus de détails, il vaut mieux s'addresser au saint-père plutôt qu'à ces saints :
http://kerneltrap.org/node/4793(...)
[^] # Re: EarlyUserspace?
Posté par Sebastien . En réponse au journal Ubuntu - The Breezy Badger. Évalué à 2.
Exact.
Je n'ai pas une connaissance arcanique du processus de démarrage, des runlevels et autre init.d/runit/simpleinit donc je ne sais pas à quel moment du démarrage on peut raisonnablement dire "bon maintenant on est en espace utilisateur, 90% des tâches noyau ont été réalisées" et donc être moins sensibles aux "kernel lock".
Cependant, si les tâches sont parachutées dans l'espace utilisateur, n'est-ce pas ensuite plus facile de paralléliser tout ça ? (En faisant abstraction des capacités différentes de chaque gestionnaire de démarrage vis à vis de la parallélisation).
PS: message à caractère subliminal... micro-noyau, HURD, L4...
[^] # Re: EarlyUserspace?
Posté par Sebastien . En réponse au journal Ubuntu - The Breezy Badger. Évalué à 4.
Je suppose que c'est parce qu'optimiser les temps de chargement à l'intérieur du kernel est très hasardeux (stabilité+sécurité?) et donc que le temps passé dans le kernelspace est difficilement compressible.
De plus, comme tu en as moins à charger, t'as plus rapidement la main, non ?
(Je sais pas, je pense à voix haute)
[^] # Re: Noyau
Posté par Sebastien . En réponse au journal Ubuntu - The Breezy Badger. Évalué à 4.
Je n'ai rien vu qui permettait d'affirmer que ce serait le 2.6.12.
En tout cas ce sera au moins le 2.6.11 : j'ai bon ? :P
Ou sinon, un petit lien qui était tombé :
http://www.ubuntulinux.org/wiki/BreezyBadger(...)
(où on peut noter la possible intégration de SELinux)
# Details de la migration
Posté par Sebastien . En réponse à la dépêche Le basculement de KDE vers Subversion est terminé. Évalué à 3.
Une migration de cette taille ne s'est sûrement pas passée sans heurts (1 mois de décalage entre la lettre d'intention (1 Avril) et la date effective) et j'aurais donc voulu avoir accès à cette expertise...
PS: mon ami google me donne juste des pointeurs vers comment se servir de SVN pour les commits de KDE...
[^] # Re: KDE 4
Posté par Sebastien . En réponse à la dépêche Le basculement de KDE vers Subversion est terminé. Évalué à 5.
Mais les dates ne sont pas encore fixées, même si c'est sur qu'il va falloir attendre que Qt4 se stabilise pour pouvoir sereinement baser une release de KDE dessus.
Cependant, le développement pour KDE4 a débuté : wouhou ! (Cf blog d'Aaron Seigon).
En effet, kdelibs a été compilé avec Qt4 : c'est le commencement du début.
Par contre je n'ai trouvé aucun tag ni aucune branche KDE4-dev ou quoi que ce soit d'approchant sur le SVN de KDE...
# Oeuf/Poule
Posté par Sebastien . En réponse au journal Wiki de code source ?. Évalué à 4.
Cela étant, c'est vrai que ça a l'air sympa comme idée... Quelqu'un pour le faire en XUL ?
[^] # Re: RC-bugs
Posté par Sebastien . En réponse à la dépêche Debian : Sarge prévue pour la fin du mois, chasse aux bogues, AMD64. Évalué à 2.
C'est en effet un concept intéressant, je n'avais pas vu toute la portée de ma suggestion.
Je ne saurais que trop encourager toute initiative ressemblant à ta suggestion.
Cependant, un doute subitement m'étreint : est-ce que la jupette avec le T-shirt (et quelques tâches de café/bière/soda), la barbe de geek et les jambes non-épilées de geek ça ne jurerait pas un petit peu ?
# RC-bugs
Posté par Sebastien . En réponse à la dépêche Debian : Sarge prévue pour la fin du mois, chasse aux bogues, AMD64. Évalué à 4.
Sur la page du nombre de bogues bloquant pour la sortie de Sarge, il y a marque 79 apres le petit week-end prolonge que tout bon geek aura passe a corriger des bogues...
On n'est pas tres loin de l'estimation ~60-70 donnee dans l'annonce sur la mailing-liste...
Aller, haut les coeurs !
Si on y croit, on peut l'avoir cette Sarge.
(Si on peut pas deboguer, au moins on peut encourager ;)