Victor STINNER a écrit 1639 commentaires

La dépêche sur le noyau 2.6.32 en parle :
http://linuxfr.org/2009/12/03/26207.html#ksm

Tiens, ça me rappelle Windows 98 dès qu'on accédait au lecteur de disquette :-)

Pour Linux 2.6.32, le mieux sera de tester je pense ;-)

Le film « Python » parle de serpent, et d'ailleurs il se déroule à « Ruby » :-) Par contre, c'est un super nanar !
http://www.nanarland.com/Chroniques/Main.php?id_film=python

Ils ont fait un « Python 2 », mais pas encore Python 3.

Quels acronymes / termes / autre n'as-tu pas compris ? En tant que modérateur, je serai intéressé de savoir ce qu'il faut améliorer, mais là tu es trop vague. Cette dépêche est bourrée de liens pour en savoir plus : je pense que tu trouveras des réponses en suivant les liens ;-)

À ce que j'ai compris, il y a rarement du nouveau code ajouté durant les phases de RC. Seuls les nouveaux pilotes sont acceptés, vu qu'ils ne peuvent pas introduire de régression (vu qu'ils n'existaient pas dans la version précédente). Les phases de RC servent essentiellement à détecter les régressions. C'est cohérent avec la définition de Julien04.

Si on reprend le vocabulaire alpha/béta/RC, je pense que ça ressemble à ça :

Comme dit patrick_g, la version alpha d'un patch est développé sur la machine perso d'un développeur. Une fois qu'elle est assez stable, le patch est soumis pour relecture (phase béta). Le merge dans le dépôt de Linus est la dernière étape (phase RC).

On se demande...

(ah bah bravo, faudrait modérer les messages aussi, et en plus nohjan me fout la honte avec sa BD)

On me demande vraiment à quoi servent les modérateurs si c'est pour laisser passer autant de fautes !

comment peut-on commit dans ce repo ?

Le développement est hiérarchique : chaque sous-système a son dépôt, exemples : le réseau ou le son (ALSA). À vrai dire, il existe des dizaines et des dizaines de dépôts. Tu peux avoir un petit aperçu par ici : http://git.kernel.org/

Par contre, pour le tarball du noyau Linux saveur vanille, c'est le dépôt Linus qui est utilisé :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)

Disons qu'il y a deux types de commits : patchs pour améliorer un sous-système dans un dépôt (autre que celui de Linus), et acceptation (merge) des modifications depuis un dépôt tiers dans le dépôt de Linus. Je dis que le développement est hiérarchique car tu peux avoir plusieurs "couches" de dépôts (ex: dépôt d'une personne qui contient un patch spécifique => dépôt du sous-système => dépôt de Linus).

Beaucoup de code est écrit sous forme de patchs soumis sur des listes de diffusion, comme par exemple la "LKML", mais ça peut aussi être sur la liste de diffusion d'un sous-système. Ces patchs sont relus par tous les abonnés à la liste de diffusion qui sont intéressés par la fonctionnalité. Vu le nombre de messages quotidiens sur la LKML, je pense qu'il y a pas mal de monde qui relit les patchs (mais toutes les personnes postant sur la LKML ne sont pas capable de relire tous les patchs bien sûr).

Si le patch ne respecte pas le style de code imposé par le noyau, utilise une ancienne API, n'est pas assez générique, etc. : un nouveau patch sera exigé. Si la fonctionnalité est critique, il peut avoir plus d'une dizaine de versions d'un patch avant qu'il soit appliqué. Le patch "eventfd" (noyau 2.6.22) a par exemple exigé 26 versions avant d'être commité :-)

y'a t-il des tests unitaires ou à défaut des tests plus larges de non régression ?

Les phases de RC visent à dégrossir les régressions. Le site Kernel Oops liste les régressions :
http://www.kerneloops.org/
(on y trouve des stat' intéressantes)

Il y a beaucoup d'outils d'analyse statique du code : kmemcheck, kmemleak, Sparse, etc. (développés spécifiquement pour le noyau Linux) J'ai même vu des motivés qui ont portés Valgrind pour tester le noyau Linux (un truc avec QEMU, je me souviens mal).

Pour les tests automatiques, je n'en connais pas, mais il en existe peut-être. Je pense que les bugs sur les composants critiques (ex: gestion de la mémoire ou ordonnanceur de processus) sont détectés très rapidement, un bug sur un pilote d'un matériel désuet sera détecté beaucoup plus difficile car qu'un testeur ait ce matériel.

Comme le code source de Linux est ouvert, il y a énormément de monde qui le relit pour apprendre à programmer, pour valider le code d'un pilote, ou encore pour traquer des failles de sécurité. Il existe aussi des logiciels de fuzzing spécifiques au noyau.

y'a t-il des relectures de code, si oui sur tous les commits ? qui relit ?

Comme dit, les patchs soumis sur les listes de diffusion sont relus par plusieurs personnes différentes. Je doute qu'une ligne de code ne soit commité sans avoir été relue par plusieurs personnes. D'ailleurs, depuis que git est utilisé, un commit peut être signé par plusieurs personnes (peut-être que c'était déjà possible avec BitKeeper, je sais pas). Exemple sur l'avant dernier commit du dépôt de Linus :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)

Le commit a été signé par Julia Lawall (auteure du patch) et Ralf Baechle (qui a commité le patch). Tiens, ce patch corrige un bug trouvé par un autre outil d'analyse de code automatique : http://coccinelle.lip6.fr/

--

Je ne suis pas développeur noyau, juste spectateur, je peux donc raconter des conneries. Mais j'espère t'avoir éclairé un peu ;-) Sinon il existe des nombreux documents qui expliquent comment le noyau Linux est développé (y'a même des analyses sociologiques ;-)).

La principale différence est la licence. Contrairement à Qt, PyQt est sous licence GPL, et son auteur vend une version commerciale (comme le faisait Qt il y a quelques temps). PySide est diffusé sous licence LGPL, comme Qt.

PyQt utilise un outil de binding spécifique à Qt, « SIP ». C'est un genre d'extension au C++ qui sert à générer un binding pour l'API C de Python. C'est assez spécial et ça n'est utilisé par aucun autre projet. Ça ne facilite pas les contributions, ni le debug :-/

Je ne sais pas ce que PySide utilise pour écrire le binding.

Si tu es motivé, ouvre un rapport de bug ou envoie carrément un patch ;-) (le livre est sous licence libre)

J'ai survolé le livre en diagonale, et j'ai juste vu « Congratulations ! ».

Le livre utilise Python 3.0.1 sous Windows pour les exemples. Les noms de variables en unicode prennent tout leur sens : on peut orthographier correctement les noms de variables, comme « ménage » ou « âge » :-)

Certes, il reste les erreurs à rallonge de gcc (mais ce n'est pas spécifique au C++)

C++0x vise à simplifier les messages d'erreur des compilateurs.
http://linuxfr.org/2009/07/24/25763.html

la syntaxe qui n'est pas la plus fun en ce moment mais qui a l'immense avantage d'être compatible avec celle du C

Contrairement à une idée reçue, C et C++ sont deux langages différents. Écrire des bouts de C en C++, c'est possible, mais c'est très crade (ex: mélanger printf(...) et cout<<...). D'ailleurs, quand on débute en C++, on a tendance à coder C plutôt qu'en C++ (genre préférer les structures aux objets).

Tiens, en parlant de problèmes :
* J'avais d'abord installé le jeu à partir de l'archive partielle (le téléchargement était interrompu à 20 Mo de la fin, je sais pas pourquoi). J'avais commencé à jouer et j'ai eu un plantage (segfault !).
* J'ai retéléchargé le jeu et j'ai supprimé l'ancien dossier partiel : bah j'ai perdu mes sauvegardes :-( (après coup, je pense que c'est lié au segfault)
* Plus tard, j'ai eu deux autres plantages : à chaque fois j'ai perdu mes sauvegardes. C'est à dire que même en cliquant sur "Save", en cas de plantage on perd tout ! Pour être sûr, il faut sauver, quitter puis relancer le jeu

Une fois qu'on a résolu un casse tête, c'est facile de le refaire. C'est juste pénible, car c'est lent et qu'on l'a déjà fait. 3 plantages en quelques heures de jeu, c'est quand même pas terrible :-/

En tout cas, plus on avance, plus le jeu est magnifique :-) On croise pas mal de monde, les décors sont très beaux, et les énigmes bien énervantes comme je les aime ;-)

La configuration et les sauvegardes sont sûrement dans un de ces fichiers :

~/.macromedia/Flash_Player/#SharedObjects/3BBSWCPZ/#localWithNet/home/haypo/Machinarium/Machinarium/Machinarium.sol
~/.macromedia/Flash_Player/#SharedObjects/3BBSWCPZ/#localWithNet/Machinarium/Machinarium.sol
~/.macromedia/Flash_Player/./macromedia.com/support/flashplayer/sys/#machinarium.net/settings.sol

16€ c'est cher pour un jeu de 93, fut-il flashback

Hein ? J'ai acheté Machinarium, pas Flashback. Je n'ai plus trop envie de rejouer à Flashback.

Alors j'ai joué un peu à Machinarium : bah c'est superbe, et ça semble assez difficile, ce qui laisse penser à une durée de vie assez longue.

Côté technique, Machinarium est développé intégralement en Flash. Il utilise des images JPEG et du son MP3 (stocké dans les fichiers Flash compressés) et le programme exécutable est « simplement » le player Adobe Flash pour Linux. Ce player pèse 9,3 Mo, utilise gtk, X11, Xrender, directfb, libdl.so, etc.

Mais dépêche toi de jouer, la fatigue et les couches culottes vont bientôt te priver de tout!

T'as raison, je l'ai acheté : 15,57 € (23,92 USD). Le prix affiché de 15,57 € est estimé en appliquant un taux de change de devises récent. Votre paiement réel sera soumis dans l'une des devises supportées suivantes : US Dollar: 23,92 USD

16€ c'est pas cher comparé à n'importe quel jeu de Wii, Xbox 360 ou PS3 !

Bien que le jeu soit en Flash, la mention de Linux m'a donné envie d'essayer la démo. Bah au bout de 3 minutes, j'ai craqué : j'adore ce jeu :-) Il me rappelle le jeu Flashback :
http://fr.wikipedia.org/wiki/Flashback:_The_Quest_for_Identi(...)

Le personnage est attachant et l'utilisation de dessins pour se passer de dialogues textuels/sonores est une très bonne idée. Je pense m'acheter la version complète très bientôt !

Cette dépêche n'a pas fait l'unanimité auprès des modérateurs, mais finalement elle a été acceptée. Perso j'ai voté pour car la liste des nouveautés semble quand même importante. Et puis bon, c'est les dépêches qui font vivre le site. S'il y avait plus de propositions de dépêches, on serait plus difficile sur l'acception d'une dépêche d'une version mineure je pense.

J'ai du mal à suivre cette discussion. Mais sinon quelques infos :

mpfr fait de l'arrondi correct, comme crlibm, sauf que c'est plus lent. mpfi propose du calcul par intervalle. mpfr et mpfi sont basés sur GMP (nombres entiers), alors que crlibm est basé sur scslib (nombres flottants).

Le problème du calcul par intervalle est qu'il faut choisir la précision au début du calcul, et que si ça se trouve à la fin l'erreur sera énorme (intervalle trop large). Enfin, c'est LE problème du calcul numérique :-) Mais crlibm, pour les fonctions qu'il offre, est différent car la précision a été précalculée. Alors que libultim utilise toujours 800 bits de précision, ce qui est largement trop la plupart du temps, crlibm utilise juste ce qu'il faut.

Si l'objectif est la précision et que le temps de calcul n'est pas un problème : il existe aussi crlibm qui offre un arrondi exact (gère les 4 modes d'arrondi IEEE 754).

http://www.haypocalc.com/blog/index.php/2009/02/20/188-bibli(...)

Existe-t-il une bibliothèque de substitution ?

Non, il en existe plusieurs : http://www.and.org/vstr/comparison

>> haypo: Si strlen() va plus vite, tout le système va plus vite.
> antoine: Sauf Python et tous les langages ayant une représentation
> antoine: des chaînes de caractères pas totalement pourrie.

Ah bon ? Tiens, regardons à quel point strlen() n'est pas utilisé dans CPython :
$ grep strlen $(find -name "*.c")|wc -l
340
avec des occurences dans des fichiers assez courants : Parser/{grammar,parsetok,tokenizer}.c, Objects/{bytearray,class,complex,file,float,int,long,string,type,unicode}object.c, Python/{ast,bltmodule,codecs,compile,import,pythonrun,traceback}.c, et j'en passe (la liste est longue).

strlen() est une fonction utilisée par l'ensemble des programmes du système. Si strlen() va plus vite, tout le système va plus vite. Je n'ai pas trop compris ces histoires de « variables conditionnelles avec des mutex PI », mais je pense qu'au final ça va améliorer la réactivité des processus utilisant beaucoup de processus légers. Avec les processeurs multi-coeurs, les applications utilisent de plus en plus de parallélisme, et la glibc est plus rapide pour le parallélisme.

Le support DNSSEC va améliorer la sécurité de DNS, ce qui va empêcher pas mal des attaques récentes voir futures (ex: le nom Dan Kaminsky vous dit quelque chose ?). Les serveurs racines vont d'ailleurs tous passer supporter DNSSEC d'ici 2010 (les domaines .se ou .org le supportent déjà).
http://www.bortzmeyer.org/signature-racine.html

Pour les instrutions AVX : ça permet de préparer l'arrivée des prochains processeurs AMD et Intel. Ils n'existent même pas qu'ils sont déjà supportés par Linux !

Tiens, cet article me fait penser à la 4e dimension : le temps. Mesurer le temps est très compliqué, surtout quand on veut une excellente précision ;-) Extrait de mon article sur le temps universel :

« En 1928, le temps universel est défini comme une mesure de la rotation de la Terre. La mesure est effectuée en observant des objets en dehors du système solaire par rapport au Soleil. La précision est de l'ordre de la microseconde. Le temps universel est irrégulier à cause des marées, de la Lune, du Soleil, des tremblements de Terre, etc. Il existe deux principales versions du temps universel : UT0 est la mesure brute tandis que UT1 corrige les effets du mouvement polaire. »

http://www.haypocalc.com/blog/index.php/2008/11/25/176-petit(...)

--

Extrait de l'article Wikipédia :

« Le Temps universel (UT) est une échelle de temps basée sur la rotation de la Terre. Sa mesure peut être effectuée en observant chaque jour le passage d'objets célestes au méridien du lieu d'observation. Les astronomes ont privilégié l'observation d'étoiles hors du système solaire par rapport à celle du Soleil, car ces observations sont plus précises. Actuellement, le Temps universel est déterminé par les observations par interférométrie à très longue base de quasars lointains, une méthode qui possède une précision de l'ordre de la microseconde. »

http://fr.wikipedia.org/wiki/Temps_universel

On retrouve ces histoires de quasars ;-)

Il n'y a pas de problème, Qt fonctionne très bien avec des noms de fichier mal encodés. Le bug est dans ton code, pas dans Qt (ni dans Linux :-)). Exemple en Python :
from PyQt4.QtCore import QDir, QFile, QIODevice
cwd = QDir('.')
entries = cwd.entryInfoList()
for entry in entries:
.. name = entry.fileName()
.. if unicode(name).startswith(u"."):
.... continue
.. file = QFile(name)
.. file.open(QIODevice.ReadOnly)
.. data = file.read(10)
.. file.close()
.. bytes_name = str(QFile.encodeName(name))
.. print "%r: content=%r" % (bytes_name, data)
Pour créer un fichier avec un nom invalide sous Linux : echo "pouet" > $(echo -ne "b\xff--").

Qt ne liste pas les fichiers de ce type

De quoi tu parles ?

On peu cliquer sur passé, ce qui passe juste le fichier courant, les utilisateurs souhaite ce fonctionnement, et faire le fonctionnement que tu à évoquer peu être très difficile.

Oui on peut cliquer ignorer un fichier, mais ce n'était pas ce que je demandais. Peut-être que ce que je demande est compliqué à implémenter, mais ça serait un vrai plus pour ton logiciel (parce que pour l'instant, je n'en ai toujours pas trouvé d'utilité à ce logiciel et il semble pas mal bogué).

En instantané sur linux j'ai 0Mo/s 500Mo/s 300Mo/s 10Ko/s 1500Mo/s,

Ces valeurs me semblent tout simplement fausses (ou alors ton disque dur peut écrire à 1,5 Go/sec ?). Et puis, passer de 10 Ko/s à 1500 Mo/s en un instant ... Calcule une moyenne sur les 5 dernières secondes par exemple, ça sera plus sympa pour l'utilisateur.