Il corrige le problème de corruptions des inodes du 2.4.15 et aussi quelques autres corrections.
Voici un morceau du ChangeLog :
- Fix 8139too oops (Philipp Matthias Hahn)
- Correctly sync inodes in iput()(Alexander Viro)
- Make pagecache readahead size tunable via /proc (was in -ac tree)
- Fix PPC kernel compilation problems (Paul Mackerras)
Maintenant que Linus ne s'occupe plus de la branche 2.4.x, espérons que ça ira mieux ;-)
Aller plus loin
- Liste des miroirs (2 clics)
- ChangeLog (2 clics)
# Juste pour dire...
Posté par Anonyme . Évalué à 1.
Marcello ferait-il de l'excès de zèle ? ;)
[^] # Re: Juste pour dire...
Posté par gle . Évalué à 1.
le trollla dernière ligne ne fait pas partie du ChangeLog d'origine. ;-)[^] # Re: Juste pour dire...
Posté par kalahann . Évalué à 1.
A partir de maintenant, les patchs seront testés dans le noyau instable puis backportés dans le noyau 2.4, on n'aura plus de problèmes de ce genre (ou alors beaucoup plus rarement) car tout sera mieux testé. On se plaindra tôt ou tard que tout n'est pas backporté assez vite dans le noyau stable comme pour l'USB, mais c'est une autre histoire ;)
Les développeurs ont enfin un noyau "on the bleeding edge" pour s'amuser entre eux et faire péter toutes leurs données dans la joie et la bonne humeur. Ils vont s'arrêter de tout casser dans le noyau stable en voulant réécrire des VM et toucher aux inodes à tout bout de champ!
C'est quand même dingue de toucher à des parties aussi sensibles sur un noyau stabilisé sans les tester à fond. Je sais y'avait de très bonnes raisons pour ça, dont leur frustration de pas avoir de *vrai* noyau de dev, mais de toute façon c'est un troll sans fin.
[^] # Re: Juste pour dire...
Posté par freePK . Évalué à 1.
Mais arretez un peu avec cette histoire... Le noyau 2.4.x, avec x<=15 n'etait pas un noyau stable, dixit Linus en personne. C'est quand meme lui que l'on peut croire, non ? Il change les regles comme cela l'arrange (car depuis les 1.2.x, cela a change souvent, notamment le backport de code stabilise d'une version en dev). Qu'il y ait eu des problemes ou des changements majeurs dedans est normal. Il n'y a rien a dire d'autre sur le sujet (si ce n'est que d'utiliser un 2.2.x pour les serveurs).
C'est quand meme pas difficile a comprendre...
PK, qui n'arrive pas a comprendre comment on peut disserter la-dessus.
[^] # Re: Juste pour dire...
Posté par kesako . Évalué à 1.
vi, vi, mais y a quand meme certains trucs du 2.4 qui sont trop importants pour laisser un serveur en 2.2.
Eternel probleme de "ceux qui se mouillent les premiers" ...
[^] # Re: Juste pour dire...
Posté par gege . Évalué à 1.
Les principales évolutions entre le 2.2 et le 2.4 concernent des éléments multimédia et USB. Pour le reste, la VM a changé, la stack IP a été refaites, mais les fonctionnalités équivalentes sont présentes dans les kernel 2.2.
Alors si tu préfères utiliser un noyau optimisé (ce que je suppose être tes 'trucs') mais instable sur un serveur, libre à toi, mais ne viens pas te plaindre qu'il est instable... Personnellement, je préfère laisser les optimisations aux autres et garder un noyau stable pour les applis importantes.
[^] # Re: Juste pour dire...
Posté par Gentoo][Gravis . Évalué à 1.
[^] # Re: Juste pour dire...
Posté par kesako . Évalué à 1.
non non ca c'est du pipi de chat. et d'ailleurs l'USB a ete back porté sur le 2.2
Je parle plutot des fonctionnailté SMP, des locks , du raw data, ... tout un tas de trucs indispensables pour faire un serveur sgbd digne de ce nom par exemple.
Les entreprises sous unix n'ont vraient commencé a s'interresser a linux qu'avec le 2.4. Le 2.2 ne tient absolument pas la comparaison avec Sparc , HPUX, AIX, ... Le 2.2 est ok pour un poste client, un firewall, un petit serveur web ou de fichier. Ca fait beaucoup de machines. Mais pour les choses vraiment serieuses c'est pas ca.
[^] # Re: Juste pour dire...
Posté par gege . Évalué à 1.
Le problème avec la branche 'stable' du noyau linux, c'est qu'elle ne représente pas la branche des noyaux stables, mais seulement la branche des noyaux dont les évolutions sont figées afin de lui apporter de la stabilité. Elle ammène à un noyau stable, mais n'est pas composée de noyaux stables.
En conclusion, comme tu le dis, linux est pour l'instant parfaitement adapté pour un firewall, un serveur web, de fichiers, mail, etc. Il sera adapté pour des serveurs plus conséquents, mais il ne l'est pas actuellement. Et l'utiliser comme tel est dangeureux pour le service en lui-même, et pour l'image de linux aussi qui se trouve ainsi dévalorisé par son inadaptation actuelle pour les utilisations sur des gros serveurs.
PS: pour le post précédent: reiserfs fonctionne très bien sur noyau 2.2 (j'étais passé sur reiserfs bien avant d'upgrader mon poste de travail en 2.4.x)
[^] # Re: Juste pour dire...
Posté par kesako . Évalué à 1.
A ton avis qui c'est qui a besoin du raw data sinon les grosses bases de donnees sur des machines multipro tres chargees ? Tu peux simuler ca sur ta becane a toi ? Il s'agit de machines 16 proc et de teraoctets de donnees.
C'est bien pour ca qu'Oracle 9i ne marche que sur 2.4
Evidement qu'on ne met pas ces machines en production mais faut bien tester en "semi-production" . Sinon on ne reglera jamais les bugs ! Et le fait que certain s'y mettent c'est la preuve que ca interresse *beaucoup* les grosses entreprise. Car ca coute cher. Elles savent bien que ca ne marchera pas aussi bien que solaris mais elles croient en l'avenir Linux. Les problemes rencontres ne devalorisent aucunement linux au contraire.
Tu as completement sauté mon commentaire :
'Eternel probleme de "ceux qui se mouillent les premiers" ...'
(dernier message. j'arrete la)
[^] # Re: Juste pour dire...
Posté par kalahann . Évalué à 1.
Je me cite:
Je sais y'avait de très bonnes raisons pour ça [les développements sauvages sur les noyaus stables]
mais de toute façon c'est un troll sans fin.
Justement, je voulais préciser que *maintenant* qu'on a un noyau de développement, sur lequel les développeurs vont pouvoir bosser et qu'on va pouvoir tester, il n'y aura (presque?) plus de problèmes de ce genre, le noyau stable va enfin pouvoir *commencer* à devenir mature.
D'ailleurs je pense suivre dorénavant le noyau instable au lieu du noyau stable pour pouvoir tester les nouvelles évolutions. Je sais que c'est dangereux, mais bon si on sauvegarde suffisamment ses données...
[^] # Re: Juste pour dire...
Posté par - - . Évalué à 1.
comprenez qu en AUCUN CAS ils representent un produit fini et parfait
ils sont juste une estimation d'un noyau a peu prés correct qui peut etre testé par des NON developpeurs
mais en realité, jamais il n'a été pensé qu'ils etaient parfait
comprenez bien que vous sautez une ETAPE par un rapport aux logiciels proprietaires types, vous avez accés aux developpements reguliers du NOYAU
et il vous est demandé en tant que communauté de les tester et dire trés vite s'il y a des bugs pour vite ameliorer le noyau linux
en fait 2.4.15 ou 2.4.88 ca ne sera _jamais_ un produit fini completement.
c'est la nature meme du developpement de linux depuis des siecles
"stables" c est qu ils sont censé aller vers une stabilisation des fonctionnalités et ne plus en rajouter.
(par exemple un noyau 2.4 ne vas pas se mettre a rajouter les ACL subitements )
ce n'est pas nouveau, il en est ainsi depuis les 2.0.x ce genre de troll (quand linux a commencé a devenir populaire et que plus en plus de gens pris de la manie du updateur fou ont cru que "stable" voulait dire : pret a etre vendu et garantie sur place)
vous dites qu ils doivent les tester ? mais comment et avec quel moyen ???
confondez pas suse ou redhat ou ibm qui EUX ont les ressources de tester ce qu ils vendent avec les _developpeurs_ comme linus ou cox qui vous donnent un accés a leurs developpements en quasi temps reel
les tests, c'est a VOUS (moi ,nous, ceux qui utilisont linux regulierement) de les faire
OU
on attends qu un distributeur fasse le job et on le paye pour ca. (achat d une redhat 7.2 parce qu'il y a une valeur ajoutée, redhat fait des tests et justement n ont pas le temps d implanter le tout dernier kernel de la mort dans leur distrib ,comme tout distrib un peu serieuse)
ne confondez pas les roles, sinon vous allez longtemps continuer le troll
tien,s je le prevois deja pour le 2.6.23 qui aura un bug sur la gestion de l ajout a chaud d un disque dur (ca fera boum! "mais que font ces developpeurs? rhalalalal")
hmmf... toujours la meme routine
[^] # Re: Juste pour dire...
Posté par matiasf . Évalué à 1.
Score -1 : Je n'ai pas pu me retenir tellement j'en ai marre de ces critiques faciles sur le noyau.
[^] # Re: Juste pour dire...
Posté par kalahann . Évalué à 1.
Ce que je trouve dommage, c'est que le 2.5 n'ai pas pu être lancé plus tôt. C'est à ça qu'il sert: pouvoir tout casser, mettre du code tout neuf, puis tester avant intégration dans le noyau stable. Comme ça on n'a pas de mauvaise surprise. De toute façon il faut être STUPIDE pour installer les derniers noyaux en croyant que tout va forcément bien se passer.
Mais globalement c'est satisfaisant, car ça nous a permis entre autres d'avoir au hasard ext3 et une VM sensiblement meilleure dans le noyau stable sans attendre le 2.6
[^] # Re: Juste pour dire...
Posté par kesako . Évalué à 1.
C'est pas au sens perf que ca compte c'est au sens "possibilite de maintenance future" .
L'ancienne VM devenait de plus en plus infernale a maintenir d'ecquere, C'etait une source potentielle de bug sournois a n'en plus finir.
La nouvelle aura des bugs c'est sur, mais elle est bien plus "propre" et on peut donc raisonablement arriver a court terme a un etat de "bug free".
[^] # Re: Juste pour dire...
Posté par Anonyme . Évalué à 1.
C'est pas tout à fait comme ça que ça se passe...
Les développements de linux, comment ça marche ? (bilan de mon observation... ; à quelques exceptions près, c'est comme ça que ça se passe)
Les développeurs travaillent sur la branche instable du noyau (x.y.z avec y impair), en partant d'une version qu'ils estiment suffisament stable de la branche stable.
Sur cette version, ils ajoutent des fonctionnalités, innovent, font des changements en profondeur (on a par exemple vu apparaitre la modularité du noyau dans le 1.3, ipchains dans le 2.1 et iptables dans le 2.3), débugguent, etc.
Si d'aventure ils découvrent un bon vieux bug tout pourri des familles qui traine dans la branche stable, ils back-portent le patch.
Une fois que les fonctionnalités sont suffisamment avancées et stabilisées, la dernière version de la branche instable devient la première de la branche stable suivante (à un patch près).
On fige les fonctionnalités, on lâche les utilisateurs dessus, qui vont apporter tous les bug-reports voire bug-fixes nécessaires.
Par ailleurs, gel des fonctionnalités ne veut pas dire gel du support matériel, on ne refuse pas l'ajout de drivers pour certains matériels (anciens pas encore supporté ou tout nouveau tout beau)
... et ainsi de suite ...
C'est pour ça que les patches 2.5.1pre1 et 2.4.16 ne comprennent pas les mêmes choses...
PS: Je te vois venir, tu vas me parler de la VM de la 2.4.
La VM de la 2.4 a souffert de sa complexité : la maintenance du code et les problèmes qui étaient rencontrés avec ont fait qu'il valait mieux en changer (et pourtant, tout le monde s'accorde pour dire qu'il y avait de bonnes idées)
# Changelog
Posté par David Derisbourg . Évalué à 1.
... no comment...
# A propos de noyaux qui sortent trop vite
Posté par Frédéric RISS . Évalué à 1.
Voila, pour ceux que ca intéresse, je trouve que ses arguments sont tout ce qu'il y a de plus valable.
[^] # Re: A propos de noyaux qui sortent trop vite
Posté par mcjyc (site web personnel) . Évalué à 1.
Je suis d'accord avec ce que dit Torvalds ici.
En effet, le noyau 2.4 n'avait plus besoin d'attendre avant de sortir.
le noyau etait stable depuis deja longtemps, et c'etait correcte de le sortir.
Le sujet d'un des trolls de la derniere fois, c'etait :
dans une branche "dite" stable, la sortie des nouvelles version ne doit elle pas
etre plus lente, que sur une version de developpement ?
laissons l'innovation au 2.5
et continuons à avancer dans la stabilité du 2.4
"qui va piano, va sano"
[^] # Re: A propos de noyaux qui sortent trop vite
Posté par bmc . Évalué à 1.
La fréquence de sortie des versions peut être élevée sans que les changements soient importants. Ainsi, il est probable qu'il y ait plus de différences entre deux versions de développement du noyau qu'entre deux versions stables.
[^] # Re: A propos de noyaux qui sortent trop vite
Posté par Frédéric RISS . Évalué à 1.
Parce que faut pas charrier, maintenant, il est bien le noyau, et avec un autre système de dev ça aurait pu prendre bien plus de temps.
D'un autre côté, les gens qui qualifient les premiers noyaux de la branche 2.4 « de noyaux de tests tous buggués et absolument pas utilisables » (bon, ok j'exagère un poil ;) ) eh bien c'est qu'il n'ont jamais utilisé de noyaux de branche instable.
[^] # Re: A propos de noyaux qui sortent trop vite
Posté par Jaimé Ragnagna (site web personnel) . Évalué à 1.
Sans troll aucun, peut etre que si ils s'interessent au noyau stable, c'est justement parce qu'il n'ont pas envie d'utiliser un noyau instable non ?
Bon, maintenant, je suis d'accord, on peut trouver son bonheur avec certaines versions du noyau 2.4.x
Bref, c'est juste mon avis qui n'engage que moi hein !
[^] # Re: A propos de noyaux qui sortent trop vite
Posté par Frédéric RISS . Évalué à 1.
Exactement ! C'est bien pour ça que je dis simplement qu'il faut avertir les utilisateurs que l'ouverture de la nouvelle branche stable ne veut pas dire que le noyau peut être mis en production, ni même qu'il va être stable à 100% sur une machine utilisateur. Cela veut juste dire qu'on entre dans une phase de tests plus complète à laquelle peut participer n'importe qui. Et si les utilisateurs ne veulent vraiment aucun problème, qu'ils attendent l'ouverture de la branche de dev suivante, à ce moment là le noyau de la branche stable sera vraiment stable.
[^] # Re: A propos de noyaux qui sortent trop vite
Posté par PLuG . Évalué à 1.
La bonne démarche, de notre part (les adeptes de linux qui savent compiler et patcher) serait d'utiliser les noyaux "dits stables" dès qu'ils sortent sur toutes les machines pas critiques.
Voir de tester les noyaux un minimum sur les hardware de prod (sur le spare par exemple).
par exemple, si j'ai un serveur web en 2.2.19, il faut tester le 2.4.0 des qu'il sort sur le meme hardware pour signaler les problèmes de drivers et autres complications. Sinon quand le 2.4.16 devient interessant, je ne pourrai pas changer de noyau si personne n'utilise la meme config bizarre.Le serveur Web n'est pas forcement un bon exemple non plus, testez systématiquement sur les portables, y a encore pas mal de surprises, notement avec le suspend/resume ...
les problemes de scheduleur/vm/inodes, tout le monde y est confronté quel que soit sa configuration, il y a donc un maximum de chances que cela soit détecté. Par contre les configurations exotiques (3 cartes son, 4 controleurs ieee1394, 6 controleurs ide ... le tout en eisa et token ring) on peut etre sur qu'il y a des problemes de driver/detection
[^] # Re: A propos de noyaux qui sortent trop vite
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
Mais il est courrant d'avoir une machine de test/bidouille avec aucune donnée importante dessus (un vieux pentium par exemple).
Alors meme si on ne test pas les pilotes dernier cris...
Au moins on test la compilation et le bon fonctionnement sur du vieux matériel !
C'est déjà un grand pas !
[^] # Re: A propos de noyaux qui sortent trop vite
Posté par Tony Gencyl . Évalué à 1.
le noyau etait stable depuis deja longtemps
bof ... loin de moi l'idee de vouloir troller, mais la stablite du 2.4 a ete grandement mise a l'epreuve (voir les differents deboires des version bugees). J'ai constement mis a jour mon noyau jusqu'au 2.4.13, et j'ai regulierement rencontre des pb (lies principalement a ReiserFS, l'allocation memoire et autres). L'integration de la nouvelle VM, meme si elle est +performante a ete rapide, peut-etre trop rapide (pour preuve les bugs corriges par la suite).
Je n'ai aucune config exotique, n'ayant que du vieux matos, et depuis qq temps je suis victime de trop nombreux "kernel oops", tres svt lies aux applications X ... ce qui donne un reset immediat, ca m'arrive 4-5 fois par semaines, et pour une branche dite stable, c'est carrement decevant.
Je ne critique pas le boulot des kernel-coders, srtt pas, mais j'ai juste l'impression que de nombreux changements recents n'auraient pas du etre integre ds une version stable.
[^] # Re: A propos de noyaux qui sortent trop vite
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
Ainsi, meme si tout le monde tape sur la VM du 2.4, moi je dis : elle est bien mieux que celle du 2.2.
Encore ce matin, j'ai balancé un processus très gourmand en mémoire (plus que la swap et la RAM physique) sur mon 2.4 et il a tué le processus et j'ai pu réutiliser ma linuxbox aussitot...
Alors qu'avec le 2.2, j'ai été obligé d'attendre 20 min avec la meme manip et la meme machine...
# 8139too oops ?
Posté par bmc . Évalué à 1.
Merci.
[^] # Re: 8139too oops ?
Posté par degeu raoul ⭐ (Mastodon) . Évalué à 1.
# [url] Linus Torvalds: Comments on Kernel Releases
Posté par David Derisbourg . Évalué à 1.
Nov 26, 2001, 10 :03 UTC
http://linuxtoday.com/news_story.php3?(...)
ltsn=2001-11-26-004-20-OP-KN
# Linus doit faire de l'hyper-stable ?
Posté par matiasf . Évalué à 1.
Le noyau 2.4 est la branche stable, çà ne veut pas dire qu'il n'évolue pas avec les risques que celà impliquent. La seule chose que garanti un noyau 2.4 durant ces versions est que l'API ne change pas pour les programmes en user-mode (quoique parfois...). Compte-tenu de cette contrainte, les développeurs font le maximum pour avoir le meilleur noyau possible (même si c'est une branche stable).
On reproche parfois le changement de VM dans le 2.4. mais celà c'est aussi produit avec le 2.2.
Le travail de fiabilisation, de garantir que tout fonctionne sans accros est du ressort des distributeurs (Mandrake, Debian, etc...). Distributeurs qui ajoutent des patchs souvent refusés par Linus. Car le rôle de linus est de fournir une infrastructure pour obtenir un noyau hyper stable et pas de fournir au premier jet un noyau hyper stable, optimiser MMX, avec tous les derniers drivers etc...
Les gens veulent le beurre et l'argent du beurre :
- Les dernières techno/perfo
- Une super fiabilité.
=> faut par rêver. Bien qu'avec Linux çà arrive parjois ;-) ...
[^] # Re: Linus doit faire de l'hyper-stable ?
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Le 2.4.14 par exemple, une fois viré les 2 lignes en trop dans loop.c (oubliées aprés un changement de nom d'une fonction) fonctionnait très bien.
Si on veut un noyau prémaché et testé corrigé de partout, on ne compile pas son noyau soi même, on installe une distrib depuis un CD et on n'y touche plus que pour installer les correctifs officiels.
Si on compile son noyau soi même, on doit être prêt à faire ce genre de modifs, à lire LKML pour y pécher les dernières infos et a "adapter un peu".
C'est comme quand on compile une appli soi-même : "./configure; make; make install", ça ne passe pas toujours du premier coup.
PS : Je suis déçu, aprés "EXTRAVERSION = -greased-weasel" dans Makefile, j'ai été déçu de ne pas trouver ""EXTRAVERSION = -brown-bag" dans le 2.4.16 :-)
[^] # Re: Linus doit faire de l'hyper-stable ?
Posté par wismerhill . Évalué à 1.
Alors c'est tout ou rien, soit on se contente de ce que nous fournis notre distrib soit on est un vrai développeur capable de corriger lui-même les erreurs du noyau.
Pas de juste milieu du genre "je vais recompiler mon noyau pour n'avoir que ce dont j'ai besoin et avoir la fonctionnalité X qui n'était pas dans les noyaux pré-compilés de ma distrib".
J'ai souvent recompilé mon noyau pour qu'il soit le plus adapté possible à mes besoin mais c'est tout juste si je sais appliquer un patch et ne me parle pas de reporter des bugs du noyau je ne sais même pas comment les mettre en évidence, quand à la LKML j'ai pas le temps de lire les centaines de messages par jours qui y sont postés.
Tiens je parie que tu va me répondre une connerie du genre "connait pas touche pas" mais après tu te plaindra que les gens sont pas capables de penser par eux-mêmes.
</coup de gueule>
Aaaaah, ça fait du bien...
[^] # Re: Linus doit faire de l'hyper-stable ?
Posté par Yohann (site web personnel) . Évalué à 1.
Apres si tu comprend rien, tu attends sagement que Monsieur Chaporouge te file ses sources qu'il aura tester, et que tu pourras utiliser.
Ne pas confondre 'avoir le dernier truc de suite' et 'avoir le premier truc qui marche'...
[^] # Re: Linus doit faire de l'hyper-stable ?
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Compiler un noyau est facile mais pas "foolproof" !
C'est d'autant plus vrai que tous les bugs récents ont été détectés aussitôt et tout les sites de news (dont LinuxFr) en ont parlé aussitôt en indiquant les modifs à faire. C'est quand même pas sorcier !
[^] # Kernel 2.0
Posté par VACHOR (site web personnel) . Évalué à 1.
Un peu dans le même esprit cependant, mes machines de production sont restées en noyau 2.2.19, après une brève incursion en 2.4.x.
C'est quand même bien mieux quand y'a aucun problème, et c'est bien pour cela que Linux est apprécié a priori.
En conclusion c'est très bien d'avancer en développement, mais les releases annoncées comme stables ne le sont plus forcément, c'est dommage. Si on veut une machine à la pointe du dev mais pas stable, chacun son tuc...
[^] # Re: Kernel 2.0
Posté par matiasf . Évalué à 1.
Il est pas stable car il y a le 2.0.39.
Chez moi je suis sous 2.2.19 qui roulaize mortel. Et je n'ai pas de grosses motivations pour passer en 2.2.20 ou faire le grand saut en 2.4.
[^] # Re: Kernel 2.0
Posté par LeAg . Évalué à 1.
>Il est pas stable car il y a le 2.0.39.
Dans mes souvenirs, il a ete remplace assez rapidement par le 2.0.38 qui lui est tres stable.
Longtemps apres, AC a fait les derniers updates de drivers pour le 2.0.39.
Donc utilise le 2.0.39 si tu as le choix !!
[^] # Re: Kernel 2.0
Posté par bmc . Évalué à 1.
C'est pourquoi il est communément conseillé d'attendre quelques jours/semaines pour utiliser un noyau (sauf si on veut tester bien sûr). Si le 2.4.16 sort, tu peux estimer par exemple que le 2.4.13 a été pas mal utilisé, et donc qu'il n'a pas de bugs "évident".
D'ailleurs je peux t'assurer que le 2.4.13, du moins chez moi, ne pose aucun problème :)
[^] # Re: Kernel 2.0
Posté par daniel . Évalué à 1.
A mon avis quand un noyau sort, le mieu est de vérifier dans le changelog si les changements avec la version précédente te concernent, et sinon tu installe la version précédente.
# petit historique Linux
Posté par matiasf . Évalué à 1.
Le 07/03/1995 : Version 1.2.0 taille du tar.gz : 2 301 256
Le 09/06/1996 : Version 2.0.0 taille du tar.gz : 5 843 677
Le 26/01/1999 : Version 2.2.0 taille du tar.gz : 13 080 195
Le 04/01/2001 : Version 2.4.0 taille du tar.gz : 24 378 762
Avec une telle inflation, il est plus dure d'avoir un noyau sans le moindre bug.
[^] # Re: petit historique Linux
Posté par wismerhill . Évalué à 1.
Si ça continue ainsi on peut estimer que le 2.6 fera de l'ordre de 45MO, et combien pour le suivant?
La perspective fait peur.
[^] # Re: petit historique Linux
Posté par Neryel . Évalué à 1.
Bon, le kernel en lui meme aussi, mais ce que je veux dire, c'est qu'il faudrait peut etre plutot voir la taille du noyau une fois qu'il est compilé et que t'as que ce qui te concerne :)
[^] # Re: petit historique Linux
Posté par matiasf . Évalué à 1.
Les souvenir du zImage sont :
1.2 : 180 k (de tête)
2.0 : 320 k (de tête)
2.2 : 430 k (réel)
2.4 : 480 k (réel)
Il faut noté que le 1.2 n'a pas de support de module. Et les valeurs que je donne ne sont pas à configuration équivalente !
-1 : car c'est pas très interessant...
[^] # Re: petit historique Linux
Posté par Axel R. (site web personnel) . Évalué à 1.
disquette bootableDVD-rom bootable...Axel - 584
[^] # Re: petit historique Linux
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
Mais ce qu'on va peut-être voir arriver c'est une distribution du noyau dans une forme différente... en effet, pourquoi télécharger tous les modules gérant les drivers pour le réseau 1Gbits alors que la machine est sur un réseau 10M ou même pas sur le réseau du tout...
Donc, il y aurait une archive pour le corps du noyau (VM...) et plusieurs archives par types de périphériques... (sous forme de patch).
Ca serait peut-être une bonne idée non ?
# 2.4 ça marche plus pas si mal...
Posté par Gonéri Le Bouder (Mastodon) . Évalué à 1.
[^] # Re: 2.4 ça marche plus pas si mal...
Posté par matiasf . Évalué à 1.
Il faut que tu publies les sources en mettant un README.txt pour expliquer ce mistère.
hop : -1 (je suis bête et méchant).
# Scoring des messages
Posté par Marc Quinton . Évalué à 1.
concernant les pro-microsoft, les pro-mandrake, les pro-debian, les anti-trucs ... je crois que ca reste affaire de conviction, et les notation ne devraient pas tenir compte de certains de ces aspects.
bonne journée.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.