Reprise du message précédent :

 
Et donc d'où sort l’accélération du futur ? Parce qu'il n'y a rien qui change depuis 2 ans mais ça va être pire  

Parce que c'est prévu depuis 2 ans d'aller plus vite, et que la validation des patch est de plus en plus accéléré, et que c'est la nouvelle philosophie que Linus souhaite, et que donc, a terme, on se dirige vers un patch mineur inférieur a la semaine (se qui est déjà le cas des fois), et que donc ça ira de plus en plus vite, et que donc certaines distro auront du mal a suivre ?

Clairement non : https://git.kernel.org/cgit/linux/k [...] .git/refs/
 
Déjà dans les dernière 2.6.3x on était calé dans le schéma actuel, et j'aimerai bien que tu me trouves les sources comme quoi il (Linus) veut/voudrait aller "plus vite". C'est le manque de visibilité qu'apportait en 2.6.31.5 par rapport à la 2.6.31.4 (et aussi un clin d'oeil aux 20 ans du noyau) qui a fait qu'il ait passé un un système plus "dynamique" avec la 3.0 qui n'était qu'en fait qu'une 2.6.40 et aussi qu'il en avait juste envie.
 
Le fait que l'utilisation de git (qui ne passera pas avant longtemps sous libgit2 malheureusement) facilement grandement la vitesse d'intégration de code source externe au noyau de grande ampleur (genre une architecture complète ARM) mais non, ce n'est pas avec une fois un 9 changements à l'heure qu'on doit penser à une accélération (ou alors il faut des sources qui corroborent cela).

 
Je te laisse relire le pourquoi du comment ici http://thread.gmane.org/gmane.linu [...] us%3D54378 et ici https://lkml.org/lkml/2011/5/29/204 et c'est encore discuté sur la lkml, mais bon ...  

 
As tu compris ce qu'était la Merge Window ?

 
Le sujet de discussion qu'on as actuellement, la fenêtre entre la parution d'un patch et/ou modification et son commit dans le kernel, donc théoriquement l'espace qui sépare 2 releases du kernel entre un 3.X.Y et un 3.X.Z

 
Bah la Merge Window n'est pas du tout cela.
 
Ça a été formalisé avec l'apparition en 2005 de git : c'est le temps imparti aux développeurs de nouvelles fonctionnalités et/ou lourdes modifications de l'existant pour voir leur Pull Requests acceptés par Linus et/ou ses "lieutenants" selon le domaine impacté. C'est la qu'on inspecte, approuve ou pas et merge ou pas (et avec Git c'est nettement plus simple vu qu'il a été limite fait pour) pour une version 3.X.0. Et la durée est de plus ou moins 15 jours. Ce n'est pas le temps entre les tags d'une version 3.X.Y à 3.X.Y+1.
 
Et par habitude (de git), on commence à raccourcir le temps de la Merge window, il y a aussi en effet une volonté de réduire ce temps car c'est à ce moment la que l'état du noyau est le plus "instable", les -rc étant la pour éprouver et tester à plus grande échelle les nouveautés mais bien sur pour intégrer au fil de l'eau des correctifs sur de l'existant, tout comme le font les versions "mineures" en 3.X.Y quasiment chaque semaine.
 
Après libre aux mainteneurs de distribution de faire le tri entre correctifs majeurs / mineurs venant de l'upstream (sachant qu'ils sont déjà backportés sur les noyaux LTS comme le 3.0, 3.2, 3.4 qui sont aussi les bases des kernels Android) mais faut m'expliquer en quoi c'est plus complexe qu'avant de les maintenir (avec 3 LTS) avec les outils actuels.
 
PS : je peux comprendre que l'on puisse raisonner dans ton schéma, 5 minutes avant de tager la version 3.10 Linus a mergé un fix pour PowerPC  

Tu sais les formalisations, je m'en fou, les accords plus ou moins tacites, je m'en fou aussi, ta merge windows, au final ça reviens quand même a dire que c'est un temps entre deux releases, osef de savoir la technique derrière, je vois pas ce que ça change, pour moi au niveau système. Moi je constate que les changements sont de plus en plus nombreux, dans un laps de temps donné, ou alors pour faire l'inverse : le temps entre deux changements est de plus en plus court. Parce que se que t'oublie derrière, c'est que les mainteneurs de distro doivent valider de plus en plus de modifications avec un temps de sortie peut être fixe, mais ou les changements de sont de plus en plus nombreux > on en revient a se qu'il faille de moins en moins de temps pour faire évoluer le kernel.
Tu pourra prendre le problème dans tout les sens : tout est une question de X/temps, que ça soit temps qui soit varible, ou X qui soit variable, dans les deux cas c'est une mesure de travail, que ça soit le travail d'un choux, d'un navet, d'un dev, ou d'un muscle voir même de n'importe quoi : c'est des mécanique, et je doute qu'on soit dans un univers quantique pour modifier cet état de fait, si les modifs sont plus importantes dans un même temps donné, la quantité de travail augmente (effectuée ou a effectuer), moi je dit que le temps diminue entre deux modifs, ce qui reviens au même, puisqu'au final, la quantité de travail augmente quand même.
 
Et non, les mainteneurs de distribution ne sont pas libre, puisque justement ça a été quoté, faut qu'ils arrêtent de dire qu'ils supportent une série de kernel alors qu'ils ne supportent pas tout, et d'ailleurs au final, la numérotation kernel va dans le sens d'une mesure du temps puisqu'on as (et tu l'a souligné) X.Y.Z ou X = décennie avec un temps donné pour Y (plus ou moins 15 jours) et Z pour mesurer le travail <_<, donc au final on en revient au fait que la quantité de travail est de plus en plus importante pour maintenir le kernel dans une distro.

Si tu te fous du formalisme, je vais avoir du mal à faire des réponses "précises", non ? Sinon en vrac:
 
_ La version 3 n'a rien a voir avec une question de décennie, c'est Linus qui a décidé ça, limite unilatéralement car il en a le pouvoir en tant que dictateur bienveillant (à la Guido van Rossum), il trouvait que ça tombait bien pour les 20 ans (la version 2 n'est pas sortie 10 ans après) et que ça rendait plus lisible l'évolution du noyau SANS changer son rythme (cf le gitlog sur 7 ans) ni casser les ABI / API.
 
_ les releases sont depuis 7 ans toujours au même rythme (cf le gitlog) à une ou deux semaines prés (nombre de rc). Toutes les dates de tag sont disponibles et vont dans ce sens.
 
_ le nombre de fichiers à intégrer augmente (ainsi que leur taille), mais la facilité à le faire aussi : merger 3 branches différentes avec 1,2.. 50.. 250, 1000 fichiers différents prend quelques minutes avec git, merger UNE seule feature repartie sur 50 fichiers sur pouvait prendre des dizaines de minutes avec CVS par exemple (merci je l'ai fait durant des années sur un autre kernel libre que Linux donc je connais un peu le truc !! Maintenant, c'est un plaisir de mettre à jour son noyau custom android avec la LTS 3.0)
 
_ que certains mainteneurs de kernel pour certaines distributions aient du mal, bah c'est parce qu'ils ont trop dévié de l'upstream (ie Kernel Linux "de base" ) ou quoi ? Maintenant que ceux sous 2.6.18.x.y-pouet-pouet galèrent, c'est cool, mais on est en 2013 et il y a plein de branches "vanilla" (les 3.0, 3.2, 3.4) qui sont en LTS. Alors je sens venir le couplet des RedHat ou truc ou bidule qui font des releases du genre parce qu'ils certifient du matériel avec des versions paléolithiques (2.6.16 ou 2.6.27 qui sont en plus en "EOL" ) tu penses que ce même matériel marche moins bien en 3.9.9 ? Surtout que dans 99.9% des cas, il fonctionnera de la même façon voire mieux. Mais bon si ça peut en rassurer certains d'être en 2.6.18 ou .27 ou .32, pourquoi pas hein (je bosse dans une structure avec des centaines de serveurs Linux en RH). Certes il y a des modules un peu reloud mais il ne faut pas abuser non plus...
 
 
Sinon pour le reste de la discussion initiale :  
 
_ le nombre de changements par jours (respectivement par heure) n'est rien d'autres que le nombre total de commits (Merge Windows + rc) pour arriver à la version 3.X divisé par le nombre de jours (respectivement (jours x 24)) entre début de Merge Window et le tag de la version 3.X (c-à-d 13627 commits sur 63 jours dans le cas du 3.10 et 10247 commits sur 71 jours pour le 3.6)
 
_ le nombre de commit est décorrélé du nombre de lignes ajoutées / supprimée / modifiées (modulo qu'un commit fait au moins l'un des trois actions pour au moins une ligne) : un commit peu ajouter 1000 lignes, comme 100 commits peuvent au final modifier juste 1 caractère entre la V1 et V100 (sauf que c'est typiquement le genre de commit qui sera refusé, faut pas déconner).
 
_ si le nombre global entre modifiées / ajoutées / supprimées augmente de 10% mais que le nombre de commit augmente de 20%, moi je trouve pas ça forcement rassurant en terme de qualité (les commits, je le rappelle, passent par une revue de code) parce que pour augmenter de 10% le nombre de ligne on a du passer par bien plus que 10% de commit supplémentaires : les premières versions n'étaient pas si bonnes, il a fallu les reprendrel. Donc pour ceux qui pensent que c'est mieux, bah non pas franchement, mais après il faut corréler ça avec le fait qu'il y a plus de developpeurs donc des moins expérimentés, donc plus de chance qu'il faille rependre des commits, donc qu'on en ai plus donc plus de changements à l'heure DURANT le développement d'une version 3.X.
 
 
Je suis désolé d'être aussi reloud avec ça, mais je préfère que les choses soient plus claires et précises et si certain(e)s n'en n'ont cure du formalisme, méthodologie, chiffres, et bien tant pis.
 
PS : l'analyse du tableau de MagicPanda ne se fait pas en 10 secondes, surtout pour penser que 9 changements/heure est un "bon" point.

 
Ca serait encore mieux si l'échelle de temps était linaire.
 

 
Globalement ok, mais sur ce point, t'es pas super précis non plus.
1 ou 2 semaines sur 60 jours, c'est pas négligeable.
On voit qu'avant mai 2011, il faut remonter à 2005 avant d'avoir 62-63 jours entre 2 versions majeures.
 
Après, je me garderais de faire l'expert, mais on peut penser que la complexification du noyau appelle des commits plus atomiques & "transparents" pour mieux suivre ce qui se passe.

La prochaine version du noyau Linux s’appellera…

Linux pour Workgroups 3.11, le noyau prêt pour le bureau .

Hello,
 
J'ai tenté une installation d'un Linux pour un pc au boulot sur un DD partionné (quick format;procédure habituelle à ce qui parait) mais malgré l'installation réussie,le pc ne boot pas car ne trouvant pas d'OS.
 
Je dois aussi effacer le mbr a l'aide d'une disquette mais j'obtiens ce message d'erreur "no such fixed disk" et ça ne me dit rien.
J'ai tenté de switcher les DD et de changer de nappe et c'est pareil.
 
Ca interpelle quelqu'un ? Thanks

salut, tu devrais plutôt demander ça sur le topic dédié à la distribution que tu as installé, ou de créer un nouveau topic à défaut.
Ici on parle juste du kernel linux, qui n'est pas un OS à lui seul.

Oki (mais me souvient pas de la version) j'verrai demain si j'y arrive toujours pas.

(Parce que Linux et moi........)

Linux est moi
   Linux !
 
Sinon, je pense que la grammaire et l'orthographe, c'est aussi un souci   .

Aussi

On réveille les vieux topics : 3.13 out .

Linux prêt pour le bureau, le running gag depuis 1998

 
Le running troll depuis 1998

http://kernelnewbies.org/Linux_3.13

ça poste très peu sur ce topic, pas normal tout ça vu l'impact du noyau sur une distribution, je m'attendais à voir des rapports de bugs ici vu la mauvaise réputation du noyau 3.13.x,

ou alors il y a très peu de forumeurs HFR qui utilisent une rolling release comme distribution

Je pense surtout que la cat a été déserté..
 
XaT

Pas de souci en 3.13.(2 là) pour ma part.

Sur fedora, ca m'a cassé le module Nvidia pour bumblebee  
 
Upgrade foireuse du matin bonjour  

 
Peut être aussi que les mainteneurs du package noyau veulent aussi que le 3.13 soit bien perçu et avoir un nftable "complet" ?
Et franchement les changelog entre le 3.13.1 et 3.13.2 faisait peur !

Je pense aussi que beaucoup de distrib ont des noyaux plus anciens, et que ceux qui suivent ce qu'il se passe regardent LKML !

Nan mais moi non plus j'ai pas de soucis avec le 3.13.x c'est surtout ceux qui utilisent des kernel précompilés qui se bouffent les roustons xD

 
T'as pas d'ATI/AMD donc forcement pas de problème, Gentoo ou pas, avec t'as des emmerdes avec les premiers 3.13.x

J'ai une 7870 qui me sert a miner de temps en temps :>

Ouais donc pas soumise aux problèmes rencontrés. Alors la remarque des kernels compilés, comment dire. Enfin j'ai trouvé marrant il fut un temps de compiler moi même mon kernel, mais ça fait très très longtemps (et ça me fait flipper en fait de repenser à la date !), mais les gains maintenant, quand tu n'as pas le userland qui va bien, bof.. Je me voyais pas faire la course aux 3.13.x sans nftables un peu plus avancé... Après chacun son trip !

3.14 out .

http://linuxfr.org/news/sortie-de-linux-3-14
 
yep le changelog est impressionnant

Ouch sur le coup j'ai cru à poisson !

Le lecteur de carte sd de mon dell latitude e7440 fonctionne enfin

Hello,  
 
J'ai installé le kernel 3.13-1 (linux-image + header) sur une distri Raspbian sur Raspberry PI.
J'ai bien les nouveaux fichiers dans /boot, mais un uname-a me retourne toujours la version 3.10.
 
J'ai manqué une étape ?

redémarrer sur le bon noyau ?

Effectivement, je n'ai pas fait cette étape =/
Ça se passe comment ? make menuconfig ? Première fois que je fais ça