Le kernel Linux n'est sans doute pas la chose à laquelle il est techniquement le plus facile de contribuer.
Mauvais exemple, il est très très facile de contribuer au kernel en temps que débutant. Le nombre d'aspects même fondamentaux du kernel qui ont été chamboulés par un étudiant universitaire première année (notamment gestion mémoire, priorisation des processus, ordonnancement etc.) est considérable. J'étais en première année, avec moins de 6 mois de C dans les pattes quand j'ai participé au module smbfs, pendant qu'un autre étudiant pas meilleur que moi écrivait un pilote pour la prise en charge du retour de force sous Linux.
Si tu as un sujet qui intéresse, même si tu est nul en C, tu vas avoir pleins de contributeurs qui vont te prendre par la main et t'aider à mener ton truc à terme.
Bon sur certains sujets tu te fais allumer (genre changer le code des VT), mais en général le kernel Linux c'est plutôt sympa, même avec les newbies. Honnêtement c'est beaucoup plus facile d'aller dans le Kernel pour écrire un petit module rigolo que d'aller sur la glibc, DBus ou tout un tas de truc Gnome... (Et Xfree a "disparu", mais la il fallait avoir le cuir du dos bien tanné pour rentrer.)
La liberté d'un logiciel, c'est une techniquement question de licence, pas de complexité plus ou moins grande du code concerné.
Ça se discute, la liberté c'est surtout la capacité technique et légale de pouvoir adapter un logiciel à ses besoins. La capacité technique peut toujours s’acquérir en signant un gros chèque si besoin est. Enfin elle pouvait avant systemd. Si systemd rigidifie encore l'OS il n'y aura bientôt plus moyen de passer outre sans créer de toute pièce une nouvelle distrib et en la maintenant. Ça fait un vraiment gros chèque là quand même. Techniquement Linux en tant qu'OS sera toujours libre, mais si il devient impossible d'utiliser cette liberté on aura quand même perdu quelque chose. En théorie je suis libre de marcher sur la planète Mars, en pratique ça me fait une belle jambe.
Peut-être. Les technos en question n'en sont pas moins libres et documentées.
Documentées il faut le dire vite. Au niveau interface déjà c'est loin d'être évident, pour systemd sur les scopes et les environnements j'en ai soupé avant que la doc ne soit claire et à jour. Pour tout un tas de trucs genre journald, même si on nous explique comment s'en servir, bien malin qui est capable de dire comment ca fonctionne aujourd'hui - et même Lennart ne doit pas savoir comment ca fonctionnera dans six mois.
Par contre coté mécanique, les entrailles de la bête sont en constante évolution. C'est tous les jours une surprise. Un jour on fait un hold-up sur les cgroups, le lendemain on rajoute un démon NTP - tiens on a encore changé le format interne de networkd etc. La roadmap de systemd ressemble à un mauvais trip sous acide, j'aimerai vraiment pas avoir besoin de faire un dev spécifique pour cet init (vous savez le genre de trucs pour faire fonctionner une interface ou un périph très peu utilisé au sein de la communauté systemd...)
Et pour celui s'intéressant au basses couches du système, je ne doute pas qu'il saura s'adapter.
Ben écoute personellement, étant quelqu'un pour qui les couches basses du systèmes sont à la fois mon gagne pain, mon domaine d'expertise et ma passion - je ne te cacherai pas que j'ai des doutes. Je passe autant de temps que possible sur systemd (c'est à dire environ 10h par mois, j'ai une prod à faire tourner, d'autres trucs à surveiller et une vie sociale déjà bien assez maigre) et j'ai plus l'impression de me faire distancer par systemd que d'apprendre à le maitriser.
[^] # Re: vers la "privatisation" du système
Posté par Kaane . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 10.
Mauvais exemple, il est très très facile de contribuer au kernel en temps que débutant. Le nombre d'aspects même fondamentaux du kernel qui ont été chamboulés par un étudiant universitaire première année (notamment gestion mémoire, priorisation des processus, ordonnancement etc.) est considérable. J'étais en première année, avec moins de 6 mois de C dans les pattes quand j'ai participé au module smbfs, pendant qu'un autre étudiant pas meilleur que moi écrivait un pilote pour la prise en charge du retour de force sous Linux.
Si tu as un sujet qui intéresse, même si tu est nul en C, tu vas avoir pleins de contributeurs qui vont te prendre par la main et t'aider à mener ton truc à terme.
Bon sur certains sujets tu te fais allumer (genre changer le code des VT), mais en général le kernel Linux c'est plutôt sympa, même avec les newbies. Honnêtement c'est beaucoup plus facile d'aller dans le Kernel pour écrire un petit module rigolo que d'aller sur la glibc, DBus ou tout un tas de truc Gnome... (Et Xfree a "disparu", mais la il fallait avoir le cuir du dos bien tanné pour rentrer.)
Ça se discute, la liberté c'est surtout la capacité technique et légale de pouvoir adapter un logiciel à ses besoins. La capacité technique peut toujours s’acquérir en signant un gros chèque si besoin est. Enfin elle pouvait avant systemd. Si systemd rigidifie encore l'OS il n'y aura bientôt plus moyen de passer outre sans créer de toute pièce une nouvelle distrib et en la maintenant. Ça fait un vraiment gros chèque là quand même. Techniquement Linux en tant qu'OS sera toujours libre, mais si il devient impossible d'utiliser cette liberté on aura quand même perdu quelque chose. En théorie je suis libre de marcher sur la planète Mars, en pratique ça me fait une belle jambe.
Documentées il faut le dire vite. Au niveau interface déjà c'est loin d'être évident, pour systemd sur les scopes et les environnements j'en ai soupé avant que la doc ne soit claire et à jour. Pour tout un tas de trucs genre journald, même si on nous explique comment s'en servir, bien malin qui est capable de dire comment ca fonctionne aujourd'hui - et même Lennart ne doit pas savoir comment ca fonctionnera dans six mois.
Par contre coté mécanique, les entrailles de la bête sont en constante évolution. C'est tous les jours une surprise. Un jour on fait un hold-up sur les cgroups, le lendemain on rajoute un démon NTP - tiens on a encore changé le format interne de networkd etc. La roadmap de systemd ressemble à un mauvais trip sous acide, j'aimerai vraiment pas avoir besoin de faire un dev spécifique pour cet init (vous savez le genre de trucs pour faire fonctionner une interface ou un périph très peu utilisé au sein de la communauté systemd...)
Ben écoute personellement, étant quelqu'un pour qui les couches basses du systèmes sont à la fois mon gagne pain, mon domaine d'expertise et ma passion - je ne te cacherai pas que j'ai des doutes. Je passe autant de temps que possible sur systemd (c'est à dire environ 10h par mois, j'ai une prod à faire tourner, d'autres trucs à surveiller et une vie sociale déjà bien assez maigre) et j'ai plus l'impression de me faire distancer par systemd que d'apprendre à le maitriser.