Journal devenez un développeur linux

Posté par  . Licence CC By‑SA.
Étiquettes :
57
4
mar.
2014

Greg Kroah-Hartman (un des mainteneurs noyau) a partagé un lien aussi diffusé sur mailing list de http://kernelnewbies.org :
http://eudyptula-challenge.org

En s'inscrivant sur ce site, on vous propose via une série d'exercice envoyé par email de passer de simple bidouilleur à mainteneur noyau.

Je m'y suis inscrit hier et ai reçu le premier exercice qui est un hello world.

Bonne nouvelle, pour l'instant l'adresse utilisée n'a pas été pourri de spams

  • # LKML

    Posté par  . Évalué à 10.

    Bonne nouvelle, pour l'instant l'adresse utilisée n'a pas été pourri de spams

    En même temps tu va finir sur la LKML donc bon il vaut mieux considérer que c'est une adresse publique qui va commencer à se faire remplir :)

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Faut pas rêver

    Posté par  (site web personnel) . Évalué à 10.

    Il s'agit de parvenir à avoir un patch qui soit accepté dans la branche principale….et pas de devenir mainteneur.
    Mais excellente initiative.

    • [^] # Re: Faut pas rêver

      Posté par  . Évalué à 3.

      Effectivement, ce n'est pas écrit comme çà sur le site, mais je faisait référence au contenu du premier email :

      This "challenge" is a series of Linux kernel programming exercises
      starting out small, and in the end, if all goes well, you'll be the
      maintainer of a subsystem, if you so desire. Well, maybe not a
      maintainer, but you will be qualified enough to point out any problems
      that your favorite maintainer is causing, and that's actually way more
      fun than being in charge.

      Il y a effectivement peu de chance que je finisse mainteneur, mais gardons espoir pour les autres :)

    • [^] # Re: Faut pas rêver

      Posté par  . Évalué à 9.

      Mais excellente initiative.

      Exactement et c'est ce qui manque dans les gros projets libres sensibles.
      Si Wayland, nouveau/radeon offraient des approches du genre, on avancerait sans doute plus vite.
      Alors certes, ça n'enlève rien à la difficulté mais ça offirait une porte d'entrée plus accèssible et comme effet de bords d'améliorer la documentation.

      NB: J'ai choisi ces projets car ceux-ci sont actuellement les plus attendus à aboutir.

      • [^] # Re: Faut pas rêver

        Posté par  (site web personnel) . Évalué à -9.

        NB: J'ai choisi ces projets car ceux-ci sont actuellement les plus attendus à aboutir.

        Linux est principalement utilisé sur des serveurs, alors parler de pilotes graphiques comme "les plus attendus à aboutir" me laisse très songeur si je regarde les utilisateurs Linux dans leur ensemble…
        Perso, j'aurai plutôt imagine un projet genre btrfs ou LXC, après ça va dépendre beaucoup de avec qui tu parles et chacun va avoir un avis différent sur "le plus attendu à aboutir".

        Ensuite, pas sûr (que ce soit tes noms ou mes noms) que ça avance plus vite, dans ces projets les compétences très pointues sont nécessaires.

        • [^] # Re: Faut pas rêver

          Posté par  . Évalué à 5.

          Ensuite, pas sûr (que ce soit tes noms ou mes noms) que ça avance plus vite, dans ces projets les compétences très pointues sont nécessaires.

          S'ils peuvent déléguer une partie de leurs tâches (trier les bugs et faire un support dit de niveau 1) c'est du temps gagner sur leur corps de métier.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Faut pas rêver

            Posté par  . Évalué à 1.

            @Zenitram

            Linux est principalement utilisé sur des serveurs,…

            Je n'ai vraiment pas envie d'y voir un troll ou de tomber dedans, néanmoins, vu qu'effectivement Linux est très utilisé en mode serveur, il ne lui manque justement pas de fonctionnalité ou de solution qui nécessiterait une urgence ou disont un besoin pressant d'aboutir.

            @Michel: Effectivement, c'est une des choses à laquelle je pensais.

        • [^] # Re: Faut pas rêver

          Posté par  (site web personnel) . Évalué à 2. 

          Linux est principalement utilisé sur des serveurs

          Comme la news parle du noyau il me semble maintenant que ton troll a vécu.

        • [^] # Re: Faut pas rêver

          Posté par  . Évalué à 10.

          Linux est principalement utilisé sur des serveurs

          Non, Linux est principalement utilisé sur des téléphones.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Faut pas rêver

          Posté par  . Évalué à 3.

          Linux est principalement utilisé sur des serveurs, alors parler de pilotes graphiques comme "les plus attendus à aboutir" me laisse très songeur

          Pas moi, comme tu le fais remarquer il est déjà pas mal utilisé sur les serveur, les machins comme btrfs, lxc, personne ne sait ce que c'est ou à quoi ça sert, et encore moins ce que ça va changer à leur vie de tous les jours; par ailleurs, faire des modifs sur un fs et tester le truc risque pas mal de perdre toutes les données du disque, donc il faut en faire une sauvegarde, avec de surcroit un disque de restauration (ou réinstallation). Bref un risque non négligeable de rendre la machine inutilisable.

          l'avantage de faire avancer un pilote comme radeon ou wayland c'est que
          1) c'est facile à tester
          2) au pire on rebascule en mode vesa sans kms.
          3) l'arrivée des jeux steam
          4) j'en ai rien à battre de btrfs, alors que je suis bien intéressé par un pilote performant pour ma carte grahique (ie: 100% des gens à qui j'ai posé la question n'en on rien a battre de btrfs, sondage réalisé par moi, sur un échantillon représentatif de 1 personne par la méthode très personnelle des quotas )

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Faut pas rêver

            Posté par  . Évalué à 5.

            Pourtant btrfs ça a l’air de roxxer du poney pour les sauvegardes : https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

            J’ai pas encore testé, mais si ça tient ses promesses c’est franchement intéressant.

            • [^] # Re: Faut pas rêver

              Posté par  . Évalué à 8.

              Les sauvegardes, c'est bien le truc qu'on fera "plus tard", dès que j'aurai fini ma partie de "Tue-tes-potes-3D"?

              Hmm, nan, je crois que les pilotes graphiques sont toujours plus attendus par les particuliers.

              ---------> [ ]

            • [^] # Re: Faut pas rêver

              Posté par  (site web personnel) . Évalué à 1.

              Moi ça me fait un peu peur de dépendre du fs pour faire des backups.

              Les backups, pour les particuliers en tout cas, c'est typiquement le truc dont tu ne te serviras qu'une fois dans 10 ans après avoir change 10 fois de machine. Tu penses que t'arriveras toujours a lire ton backup dans 10 ans, quand le nouveau système de fichiers mdrfs sera le plus mieux du monde et que tes machines ne sauront plus parler le vieillissant btrfs ?

              Moi, si je faisais correctement mes backups, je resterais sur quelque chose qui s’éloigne le moins possible de la hiérarchie dossiers/fichiers (typiquement rdiff-backup, ou a la limite un format bien documenté et facile a comprendre, comme duplicity ou ddar ou bup). Mais ça, c'est quand je ferai les choses proprement.

              • [^] # Re: Faut pas rêver

                Posté par  . Évalué à 7.

                Le format de backup de btrfs est documenté et assez clair (c’est grosso-modo un journal de modifications, pas un dump brut du FS).

                Ce qu’apporte btrfs c’est qu’il sait à priori bien mieux qu’un outil externe ce qui a changé depuis le dernier snapshot, le tout en gérant au poil la concurrence (modification pendant la sauvegarde). De fait, la notion de snapshot est un truc assez central dans btrfs et s’adapte particulièrement bien à la problématique. Les outils classiques qui ne se basent pas sur le FS sont obligés de :

                • soit faire un diff complet à la volée entre la source et la destination… ce qui interdit de fait de chiffrer les sauvegardes sur la machine d’origine sans que la machine de destination ait la possibilité de déchiffrer
                • soit garder l’état en mémoire, ce qui est une horreur d’un point de vue maintenance (par exemple avec duplicity, si tu veux ne garder que les clés de chiffrement sur la machine, et garder les clé de déchiffrement hors-site et hors-ligne, c’est un bordel incroyable si l’index local est corrompu/perdu : il faut le télécharger depuis la machine de sauvegarde sur la machine qui possède les clé de déchiffrement, déchiffrer les index, les renvoyer sur la machine original)

                Et dans les deux cas gérer le cas « modification du FS pendant qu’on sauvegarde » est un vrai cauchemar. Bon OK c’est pas moi qui gère ça mais les devs de duplicity/rdiff-backup/unison/whatever, mais quitte à faire confiance à une tierce partie je préfère faire confiance à btrfs (qui par design est bien mieux équipé pour gérer ce cas de figure) qu’à des devs externes qui doivent gérer toute cette complexité sans aide du FS.

    • [^] # Re: Faut pas rêver

      Posté par  . Évalué à 2.

      Il s'agit de parvenir à avoir un patch qui soit accepté dans la branche principale….et pas de devenir mainteneur.

      Et c'est tant mieux parce qu'être mainteneur est loin d'être le boulot le plus sympa quand on veut contribuer au noyau…

  • # me too

    Posté par  . Évalué à 3.

    Pareil, j'ai découvert ça hier et je me suis inscrit.
    Je n'y connais pas grand chose dans le noyau mais ça m'intéresse alors pourquoi pas!

    J'ai renvoyé le premier exo en essayant de bien montrer les preuves, comme demandé.. Il y a en a qui ont eu des réponses à ce premier truc ? La réponse automatique est se fait attendre par rapport à l'inscription ;)

    • [^] # Re: me too

      Posté par  . Évalué à 3.

      Pour ma part, exercice envoyé à 20h54, réponse à 21h54.

      • [^] # Re: me too

        Posté par  . Évalué à 5.

        J'attend de recevoir le premier exercice depuis 11h ce matin. Je vais casser ma touche F5.

        • [^] # Re: me too

          Posté par  . Évalué à 0.

          Oui, le délai entre le mail d'inscription et la confirmation/premier exo était plus important : mail envoyé à 11h27, confirmation + premier challenge à 17h46. Ce qui me fait me demander quelle est la part d'actions automatisées/manuelles dans l'infra mise en place.

          • [^] # Re: me too

            Posté par  . Évalué à 0.

            J'ai finalement eu la réponse à 21h pour un envoi à 14h…
            ça semble bien automatisé vu la réponse, qui me demande d'ailleurs des corrections et les logs… (que j'avais mis en pièce jointe…)

            • [^] # Re: me too

              Posté par  . Évalué à 5.

              Je pense qu'il s'agit d'un être humain qui répond avec des messages pré écrits.
              La validation des exercices se fait sans contraintes de formatages au niveau du rendu et il est dit qu'on peut envoyer des questions via cet email … J'ai envoyé une réponse hier soir et obtenu une réponse dans l'heure, j'en ai envoyé une autre ce matin et je n'ai toujours rien reçu …
              Je suppose qu'il est sur un autre fuseau horaire que moi, mais en tous cas, il est bien sympa de gérer tout ça.

              • [^] # Re: me too

                Posté par  . Évalué à 1.

                Hum, la ça a répondu du tac au tac…

                Vous comprenez quoi dans : "Please print to the kernel debug log level."

                J'ai perso fait un printk(KERN_INFO "Hello world\n");
                Vous avez fait quoi ? :P

                • [^] # Re: me too

                  Posté par  . Évalué à 3.

                  C'est bon, compris, j'ai changé le level du printk…

                  printk(KERN_DEBUG "Hello world\n");

        • [^] # Re: me too

          Posté par  (site web personnel) . Évalué à 0.

          La réponse était super rapide pour les Tasks 01 & 02, mais du coup pour la 03, j'attends depuis 24h…

          • [^] # Re: me too

            Posté par  (site web personnel) . Évalué à 2.

            Challenge victime de son succès ?
            Bot débordé par l'afflux de newbies ?
            Wait(random) pour nous habituer au fait que parfois les réponses de certains mainteneurs peuvent tarder ?
            Toujours est-il que la réponse est arrivée, après 3 jours d'attente.

      • [^] # Re: me too

        Posté par  (site web personnel) . Évalué à 1.

        Envoyé à 21h08, réponse à 21h12, rapide le lascar!

    • [^] # Re: me too

      Posté par  . Évalué à 3.

      Tu as mis quoi comme preuves ? Je ne comprend pas vraiment ce qu'il veut dire. Une capture d'écran du terminal ?

      • [^] # Re: me too

        Posté par  . Évalué à 2.

        J'ai copié/collé la sortie de mon terminal dans le mail au cours des diverses étapes : insertion du module, affichage du message, suppression du module, lsmod, etc.

        Pas de remarque sur ce format dans la réponse reçue.

      • [^] # Re: me too

        Posté par  . Évalué à 2.

        Idem, j'ai copié les deux fichiers puis la sortie de dmesg | tail -n 2

  • # Greg KH

    Posté par  . Évalué à 2.

    Comment sais-tu qu'il s'agit de Greg Kroah-Hartman ?
    Le seul email en rapport que je vois dans les archives de la liste kernel newbie vient de "Little Penguin"
    http://lists.kernelnewbies.org/pipermail/kernelnewbies/2014-February/009837.html

    • [^] # Re: Greg KH

      Posté par  . Évalué à 6.

      Il l'a posté sur G+ :
      https://plus.google.com/111049168280159033135/posts/6FtxJoaexro

    • [^] # Re: Greg KH

      Posté par  . Évalué à 3.

      L'adresse de contact est little at eudyptula-challenge.org

    • [^] # Re: Greg KH

      Posté par  . Évalué à 6.

      Je pense qu'il y a un petit malentendu : il n'est dit nulle part que c'est GKH qui est à l'origine de cette idée, il a juste relayé l'information sur les listes.

      • [^] # Re: Greg KH

        Posté par  . Évalué à 2.

        En effet, et rien ne permet de l'affirmer avec certitude (il ne vaudrait mieux pas pour lui, d'ailleurs).

        Par contre, au fur et à mesure que l'on avance au sein des différentes « tâches », un faisceau de présomptions commence à se former… :-)

  • # Levons le voile : premier exercice !

    Posté par  (Mastodon) . Évalué à 6.

    Je me suis aussi inscrit, et j'ai reçu le premier exercice.

    Je le copie/colle ici, car je pense qu'il est important d'en voir la teneur : ça a plus l'air d'être un guide (quelles sont les étapes à franchir, une par une), et pas un tutoriel (écrit ça, compile et voilà !). Ça me va, mais j'avoue avoir été un peu surpris.

    Il n'y a pas marqué RTFM en gros, mais il est clair que ça va être la première étape :)

    This is Task 01 of the Eudyptula Challenge
------------------------------------------

Write a Linux kernel module, and stand-alone Makefile, that when loaded
prints to the kernel debug log, "Hello World!"  Be sure to make the
module be able to be unloaded as well.

The Makefile should build the kernel module against the source for the
currently running kernel, or, use an environment variable to specify
what kernel tree to build it against.

Please show proof of this module being built, and running, in your
kernel.  What this proof is is up to you, I'm sure you can come up with
something.  Also be sure to send the kernel module you wrote, along with
the Makefile you created to build the module.

Remember to use your ID assigned to you in the Subject: line when
responding to this task, so that I can figure out who to attribute it
to.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Levons le voile : premier exercice !

      Posté par  . Évalué à 5.

      Tache 2 alors ;)

      This is Task 02 of the Eudyptula Challenge
------------------------------------------

Now that you have written your first kernel module, it's time to take
off the training wheels and move on to building a custom kernel.  No
more distro kernels for you, for this task you must run your own kernel.
And use git!  Exciting isn't it!  No, oh, ok...

The tasks for this round is:
  - download Linus's latest git tree from git.kernel.org (you have to
    figure out which one is his, it's not that hard, just remember what
    his last name is and you should be fine.)
  - build it, install it, and boot it.  You can use whatever kernel
    configuration options you wish to use, but you must enable
    CONFIG_LOCALVERSION_AUTO=y.
  - show proof of booting this kernel.  Bonus points for you if you do
    it on a "real" machine, and not a virtual machine (virtual machines
    are acceptable, but come on, real kernel developers don't mess
    around with virtual machines, they are too slow.  Oh yeah, we aren't
    real kernel developers just yet.  Well, I'm not anyway, I'm just a
    script...)  Again, proof of running this kernel is up to you, I'm
    sure you can do well.

Hint, you should look into the 'make localmodconfig' option, and base
your kernel configuration on a working distro kernel configuration.
Don't sit there and answer all 1625 different kernel configuration
options by hand, even I, a foolish script, know better than to do that!

After doing this, don't throw away that kernel and git tree and
configuration file.  You'll be using it for later tasks, a working
kernel configuration file is a precious thing, all kernel developers
have one they have grown and tended to over the years.  This is the
start of a long journey with yours, don't discard it like was a broken
umbrella, it deserves better than that.

      • [^] # Re: Levons le voile : premier exercice !

        Posté par  . Évalué à 9.

        Ça me fait réaliser qu’il est loin le temps où recompiler son noyau était LE rite initiatique que tout Linuxien devait accomplir tôt ou tard, même s’il n’avait aucune intention de devenir développeur noyau…

  • # Linux Device Drivers

    Posté par  (site web personnel) . Évalué à 6.

    Je pense que ça va être l’occasion de mettre un peu le nez dans Linux Device Drivers.

    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

  • # Réponse avec gmail

    Posté par  (site web personnel) . Évalué à 1.

    Bonsoir,

    il y en a qui ont réussi à répondre aux tâches en utilisant gmail ? J'ai posté ma réponse (en texte et pas html) mais il me dit que mes pièces jointes sont en encodées en base64. Une idée ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.