"…mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code…"

Archive for janvier 2008

Une cuvée exeptionnelle: la sortie du noyau Linux 2.6.24

Posted by patrick sur janvier 28, 2008

Un excellent article sur la sortie du noyau Linux 2.6.24 par http://linuxfr.org/~patrick_g/ dont le travail a été très apprécié.

voir l’article ici: http://linuxfr.org/2008/01/25/23529.html

Quelques extraits:

————————————————8<———————————————————

Après un cycle de développement inhabituellement long la sortie de la vingt-cinquième version stable de la branche 2.6 du noyau Linux vient d’être annoncée. Le code source du noyau est maintenant téléchargeable sur les serveurs du site kernel.org.

  • Cette version 2.6.24 se caractérise essentiellement par l’ampleur des changements, en terme de lignes de codes, avec la version précédente. Le 23 octobre, dans son mail d’annonce de la RC-1, Linus écrit :

    Cela doit être l’une des plus grosses versions candidates de tous les temps. C’est monstrueux. D’habitude, pour la RC-1, la taille du fichier compressé des différences est de l’ordre de 3 à 5 Mo. Certains sont plus petits que ça et on a occasionnellement des pointes à 6 Mo. Celle-ci fait *onze* méga-octets.
    En bref nous avons juste eu un grand nombre de merges, et pas seulement pour x86 mais aussi des tonnes de nouveaux pilotes (surtout pour le wifi mais pas seulement – dvb, réseau classique, mmc..etc) ainsi qu’une bonne quantité de travail sur les diverses architectures, les systèmes de fichiers, le réseau etc.
    Donc il y a juste beaucoup de nouvelles choses.


Vous trouverez plus de détails sur les nouveautés dans la suite de cette dépêche.

  • La fonction d’ordonnancement de groupe, qui a été évoquée lors de la sortie du précédent noyau, est maintenant intégrée dans cette version. Cela permet à l’ordonnanceur de nouvelle génération CFS de gérer plus finement l’allocation des ressources de calcul aux différents processus s’exécutant sur la machine. Avec l’ordonnancement de groupe on peut diviser à volonté le temps processeur selon deux politiques : Soit entre les utilisateurs soit entre les groupes de tâches.
    • La première option (sélectionnable avec CONFIG_FAIR_USER_SCHED) divise le temps processeur entre les différents utilisateurs d’une machine. Celui qui lance 30 processus ne sera plus avantagé par rapport à celui qui n’en lance qu’un seul et chacun des deux utilisateurs aura équitablement la moitié du temps de calcul. Un avantage additionnel relevé par Ingo Molnar est que cela limite drastiquement les risques de Fork Bomb.
    • La seconde option (sélectionnable avec CONFIG_FAIR_CGROUP_SCHED) divise le temps processeur entre différents groupes de tâches. La documentation décrit très bien cette nouvelle fonction : on peut par exemple créer le groupe « multimédia » et le groupe « bureautique » et décider que le premier groupe aura 75 % du temps de calcul alors que le second n’aura que 25 %. L’administrateur a ainsi a sa disposition un outil très souple pour créer tous les groupes qu’il désire et y rattacher les processus à volonté.

    En plus de cet enrichissement fonctionnel apporté par l’ordonnancement de groupe, CFS a également été amélioré sur le plan de la taille du code et de la rapidité. L’empreinte mémoire du code compilé a été réduite puisqu’on passe de 29 145 octets à 26 666 octets (-8,5 %) sur un système multiprocesseur et de 15 633 octets à 13 379 (-14,4 %) sur un système mono-processeur. Cette réduction de taille est cruciale pour le monde de l’embarqué ou Linux est devenu un système incontournable. Diverses micro-optimisations ont également permis de réduire les latences de l’ordonnanceur. Ingo Molnar a mesuré ces latences à l’aide de l’outil lmbench : le noyau 2.6.22 (ne contenant pas CFS) atteignait 0,64 microsecondes. Le noyau 2.6.23 (contenant la première version de CFS) avait régressé à 0,72 microsecondes (+12 %). Le nouveau noyau 2.6.24 et son code optimisé permet de redescendre à 0,62 microsecondes (soit -3 % par rapport à l’ordonnanceur non équitable d’ancienne génération). On voit donc que le caractère complètement équitable et extrêmement robuste du nouvel ordonnanceur CFS n’aura rien coûté en performances.

  • Pour permettre, entre autre, l’ordonnancement de groupe le noyau 2.6.24 propose l’infrastructure Control Group. Elle permet de définir de façon très générique des groupes de contrôle (ou cgroups) afin de gérer les ressources disponibles de la machine et de définir des quotas d’utilisation. L’administrateur utilise les cgroups pour créer des hiérarchies de processus au travers, comme c’est l’habitude sous Linux, d’un système de fichier virtuel se trouvant dans /dev/cgroup. Ces cgroups associent des listes de tâches avec des listes de paramètres pour les divers gestionnaires des ressources (les processeurs, les utilisateurs, les disques, le réseau, etc.).
    Pour simplifier évoquons un exemple (tiré directement de la documentation) : l’administrateur du serveur d’une université désire gérer finement les ressources de sa machine. Il crée donc deux cgroups, l’un pour les professeurs et l’autre pour les étudiants. Une fois que c’est fait l’administrateur peut utiliser la nouvelle infrastructure Control Group afin de définir des quotas et des limites pour chaque groupe. Par exemple, 50 % de la mémoire pour les professeurs, 30 % pour les étudiants et le reste pour le système. Observez sur le schéma ci-dessous l’application d’une hiérarchie des quotas pour les ressources réseau. La navigation web a une allocation de 20 % de la bande passante qui est elle-même divisée inégalement entre professeurs et étudiants.

               /         \
    
        cgroup1    cgroup2
    
           |              |
    
       (Profs)         (Etudiants)
    
    Mémoire : Profs (50%), étudiants (30%), système (20%)
    
    Disques : Profs (50%), étudiants (30%), système (20%)
    
    Réseau : navigation web (20%), accès par NFS (60%), autre (20%)
    
                       /        \
    
            Prof (15%) étudiants (5%)

    Cette nouvelle infrastructure de quotas et de groupes de contrôle est utilisée par CFS pour l’ordonnancement de groupe des processus évoqué plus haut. Ainsi CFS évite de dupliquer du code et profite du mécanisme générique se trouvant dans le nouveau noyau.

  • L’unification des architectures i386 et x86-64 est réalisée pour la première fois au sein du noyau 2.6.24. Quand on regarde le code source de Linux on constate que le répertoire arch contient le code spécifique aux divers processeurs qui sont supportés par le noyau (PowerPC, i386, ARM, SPARC, etc.). Ce nombre de sous-répertoires est important (plus de 25 architectures différentes) et les développeurs ont intérêt à essayer de fusionner au maximum ce qui peut l’être afin de partager le plus de code possible. Comme il existe de nombreuses ressemblances entre les i386 et les x86-64 (essentiellement l’architecture passe de 8 à 16 registres et ces registres passent de 32 à 64 bits) un projet de fusion a vu le jour. Actuellement une correction de bug sur l’une des branches doit être dupliquée sur l’autre. Quand une nouveauté est introduite, il faut l’incorporer à l’autre branche, etc. Ce processus de double maintenance est très lourd et provoque de nombreuses erreurs. La décision a donc été prise de faire comme pour l’architecture PowerPC : les variantes 32 et 64 bits ont fusionné à l’occasion de la sortie du noyau 2.6.15 et, avec le recul, cela s’est avéré être une très bonne décision.
    Thomas Gleixner et Ingo Molnar, dans un mail très argumenté, ont donc proposé un méga patch (près de 2 000 fichiers sont impactés) qui renomme tous les fichiers spécifiques avec le suffixe _32 ou _64 et les déplace dans le nouveau répertoire unifié x86. C’est une sorte de « Big Bang » au niveau des répertoires de arch mais cela ne change rien au niveau du code lui-même. De cette façon le travail d’unification, qui a déjà commencé, peut se faire progressivement (en fusionnant les fichiers toto_32.C et toto_64.c en un unique toto.c) avec chaque nouvelle version du noyau.
    Cette décision a néanmoins provoqué une controverse car Andi Kleen, le mainteneur de la branche x86-64, n’était pas d’accord avec l’unification. Il a défendu son point de vue sur la liste de diffusion :

    Vous connaissez ma position à ce sujet. Je pense que c’est une mauvaise idée car cela signifie que nous ne pourrons jamais plus nous débarrasser des vieilleries. La branche arch/x86_64 est significativement plus propre et plus simple que arch/i386 et je voudrais préserver cela. […] Ce n’est pas vraiment la même plate-forme : l’une est une architecture PC remontant à la nuit des temps et contenant des zillions de bugs, l’autre est une plate-forme PC moderne avec bien moins de bugs et de bizarreries.

    Linus n’était pas de cet avis:

    Je pense qu’il est *bien* plus difficile de gérer ce genre d’héritage dans un vieux répertoire que presque personne n’utilise (ce n’est probablement pas vrai à l’heure actuelle mais, pour la plupart des développeurs, je parie que cela sera vrai dans un an). Spécialement si ce vieux répertoire se contente de dupliquer 99% du boulot. Il n’y a pas tant de vieilleries que ça. Il y a certes des choses bizarres ici et là, mais chaque fois que j’entends l’argument (théorique) selon lequel nous économiserions du temps et des efforts en ayant ce code dupliqué ailleurs je pense à tout le temps que nous perdons réellement en corrigeant le même bug deux fois (et je m’inquiète pour les fois ou nous ne le faisons pas).

    Andi n’a pas été convaincu par Linus et il a décidé de ne pas assurer la maintenance de la nouvelle branche fusionnée x86. Les nouveaux mainteneurs sont donc Thomas Gleixner, Ingo Molnar, et H. Peter Anvin.

  • Un changement concernant les entrées/sorties de type scatter/gather a provoqué quelques soucis dans le nouveau noyau. La technique de scatter/gather permet d’utiliser un seul appel système pour écrire séquentiellement des données depuis plusieurs tampons mémoires ou pour lire des données dans plusieurs tampons mémoires. Ce mécanisme, qu’on pourrait traduire imparfaitement par Rassemblement/Dispersion, élimine l’obligation de copier les données dans un seul gros buffer et permet d’utiliser beaucoup de petits tampons dispersés. Cela permet d’augmenter les performances et d’éviter d’avoir à créer un gros buffer d’une seule pièce (ce qui est parfois difficile). La technique scatter/gather est très efficace et pratique puisqu’une seule instruction permet de faire plusieurs choses simultanément. Cela explique pourquoi cette technique est aussi connue sous le nom d’entrées/sorties vectorielles. La liste des multiples tampons est présente dans un tableau mais celui-ci ne peut pas excéder la taille d’une page mémoire. Afin de faire sauter cette limitation contraignante le noyau 2.6.24 a introduit la possibilité de chaîner ces listes. Le but est d’augmenter encore les performances d’entrées/sorties mais ce changement a été douloureux et a provoqué le dysfonctionnement de plusieurs pilotes. Jonathan Corbet a même indiqué que

    le chaînage des listes scatter/gather a sans doute été le changement le plus problématique du noyau 2.6.24, en dépit du fait qu’il s’agit d’un nombre réduit de lignes de code

    L’API scatter/gather doit aussi encore être améliorée afin de simplifier son utilisation. Deux directions sont envisagées pour inclusion dans le noyau 2.6.25 afin d’avoir une API qui permette d’écrire plus facilement à l’avenir du code haute-performance.

  • Le support de l’espace de noms pour les processus fait son entrée dans le nouveau noyau….De même ce support de l’espace de noms pour les processus est pour l’instant encore marqué comme « expérimental » afin de prévenir les développeurs que l’interface de programmation est susceptible de changer. La finalisation définitive de l’API est prévue pour la version 2.6.25 et elle pourrait bien annoncer le début de la fin pour les patchs externes du type Vserver. Quand tous ces mécanismes de gestion de conteneurs seront inclus dans la branche principale, Linux possédera une solution plus puissante et plus générique que ses concurrents. On peut noter à titre d’exemple que les Zones de Solaris ne possèdent pas d’espace de noms pour le réseau.
  • L’interface Virtio qui permet de proposer aux différentes solutions de virtualisation une couche commune pour gérer les entrées/sorties a été développée par Rusty Russell et le patch a été inclus dans le nouveau noyau Linux. Comme il existe plusieurs solutions de virtualisation utilisables avec Linux (Xen, Lguest, KVM, etc.) il est apparu nécessaire de chercher à mutualiser une partie du code et à proposer une couche d’abstraction pour éviter une divergence des outils. Virtio est une interface virtuelle qui permet de gérer les entrées/sorties et évite ainsi la prolifération anarchique des pilotes virtuels. Interrogé sur l’utilité réelle de Virtio, Rusty a répondu que :

    personne ne veut maintenir cinq pilotes virtuels différents pour le réseau, cinq pilotes virtuels différents en mode bloc, etc. En fait à un moment la communauté du noyau va se rebeller […] Nous pouvons donc au moins simplifier pour chaque technologie de virtualisation le fait d’implémenter le nouveau périphérique XYZZY.

    Virtio reste volontairement simple car la technique de virtualisation des entrées/sorties change rapidement et il ne faut pas que cette nouvelle interface devienne un facteur limitant par la suite…ou comme le dit plus brutalement Rusty:

    Of course, the new interface must not suck.

  • La gestion dynamique des tranches de temps pour l’architecture x86-64 et pour l’architecture PPC fait maintenant partie du code du noyau Linux. Cette technologie est apparue dans le noyau 2.6.21 mais elle était jusqu’à présent réservée aux processeurs i386 et aux SPARC64. Elle permet (quand on utilise l’option CONFIG_NO_HZ) d’éviter d’avoir une fréquence fixe de « réveil » du processeur et donc de le laisser plus longtemps dans des modes d’économie d’énergie. Cela se traduit par moins de chaleur dissipée et plus de durée d’utilisation pour les ordinateurs portables (c’est également intéressant pour la gestion des machines virtuelles). Les nombreux utilisateurs de distributions x86-64 peuvent donc maintenant découvrir les bienfaits d’un noyau « tickless« .
  • le support de la norme Secure Digital Input Output fait son entrée au sein du code permettant de gérer les cartes mémoires MMC et SD. Cette modification autorise le branchement sur un port SD de divers gadgets: Récepteurs GPS, adaptateurs Wi-Fi ou Bluetooth ou Ethernet, Lecteurs de code-barre, Tuners FM ou TV, Appareils photos, etc.
    Pierre Ossman, qui est le mainteneur officiel du sous-système MMC/SD, a annoncé que trois pilotes SDIO étaient déjà inclus dans le noyau et que le travail continue pour inclure de nombreux autres pilotes. Néanmoins il tient à avertir les développeurs que son implémentation de SDIO force à écrire proprement le code des pilotes :

    Cette implémentation oblige à une stricte séparation des couches et masque tous les détails du protocole. Cela pourra en ennuyer certains qui voulaient porter plus facilement les pilotes entre différentes implémentations mais je crois que le résultat final sera un système bien plus robuste au lieu de n’être qu’une collection de hacks et de bidouilles.

  • L’infrastructure Kernel Markers est maintenant en place dans le noyau 2.6.24. Depuis plusieurs mois les développeurs ont entrepris d’améliorer les fonctions de tracing, c’est à dire d’enregistrement d’informations lors de l’exécution de la machinerie interne de Linux. Ce « tracing » est très important pour diagnostiquer d’éventuels problèmes et pour régler finement les performances du noyau. La société Sun propose l’outil Dtrace dans son système d’exploitation Solaris et la sophistication de cet outil a provoqué un très grand intérêt dans le monde informatique au point que le projet FreeBSD a décidé de porter Dtrace vers son propre environnement. La puissance du logiciel de Sun a provoqué un sentiment d’envie chez les développeurs Linux qui, pour revenir à parité, ont accéléré leurs efforts. Le premier résultat est Kernel Markers qui permet d’insérer des points de contrôles statiques dans le noyau. Le fait que ces points soient statiques est important car cela leur permet d’être insensibles aux modifications de code qui les rendraient obsolètes à très court terme et cela rend négligeable leur impact sur les performances. Maintenant que cette infrastructure est en place les outils concurrents de Dtrace (comme SystemTap ou LTTng) vont pouvoir s’appuyer dessus pour devenir compétitifs.
  • Une autre nouveauté de ce noyau est le mécanisme d’autorisation des périphériques USB. Dans un futur proche la nouvelle norme Wireless USB (c’est à dire le branchement des périphériques par ondes radio) va faire son apparition. Cela pose évidemment un problème de sécurité nouveau qu’il faut résoudre dès maintenant. Actuellement quand un utilisateur branche par exemple un disque dur USB le noyau suppose que ce périphérique est autorisé et il est automatiquement configuré et rendu disponible. Avec le WUSB et ses connexions sans fil à distance il faut mettre en place un mécanisme d’authentification similaire au WPA qui existe pour les réseaux Wi-Fi. La spécification WUSB a pris en compte ce problème et le noyau 2.6.24 implémente maintenant ce mécanisme qui permettra d’éviter que votre voisin puisse se connecter sur votre disque dur WUSB tout neuf. Pour entrer un peu plus dans les détails la partie authentification est laissée à un programme en espace utilisateur alors que la partie autorisation relève du noyau. Cela permet de bien séparer les fonctions et d’éviter de faire entrer dans le noyau un grand nombre de lignes de code qui peuvent tout aussi bien rester à l’extérieur. Maintenant chaque périphérique USB a trois flags supplémentaires: wusb, authorized, et authenticated et l’administrateur de la machine peut changer librement la valeur de ces flags. On voit immédiatement le profit pour la gestion des périphériques USB classiques qui peut être tiré de cette infrastructure introduite pour accueillir le Wireless USB. Par exemple maintenant un administrateur peut décider que les souris et les claviers sont autorisés (en leur passant le flag authorized à 1) alors que les imprimantes et les périphériques de stockage sont interdits (valeur 0 dans leur flag). Ce mécanisme d’autorisation introduit donc beaucoup de souplesse dans la gestion fine des périphériques sous Linux.
  • Le patch permettant le réglage intelligent de la vitesse d’écriture a été intégré au noyau. Avant ce patch l’écriture sur un disque se passait de la façon suivante: Une application voulant écrire des données utilise la fonction write() et le noyau copie ces données dans la mémoire vive en mettant un flag « dirty ». Ce flag signifie que ces pages mémoire ne doivent pas être réutilisées tant que le disque dur n’aura pas effectivement écrit toutes les données. Le danger c’est que l’application continue d’écrire dans la mémoire plus rapidement que le disque ne peut absorber. La conséquence c’est que de plus en plus de pages mémoires deviennent « dirty » ce qui peut, dans des cas extrêmes, mettre en danger la stabilité de la machine qui n’aurait plus assez de mémoire vive. Pour éviter cette fâcheuse situation le noyau contrôle en permanence la quantité totale de pages « dirty » et, en cas de besoin, il force le processus à écrire directement sur le disque (ce qui est lent) au lieu d’écrire dans la mémoire. Jusqu’à présent ce mécanisme de contrôle n’était pas intelligent et il forçait tous les processus à ralentir ! Ainsi une clé USB très lente, ne pouvant donc pas absorber assez vite les pages « dirty », va entraîner le déclenchement par le noyau du processus de contrôle ce qui va ralentir tous les processus écrivant sur des périphériques.
    Peter Zijlstra a donc proposé un patch qui permet un contrôle pour chaque disque (et non plus global). Ainsi quand le contrôle de vitesse se déclenche pour le processus écrivant sur la clé USB, les autres processus, ceux qui écrivent sur des disques rapides, peuvent continuer à remplir des pages « dirty » dans la mémoire vive. Bien entendu la partie difficile de cette solution est d’arriver à déterminer le moment exact où doit se déclencher le contrôle autoritaire. Pour bien faire les choses un processus écrivant sur un disque rapide devrait avoir droit à plus de pages « dirty » qu’un autre écrivant sur un périphérique lent et le contrôle ne devrait pas se déclencher avec le même seuil. Pour prendre ces décisions délicates Peter Zijlstra a introduit la bibliothèque « Floating Proportions« . Cette dernière permet de suivre le nombre d’écritures effectives sur chaque disque et d’accorder des quotas de pages « dirty » en fonction de ces résultats. Ce réglage intelligent de la vitesse d’écriture permet ainsi d’améliorer les performances et la robustesse des entrées/sorties sous Linux.
  • Outre les nouveautés décrites ci-dessus, une multitude d’autres nouveautés sont présentes dans ce noyau.
    • De très nombreux pilotes Wi-Fi utilisant la nouvelle pile mac80211 (introduite dans le 2.6.22) entrent enfin dans la branche principale. Cela représente 2,3 Mo de code source ce qui donne une indication du nombre de pilotes. On trouve notamment celui de la carte Intel PRO/Wireless 3945ABG/BG ou encore de la carte Broadcom BCM43xx.
    • Après la correction de quelques problèmes de jeunesse le nouvel allocateur de mémoire SLUB, inclus dans le noyau 2.6.22, a été optimisé par Christoph Lemeter. On observe un gain de 10 à 20% quand l’allocation est de la même taille que la page mémoire et de 50% quand la libération est de la même taille que la page mémoire.
    • Pour des raisons de sécurité il n’est plus possible de charger des modules à chaud par l’intermédiaire de l’interface LSM. Les modules de sécurité devront donc être inclus lors de la compilation du noyau (ce qui va évidemment poser des problèmes aux firmes diaboliques qui utilisaient LSM pour brancher leurs modules propriétaires).
    • Toujours dans le domaine de la sécurité l’algorithme de chiffrement symétrique SEED, très répandu en Corée, est inclus dans le noyau.
    • L’allocation de port pour les protocoles UDP et SCTP se fait maintenant de façon non prévisible comme c’était déjà le cas avec TCP et ce afin de renforcer la sécurité.
    • Les disques SATA utilisent désormais par défaut la gestion de l’économie d’énergie par ACPI (même si le commentaire lapidaire et humoristique du commit laisse craindre le pire 😉
    • Le patch LRO (Large receive offload) permet d’agréger les multiples paquets TCP reçus en un seul gros paquet ce qui permet de réduire le travail de la pile réseau et donc d’augmenter les performances de la machine. Les pilotes réseau seront modifiés progressivement pour tirer partie de cette nouvelle fonction.
    • L’API de la couche d’abstraction des systèmes de fichiers (VFS) a été modifiée afin d’éviter un risque d’interblocage. Les mainteneurs de systèmes de fichiers qui ne sont pas dans la branche principale de Linux vont devoir, à moyen terme, adapter leur code.
    • Le système de fichiers CIFS inclus dans le noyau devient compatible avec les listes de contrôle d’accès (ACL).
    • Il est maintenant possible d’utiliser la fonction de multiplicateurs de ports de la norme SATA. Cela permet à plusieurs disques d’utiliser simultanément le même port SATA.

    La liste détaillant toutes les nouveautés (réseaux, systèmes de fichier, pilotes disques, cartes son, vidéo, Bluetooth, etc.) est disponible sur le site de Kernelnewbies.

Comme c’est devenu l’usage le site Linux Weekly News propose un article résumant les multiples contributions durant ce cycle. On apprend ainsi que le plafond des 10000 patchs a été dépassé (seulement 6200 patchs pour le 2.6.23) et que le nombre de contributeurs a été de 950 contre 860 pour le noyau précédent. Si on regarde le bilan global de l’année 2007 ce sont plus de 1900 développeurs qui sont intervenus sur le noyau en produisant plus de 30000 patchs (ce qui représente 5000 modifications de lignes de code par jour).
De nombreuses autres statistiques très intéressantes sont également présentes dans cet article et la conclusion est rassurante à lire :

L’image qui résulte de tous ces chiffres est celle d’une communauté de développement saine et diversifiée. Le noyau est vraiment une ressource commune avec littéralement des milliers de personnes qui travaillent pour l’améliorer. Et il ne montre aucun signe de ralentissement de sitôt.

Most active 2.6.24 employers
By changesets
(None) 1417 14.1%
(Unknown) 1108 11.1%
Red Hat 1045 10.4%
IBM 819 8.2%
Novell 680 6.8%
Intel 446 4.5%
linutronix 369 3.7%
Oracle 240 2.4%
SWsoft 212 2.1%
CERN 205 2.0%
Movial 190 1.9%
Linux Foundation 190 1.9%
MIPS Technologies 176 1.8%
Renesas Technology 140 1.4%
(Academia) 132 1.3%
Freescale 126 1.3%
MontaVista 122 1.2%
Analog Devices 115 1.1%
(Consultant) 112 1.1%
NetApp 101 1.0%
By lines changed
(None) 140730 18.0%
(Unknown) 121511 15.5%
Intel 114990 14.7%
Red Hat 58858 7.5%
IBM 51777 6.6%
linutronix 47968 6.1%
Novell 29856 3.8%
Movial 19093 2.4%
Freescale 15262 1.9%
Analog Devices 14971 1.9%
MIPS Technologies 11726 1.5%
SWsoft 8331 1.1%
Linux Foundation 7917 1.0%
Oracle 7777 1.0%
Atmel 7125 0.9%
CERN 6618 0.8%
Renesas Technology 6414 0.8%
Google 6373 0.8%
MontaVista 6026 0.8%
NetApp 5620 0.7%
Top contributors in 2007
By developer
Ralf Baechle 507 1.7%
Thomas Gleixner 485 1.6%
David S. Miller 468 1.6%
Adrian Bunk 439 1.5%
Tejun Heo 394 1.3%
Ingo Molnar 351 1.2%
Paul Mundt 351 1.2%
Al Viro 337 1.1%
Bartlomiej Zolnierkiewicz 330 1.1%
Andrew Morton 319 1.1%
Stephen Hemminger 302 1.0%
Patrick McHardy 277 0.9%
Alan Cox 270 0.9%
Takashi Iwai 269 0.9%
Trond Myklebust 256 0.9%
David Brownell 254 0.8%
Avi Kivity 229 0.8%
Jeff Dike 227 0.8%
Jeff Garzik 216 0.7%
Jean Delvare 215 0.7%
By employer
(None) 4881 16.2%
Red Hat 3441 11.4%
(Unknown) 2933 9.7%
IBM 2379 7.9%
Novell 2054 6.8%
Intel 1060 3.5%
Linux Foundation 784 2.6%
Oracle 677 2.2%
(Consultant) 631 2.1%
MIPS Technologies 507 1.7%
linutronix 507 1.7%
Renesas Technology 394 1.3%
(Academia) 392 1.3%
SWsoft 384 1.3%
SGI 368 1.2%
MontaVista 342 1.1%
CERN 330 1.1%
Freescale 291 1.0%
NetApp 279 0.9%
Astaro 277 0.9%

Pour la suite…
En ce qui concerne le futur du noyau Linux on peut se tourner vers la page spécifique maintenue par Jonathan Corbet.

  • L’outil de tracing utrace, qui était pressenti pour faire son entrée dans le 2.6.24, a été retardé mais il devrait être présent dès la prochaine mouture de Linux.
  • Le module de sécurité SMACK (Simplified Mandatory Access Control Kernel), qui est développé par Casey Schaufler, pourrait entrer en mainline et faire concurrence à SELinux en proposant moins de fonctions mais une configuration bien plus simple. Casey propose régulièrement des mises à jour de version qui intègrent la branche de test -mm sans problèmes ce qui est de bon augure pour le futur de ce module.
  • Le système de fichier de nouvelle génération ext4 continue sa phase de développement et il incorpore de nouvelles fonctions. Cette fois-ci c’est UBG (uninitialized block groups) qui est annoncé. Cela consiste à contrôler si un bloc disque a été initialisé ou pas. Si le bloc n’a jamais été utilisé alors le programme fsck n’aura pas besoin de le vérifier lors de son passage suivant. Cela permet potentiellement de gagner beaucoup de temps lors du boot (entre 2 et 20 fois plus rapide) quand on doit procéder à l’examen d’un disque.
  • Le support des bus de données de type CAN (Controller Area Network) est en cours de développement par des ingénieurs de la société Volkswagen. Cette nouvelle infrastructure PF_CAN devrait faire son entrée dans le noyau 2.6.25 ou 2.6.26 et faciliter ainsi l’utilisation de Linux au sein de l’industrie automobile .
  • Enfin le vieux serpent de mer du débogueur interactif intégré au noyau refait surface. Selon les prévisions de Jon Corbet il y a une chance non nulle qu’en dépit de la mauvaise volonté de Linus, qui n’aime pas les débogueurs intégrés (voir le fameux post « because i’m a bastard« ), le patch KGDB puisse faire partie du prochain noyau 2.6.25

Autres sites d’informations sur le noyau Linux:

http://kernelnewbies.org/LinuxChanges (« A comprehensible changelog of the Linux kernel, this page shows a summary of the important changes being added in each Linux kernel release – support for new devices, features, filesystems, and subsystems as well as important internal changes. While this text is aimed to be readable (unlike the full changelog), its primary audience is those who know a fair amount about how a kernel operates. Other places to get news about the Linux kernel are LWN kernel status, LWN driver porting guide, LWN list of API changes in 2.6, or www.lkml.org. If you’re going to add something here look first at LinuxChangesRules!« )

http://lwn.net/Kernel/ (« LWN.net’s coverage of Linux kernel development is detailed, technical, and timely. »)

Posted in Authentification, linux, machines virtuelles, open source, Réseau, Sécurité informatique, système embarqué, Temps réel, virtualisation | Tagué: , , , , , , | Leave a Comment »

Ce qui caractérise les utilisateurs de logiciels libres

Posted by patrick sur janvier 24, 2008

Source: http://framablog.org/index.php/post/2008/01/22/Ce-qui-caracterise-un-utilisateur-de-logiciels-libres (« Alors voilà. Nous y sommes. Le logiciel libre est clairement en train de gagner la bataille du desktop. Quelque soit son système d’exploitation, on trouve désormais des logiciels libres de grande qualité répondant à tous les usages de base (web, bureautique, graphisme, multimédia…). Dans le même temps des distributions GNU/Linux toujours plus conviviales arrivent à maturité et les revendeurs ne s’y trompent pas puisqu’ils commencent à en proposer au grand public dans leurs offres d’ordinateurs neufs. Cependant n’oublions pas la phrase en exergue de ce blog : « …mais ce serait peut-être l’une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d’autre que du code ». En effet, utiliser des logiciels libres c’est non seulement faire des économies, c’est non seulement se retrouver avec plein d’applications qui nous comblent au quotidien mais c’est aussi et surtout adopter certains comportements (et rompre avec d’autres), participer à un mouvement et, osons le mot, faire partie d’une culture. Une culture qui favorise l’écoute, l’indépendance et l’autonomie. Une culture de coopération et non de compétition. Une culture aux antipodes de certaines logiques et structures politico-économiques qui nous demandent avant tout d’être des consommateurs passifs. Il serait non seulement dommage mais fort dommageable que la nouvelle génération d’utilisateurs fraîchement débarqués du monde Windows, et dont Framasoft se réclame, perde cela de vue… La traduction que nous vous proposons aujourd’hui brosse le portrait d’un utilisateur de logiciels libres en soulignant neuf caractéristiques qui le distinguent justement de l’utilisateur de logiciels propriétaires.Parce qu’il en va de la responsabilité de tous que cette précieuse culture ne se dilue pas avec sa démocratisation…« )

Lire la suite sur le blog de Framasoft:  http://framablog.org/index.php/post/2008/01/22/Ce-qui-caracterise-un-utilisateur-de-logiciels-libres

 Voir:

http://fr.wikipedia.org/wiki/Framasoft (« Framasoft est un réseau de sites web collaboratif à géométrie variable dont le dénominateur commun est le logiciel libre et son état d’esprit. Il vise à faire connaître et diffuser le logiciel libre au plus large public. Lieu d’informations, d’actualités, d’échanges et de projets, Framasoft, de par la diversité et le dynamisme de son réseau, est aujourd’hui l’une des portes d’entrée francophones du logiciel libre. Sa communauté accompagne ceux qui souhaitent substituer leurs logiciels propriétaires par des logiciels libres. Elle attache une attention toute particulière au processus de migration du système d’exploitation Microsoft Windows vers GNU/Linux. Framasoft a été créé en novembre 2001 par Alexis Kauffmann, professeur de mathématiques. Le nom dérive de Framanet (pour FRAnçais et MAthématiques en intraNET), projet éducatif dont Framasoft a d’abord été une rubrique logicielle avant de devenir indépendante« )

http://framablog.org/ (« Framablog.org est le blog du réseau Framasoft. Il évoque aussi bien l’actualité du logiciel libre en général que celle du réseau Framasoft en particulier. Il propose souvent des traductions originales d’articles anglophones via le groupe de travail Framalang. »)

Posted in culture, GNU/Linux, logiciel libre, migration vers le libre, open source | Tagué: , | Leave a Comment »

Taxe windows, vente liée : quel argumentaire développer face à un vendeur ?

Posted by patrick sur janvier 23, 2008

Source: APRIL
Racket

« Récemment, en demandant à un vendeur de la Fnac s’ils vendaient des PC sans OS, le seul argument valide qui m’a été opposé est que la Fnac est un revendeur et non pas un intégrateur. Ceci justifie donc à leurs yeux le fait que seul Windows (ou Mac) soit proposé sur leurs machines. Dans quelle mesure cet argument peut-être combattu et avec quels arguments ? »

« La loi (notamment les articles L122-1, L113-3 et 111-1 du code de la consommation) interdit la vente liée, oblige les vendeurs à informer sur les prix et les conditions particulières. Il est précisé ‘vendeur’
dans la loi, et pas « intégrateur » ou « fournisseur ». D’autres articles comme la loi sur les cadeaux nous informe que si les logiciels sont offerts, cela veut dire qu’ils coutent (au total) moins de 60€. Enfin, la loi sur les garanties nous informe que la garantie est obligatoire même en cas de changement de système d’exploitation.

Aujourd’hui, cependant, les rares personnes a avoir *vraiment* obtenu
un ordinateur sans logiciels sont passées par la case procès. C’est
triste, mais c’est comme ça.

Quelques liens supplémentaires vers des articles de loi (qu’il est toujours bon de connaître, même si la tête dans le code de la consommation, les vendeurs refusent d’admettre l’illégalité de la situation) :

Si tu cherches aujourd’hui à acheter un ordinateur sans logiciels, je
te propose de t’inscrire à la liste de diffusion détaxe http://www.aful.org/wws/info/detaxe. C’est sur cette liste que se traitent
les tentatives d’achat sans logiciels.

Merci à Jerémy Monnet pour ces informations.

A Voir:

http://fr.wikipedia.org/wiki/Taxe_Windows (« désigne le prix masqué de Microsoft Windows fourni avec la quasi-totalité des ordinateurs et, par extension, le coût de toutes les licences de logiciels imposées à l’achat d’un ordinateur. L’expression, jeu de mot en référence à l’ancienne taxe sur les fenêtres « Window Tax », a été lancée aux États-Unis par des utilisateurs de logiciels libres utilisant des systèmes d’exploitationGNU/Linux et BSD. En France, le terme fait référence à : alternatifs à Microsoft Windows, notamment

  • l’obligation de payer pour les licences de logiciels, même dans le cas où l’acheteur refuse les contrats de licence des logiciels ;
  • au fait que l’État soutient cette « taxe » en ne faisant pas appliquer l’article L122-1 du Code de la consommation interdisant explicitement la vente liée d’un bien (le matériel) et d’un service (les licences de logiciels).« )

https://listes.aful.org/wws/info/detaxe (« La liste DETAXE, hébergée par l’association AFUL, est une liste de discussion liée au Groupe de Travail (GdT) Détaxe de l’AFUL, dont les buts sont :

  • – En amont, d’obtenir de pouvoir acheter tout type d’ordinateurs sans payer les logiciels pre-installés, c-à-d de faire respecter les droits des consommateurs en ce qui concerne les VENTES LIEES (dites aussi ventes subordonnées) de LOGICIELS lors de l’achat d’ordinateurs;
  • En aval d’obtenir le remboursement des logiciels non désirés. Corollairement, ceci concerne aussi le monopole lucratif de Microsoft sur le marché de l’informatique grand public.

C’est un canal de discussion ouvert sur abonnement (ici, colonne de gauche !) en complément du Wiki http://www.aful.org/sections/wikis/detaxe/PageAccueil et de la page d’information http://www.detaxe.org. Vous pouvez aussi signer la pétition http://www.racketiciel.info« )

Posted in april, logiciel libre | Leave a Comment »

Comment poster du code python avec WordPress ? -> [sourcecode language="python"']xxxx [/sourcecode]

Posted by patrick sur janvier 21, 2008

Pour poster du code python, il faut utiliser dans la fenêtre de composition visuel de l’éditeur et placer le code python entre les balises suivantes: balises python

'['sourcecode language="python"']'  xxxx [/sourcecode]

supprimer les '' autour de '[' et ']'

Source: http://www.edwardandrewrobinson.com/source_code_to_wordpress.txt

Exemple 1:

indentation python
#This
#is an example
#of what your source code will look like
x = True
if x:
    print 'hello world'

Exemple 2:

sourcecode_python1.png
from django.utils.translation import ugettext as _
def my_view(request):
    output = _(&quot;Welcome to my site.&quot;)
    return HttpResponse(output)

Exemple 3:



exemple 3
def my_view(request):
    sentence = 'Welcome to my site.'
    output = _(sentence)
    return HttpResponse(output)

Posted in blogs, python, Web applications, wordpress | Tagué: | Leave a Comment »

Twisted : le moteur réseau événementiel écrit en Python + scapy l’outil python très puissant d’analyse de paquets + kamaelia le framework python développé par la BBC

Posted by patrick sur janvier 21, 2008

Dans Linux-Fr, on parle du passage de NuLog de PHP à Python (utilisation de Twisted). C’est donc une bonne occasion de parler de Twisted.

http://linuxfr.org/2008/01/18/23582.html (« Sécurité : Nulog 2 est disponible Posté par _gryzor_ (display_envoyermessageperso(‘_gryzor_’);). Modéré le vendredi 18 janvier. isadmin(‘23582’)

Voici la 2ème génération de l’incontournable outil d’analyse de fichiers journaux de pare-feu. Nulog2, presque 6 ans après la v1, s’appuie toujours sur un format de journalisation SQL, mais présente les informations de manière plus synthétique, et beaucoup plus exploitable.
Au menu des nouveautés :

  • Réécriture complète du code, passage de PHP à Python avec Twisted Matrix ;
  • Génération à la volée de diagrammes et de camemberts, au souhait de l’utilisateur ;
  • Personnalisation totale de la page d’accueil, pour chaque utilisateur ;
  • Refonte de l’ergonomie de l’outil et de la manipulation des critères d’affichage des connexions réseaux ;
  • Possibilités de recherches beaucoup plus avancées ;
  • Export des données affichées en CSV pour traitement personnalisé ;
  • Passage à la licence GPLv3.

Bien entendu, Nulog2, permet, comme la v1, d’exploiter des logs authentifiés par un pare-feu NuFW. Il est donc très simple de créer ses propres indicateurs à placer sur sa page d’accueil, par exemple « Histogramme des derniers paquets droppés des trois dernières heures de l’IP 10.56.140.47 ou de l’utilisateur Martin ».

Voir:

http://en.wikipedia.org/wiki/Twisted_%28software%29 (« Twisted is an event-driven network programming framework written in Python and licensed under the MIT License. Twisted projects variously support TCP, UDP, SSL/TLS, IP Multicast, Unix domain sockets, a large number of protocols (including HTTP, NNTP, IMAP, SSH, IRC, FTP, and others), and much more. Twisted is based on the event-driven programming paradigm, which means that users of Twisted write short callbacks which are called by the framework...Deferreds Central to the Twisted application model is the concept of a deferred (elsewhere called a future). A deferred is a value which has not been computed yet, for example because it needs data from a remote peer. Deferreds can be passed around, just like regular objects, but cannot be asked for their value. Each deferred supports a callback chain. When the deferred gets the value, it is transferred through the callback chain, with the result of each callback being the input for the next one. This allows operating on the values of a deferred without knowing what they are…« )

Twisted

http://twistedmatrix.com/trac/wiki/Downloads  (« Source Checkout .To checkout code from the repository, use: 

svn co svn://svn.twistedmatrix.com/svn/Twisted/trunk  Twisted« )

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/84317 (« Easy threading with Futures. Although Python’s thread syntax is nicer than in many languages, it can still be a pain if all one wants to do is run a time-consuming function in a separate thread, while allowing the main thread to continue uninterrupted. A Future provides a legible and intuitive way to achieve such an end. »)

http://linuxfr.org/2008/01/18/23582.html (« Explications du passage de PHP à Python par Eric Leblond. La question est mieux posée dans le sujet que dans le corps du message. Il y a en effet deux choses séparées : 1) le passage d’un langage à un framework et 2) le passage de PHP à Python
Le choix 1 est simple : J’ai commencé à travaillé sur nulog 1) (connu comme ulog-php à l’époque) aux alentours de 2001/2002 . La notion de framework n’était pas encore bien implantée (voir même n’existait pas). Début 2007, nulog commençait à devenir difficile à faire évoluer et nous avons donc décidé de lancer un projet de réécriture au sein d’INL (dont je fais parti). Le projet Nulog 2 a ainsi été initié avec dès le départ la décision d’utiliser un framework et une architecture MVC. Le choix 2) s’explique par plusieurs points: Grandes qualités du framework Twisted, notamment capacité à offrir des vues dans des protocoles variés (SOAP, XML-RPC, IRC, HTTP). Présence de bons développeurs Python à INL, développeurs capable d’épauler Romain Bignon, développeur principal de Nulog 2. Langage PHP trop laxiste et surtout lié au web alors que l’on souhaitait ne pas se limiter à ce media. L’ensemble de ces raisons nous ont fait abandonner PHP pour passer à Python/Twisted
. »)

– le numéro 100 de Linux Magazine p.72 « Utilisez Twisted, un moteur réseau événementiel écrit en Python et sous licence MIT » écrit par Sylvain de Tilly.

http://nufw.org/ (« NuFW ajoute la notion d’utilisateurs aux règles de filtrage. Le projet s’appuie sur Netfilter, la couche pare-feu du noyau Linux et est disponible sous licence GPLv3. »)

http://software.inl.fr/trac/wiki/EdenWall/NuLog2 (« Nulog2 is a complete rewrite of Nulog the historical filtering log analysis solution from INL. Nulog2 is an application build upon Twisted, an advanced Python framework…You can also directly checkout subversion source:

svn co http://software.inl.fr/svn/mirror/edenwall/nulog2/trunk/ nulog2

Nulog2’s Source are available for browsing… »)

http://inl.fr/ (« INL propose des solutions Logiciels Libres aux entreprises et administrations qui cherchent des services et produits fiables et sécurisés. Nous fournissons des produits intégrés de haut niveau, autour de solutions bien connues, comme Spamassassin, Postfix, Apache, etc, auxquelles nous contribuons. Nous menons également des développements innovants, à la pointe des technologies actuelles au bénéfice de la communauté du Logiciel Libre. »)

http://wiki.python.org/moin/WebServers (« TwistedMatrix includes a very scalable web server written in Python. »)

http://wiki.python.org/moin/TwistedMatrix (« *NOT* just framework for WebProgramming. Includes a scalable and safe web server that outperforms apache in terms of security and scalability« )

Sujet lié à la sécurité et au réseau: scapy

http://linuxfr.org/2007/10/27/23264.html (« Scapy est un utilitaire Open Source en Python développé par Philippe Biondi, cet outil vous permet de disséquer, de forger, de recevoir et d’émettre des paquets (et des trames) de données pour un grand nombre de protocoles que vous pourrez également décoder : DNS, DHCP, ARP, SNMP, ICMP, IP, TCP, UDP. L’un des seuls points faibles connu à ce jour, concernant Scapy, est son manque de documentation officielle ou non, notamment francophone, permettant de le destiner à un plus large public que les experts du domaine ; partant de ce constat, le site Secuobs.com, spécialisé dans le domaine de la sécurité informatique, met à disposition de tous un document venant combler une partie de ce manque. Vous y apprendrez notamment comment installer et configurer Scapy ainsi que les rêgles rudimentaires relatives à son utilisation (commandes basiques et avancées) et à la manipulation de paquets (et de trames) de données dont un exemple de génération de graphiques 2D/3D à partir des résultats d’un traceroute réalisé à l’aide de Scapy.

« )

http://trac.secdev.org/scapydoc-com/wiki/FRscapydoc (« D’après la documentation officielle (man scapy), Scapy est un puissant programme interactif de manipulation de paquets. Il peut forger ou décoder les paquets d’un grand nombre de protocoles, les émettre, les capturer, faire correspondre des requêtes et des réponses et bien plus encore. Il permet la manipulation de la plupart des outils de scan, traceroute, de sonde, de tests unitaires, d’attaques ou de découverte de réseau (il remplace facilement hping, 85% de nmap, arpspoof, arp-sk, arping, tcpdump, tethereal, p0f, etc.). Il se comporte également très bien sur un grand nombre de tâches qu’un grand nombre de programme n’est pas en mesure de manipuler, comme envoyer des trames invalides, injecter vos propres trames 802.11, combiner des techniques (VLAN hopping+ARP cache poisoning, VOIP decoding sur canal chiffré en WEP…), etc.Scapy est écrit en python, parce que le python, c’est bien. Personne n’a besoin de comparer Python à Ruby. Par contre, tout le monde se sent obligé de comparer Ruby à Python. À vous d’en tirer les conclusions.) »)

http://trac.secdev.org/scapydoc-com/wiki/FrInstall (« Scapy est un logiciel écrit en langage Python qui se rapproche de la famille des langages de script. Pour pouvoir utiliser Scapy, il suffit donc de posséder un interpréteur de commande Python.

Commencez par télécharger le script avec l’une des méthodes suivantes :

  • La dernière version issue du dépôt (recommandé, mis à jour régulièrement)
  • Le tarball, version 1.1.1 (peu mis à jour)

Il vous suffit de copier le script dans le répertoire de votre librairie python actuelle :

wget http://hg.secdev.org/scapy/raw-file/tip/scapy.py
cp scapy.py /var/lib/python-support/python2.4/

Il peut être intéressant de créer un lanceur directement dans le répertoire d’exécution des binaires de l’utilisateur :

$ cat /usr/bin/scapy
#!/bin/sh
exec /usr/bin/python /var/lib/python-support/`pyversions -d`/scapy.py

Si vous possédez une distribution GNU/Linux :

aptitude install scapy
urpmi scapy

Il existe également un portage pour l’OS privatif de Microsoft :

Vous avez maintenant les outils nécessaires, passons à la mise en pratique« )

– pour information, Philippe Biondy prépare un numéro spécial sur Python pour Linux Magazine (source http://lists.afpy.org/mailman/listinfo/afpy-membres)

======================

Kamaelia

–  http://en.wikipedia.org/wiki/Kamaelia  (« Kamaelia is a free software/open source Python-based systems-development tool and concurrency framework produced by BBC Research. Kamaelia applications are produced by linking independent components together. These components communicate entirely through « inboxes » and « outboxes » (queues) largely removing the burdens of thread-safety and IPC from the developer. This also makes components reusable in different systems, allows easy unit testing and results in parallelism (between components) by default. Components are generally implemented as generators – a method more light-weight than allocating a thread to each (though this is also supported). As a result, switching between the execution of components in Kamaelia systems is very fast. Applications that have been produced using Kamaelia include a Freeview digital video recorder, a network-shared whiteboard, a 3D GUI, an HTTP Server, an audio mixer, a stream multicasting system and a simple BitTorrent client. »)

http://kamaelia.sourceforge.net/Introduction (« A key aim of Kamaelia is to enable even novice programmers to create scalable and safe concurrent systems, quickly and easily. Lego/K’nex for programmers. For people. For building things. It’s about making concurrency on systems easier to use, so easy you forget that you’re using it. It’s been done once before, spectacularly well, so well many people forget it’s there, a key example – unix pipelines. However it’s been done in hardware since day 1, since that’s how hardware works. One day, I sat back and realised that network systems looked almost identical in nature to the asynchronous hardware systems, conceptually, with one major exception. In hardware, you don’t know who your buffers are connected to via wires. You have a protocol for getting that information over (be it a clock, or handshake circuits) but no other knowledge. Kamaelia was borne, technology wise, from the idea « what if we developed software like hardware » – each component with no direct knowledge of any other. Similar to programs in a unix pipeline. This is proving to be a very useful approach. Kamaelia is the result. Kamaelia is divided into 2 sections:

  • Axon – this is a framework, developed by application spikes, for wrapping active objects. Specifically these are generators (mainly) and threads. The resulting library at it’s core is pretty simple – a novice programmer can learn python one week and implement their own version in about a week.
  • Kamaelia – this is the toy box – a library of components you can take and bolt together, and customise. This includes components for TCP/multicast clients and servers, backplanes, chassis, Dirac video encoding & decoding, Vorbis decoding, pygame & Tk based user interfaces and Tk, visualisation tools, presentation tools, games tools…

The reason for concurrency here isn’t because we’re after performance, but due to the problems we’re facing are naturally
concurrent – millions of people watching content
. Therefore, the aim is to make dealing with this concurrency simple/easy, or natural/fun. Hence the lego/K’nex analogy
.
« )

http://kamaelia.sourceforge.net/Repository (« Checking out a working copy

From the command line:

You can check out the whole repository, but be warned, we use alot of branches – so your initial checkout may be rather large! You can also view the repository contents from a web browser here. There are more details about the subversion service on sourceforge.net. Keeping abreast of check-ins:
Keep tabs on the check-ins we make by subscribing to the kamaelia-commits mailing list.
« )

http://yeoldeclue.com/cgi-bin/blog/blog.cgi (« un blog très original »)

http://darkness.codefu.org/wordpress/ (« Kamaelia looks interesting. The system of “wiring” components together feels right to me; I was first exposed to this in NesC. However, the implementation needs to be updated to support the new features of generators in Python 2.5, as the current syntax strikes me as rather ugly. In fact, it looks like Kamaelia needs a recent release, period: the last one I saw was from 2006… (As a side note: everything should be easy_installable. Kamaelia and Twisted are not, though Twisted has ongoing work to this end ».)

http://yeoldeclue.com/cgi-bin/blog/blog.cgi?rm=viewpost&nodeid=1200187974 (« Interesting wishlist for kamaelia (and others, but I’m interested from a kamaelia perspective) here: http://darkness.codefu.org/wordpress/2007/12/26/295
I’m not sure I buy all the criticisms, and feel they’re more a wish-list in terms of improvements specific points mentioned about kamaelia as (IMO) potential wishlist items:
« ) »)

Posted in 2008, Internet, MVC, network applications, python, Sécurité informatique | Tagué: , , | Leave a Comment »

Nouvelles de python pour la semaine du 14 au 20 janvier 2008

Posted by patrick sur janvier 21, 2008

En vrac, quelques nouvelles de python

================================
http://highscalability.com/youtube-architecture (« – encore sur la liste Tutor, on apprend que YouTube emploie Python: YouTube grew incredibly fast, to over 100 million video views per day, with only a handful of people responsible for scaling the site. How did they manage to deliver all that video to all those users? And how have they evolved since being acquired by Google?

Information Sources

  • Google Video

    Platform

  • Apache
  • Python
  • Linux (SuSe)
  • MySQL
  • psyco, a dynamic python->C compiler
  • lighttpd for video instead of Apache

    What’s Inside?

    The Stats

  • Supports the delivery of over 100 million videos per day.
  • Founded 2/2005
  • 3/2006 30 million video views/day
  • 7/2006 100 million video views/day
  • 2 sysadmins, 2 scalability software architects
  • 2 feature developers, 2 network engineers, 1 DBA
  • Web Servers

  • NetScalar is used for load balancing and caching static content.
  • Run Apache with mod_fast_cgi.
  • Requests are routed for handling by a Python application server.
  • Application server talks to various databases and other informations sources to get all the data and formats the html page.
  • Can usually scale web tier by adding more machines.
  • The Python web code is usually NOT the bottleneck, it spends most of its time blocked on RPCs.
  • Python allows rapid flexible development and deployment. This is critical given the competition they face.
  • Usually less than 100 ms page service times.
  • Use psyco, a dynamic python->C compiler that uses a JIT compiler approach to optimize inner loops.
  • For high CPU intensive activities like encryption, they use C extensions.
  • Some pre-generated cached HTML for expensive to render blocks.
  • Row level caching in the database.
  • Fully formed Python objects are cached.
  • Some data are calculated and sent to each application so the values are cached in local memory. This is an underused strategy. The fastest cache is in your application server and it doesn’t take much time to send precalculated data to all your servers. Just have an agent that watches for changes, precalculates, and sends….)
  • =============================
    http://www.oreillynet.com/onlamp/blog/2008/01/pymotw_threading.html (« Doug Hellman’s Python Module of the Week is all about threading. »)

    http://www.python.org/dev/peps/pep-0369/ (« This PEP proposes enhancements for the import machinery to add post import hooks. It is intended primarily to support the wider use of abstract base classes that is expected in Python 3.0.The PEP originally started as a combined PEP for lazy imports and post import hooks. After some discussion on the python-dev mailing list the PEP was parted in two separate PEPs « )

    http://www.python.org/dev/peps/pep-3119/ (… Abstract This is a proposal to add Abstract Base Class (ABC) support to Python 3000. It proposes:

    • A way to overload isinstance() and issubclass().
    • A new module abc which serves as an « ABC support framework ». It defines a metaclass for use with ABCs and a decorator that can be used to define abstract methods.
    • Specific ABCs for containers and iterators, to be added to the collections module.

    Much of the thinking that went into the proposal is not about the specific mechanism of ABCs, as contrasted with Interfaces or Generic Functions (GFs), but about clarifying philosophical issues like « what makes a set », « what makes a mapping » and « what makes a sequence ». There’s also a companion PEP 3141, which defines ABCs for numeric types. Acknowledgements Talin wrote the Rationale below [1] as well as most of the section on ABCs vs. Interfaces. For that alone he deserves co-authorship. The rest of the PEP uses « I » referring to the first author. In the domain of object-oriented programming, the usage patterns for interacting with an object can be divided into two basic categories, which are ‘invocation’ and ‘inspection’. Invocation means interacting with an object by invoking its methods. Usually this is combined with polymorphism, so that invoking a given method may run different code depending on the type of an object. Inspection means the ability for external code (outside of the object’s methods) to examine the type or properties of that object, and make decisions on how to treat that object based on that informationone of the criticisms of inspection by classic OOP theorists is the lack of formalisms and the ad hoc nature of what is being inspected. In a language such as Python, in which almost any aspect of an object can be reflected and directly accessed by external code, there are many different ways to test whether an object conforms to a particular protocol or not. For example, if asking ‘is this object a mutable sequence container?’, one can look for a base class of ‘list’, or one can look for a method named ‘__getitem__’. But note that although these tests may seem obvious, neither of them are correct, as one generates false negatives, and the other false positivesThis PEP proposes a particular strategy for organizing these tests known as Abstract Base Classes, or ABC. ABCs are simply Python classes that are added into an object’s inheritance tree to signal certain features of that object to an external inspector. Tests are done using isinstance(), and the presence of a particular ABC means that the test has passed…Specification The specification follows the categories listed in the abstract:

    • A way to overload isinstance() and issubclass().
    • A new module abc which serves as an « ABC support framework ». It defines a metaclass for use with ABCs and a decorator that can be used to define abstract methods.
    • Specific ABCs for containers and iterators, to be added to the collections module. »)

    http://www.webfaction.com/demos/django (« How to install a real-life Django application on our servers. Watch Demo« )

    http://www.vulnerabilite.com/securite-open-source-audit-faille-coverity-actualite-20080110223332.html (« Doté d’une enveloppe initiale de 300 000 dollars, le programme Open Source Hardening Project a été lancé en mars 2006 avec pour mécène le département américain de la sécurité intérieure ( DHS ). Ce programme dont la conduite a été confiée à l’Université de Standford et à la société Coverity, a pour objectif de passer au crible le code de plusieurs logiciels open source (écrits en C et C++) parmi les plus populaires afin d’identifier les failles présentes, et ainsi contribuer au renforcement de leur sécurité... La société basée à San Francisco a par ailleurs défini plusieurs niveaux dans le processus de correction de bugs, soit 3 au total et a annoncé mardi que 11 projets open source ont atteint le niveau le plus élevé ( Rung 2 ). En raison des efforts fournis pour assurer de façon proactive l’intégrité et la sécurité des applications développées, Coverity indique que les entreprises et particuliers peuvent choisir avec encore plus de confiance les logiciels open source suivants : Amanda, NTP, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba et TCL... Si tous les logiciels contrôles ne peuvent pas encore prétendre au Rung 2, certains le pourront dans les prochains mois mais en attendant, Firefox ou encore Apache restent cantonnés au Rung 1 (86 projets), voire au Rung 0 (173 projets) comme nmap ce qui signifie que les bugs détectés n’ont pas encore été corrigés« )

    http://holdenweb.blogspot.com/2008/01/resolver-released.html (« In yet another piece of good news for Python fans, Resolver Systems have released their first product. It’s a spreadsheet that you can manipulate in Python, and it’s received a lot of interest from the financial communities on both sides of the Atlantic. [You would not believe how much of the world’s financial dealing is controlled and managed by spreadsheets; it’s really quite scary]. Resolver One is written in IronPython by a team which includes the Fuzzyman (occasionally also known as Michael Foord), of Voidspace Techie Blog fame, and it’s currently the largest product developed in that languages, with a total codebase (including tests) of over 100 kloc. The company is bravely making the product available (though not, I believe, as open source) free for non-commercial use.« )

    Posted in 2008, Ironpython, python, Web applications, Web Frameworks | Tagué: , , , , , | Leave a Comment »

    GUILDE: Conférence le mercredi 13 février 2008 sur « Cryptographie : protéger sa vie privée avec des logiciels libres »

    Posted by patrick sur janvier 20, 2008

    La guilde
    Source: http://www.guilde.asso.fr/rencontres/20080213/

    Cryptographie : protéger sa vie privée avec des logiciels libres
    Mercredi 13 février de 19:30 à 21:45,
    par Xavier Belanger, administrateur système
    à l’ENSIMAG, campus de Saint Martin d’Hères, Amphi E (accès).

    Sujets abordés

    • Principe du chiffrage à deux clés (publique/privée)
    • Les différents types de clé
    • Les logiciels PGP et GPG
    • Les interfaces graphiques
    • Signer ses courriers : Thunderbird et Enigmail
    • Réseaux de confiance et key-signing parties

    Communication

    N’hésitez pas à relayer l’annonce ou à mettre un lien vers cette page.

    Vous pouvez également imprimer et diffuser les affiches (PDF) : normale ou paysage. Dans ce cas, vous pouvez vous inscrire sur la page wiki pour coordonner les efforts des « colleurs d’affiche ».

    Posted in 2008, cryptographie, Guilde, logiciel libre | Tagué: , , , , | Leave a Comment »

    Les nouvelles de python pour la semaine du 7 au 13 janvier 2008

    Posted by patrick sur janvier 14, 2008

    – Utilisation d’Automation dans .NET3 avec IronPython (« Another option would be to use the System.Windows.Automation library – new in .NET 3.0. It’s a lot easier to use than the native APIs when it works for you. This sample will print the titles of all the top-level windows.

    jim1.pnghttp://ironpython-urls.blogspot.com/2008/01/ui-automation-on-fepy-blog.html (« à partir du courriel de Jim Hugunin: Jim Hugunin recently posted an example of using the .NET 3.0 UI Automation API from IronPython (code ci-dessus) . This library hasn’t yet been implemented for Mono, so Seon Sanghyeon has written two blog entries on using an equivalent, « Assistive Technology Service Provider Interface », with IronPython:

    http://fepy.blogspot.com/2008/01/using-at-spi-from-ironpython-1.html (« This adventure started when Jim Hugunin mentioned GUI test automation and assistive technology (such as screen readers) share some common needs. While UI Automation is named after the former, AT-SPI is named after the later. AT-SPI, which stands for « Assistive Technology Service Provider Interface » — this is the first of lengthy acronyms that will appear in this post — is an accessibility standard for Unix/X world. Initially developed by the GNOME project, now it is also supported by Java, Mozilla, OpenOffice.org, and Qt 4 …etc. »)

    http://fepy.blogspot.com/2008/01/using-at-spi-from-ironpython-2.html (« …Before continuing, let me mention that all the relevant code is in the FePy repository: https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/atspi/« )

    – nouvelle liste pour la réorganisation des bibliothèques de Python 3.0 : http://lists.peadrop.com/listinfo.cgi/python-stdlib-reorg-peadrop.com

    http://pypi.python.org/pypi/virtualenv/ (« virtualenv is a tool to create isolated Python environments. The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.4/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded. Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application. Also, what if you can’t install packages into the global site-packages directory? For instance, on a shared host. In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn’t share libraries with other virtualenv environments (and optionally doesn’t use the globally installed libraries either). »)

    http://sagemath.org.(« Une intervention sur la liste python 3000 à propos de sagemath: « All Python-based, developed originally by a number theorist (http://wstein.org), and with a rapidly growing team of developers
    (including John Cremona, who’s contributed a lot of his code to Sage).
    The Python-dev team should be proud of the impact Python is having in
    scientific computing: python is without a doubt the leading tool for open
    source, high-level scientific codes (i.e. not Fortran/C), and growing…
    http://wiki.sagemath.org/days8 Just contact me off list at Fernando.Perez@colorado.edu if you think you’d like to attend.
    ) »

    – quelques liens sur Python et LDAP:

    http://stacktrace.it/articoli/2008/01/metaclassi-python-3000/ (une discussion sur python 3000 à propos des métaclasses:

    > On Jan 13, 2008 9:37 AM, Charles Merriam <charles.merriam@gmail.com> wrote:
    >> Well, I’m explicitly dropping this. So far no one has pointed out any use cases that are not equivalent to intercepting an array of the namespace in the __init__() of a subclass of type, then calling
    type’s __init__() on the modified namespace.

    There are many use cases. For instance in
    http://stacktrace.it/articoli/2008/01/metaclassi-python-3000/
    I discuss operator overloading on records. The paper is in Italian, but you can just look at the code and at the examples.

    Michele Simionato

    You’ve misunderstood Michele’s example code. __add__ in the
    metaclass lets you add two *record classes* together, not two records.

    Your proposal didn’t support this behavior, nor *any other use case* for actually having a metaclass (as opposed to class decoration).

    You might find this metaclass tutorial enlightening, especially the section I’ve linked to:

    http://www.ibm.com/developerworks/linux/library/l-pymeta2/#h4

    In the paper I have a metaclass definining the methods __new__, __eq__, __call__, __add__ and __repr__ in the class body. In Python, the ability to define methods in the class body is purely syntactic sugar. One could just define the methods externally and attach them to the class dictionary later on.
    Or one could just have a single __new__ method taking a dictionary as argument
    (even for ordinary classes) and setting all the methods, possibly with
    a memoization mechanism, since you don't want to reset all the methods at each instantiation.
    However, everybody basically agrees that it is nicer to define the
    methods in the class body for ordinary classes, so why it should be different in metaclasses?
    Special cases are not special enough.

    http://www.python.org/dev/peps/pep-3115/ (« …This PEP proposes changing the syntax for declaring metaclasses, and alters the semantics for how classes with metaclasses are constructed…The primary reason for changing the way metaclasses work, is that there are a number of interesting use cases that require the metaclass to get involved earlier in the class construction process than is currently possible. Currently, the metaclass mechanism is essentially a post-processing step. With the advent of class decorators, much of these post-processing chores can be taken over by the decorator mechanism…

         In the new model, the syntax for specifying a metaclass is via a
         keyword argument in the list of base classes:
    
           class Foo(base1, base2, metaclass=mymeta):
             ...
    
         Additional keywords will also be allowed here, and will be passed to
         the metaclass, as in the following example:
    
           class Foo(base1, base2, metaclass=mymeta, private=True):
             ...

    « )

    Posted in 2008, python | Tagué: , , , , | Leave a Comment »

    Mono : C#, IKVM, Java, Ironpython, Boo, OLPC, Silverlight/Moonlight, etc…

    Posted by patrick sur janvier 11, 2008

    Mono est encore bien méconnu aussi voici quelques liens intéressants pour en savoir plus:

    http://en.wikipedia.org/wiki/Mono_(software) (« Mono is a project led by Novell (formerly by Ximian) to create an Ecma standard compliant .NETC# compiler and a Common Language Runtime. Mono can be run on Linux, BSD, UNIX, Mac OS X, Solaris and Windows operating systems…Mono’s current version is 1.2.6 (as of Dec 12, 2007). This version provides the core API of the .NET Framework as well as partial support for C# 2.0 and Visual Basic.NET and some C# 3.0 support« )

    http://www.mono-project.com/Main_Page (« Le site du projet Mono. Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. Sponsored by Novell (http://www.novell.com), the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applicationsFeatures

    http://www.mono-project.com/Moma (« The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono. It helps pinpoint platform specific calls (P/Invoke) and areas that are not yet supported by the Mono project. While MoMA can help show potential issues, there are many complex factors that cannot be covered by a simple tool. MoMA may fail to point out areas that will cause problems, and may point out areas which will not actually be an issue. »)

    http://www.mono-project.com/Languages (« Multiple languages can be used with the Mono platform. The Mono project provides some compilers (C#, Basic, JScript) and there are both open source and commercial compilers that can be used with Mono…Mono-compatible compilers

    • C#: The main C# compiler of the Mono Project is mcs. We also have gmcs, which includes previews of several new C# features, including generics and nullable types. In the future, ‘gmcs’ will become the default compiler.
    • Java: Java applications can run in Mono, see the Java page for more details.
    • Boo: The Boo (http://boo.codehaus.org/Home) language is a scripting language similar to Python designed for the .NET Framework. For details on the particular language features see the Boo Language Features (http://boo.codehaus.org/Language+Features) page.
    • Python There are two possible choices here: PythonNet and IronPython.
      • PythonNet: Brian Lloyd (mailto:brian@No.Spam.zope.com) wrote a bridge to link the Python runtime with the .NET runtime. More information on the PS.NET project can be found here (http://pythonnet.sourceforge.net/). This uses the real Python engine and provides a bridge between the Python world and the .NET world to interoperate.
      • IronPython: is Jim Hugunin’s compiler for Python, it is a complete implementation of Python from scratch that compiles Python code into native CIL. More information is available on the IronPython site
    • GCC: In 2006, the Gcc4cil project was publicly announced. For now it supports the C language but it could be extended to support more gcc front ends..
    • Ruby Ruby.Net (http://www.plas.fit.qut.edu.au/rubynet/) from Queensland University. The compiler can be used to statically compile a Ruby source file into a verifiable .NET v2.0 assembly or it can be used to directly execute a Ruby source file (compile, load and execute). IronRuby (http://www.wilcob.com/Wilco/IronRuby.aspx) from Wilco Bauwer, includes an interactive Ruby Console and works with Mono.
    • …etc »)

    http://www.mono-project.com/Java (« Mono is able to run Java code side-by-side with .NET as well as having Java and .NET object interoperate with each other. This is done with IKVM (http://www.ikvm.net) the Java VM implementation that runs on top of .NET and Mono. IKVM was developed by Jeroen Frijters for the .NET Framework. Zoltan Varga ported it to Mono and fixed the Mono runtime to support the features required by IKVM. The class library runtime for IKVM is the GNU Classpath which is rapidly advancing but not entirely complete. IKVM is fully supported by Mono and its part of the standard Mono package distribution. As it stands today, it is able to run popular applications like Eclipse and DerbyThere are two possible ways of using IKVM: one is to use it as a Just-in-Time compiler which translates the Java bytecodes into .NET Intermediate Language as it goes. But this means that at runtime you are compiling things twice: the Java-to-CIL JIT and the CIL-to-Native JITExposing .NET Libraries to Java Now, Gtk# is a .NET assembly (this is the ECMA lingo for « library »), and Java does not know anything about this. It is necessary first to generate some stubs for these classes to let the Java compiler knows about the types defined in the C# world. This is done using the netexp.exe program from IKVM, like this:

    $ mono netexp.exe /mono/lib/mscorlib.dll
    $mono netexp.exe /mono/lib/mono/gtk-sharp/gtk-sharp.dll
    $ mono netexp.exe  /mono/lib/mono/gtk-sharp/glib-sharp.dll
    $ mono netexp.exe /mono/lib/mono/gtk-sharp/atk-sharp.dll

    The above commands basically « imports » all of the types and their definitions into something suitable for Java to consume, the result is:

    $ ls *.jar
    atk-sharp.jar  glib-sharp.jar  gtk-sharp.jar  mscorlib.jar

    The netexp.exe program will import all of the types into the « cli » namespace. So if you had a class called « Gtk.Window », it will be exposed to Java as « cli.Gtk.Window »…How Complete is Mono/IKVM ? Mono and IKVM depend on the GNU Classpath, so it is as complete as open source Java, but you get the added advantage of accessing any Mono/.NET libraries as well. Today Mono/IKVM can run large applications like Eclipse, Jython and JBoss. Screenshot of Eclipse running on Mono . »)

    http://tirania.org/blog/texts/gtkjava.html (« So today I figured it would be an interesting excercise to write a small Gtk# application with Java. To do this, I used IKVM the Java VM implementation that runs on top of .NET and Mono. There are two possible ways of using IKVM: one is to use it as a Just-in-Time compiler which translates the Java bytecodes into .NET Intermediate Language as it goes. But this means that at runtime you are compiling things twice: the Java-to-CIL JIT and the CIL-to-Native JIT. Gtk# is really a bad name. Because Gtk# is not limited to C#, any programming language in the .NET framework can use it today and because it covers more than only the Gtk API, it covers various other components of the GNOME Development Platform.« )

    http://www.mono-project.com/Companies_Using_Mono

    • Novell (http://www.novell.com): Novell uses Mono for both client and server applications:
    • Otee (http://www.otee.dk): Their Unity 3D game modeling tool uses Mono so customers can build cross-platform video games. Their engineers have also spoken about their Mono use on the Mono mailing list. Read the Otee success story here.
    • Medsphere (http://medsphere.com): The Medsphere OpenVista software allows physicians to access complete patient health information at the point of care, and it runs on both Windows and Linux, thanks to Mono. Medsphere customers now have the flexibility to choose the OS that is right for them, without worrying about application availability.
    • Quantifi Solutions: (http://quantifisolutions.com) Specialists in complex financial instruments, Quantifi Solutions use Mono to mix C# and C++ code in their finance modeling software. Their financial models are refined constantly, so they need code that is easy to manage and easy to maintain, while still running fast enough to keep up with the markets. One of the Quantifi engineers discusses their implementation here in the mailing list archives
    • Versora : Windows-to-Linux migration specialists Versora used Mono and C# to produce a cross-platform tool that helps companies move system and application setttings and user data. Read their success story here.
    • Mainsoft uses Mono for their Grasshopper product which allows ASP.NET applications to be deployed on J2EE servers.
    • Gaia (http://ajaxwidgets.com) a company that offers Ajax-based ASP.NET controls under a dual-licensing scheme: GPL or proprietary. Learn more from them here .
    • Wikipedia (http://wikipedia.org): WikiPedia uses Mono for its search facilities. The indexing and the actual searching is done by Mono-based applications.

    http://tirania.org/blog/archive/2008/Jan-04.html (« Les motivation de Miguel De Icaza pour développer mono et silverlight:…I have been using Linux as my main desktop operating system since 1992 and endured every missing feature, every broken driver, every broken X setup and every missing application since I started. I did so because it was free software, and I had decided that I wanted to run my entire system with free software. I felt that dog fooding Linux and improving Linux on a day-to-day basis would help improve this OS as opposed to improving a proprietary OS…From my perspective, it is crucial for Linux to have good support for Silverlight because I do not want Linux on the desktop to become a second class citizen ever again. Robert, you are asking those of us that use FOSS operating systems to « take one for the team » by not endorsing Silverlight, but yet, you are not willing to live among us. If you are going to preach, preach by exampleThe core of the debate is whether Microsoft will succeed in establishing Silverlight as a RIA platform or not. You believe that without Moonlight they would not have a chance of success, and I believe that they would have regardless of us. In fact, I believe strongly that it is part of Microsoft becoming more open and adapting itself to the multitude of shifts in this industry (open sourcing IronPython, IronRuby, the DLR, the JS library for ASP.NET, the MS-PL, the MS-RL, opening up their code, and so on)….Now, regardless of the strategic discussion about endorsing Silverlight, there are technicalities about Silverlight that make it a fascinating platform. I personally want to write cross platform web applications using C#, Boo, Python and Ruby. And that matters to me, and matters to others. And I have loved Silverlight since it embedded the CLR runtime. Nothing new there, you can read the gory details of my fascination from back then…What prevents anyone from taking the Moonlight source code, embracing it, extending it, innovate with it, prototype with it, and enter the same cycle that Linux, or web browsers have entered? Or someone turning it into a standard? Nothing. The only thing preventing it is lack of imagination. « )

    http://wiki.laptop.org/go/Mono (« Sugar activities are usually written in Python using the Python Activity API. This page documents how it is possible to use Mono to write a Sugar activity. With Mono, you can use any underlying language like C# or Boo. »)

    http://tquerci.blogspot.com/2008/01/mono-on-olpc-one-laptop-per-child.html (« After a lot of time I’m finally releasing the first version of Sugar assembly to « sugarize » a Mono application. This assembly is needed to integrate a Mono application with the Sugar environment so it can run on an OLPC device. This version allows creating applications that use GTK# forms created programmatically or by a Glade resource fileI have ported two applications to the OLPC device: GBrainy and MonkeysMemory. The first application is an interesting application to « improve » your brain, while the second one is a simple « Memory » game that I wrote to play with my children.« )

    http://www.mono-project.com/Software

    http://www.mono-project.com/Libraries

    GRAPHIQUES

    • Gtk# (« This toolkit is a .NET binding for the Gtk+ toolkit. It is in active development, and there are various applications in the Mono world that use it (Monodoc, Monocov, Mono’s Debugger and various smaller applications, a more complete list is available on the Gtk# Wiki. Platforms: Unix, Windows, GPE, MacOS X (using the X server)« ).

    Web Frameworks

    CHARTING

    • NPlot (http://netcontrols.org/nplot/wiki/) is a free charting library for .NET and supports various kinds of graphic modes. It boasts an elegant and flexible API. NPlot includes controls for Windows.Forms, ASP.NET and a class for creating Bitmaps. A GTK# control is also available.
    • ZedGraph (http://zedgraph.org) ZedGraph is a set of classes, written in C#, for creating 2D line and bar graphs of arbitrary datasets. The classes provide a high degree of flexibility — almost every aspect of the graph can be user-modified. At the same time, usage of the classes is kept simple by providing default values for all of the graph attributes. The classes include code for choosing appropriate scale ranges and step sizes based on the range of data values being plotted.

    SYSTEM PROGRAMMING

    • Mono.Addins is a generic framework for creating extensible applications, and for creating libraries which extend those applications. This framework is derived from the add-in engine used by MonoDevelop, although it has been completely rewritten and improved in many ways to make it more generic and easier to use. The MonoDevelop add-in engine was an improvement over the SharpDevelop engine, which took many ideas from the Eclipse add-in engine. Mono.Addins has been designed to be useful for a wide range of applications: from simple applications with small extensibility needs, to complex applications (such as MonoDevelop itself) which need support for large add-in structures.

    http://www.mono-project.com/Moonlight («  Silverlight 1.1 (http://silverlight.net) is a new development technology for the Web created by Microsoft based on the CLR that augments it with a 2D retained graphics system and media playback engine and ships a subset of the standard .NET libraries. Currently the Moonlight project supports both Silverlight 1.0 (canvas + browser-based scripting) as well as 1.1 applications (canvas + ECMA CLI powered execution engine). Building an open source implementation on top of Mono is an obvious choice as Mono has most of the technologies required to implement it but is missing a few components. In this page we will track the work required and the design decisions involved in creating an open source version of itCurrently Moonlight is not packaged as it is still under heavy development. In the future we will provide package repositories for all major distributions through the OpenSUSE Build Service (http://build.opensuse.org) as well as a Mozilla extension that will make the installation experience similar to the one that Windows and MacOS users have today. « )

    Posted in 2008, Distribution de logiciel, java, logiciel libre, openSUSE build service, packaging, python, Web Frameworks | Tagué: , , , | 1 Comment »

    Programmation : python versus C#3

    Posted by patrick sur janvier 7, 2008

    Quelques exemples de code Python versus C#3:

    http://brad.livejournal.com/2354680.html (« Cet article permet de comparer l’écriture d’un programme simple entre différents langages: Tcl, Ruby 1.8, Ruby 1.9, C#3, Perl. On apprend aussi que chez Google Python est un langage bien employé: « Google has a shitload of code and infrastructure. Google also has a shitload of engineers that altogether know a shitload of languages. If every engineer were allowed to write in his/her favorite pet language of the week, the necessary explosion of substandard bindings for each library * each language would be unmaintainable. Given that Perl/Python/Ruby are all effectively the same, it makes sense to standardize on one. Python has the right mix of learnability, readability, industry/community support, etc. I don’t object to having to write in Python… it makes a ton of sense

    C# Code

    using System;
    using System.IO;
    using System.Linq;
    using System.Collections.Generic;public class AnagramNames {
     public static void Main(string[] args) {
    
     	var names = from name in File.ReadAllLines("dist.male.first") select name.Split(' ')[0];
     	var pairs = from pair in (
     		from name in names group name by SortCharsInString(name)
     	) where pair.Count() > 1 select pair;
    
    foreach (var pair in pairs) {
     		Console.WriteLine(String.Join(",", pair.ToArray()));
     	}
     }
    
     public static string SortCharsInString(string s) {
     	char[] arr = s.ToArray();
     	Array.Sort(arr);
     	return new string(arr);
     }
    }

    Python Code

    #!/usr/bin/python
    by_anagram = {}
    for name in [l.split()[0] for l in open("dist.male.first")]:
            by_anagram.setdefault("".join(sorted(name)), []).append(name)
    print "\n".join([" ".join(n) for n in by_anagram.itervalues() if len(n) > 1])

    http://www.25hoursaday.com/weblog/2008/01/02/DoesC30BeatDynamicLanguagesAtTheirOwnGame.aspx(« Un article comparant C#3 et Python: Does C# 3.0 Beat Dynamic Languages at their Own Game? For the past few years I’ve heard a lot of hype about dynamic programming languages like Python and Ruby. The word on the street has been that their dynamic nature makes developers more productive that those of us shackled to statically typed languages like C# and Java. A couple of weeks ago I decided to take the plunge and start learning Python after spending the past few years doing the majority of my software development in C#. I learned that it was indeed true that you could get things the same stuff done in far less lines of Python than you could in C#. Since it is a general truism in the software industry that the number of bugs per thousand lines of code is constant irrespective of programming language, the more you can get done in fewer lines of code, the less defects you will have in your software. Shortly after I started using Python regularly as part of the prototyping process for developing new features for RSS Bandit, I started trying out C# 3.0. I quickly learned that a lot of the features I’d considered as language bloat a couple of months ago actually made a lot of sense if you’re familiar with the advantages of dynamic and functional programming approaches to the tasks of software development

    After getting up to speed with Python and then comparing it to C# 2.0, it was clear that the dynamic features of Python made my life as a programmer a lot easier. However something interesting happened along the way. Microsoft shipped C# 3.0 around the same time I started delving into Python. As I started investigating C# 3.0, I discovered that almost all the features I’d fallen in love with in Python which made my life as a developer easier had been integrated into C#. In addition, there was also a feature which is considered to be a killer feature of the Ruby programming language which also made it into C# 3.0

    The capability of a programming language to treat functions as first class objects that can be the input(s) or the output(s) of a function call is a key feature of many of today’s popular « dynamic » programming languages. Additionally, creating a short hand syntax where anonymous blocks of code can be treated as function objects is now commonly known as « lambda expressions ». Although C# has had functions as first class objects since version 1.0 with delegates and introduced anonymous delegates in C# 2.0, it is in C# 3.0 where the short hand syntax of lambda expressions has found its way into the language. Below are source code excerpts showing the difference between the the lambda expression functionality in C# and IronPython

    C# Code

    //decide what filter function to use depending on mode
    
    Func<RssItem, bool> filterFunc = null;
    
    if(mode == MemeMode.PopularInPastWeek)
    
       filterFunc = x => (DateTime.Now - x.Date < one_week) ;
    
    else
    
       filterFunc = x => x.Read == false;

    IronPython Code

    #decide what filter function to use depending on mode
    filterFunc = mode and (lambda x : (DateTime.Now x.date) < one_week) or (lambda x : x.read == 0)

    Although the functionality is the same, it takes a few more lines of code to express the same idea in C# 3.0 than in Python. The main reason for this is due to the strong and static typing requirements in C#. Ideally developers should be able to write code like

    Func<RssItem, bool> filterFunc = (mode == MemeMode.PopularInPastWeek ? x => (DateTime.Now - x.Date < one_week) : x => x.read == false);

    However this doesn’t work because the compiler cannot determine whether each of the lambda expressions that can be returned by the conditional expression are of the same type. Despite the limitations due to the static and strong typing requirements of C#, the lambda expression feature in C# 3.0 is extremely powerful.

    You don’t have to take my word for it. Read Joel Spolsky’s Can Your Programming Language Do This? and Peter Norvig’s Design Patterns in Dynamic Programming. Peter Norvig’s presentation makes a persuasive argument that a number of the Gang of Four’s Design Patterns either require a lot less code or are simply unneeded in a dynamic programming language that supports higher order functions. For example, he argues that the Strategy pattern does not need separate classes for each algorithm in a dynamic language and that closures eliminate the need for Iterator classes. Read the entire presentation, it is interesting and quite illuminating.

    Python vs. C# 3.0: List Comprehensions vs. Language Integrated Query

    A common programming task is to iterate over a list of objects and either filter or transform the objects in the list thus creating a new list. Python has list comprehensions as a way of simplifying this common programming task. Below is an excerpt from An Introduction to Python by Guido van Rossum on list expressions

    List comprehensions provide a concise way to create lists without resorting to use of map(), filter() and/or lambda. The resulting list definition tends often to be clearer than lists built using those constructs. Each list comprehension consists of an expression followed by a for clause, then zero or more for or if clauses. The result will be a list resulting from evaluating the expression in the context of the for and if clauses which follow it.

    Below is a code sample showing how list comprehensions can be used to first transform a list of objects (i.e. XML nodes) to another (i.e. RSS items) and then how the resulting list can be further filtered to those from a particular date.

    IronPython Code

    # for each item in feed
    # convert each <item> to an RssItem object then apply filter to pick candidate items
    items = [ MakeRssItem(node) for node in doc.SelectNodes(« //item »)]
    filteredItems = [item for item in items if filterFunc(item)]

    My friend Erik Meijer once observed that certain recurring programming patterns become more obvious as a programming language evolves, these patterns first become encapsulated by APIs and eventually become part of the programming language’s syntax. This is what happened in the case of the Python’s map() and filter() functions which eventually gave way to list comprehensions.

    C# 3.0 does something similar but goes a step further. In C# 3.0, the language designers made the observation that performing SQL-like projection and selection is really the common operation and not just filtering/mapping of lists. This lead to Language Integrated Query (LINQ). Below is the same filtering operation on a list of XML nodes performed using C# 3.0

    C# 3.0 Code

    //for each item in feed
    
    // convert each <item> to an RssItem object then apply filter to pick candidate items
    
    var items = from rssitem in
    
                  (from itemnode in doc.Descendants("item") select MakeRssItem(itemnode))
    
                where filterFunc(rssitem)
    
                select rssitem;

    These are two fundamentally different approaches to tackling the same problem. Where LINQ really shines is when it is combined with custom data sources that have their own query languages such as with LINQ to SQL and LINQ to XML which map the query operations to SQL and XPath queries respectively.

    Python vs. C# 3.0: Tuples and Dynamic Typing vs. Anonymous Types and Type Inferencing

    As I’ve said before, tuples are my favorite Python feature. I’ve found tuples useful in situations where I have to temporarily associate two or three objects and don’t want to go through the hassle of creating a new class just to represent the temporary association between these types. I’d heard that a new feature in C# 3.0 called anonymous types which seemed like it would be just what I need to fix this pet peeve once and for all. The description of the feature is as follows

    FINAL THOUGHTS

    C# has added features that make it close to being on par with the expressiveness of functional and dynamic programming languages. The only thing missing is dynamic typing (not duck typing), which I’ve come to realize is has a lot more going for it than lots of folks in the strongly and statically typed world would care to admit. At first, I had expected that after getting up to speed with C# 3.0, I’d lose interest in Python but that is clearly not the case.

    I love the REPL, I love the flexibility that comes from having natural support tuples in the language and I love the more compact syntax. I guess I’ll be doing a lot more coding in Python in 2008. « )

    Posted in 2008, C_sharp, python | Tagué: | Leave a Comment »