Le problème classique lorsque l'on gère plusieurs cartes son est leur indexation non déterministe qui empêchent d'allouer proprement et de manière systématique telle application à telle sortie. Fort heureusement le problème n'est pas insoluble, loin de là.

Une machine, c'est bien connu, cela ne tombe en rade que dans la nuit ou en week-end. Dés fois, lorsque l'on a un peu de chance, c'est même les deux... Et lorsque le plantage se situe sur une Dédibox, on est un peu dans la mouise, avec Free qui considére que l'administration est une chose qui doit se passer dans des horaires de bureau... Du coup, lorsque la demande porte sur une KVM, nous n'avons plus qu'à attendre tout le week-end avec tous nos sites en carafe...

Fort heureusement il y a l'ami GNU/Linux. Avec celui-là, même si elle n'est pas forcément évidente, il y a toujours une solution de repli. Ici, il s'agit d'exploiter le système de secours de la Dedibox.

La grosse angoisse avec une dédibox vient lorsque, par exemple après une massive attaque de spam, la machine part en toupie et s'écrase sans crier gare... Comme quoi, même Linux arrive à planter n'en déplaise à certains ;-). Bref, dans ce cas, comme dans celui d'une upgrade de noyau, il est nécessaire de redémarrer le zinzin, et là c'est grosse sueur jusqu'à ce que le ping se remette à causer et que les services soient à nouveau en ligne.

Mais voilà, il arrive que le ping ne vienne jamais, que les minutes passent et que rien ne se passe....

Quelle que soit la manière dont on utilise Apache, vient un moment où il est nécessaire de régler un peu les performances en fonction de l'usage. Alors l'objectif de ce papier n'est pas de fournir un guide exhaustif de tout ce qu'il est possible d'optimiser dans ce sacré morceau de code, mais plutôt de permettre d'éviter quelques problèmes de base.

Depuis quelques années, un classique enquiquinement avec les interfaces réseau consiste à comprendre pourquoi telle interface s'appelle eth1 plutôt qu'eth0. Problème récurrent avec VmWare, ou lorsque l'on déplace l'installation d'une configuration physique à une autre. Et il n'est pas rare de se retrouver avec un eth6 ou mieux, eth0_renamed, sans arriver à remettre les compteurs à zéros.

La dernière fois que j'ai testé une distribution 64bits, c'était il y a plus de deux ans, avec une Suse, et pour un résultat plutôt décevant. Le problème n'était pas en soit lié à l'architecture, ni à Suse d'ailleurs, mais plutôt à la maturité des distributions de l'époque.

Ce n'est donc que bien plus tard que j'ai eu envie de voir où en était Mandriva 2009.0 sur ce plan. Alors je ne vais pas expliquer l'installation avec force détails car il n'y a rien à en dire. Absolument tout a fonctionné du premier coup, elle tourne comme un charme et je n'utilise plus qu'elle sans qu'aucune de mes habitudes n'en soit changée. Le but de ce billet serait plutôt une modeste tentative pour dézinguer un certain nombre d'idées plus ou moins trollesques sur les distributions x86_64 que j'ai pu voir circuler.

La mise en oeuvre d'un kernel monolithique peut, à juste titre, rebuter par sa complexité. Et même si cette technique reste le meilleur moyen d'optimiser un kernel, il est malgré tout possible d'opter pour une approche plus douce en s'attaquant directement à initrd.

Les distributions récentes commencent de plus en plus à ressembler à leurs équivalent propriétaires. Histoire de satisfaire le plus grand nombre, des tonnes d'options sont activées pour rien Le problème des distributions généralistes reste qu'elles doivent de démarrer en toute situation. La conséquence en est que beaucoup de modules sont chargés pour rien, et même certaines fois à tord. Ces modules allongent le temps de démarrage mais diminue aussi les ressources disponibles en restant chargés tout au long de la session. Une manière de régler une partie du problème peut consister en la création d'une kernel monolithique mais si cette approche vous semble trop violent ou si vous désirez rester à jour côté kernel sans repasser systématiquement par une compilation, il est aussi possible d'optimiser la manière dont GNU/Linux démarre pour limiter la casse au maximum.

Depuis quelque temps on en parle beaucoup (sûrement moins que de la sortie d'Ubuntu ;-)) mais la nouvelle reste de taille : "la FreeBox ouvre son code". Ainsi donc l'inconcevable s'est produit, la petite boîte toujours plus chargée d'électronique est, comme certaines sectes le prédisaient, devenue vivante, douée d'une énergie propre. Et tournant le dos à ses concepteurs, la créature de Frankenstein venait de briser ses chaînes et ainsi de libérer son code.

L'arrivée des NetBook donnent clairement une nouvelle forme de légitimité à Linux. Il suffit d'avoir utilisé tour à tour une distribution quelconque et un Windows Vista sur une de ces bestioles pour se rendre à quel point le pingouin se sent à l'aise lorsqu'il est un peu à l'étroit.

Dans la même idée, ces machines redonnent sens à de "vieilles" technique visant à optimiser un kernel pour coller au plus prés des ressources. Et l'une de ces techniques est la création d'un kernel monolithique.