Marcelo Tosatti
Marcelo Wormsbecker Tosatti, né le au Brésil, est un des développeurs du noyau Linux. Il travaille pour la société Red Hat après 3 ans chez Cyclades et 6 ans chez Conectiva Inc. Beaucoup de noyaux Linux 2.4 portent maintenant le nom de Marcelo.
| Naissance | |
|---|---|
| Nationalité | |
| Activité |
Méthode de développement du noyau linux
Pour comprendre son rôle, il faut expliquer la méthode de développement du noyau : il y a un nombre énorme de développeurs, que ce soit des indépendants (de plus en plus rare) ou des grosses sociétés comme IBM ou Red Hat. Ces développeurs fournissent des patches (« rustines », modifications de code source).
Les patches sont inclus dans le gestionnaire de code source du noyau et continuent leur vie jusqu'à ce qu'un nouveau patch vienne remplacer le code qu'ils ont introduit. Pour coordonner tout ce flux de patches, il s'est vite avéré que Linus Torvalds tout seul ne suffisait pas. Il s'est donc entouré de « lieutenants » pour faire le travail, Linus s'occupant de la version en développement (2.6 pour le moment).
Mais quel est donc le travail d'un mainteneur de noyau ?
C'est justement de tester les patches, de vérifier leur validité, de corriger rapidement les failles du kernel et de publier une nouvelle version quand il est temps (chacun à sa politique dans ce domaine très subjectif).
Actuellement le kernel existe en trois versions :
- le 2.2 maintenu par Alan Cox
- le 2.4 maintenu pendant longtemps par Linus, puis par Marcelo de 2001 Ă 2006 (depuis le 2.4.16 jusqu'au 2.4.33), et maintenant par Willy Tarreau
- le 2.6 maintenu conjointement par Linus et Andrew Morton
Son parcours
Enfant prodige
Tossati a commencé à travailler sur le noyau Linux quand il avait 14 ans et est devenu le responsable des noyaux de la distribution Conectiva.
La série 2.4.x
La série 2.4.x du noyau a récemment essuyé quelques critiques dues à certains bugs. Ces dernières étant la cause de sorties (très) rapprochées de nouveaux noyaux. Pour essayer d'éviter cela, Marcelo Tosatti a décidé d'employer la méthode suivante : 2.4.x-preY tant que de nouveaux patches sont rajoutés, 2.4.x-rcZ tant que les rajouts posent problème. Et le dernier -rc auquel personne ne trouve à redire est lancé en tant que 2.4.x, sans aucun changement.