Discussion :

[Stéphane le calme]

Linux en statistiques : en 2018, le kernel a grandi de 225 000 lignes de code
et de presque 50 000 commits

Le dépôt du kernel Linux est à 782 487 commits au total et compte un peu plus de 19 000 auteurs différents. Le référentiel est composé de 61 725 fichiers et de là, environ 25 584 633 lignes. Bien entendu, il ne faut pas oublier que parmi tout ceci figure également la documentation, des fichiers de construction Kconfig, divers assistants / utilitaires, etc.

Jusqu'à présent, cette année, 49 647 commits ont ajouté 2 229 836 lignes de code et 2 004 759 lignes de code ont été perdues. Ou un gain net de seulement 225 077 lignes. Il faut garder à l'esprit qu'il y a eu la suppression de certaines anciennes architectures de CPU et d'autres codes supprimés dans les noyaux cette année, alors que beaucoup de nouvelles fonctionnalités ont été ajoutées.

En 2017, il y a eu 80 603 commits avec 3 911 061 ajouts et 1 385 507 suppressions. Étant donné qu’il reste un peu plus d’un trimestre pour clôturer l’année, les statistiques en 2018 en termes de commits et d’ajouts de lignes pourraient être inférieures aux deux années précédentes.

Linus Torvalds reste le contributeur le plus fréquent avec un peu plus de 3% pour 25 894 commits créés depuis le début de l’aventure. Les autres contributions majeures au noyau cette année proviennent de David S. Miller (1,35 %, pour 10 581 commits), Mark Brown, Takashi Iwai et Al Viro.

Jusqu'à présent, en 2018, 3 320 adresses e-mail différentes ont été validées. Ce chiffre est en réalité nettement inférieur à celui des années précédentes. De 2015 à 2017, il y avait 4014 ~ 4400 auteurs différents (4400 auteurs en 2017). Nous verrons au cours des trois derniers mois de l’année s’il ya une augmentation significative, mais c’est l’une des conclusions les plus surprenantes de ces chiffres actuels. 2013 était la dernière année durant laquelle il y avait un nombre de contributeurs tournant autour de 3300.

En ce qui concerne les principaux contributeurs au noyau basés sur le domaine de messagerie d'entreprise, cette liste est constituée d'Intel, Red Hat, de la Linux Foundation, de Linaro, de SUSE, de Texas Instruments et d'AMD. Gardez à l'esprit que le nombre de validations Intel est en réalité proche de 60 000 commits, mais que GitStats signalait séparément les emails intel.com et linux.intel.com. Un peu surprenant, ARM n’a pas encore trouvé sa place sur cette liste.

Source : statistiques générées par Gitstats

Voir aussi :

Linus Torvalds réserve le mauvais vol et le comité décide de modifier la date du prochain sommet des mainteneurs Linux
C'est un téléphone Linux basé sur le Raspberry Pi et à monter soi-même : le ZeroPhone débarque bientôt pour 50 $
VoCore2 : un nanoPC Linux de la taille d'une pièce de monnaie capable de lancer le jeu Doom et pouvant servir de routeur sans-fil
Intel veut une distribution Linux pouvant servir de solution de sécurité de référence aux systèmes où l'autonomie et la sécurité sont critiques
Linus Torvalds annonce la disponibilité de la version 4.18 du noyau Linux : un aperçu des fonctionnalités qui ont été ajoutées

[Anselme45]

Ce qui prouve que la communauté Linux est bien vivante et en pleine santé...

Ce qui est, dans un monde où les fournisseurs d'operating system ont pris la mauvaise habitude d'espionner la vie privée de leur utilisateurs, un grande et bonne nouvelle!

[Aeson]

encore des gens qui veulent etre payé a la ligne de code...

Ca ne veut absolument rien dire....

[hotcryx]

Ca veut dire que le noyau est en constante évolution.
Un projet qui n'est pas prêt de mourir.

[Aeson]

On est d'accord que Le kernel Linux ne va pas mourrir. Que du contraire. Mais le nombre de ligne de code ne veut absolument rien dire. Enlever des lignes de code a un projet peut meme vouloir dire qu'on s'occupe plus du projet car on refactorise et simplifie le code...

[yildiz-online]

Enlever des lignes de code a un projet peut meme vouloir dire qu'on s'occupe plus du projet car on refactorise et simplifie le code...

C'est le cas:

Jusqu'à présent, cette année, 49 647 commits ont ajouté 2 229 836 lignes de code et 2 004 759 lignes de code ont été perdues.

[Aeson]

Le nombre de ligne de code ne veut rien dire sur la qualité du code. Mais si vous pensez le contraire a vous de savoir....

[esperanto]

D'accord avec les interventions précédentes, le nombre de lignes est un mauvais critère, surtout en C où une ligne a de bonnes chances de se réduire à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

}

ça peut même avoir une connotation négative, on peut se demander si il n'y a pas parmi ces lignes des bouts de code qui n'ont rien à faire dans un noyau (c-à-dire qui trouveraient mieux leur place à un niveau plus applicatif)

La prochaine fois mettez plutôt en avant le nombre de commits et d'auteurs, c'est bien plus pertinent.

[yildiz-online]

Le nombre de ligne de code ne veut rien dire sur la qualité du code. Mais si vous pensez le contraire a vous de savoir....

Mais personne n'a dit ça, ce n'est pas le sujet de l'article d'ailleurs, mais si ça t'inquiète, tu peux aller vérifier, c'est open-source.

Et ensuite tu peux comparer avec windows... ah non, tu peux pas, tant pis.

[Aeson]

ce n'est pas le sujet de l'article d'ailleurs

C'est quoi le titre de l'article ?

Et ensuite tu peux comparer avec windows... ah non, tu peux pas, tant pis.

Qui parle de Windows ? personne... CA c'est pas le sujet. Par contre le titre c'est le sujet... par definition....

[yildiz-online]

C'est quoi le titre de l'article ?

Linux en statistiques : en 2018, le kernel a grandi de 225 000 lignes de code
et de presque 50 000 commits

L'article parle du nombre du LOC, commit, contributeur, nul part il n'est fait mention de qualité de code.

Qui parle de Windows ? personne...

Si moi, c'est ce qu'on appelle un contre-exemple, pour te montrer qu'il est possible de vérifier par soi même avant remettre en cause la qualité(ou quoi que ce soit d'autre), quelqu'un d'habitué à l'open source aurait eu ce réflexe, on peut donc en déduire que tu es plutôt utilisateur de système fermé, d'où l'intérêt du contre-exemple.

[Aeson]

le kernel a grandi de 225 000 lignes de code

La remarque etait JUSTEMENT la dessus... le nombre de ligne de code... Ca tombe bien c'est justement dans le titre...

Si moi, c'est ce qu'on appelle un contre-exemple

Encore une fois aucun rapport...

on peut donc en déduire que tu es plutôt utilisateur de système fermé

raté...

pour te montrer qu'il est possible de vérifier par soi même avant remettre en cause la qualité

Si t'es developpeur et que t'es pas d'accord sur le fait que le nombre de ligne de code n'as aucun rapport avec la qualité ou la popularité d'un projet,... change de metier....

De plus, t'as pas access au code de Windows donc impossible de savoir le nombre de ligne de code. Donc ton exemple n'a aucun sens...

[yildiz-online]

La remarque etait JUSTEMENT la dessus... le nombre de ligne de code... Ca tombe bien c'est justement dans le titre...

Le nombre de ligne de code ne veut rien dire sur la qualité du code. Mais si vous pensez le contraire a vous de savoir....

T'es quand même le seul à avoir évoqué la qualité de code, faudrait savoir...

raté...

Si tu es incapable de lire un code ouvert pour en déterminer la qualité, ou de faire tourner un analyseur de code statique dessus, change de métier...
Ca ne sert à rien de venir parler d'hypothétique qualité alors qu'elle est vérifiable par tout-un-chacun.

Si t'es developpeur et que t'es pas d'accord sur le fait que le nombre de ligne de code n'as aucun rapport avec la qualité ou la popularité d'un projet,... change de metier....

Mais je n'ai jamais parlé de qualité, je ne la connais pas, et elle ne m'intéresse pas, il n'y a que toi qui fait une fixette dessus.
Moi la qualité du kernel, c'est le dernier de mes soucis, je suis utilisateur final, donc tant que ça fonctionne et que c'est bien maintenu, c'est tout ce qui m'intéresse.
Puis je suis pas développeur, alors...

[Vulcania]

@Aeson je suis pas d'accord, le nombre de lignes d'un projet ne témoigne pas de sa qualité dans l'absolu, mais déclarer que ça veut rien dire...
Quand on supprime 2 millions de lignes de code inutilisé, pour moi ça traduit par moins de bordel dans le code à gérer, et je doute qu'ils se soient amusés à changer la manière de faire les sauts de lignes avec les "if" pour atteindre ce chiffre.

Ya plein d'outils d'analyses qui vont justement compter le nombre d'instructions par ligne pour obtenir une complexité/densité de code. Bref, ça reste un indicateur pertinent (et surtout dans le cas présent, quand on parle d'un grand ménage).

[hotcryx]

On est d'accord que Le kernel Linux ne va pas mourrir. Que du contraire. Mais le nombre de ligne de code ne veut absolument rien dire. Enlever des lignes de code a un projet peut meme vouloir dire qu'on s'occupe plus du projet car on refactorise et simplifie le code...

Ok, mais ils n'ont pas fait 780.000 commits de suppression de lignes

[anapurna]

salut

comme le dis de nombreux intervenant le nombre de ligne ainsi que la taille du code n'as que très peu d'importance
l'ajou de fonction ou le nombre de devices pris en compte ainsi que la vitesse,la stabilité et la sécurité sont des critère objectif

En grossissant le défaut voici pourquoi le comptage de ligne est une aberration

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
if (TEST1()) 
{ 
  OPE1
  OPES1;
}
else 
{ 
  OPE2;
  OPES2;
}

10 lignes
et tout aussi valable que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (TEST1()) {  OPE1; OPES1;} else {   OPE2; OPES2;}

1 ligne

le deux code font exactement la même chose

[Aeson]

cPuis je suis pas développeur, alors...

Ca explique tout...

[Steinvikel]

T'es quand même le seul à avoir évoqué la qualité de code, faudrait savoir...

yildiz, bien que certains de tes arguments précédents soient pertinent, je me dois de te faire remarquer que celui-ci fait preuve d'énormément de mauvaise foi :
Aeson : " Le nombre de ligne de code ne veut rien dire sur la qualité du code. "
Aeson faisait simplement remarquer /rappeler que parler de nombre de lignes d'un code n'est pas un indicateur direct de sa qualité. Une remarque qui à toute sa légitimité dans un site côtoyé à la fois par des experts et des profanes. Les gué-guerres de visibilité à coup de "c'est moi qui ai la plus grosse" sont d'une banalité aujourd'hui... et c'est peut-être le cas (consciemment ou inconsciemment) de cet article, qui n'expose que des chiffres, sans réellement étayer ces derniers par leur implication dans ce qu'il faudrait pouvoir en déduire... car après tout, c'est une news, pas une vulgarisation de statistique.

De plus, à la défense d'Aeson, pour juger de la qualité d'un code, autre que son aspect esthétique (ex: l'aération), il faut connaitre le langage, et le paradigme utilisé (un langage inconnu /pas-maîtrisé et un paradigme d'aspect complexe donne vite l'impression de programmation spaghetti).

(...) le nombre de ligne de code n'as aucun rapport avec la qualité ou la popularité d'un projet (...)

(...) le nombre de lignes est un mauvais critère, surtout en C où une ligne a de bonnes chances de se réduire à '}' (...)

@Aeson je suis pas d'accord, le nombre de lignes d'un projet ne témoigne pas de sa qualité dans l'absolu, mais déclarer que ça veut rien dire...
Quand on supprime 2 millions de lignes de code inutilisé, pour moi ça traduit par moins de bordel dans le code à gérer, (...)

Je rejoins Vulcania, un code source se décrit, entre autre, par sa taille. Ce n'est évidement pas un critère principal, mais c'est un facteur parmi d'autres. Le vrai problème si l'on retient ce critère pour juger de la qualité, c'est de ne pas le mettre en corrélation avec des critères nettement plus significatifs... on appel ça un biais cognitif, ou encore "réduire qqch à".

Se séparer du support de matériels préhistoriques fait sûrement du bien au code, je suppose que la décision à été prise à l'encontre de l'intérêt de ces utilisateurs finaux concernés, à cause de leur extrême minorité. De plus, de mémoire, une partie de ce code n'étais plus maintenu.

Moi la qualité du kernel, c'est le dernier de mes soucis, je suis utilisateur final, donc tant que ça fonctionne et que c'est bien maintenu, c'est tout ce qui m'intéresse.

Je ne suis pas développeur non plus, mais pour ma part, au contraire, j'y place une grande importance. Je ne pars pas de Windows pour un autre Windows-like (#Ubuntu), ni pour un noyau qui fonctionne, mais est bourré d'instabilité, vérolé de back-door, ou autres failles de sécurité... très peu pour moi.

(...) le nombre de lignes (...) ça peut même avoir une connotation négative, on peut se demander si il n'y a pas parmi ces lignes des bouts de code qui n'ont rien à faire dans un noyau (...)

Je ne connais pas les critères d'admission des implémentations de fonctionnalités noyau (ou des couches plus basses), mais je suppose que ça comporte au moins l'interface avec le hardware (d'où une taille toujours croissante), ainsi que des mécanismes de sécurisation avec les couches supérieures ...quand à savoir quelle est la distinction pour qu'une fonction soit "noyau" ou "applicative", je donne ma langue au chat.

Ya plein d'outils d'analyses qui vont justement compter le nombre d'instructions par ligne pour obtenir une complexité/densité de code. Bref, ça reste un indicateur pertinent (et surtout dans le cas présent, quand on parle d'un grand ménage).

Il me semble que j'en avais vu un qui comptabilisait les lignes par analogie à des blocs insécables (1 corps de fonction = 1 ligne), exemple d'une portion compté comme une ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
switch(1) {
    case 1 : cout << '1'; // prints "1",
    case 2 : cout << '2'; // then prints "2"
}

[yildiz-online]

yildiz, bien que certains de tes arguments précédents soient pertinent, je me dois de te faire remarquer que celui-ci fait preuve d'énormément de mauvaise foi :
Aeson : " Le nombre de ligne de code ne veut rien dire sur la qualité du code. "
Aeson faisait simplement remarquer /rappeler que parler de nombre de lignes d'un code n'est pas un indicateur direct de sa qualité.

Et personne ne dit le contraire, personne ne s'est pâmé devant la qualité du code, donc pourquoi venir et dire que ce n'est pas un indicateur?
C'est non seulement hors sujet, mais particulièrement négatif comme approche, si au moins il était venu avec un argumentaire factuel: par exemple sur les xxx milliers de code, autant de nouveau bugs, l'analyseur de code a détecté X problèmes... ça aurait eu de l’intérêt.

Une remarque qui à toute sa légitimité dans un site côtoyé à la fois par des experts et des profanes. Les gué-guerres de visibilité à coup de "c'est moi qui est la plus grosse" sont d'une banalité aujourd'hui... et c'est peut-être le cas (consciemment ou inconsciemment) de cet article, qui n'expose que des chiffres, sans réellement étayer ces derniers par leur implication dans ce qu'il faudrait pouvoir en déduire... car après tout, c'est une news, pas une vulgarisation de statistique.

Connaître le nombre de lignes ajoutée est une valeur intéressante sur la progression du projet, pas sur sa qualité, on peut en déduire si il attire plus de contributeurs, et faire une corrélation avec le nombre de fonctionnalités introduites dans le laps de temps étudié.
Il est également intéressant de connaitre la participation des sociétés impliquées, nulle question de "qui à la plus grosse" vu qu'on a pas vraiment de point de comparaison possible avec les autres OS grand public qui sont fermés.

De plus, à la défense d'Aeson, pour juger de la qualité d'un code, autre que son aspect esthétique (ex: l'aération), il faut connaitre le langage, et le paradigme utilisé (un langage inconnu /pas-maîtrisé et un paradigme d'aspect complexe donne vite l'impression de programmation spaghetti).

D'où l'invitation qu'il aille vérifier par lui même si ça l'intéresse, mais ce n'est pas le sujet de l'article.

Je rejoins Vulcania, un code source se décrit, entre autre, par sa taille. Ce n'est évidement pas un critère principal, mais c'est un facteur parmi d'autres. Le vrai problème si l'on retient ce critère pour juger de la qualité, c'est de ne pas le mettre en corrélation avec des critères nettement plus significatifs... on appel ça un biais cognitif, ou encore "réduire qqch à".

Au vu des architectures microservice et microkernel, la taille n'est certainement pas significative dans tous les cas, elle pourrait l'être pour les soft monolithiques, mais tout ce qui est modulaire n'est pas concerné.
Aujourd'hui la tendance est aux systèmes simples, horizontalement évolutifs, et çà déploiement rapide et automatisés, donc tout sauf de grosses applications.

[Aeson]

On parle d un Kernel ici... pas d un de tes jeux.. Le titre est clair. Il met en avant le nombre de ligne de code. Ce qui ne veut rien dire dans le dev d un Kernel... T es même pas développeur... arrête de t humilier. Chaque dev sait que le nombre de ligne de code ne veut rien dire...