Si je veux apprendre le judo, je vais m’inscrire au dojo du coin et y passer une heure par semaine pendant deux ans ; au bout de quoi, j’aurai peut-être envie de pratiquer plus assidûment.

Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004.

Cherchez l’erreur.

—Laurent Bossavit

Source : http://wiki.agile-france.org/cgi-bin/wiki.pl?LeProjetDuDojo

Rennes On Rails semble avoir trouvé son format avec le « [[Randori]] ».

Comme à chaque fois :

• propositions de sujets ;
• vote ;
• travail ;
• retour d’expérience.

Ces dernières semaines les personnes clés des principales distributions se sont réunies pour discuter des problèmes liés aux données d'exécution (runtime data) utilisées lors de la phase de démarrage et surtout de leurs emplacements.

Lors du démarrage d'un système GNU/Linux différents programmes (initscripts, dracut, mdadm, etc) ont besoin de stocker leurs données d'exécution dans l'arborescence et cela avant les éventuels montages annexes (/home, /usr ou /var). Ces données sont aussi utilisées par les programmes et daemons lors du fonctionnement du système.

Actuellement, les distributions utilisent différents subterfuges pour stocker ce type de données dans des dossiers cachés : /dev/.mdadm, /dev/.mount, /dev/.systemd, /dev/.udev, etc. Elles utilisent pour la plupart le répertoire /dev pour stocker les premières données, ce dossier est de type tmpfs et est disponible dès les premiers instants du démarrage.

À la suite des derniers montages (/home, /usr ou /var) les daemons sont lancés, ils utilisent principalement le dossier /var/run pour leurs données et cherchent les données liées au démarrage dans les différents dossiers /dev/.xxx ou autres selon les distributions.

Pour en finir avec cette cacophonie, les principales distributions ont décidé d'ajouter le dossier "run" à la racine. Ce dossier fera partie de l'arborescence initiale des prochaines versions, il contiendra les données contenues auparavant dans les dossiers /dev/.xxx, /var/run, /var/lock, /lib/init/rw, etc.

Cette décision est techniquement simple et simplifie la liaison entre les données liées au démarrage et les programmes, elle a souvent été envisagée mais repoussée pour des raisons politiques, des craintes d'intense flameware et la rupture avec la LSB/FHS.

Les développeurs de dracut, udev et systemd ont déjà mis à jour ces logiciels. Les distributions utiliseront le répertoire /run de façon progressive avec, dans un premier temps, des montages de type bind des anciens répertoires vers /run.

Lennart Poettering (Pulseaudio, avahi, systemd) a rédigé un mail pour faire le point sur cette réunion, annoncer le changement et les phases de mise en place.

Alors, LSB/FHS outragée, LSB/FHS brisée, LSB/FHS martyrisée… crouch, touch, pause, engage !

N. D. M. : Les principales distributions impliquées sont Debian, SuSE, Ubuntu et Fedora.

Ces derniers temps ont été très riches en événements dans le monde graphique libre.

Une première phase du remodelage intégral de la pile graphique de nos systèmes libres avait commencé par DRI2, apportant notamment la possibilité à un compositeur tel que Compiz de rediriger le rendu OpenGL d’une fenêtre (Redirected Direct Rendering), puis le Kernel Mode Setting (KMS) permettant de transférer la gestion des modes vidéo et de la mémoire vidéo du pilote graphique X.Org (DDX) vers le noyau, et enfin, Gallium3D, le cadriciel de Tungsten Graphics, permettant la mise en commun de nombreuses fonctionnalités auparavant implémentées dans chaque pilote graphique.

Très récemment, le noyau 2.6.38 a apporté le kernel page flipping, permettant l’arrivée du futur serveur d’affichage Wayland développé par Kristian Høgsberg (également auteur de DRI2 et de AIGLX) et popularisé par Mark Shuttleworth (qui souhaite son adoption dans Ubuntu dès l’année prochaine). Les bibliothèques graphiques GTK+ 3 et Qt 4 ont déjà des back-ends permettant le fonctionnement expérimental des applications GNOME 3 ou KDE 4 sous Wayland…

Parmi les plus récents événements, de nombreux étudiants ont proposé des projets en lien avec la pile graphique libre utilisée par GNU/Linux à l’occasion de l’édition 2011 du Google Summer of Code (GSoC). Ces projets sont plus précisément des « state trackers » pour Gallium3D :

• un étudiant belge du nom de Denis Steckelmacher (alias steckdenis), a proposé rien de moins qu’un state tracker OpenGL 4.1, entièrement récrit. Ce projet ayant été jugé bien trop ambitieux par les développeurs Mesa / Gallium3D dans le cadre du GSoC, ces derniers lui ont proposé de travailler sur le remplacement des représentations intermédiaires propres à Gallium3D (Mesa IR) par une sémantique [GLSL] plus standard. Après coup, cette idée n’a pas fait non plus l’unanimité au sein des développeurs, avec notamment deux sociétés, Intel et LunarG travaillant actuellement sur ces fameuses représentations intermédiaires. Denis Steckelmacher a finalement décidé de travailler sur Clover, le state tracker OpenCL, permettant d’exploiter la puissance des GPU pour le calcul intensif, avec pour objectif obtenir un state tracker fonctionnel réalisant, dans un premier temps, les calculs OpenCL sur le processeur en utilisant LLVMpipe, un moteur de « rendu OpenGL » logiciel basé sur LLVM (Low Level Virtual Machine).

• un étudiant français, Émeric Grange (alias Emeric_), participerait également au GSoC 2011, avec pour projet le développement d’un décodeur vidéo WebM / VP8 accéléré via les [[shaders]] des processeurs graphiques. Tout cela serait placé dans un state tracker Gallium3D, qui exposerait ses fonctions aux lecteurs multimédias comme VLC, MPlayer et Totem (via un greffon GStreamer) à travers l’API VDPAU de NVIDIA.
  Ce state tracker pourrait constituer un bon point de départ pour la prise en charge générique du décodage matériel d’autres formats vidéo, tels que le MPEG 4 ASP (DIVX < 7) et MPEG 4 AVC (H.264) ou le MPEG 2 (déjà pris en charge par le state tracker XvMC). À noter que, comme pour la gestion des textures compressées S3TC, la gestion de ces formats devra faire l’objet d’une analyse des brevets / licences impliqués.

Certes, tout n’est pas rose du côté de la pile graphique Linux, mais au moins ça bouge et ça avance plutôt dans le bon sens. Voir ci-dessous pour les détails.

Après FusionInventory , Voici FusionDirectory !

Né un an après son collègue, FusionDirectory est un nouveau projet, lui aussi issu d’une divergence (fork), mais cette fois de Gosa², un gestionnaire d’infrastructure basé sur un annuaire de type LDAP.

Pour fêter cette sortie, l’équipe de FusionDirectory n’a rien trouvé de mieux qu’annoncer en même temps la sortie de la version 1.0 !

Que permet de faire FusionDirectory 1.0 ?

FusionDirectory est un gestionnaire d’infrastructure. Il vous permet de gérer :

• les utilisateurs : UNIX, SAMBA, informations administratives ;
• les groupes : UNIX, SAMBA ;
• les services : SMTP; IMAP/POP, DHCP, HTTP, dépôts Debian, DNS, antivirus, ASTERISK ;
• les serveurs : déploiement via FAI/OPSI et paramétrage ;
• les postes clients : déploiement de système d’exploitation et d’applications.

Le tout via une interface Web !

Pourquoi un fork ?

La suite Gosa² est principalement géré par la société Gonicus en Allemagne. Cette dernière développe Gosa² pour ses clients, mais le développement et l’accès au cœur du programme restaient très difficile par des personnes non employées par Gonicus GmbH.

FusionDirectory a été donc initié afin de permettre l’amélioration de cet outil par toute personne désireuse d’y contribuer.

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

• [datanews] Open Source or Not Open Source: That's the Question…
• [business-MOBILE.FR] Google veut reprendre la main sur Android
• [OWNI] Pirat@ge: du hacktivisme au hacking de masse
• [LeJournalduNet] Les DSI du CAC40 dressent leur classement des solutions Open Source
• [LeMagIT] La Grande-Bretagne met l'Open Source et le Cloud au coeur de sa politique de mutualisation IT
• [PC INpact] LQDN : "Internet selon Riguidel, cela ressemble à l'ORTF 2.0 !"
• [WebActus] Certains développeurs en ont marre de Twitter

Depuis 2007, l'agrégation de Mathématiques se fait sur des machines tournant sous GNU/Linux. Peu de changements cette année pour l'agrégation externe, les logiciels proposés sont toujours Scilab, Octave (via Qtoctave), R, Maxima (via Wxmaxima), Giac/Xcas, PARI/GP, Axiom, GAP, ainsi que des compilateurs Java, C, Ocaml et Camllight. Un absent notable : Sage, qui devrait être proposé d'ici peu. Des logiciels propriétaires sont disponibles (Maple, Mathematica, Mupad en version 2.5 et Matlab). Sauf imprévu, l'environnement proposé est Fluxbox et le système une Debian Lenny.

Pour la deuxième année consécutive, l'agrégation interne propose aux candidats la possibilité d'utiliser l'informatique à l'un des oraux. Le support est cette fois directement ClefAgreg dans une version dédiée à cette épreuve (ClefAgrInt).

Le 31 mars dernier est sortie la Bêta d'Ubuntu 11.04. Inutile de dire que beaucoup d'entre vous ont dû l'essayer. Le serveur HTTP était encore en peine ce samedi matin. Mais pour le lien torrent, pas de soucis ! Une petite machine virtuelle (1 coeur et 1024 Mo de RAM) et hop, voilà une découverte toute chaude !

L'Assemblée Nationale du Québec a commencé la semaine dernière l'étude de la loi 133 sur la gouvernance et la gestion des ressources informationnelles des organismes publics et des entreprises du gouvernement. Cette loi permettra au gouvernement du Québec de mettre en œuvre sa politique-cadre dont l'un des objectifs est de « tirer profit du logiciel libre ». L'Association Professionnelle des Entreprises en Logiciels Libres (APELL) avait été invitée par la commission parlementaire.
La semaine prochaine se tiendra l'audition de FACIL, « Facil, pour l'appropriation collective de l'informatique libre » .

Mercredi 6 avril 2011 se tiendra une « Foire du Libre » à Louvain-la-Neuve en Belgique avec de nombreux exposants et des conférences toute l'après-midi.

Voici en résumé les festivités prévues. Plus d'informations concernant les exposants sont disponibles dans la seconde partie de cette dépêche.

• Où : Salle d'étude des Sciences et auditoire Sciences 02 de l'Université Catholique de Louvain (UCL) à Louvain-La-Neuve (Belgique)

• Quand : Mercredi 6 avril 2011 de 12 à 19h

• Pour qui : Tous publics ! Passionnés, étudiants, futurs diplômés, (futures) entrepreneurs, membres d'A.S.B.L. (Associations loi 1901) et O.N.G. à la recherche d'outils informatiques, (futurs) professeurs, instituteurs, comptables, gestionnaires d'entreprises, économistes, juristes, informaticiens, etc.

• Quoi : Des stands pour rencontrer des représentants, contributeurs et développeurs de Logiciels Libres (Beernet, Blender, Cairo-Dock, Claroline, Drupal Belgique francophone, Free Software Foundation Europe, Inkscape, LaTeXila, LouviLUG, Mozilla Europe, OOo4kids, OpenERP, PHP Compta, Ubuntu Belgique et éventuellement le passage de représentants de sociétés comme RedHat et Novell) ainsi que des conférences.

• Combien : Gratuit avec une possibilité de se désaltérer en discutant!

Vous pourrez assister à des conférences dont l'horaire est le suivant:

• 13h00 : Ouverture
• 13h15 : Ubuntu, bien plus qu'un OS
• 14h15 : L'impact des licences libres, pour qui et pour quoi ?
• 15h15 : Beernet, pBeer-to-pBeer network
• 16h15 : iCampus, vous connaissez vraiment ?
• 17h15 : Claroline entre présent et futur : un projet open source wallon reconnu mondialement
• 18h15 : OpenERP, comment gérer une entreprise avec un Logiciel Libre

Des rumeurs annoncent que Duke Nukem Forever sortira vraiment en Avr^WMa^WJuin 2011, donc il n'y a plus d'échappatoire pour le Hurd, nous devions le finir et le sortir. Des progrès considérables ont été réalisés ces derniers temps, c'est donc avec grand plaisir que l'équipe des mainteneurs du Hurd a décidé de sortir la version 0.401 du système d'exploitation GNU/Hurd.

En partenariat avec l'association FDN fournisseur d'accès Internet (et tout Internet) et le service d'accès avec anonymat No-Log, LinuxFr.org travaille actuellement sur le premier prototype de box décentralisante à dalle tactile (entièrement à base de logiciels libres, sous AGPLv3, cela va de soi).

Mais qu'est-ce donc ? Une vraie révolution : une box d'accès Internet, offrant un vrai accès décentralisé (type informatique en nuage) et toutes les fonctions utiles à l'heure des nombreuses lois sécuritaires et atteintes à la neutralité du réseau ; le concept est proche de la FreedomBox évoquée précédemment ici-même, et avec laquelle elle sera d'ailleurs compatible. La DLFPbox offre par ailleurs un accès direct à LinuxFr.org, ses informations et ses différents canaux d'échange (dont la tribune).

Les visuels prévisionnels (un prototype est en cours de réalisation avec une imprimante 3D) :

Côté fonctionnalités matérielles, on retrouve deux prises RJ42 pour permettre de faire une passerelle filtrante entre Internet et votre réseau local, un processeur Sun OpenSparc compatible Arduino - Hackable Devices. Une carte d'extension pour la détection de mouvement type Kinect est dans les cartons. On notera l'absence de wifi bien trop laxiste en terme de sécurité – le choix est résolument wirefull ici – et le pilotage possible via OpenMoko FreeRunner.

Côté fonctionnalités logicielles, on trouve l'accès au (futur) DLFPcloud, un miroir WikiLeaks, un proxy Tor, un accès du DebStore pour des dizaines de milliers d'applications, un serveur Jabber/XMPP multifonction dont chat V²oIP (voix/vidéo via IP), l'extensibilité par plugins via API (large choix de files FIFO et piles PIPO). Les logiciels libres retenus sont des grands classiques : noyau Linux (non GNU Hurd ne tourne pas sur OpenSparc), Busybox, Vlc, parefeu OOo, module PAM-loppsi, Rails 3, etc. On notera le support vidéo HTML5 plein écran et le full HD 1080p (sans DRM), avec un très bon rendu sur la dalle.

Prochainement les premières photos du prototype et des informations complémentaires.

Etoys est un système de programmation graphique qui fonctionne tant sur Windows que Linux ou MacOS X. Il permet de commander et de connecter des objets (graphiques ou réels) entre eux. Les objets graphiques d’Etoys sont des fenêtres, boutons, menus, dessins, formes vectorielles… Bref, tout élément pouvant être représenté graphiquement. Cet environnement permet de concevoir d’enrichissants scenarii pédagogiques et d’interfacer des matériels tels que les cartes Arduino.

Planète Sciences et LinuxÉdu organisent une formation collaborative sur cet outil pédagogique.

C’est en 1999 que Jeremie Miller crée Jabberd, serveur open source de messagerie instantanée et de présence. Il appelle le protocole (de fait) sous-jacent « Jabber », terme traduisible directement de l’anglais au français comme un « bavardage ». Puis, le petit protocole au nom sans prétention commença à en avoir. Voulant jouer dans la cour des grands, il fut en effet proposé comme standard auprès de l’IETF avec l’objectif de fournir une véritable interopérabilité dans le monde de la communication instantanée, encore jeune, mais déjà quasi-entièrement sous le contrôle de divers réseaux privés, propriétaires et sans aucune transparence de fonctionnement.

Mais l’Internet est sans pitié pour les jeunes présomptueux, et il fallut plusieurs groupes de travail IETF, brouillons, stabilisation du protocole, la création d’une fondation (Jabber Software Foundation)… pour que finalement, début 2004, 5 ans après la création du protocole, ce dernier soit enfin un standard reconnu. On lui accorda des numéros pour faire le fier comme James Bond : RFC 3920 (le cœur) et RFC 3921 (Messagerie Instantanée et Présence). Petit protocole devenu grand décida alors de changer de nom pour paraître plus sérieux lors d’entretiens d’embauche. Il se fit donc appeler XMPP, pour e*Xtensible **Messaging and **Presence **P*rotocol.

À partir de là, la JSF prit plus d’importance, s’organisa davantage et changea à son tour son nom en 2007 pour XSF, XMPP Standards Foundation. Notons l’évolution sémantique : on est passé d’une entité de code (Software) à une autre gérant désormais clairement des Standards. Les rôles sont répartis entre l’IETF et la XSF. L’IETF s’occupe essentiellement du centre névralgique du protocole, ce qui en fait un protocole Internet interopérable. De son côté, la XSF gère en plus les extensions : les XEP (XMPP Extension Protocols). En effet, XMPP a été créé comme un protocole extensible. Par design, il est un triple protocole — comme son nom l’indique : un protocole de Présence (qui de ses contacts est présent ?), un protocole de Messagerie (non forcément lié à la présence : on peut envoyer des messages à des entités dont nous ne connaissons pas la présence, comme pour les e-mails), et enfin, un protocole e*X*tensible, qui permet donc de créer des sous-protocoles de communication, pour tout usage. XMPP fut défini comme un protocole applicatif extrêmement générique, non limité à la messagerie instantanée.
La XSF s’occupe donc en particulier de cette dernière caractéristique (extensibilité), et travaille en collaboration avec l’IETF sur les deux autres.

Néanmoins, cela fait maintenant 7 années que le cœur de notre petit protocole n’avait pas été soigné, bien que souvent ausculté puisqu’il se faisait vieux. C’est pourquoi, après toutes ces années de traitement, le voilà comme un nouveau né avec ses nouveaux numéros d’identité.
En effet, pour fêter le printemps, le 21 mars 2011 est à noter comme le jour où les RFC de XMPP seront mises à jour : les RFC 3920 et 3921 sont désormais obsolètes et remplacées respectivement par les RFC 6120 et 6121. Enfin, une troisième RFC voit le jour, standardisant séparément le format des adresses XMPP (ce qui était auparavant intégré à la RFC 3920) : la RFC 6122.

Après le succès de sa campagne de dons, qui a atteint son objectif en moins d’un mois, l’équipe de TuxFamily a décidé d’investir l’argent récolté dans la mise à niveau de son architecture.

Prenant en compte les nouveaux développements intervenus pendant la campagne, et notamment l’adoption de la LOPPSI 2 le 13 mars, TuxFamily va mettre en place un système d’authentification unique. Utilisateurs et visiteurs devront dorénavant s’authentifier pour accéder aux contenus et aux services.

Cela permettra notamment une meilleure traçabilité des parcours des utilisateurs ainsi que des statistiques plus détaillées et individualisées. De plus, ces données pourront être transmises aux pouvoirs publics sur demande. « Nous aurons toutes les informations nécessaires pour savoir qui a fait quoi à quel moment, et nous aiderons à rendre Internet plus sûr et plus sain », résume TuxFamily.

Pour rendre le système moins contraignant pour l’utilisateur et digne de l’informatique du XXI^e siècle, l’authentification se fera par un code PIN de 4 chiffres, facilement récupérable en cas d’oubli, puisqu'il sera stocké en clair.

En toute transparence, l’équipe de TuxFamily indique qu’après la mise en place du système pour les sites Web hébergés, basé sur une solution d'une firme de Armonk, « des dispositifs similaires seront progressivement mis en place sur les autres services : espaces de téléchargement, Subversion / Git / Mercurial, IRC / Jabber, POP / IMAP / Webmail ».

Et de conclure, « nous n’excluons pas que le budget initialement prévu s’avère insuffisant. Aussi, n’hésitez pas à poursuivre les dons afin de nous soutenir dans cette phase de changement indispensable pour rester un hébergeur indépendant ET moderne ».