riri le breton a écrit 84 commentaires

C'est marrant, parce que décrit comme ça, on pourrait plus apparenter L4 à un exokernel qu'à un uKernel :-)

En effet, d'après ce que tu dis (le paragraphe consacré à L4), tout se passe en espace utilisateur, il n'implémente en son que des mécanismes (jai noté l'accentuation), des outils. En gros, il gère l'accès aux ressources, pas leur gestion. Et c'est justement la définition d'un exokernel.

Est-ce que je me trompe où c'est vraiment la réalité ?
Je m'intéresse beaucoup aux exo-kernel, et n'ai prêté que peu d'attention à L4, car pour moi, c'était un modèle de micro-kernel comme tant d'autres (je sais, c'est pas bien de faire l'impasse).

Oui !! :-)

C'est dingue ce qu'on peut s'habituer à ces p'tites choses là.

Pour ma part, vous l'avez compris, j'utilise vi(m) quotidiennement, et le seul argument contre vi ou emacs (que je n'aime bien-sûr pas, mais soyons objectifs), c'est la phase d'apprentissage, ou plutôt d'accomodation. Ttaper :w ou Ctrl+C-Ctrl+kekchose au lieu de lacher le clavier et bien pointer un menu de souris, ce n'est pas évident au début (je sais je suis passé par là).

Mais d'autres éditeurs sont intéressants : sciTe ou nedit sous X, nano en console (si si). Le tout est de trouver l'éditeur (ou les éditeurs) qui conviennent.

Il existe aussi submount [http://submount.sourceforge.net/(...)], pas très connu, mais très bien pour sa simplicité:

• pas usine à gaz pas simple d'usage (je pense à automount)
• pas de patch kernel, juste un module de plus (je pense à supermount)
• pas de dépendance à d'autres softs (je pense à magicdev)

Enfin bref, un truc simple et pratique.

Comparons ce qui est comparable:

AMD Athlon 64 3500+ Socket 939 (Box + ventilo) : 358,00 EUR
AMD Athlon 64 3700+ Socket 754 (Box + ventilo) : 519,00 EUR
AMD Athlon 64 3800+ Socket 939 (Box + ventilo) : 645,90 EUR
(source multe-pass.com)

A vitesse 'annoncée', c'est en gros le même prix (l'AMD 3500+ se trouve entre les prix des P4 3400 et 3600).

Si tu as une machine récente, la différence ne se fait pas vraiment sentir (quoi que, avec beaucoup d'utilisation cpu ça devrait quand même).

En fait, je dispose d'un PII 350MHz et d'un K6-2 500MHz, et là, on sent quand même une grosse différence.

En ce qui concerne la vélocité de la slackware, c'est plus lié au fait que justement la slack est plus légère : avec un système minimal, une redhat ou une mandrake font tourner plus de programmes qu'une slackware.

Perso j'utilise nasgaïa, qui est optimisée pour les i686, et qui ressemble (au niveau légèrement) à une slackware. Et bien ma nasgaïa est plus rapide que la slack quand je lance une gnome-session (alors que les deux distro lancent les même programmes et services au démarrage).

Je rajouterais dans ta description des optimisations (par ailleurs bien vulgarisée :-)), que les nouveaux opcodes ne sont pas les seuls en cause dans l'optimisation. Les processeurs, au fur et à mesure qu'ils évoluent, intègrent de nouvelles fonctionnalités intrasèques (comme le prefech, le branch condition, le pipeline), qui font que quelques instructions générées légèrement différemment par le compilateur tournera plus ou moins vite pour le même processeur, et cette différence n'en sera que plus flagrante entre deux versions de processeurs.

L'exemple très parlant est le double-pipeline introduit avec le Pentium, qui (théoriquement) permet de doubler la cadence des instructions. Ce n'est pas aussi rose, mais on y gagne beaucoup, et l'inversion de deux affectations peut changer la rapidité du proc (lock de registres entre les deux pipelines). Cela est du en partie à l'ordre des instructions et l'utilisation des registres par ces instructions (comme quoi c'est un domaine très précis, ce n'est pas pour rien qu'on dit que l'assembleur est difficile, et surtout pas pour la syntaxe, qui elle, est très simple)

Si on combine tout ça (ces nouveaux 'modes' de fonctionnement, plus les nouveaux opcodes, genre movcc et autres intégrations l'instructions évoluées bien pratiques), un même code peut tourner beaucoup plus vite s'il est optimisé pour un proc récent. Le problème, comme ça a déjà été souligné, c'est qu'il en devient la plupart du temps incompatible avec les procs plus anciens (du i686 sur un i486 ou i586 par exemple).

C'est vrai que le nombre de distributions se ressemblant fortement augmente à vue d'oeil. Je ne suis pas contre ce type de diversification (je fais parti des gens pensant que la loi des meilleurs qui restent fera le travail de sélection), étant moi-même participant à une distribution (Nasgaïa).

Ce qui manque vraiment, c'est la variété. Car des distros desktop, on en trouve à la pelle, les live-CD, on ne les compte plus, les distros orientées sécurité commencent aussi à faire foison; par contre, beaucoup on le même principe (basée sur Fedora, debian, etc, sans apporter de réelle valeur ajoutée).

Trouver une bonne distro serveur ou multimedia (donc spécialisée) n'est pas si simple, car énormement de ces distributions sont créées sur une base existante (debian, fedora, etc..).

Donc non, il n'y a pas trop de distributions linux à mon sens, mais oui il manque de vraies distributions pour un usage donné (pas basées sur une distro plus généraliste), et c'est ça qui est dommage.

C'est clair que côté français, ce n'est pas génial (je n'avais même pas remarqué que cela provenait d'un magazine étranger, je m'étais dit que c'était les fameuses erreurs de jeunesse).

Par contre, les sujets, la présentation des logiciels, l'aide fournie quant à l'utilisation de ces logiciels (avec le live CD qui les contient tous, et permet donc de les tester sans rien installer), sont vraiment de bonne facture.

Qui sait, avec le temps, les problèmes de traduction s'estomperont peut-être, et on aura un bon magazine.

Juste un bémol, la partie audio (pour laquelle le magazinem'a interpellé) mériterait que les installations à partir des sources de logiciels un peu funky (comme le serveur jack), soient détaillées, plutôt que de prévoir que tout le monde utilise une distro rpm'ed ou deb'ed.

oui enfin forcer à avoir la base RPM quand on n'en a pas besoin, c'est un peu gros. Et si on n'a pas le base RPM (seulement le binaire), on peut utiliser rpm dans un mode "dégradé", mais alors cela n'a plus aucun intérêt, surtout pour une meilleure standardisation (qui normalement va dans le profit des distributions).