Je dirais plutôt que c'est à cause de toutes les "basheries" dont beaucoup trop de scripts sont truffés pour qu'on puisse traduire "juste comme ça".

Unux: parce que bash est indispensable pour faire marcher une distro linux. Mes dents ne se sont pas encore remises du jour où je me les suis cassées en tentant de faire une LFS avec zsh.

Debian est pas en train de passer à /bin/sh -> /bin/dash ?

De toute façon selon moi /bin/sh devrait être un shell basique, pas un shell interactif. /bin/sh -> /bin/bash est une aberration digne de Lennart.

Dargor: pour les bootscripts, c'est déjà dash depuis longtemps (lenny). Mais dash à mes yeux c'est juste bash sans la surcouche interactive lourde.

PS: j'insiste sur *à mes yeux*. On m'a dit que ce serait plus respectueux de sh que bash.

zsh est plus léger que bash mais ça reste un sacré bousin tout de même.
Sinon (désolé si je radote) la vélocité de Gentoo par rapport aux autres distributions n’est que pure illusion. Le fait de compiler ses paquets avec trois pauvres options génériques de gcc induit souvent une sorte d’effet placebo chez le ricer Gentoo que j’ai du mal à expliquer. Les mainteneurs de paquets de distribs binaires gèrent ça beaucoup plus finement (du fait de leurs compétences et de la faible quantité de paquets dont ils ont la responsabilité) que le plus grand malade de l’optimisation sous Gentoo.
Après Gentoo à l’intérêt de permettre de ramener moins de dépendances en jouant des USE mais là encore une bonne gestion de paquets binaires (OpenBSD typiquemetn :p ) fait quasiment aussi bien.

Heu… Honnêtement, si zsh c'est pas plus lourd que bash, il y a un problème.

De la même manière que vim a qui j'en demande beaucoup interactivement parlant, je ne peux pas exiger que zsh soit léger.

« Le fait de compiler ses paquets avec trois pauvres options génériques de gcc induit souvent une sorte d’effet placebo chez le ricer Gentoo que j’ai du mal à expliquer. »
j'ai l'avis inverse. Je pense qu'on peut gagner de façon significative sur une poignée d'applis (de façon aléatoire suivant d'où on vient et ce qu'on veut). Après, un gain local suffit à se convaincre (à tort, bien sûr) d'un gain global.

Chez OpenBSD on une quenelle farcie au Valgrind, voui ma bonne dame. http://marc.info/?l=openbsd-tech&m=130459895903668&w=2

Chris_27> Disons que t’as la possibilité avec zsh de ne pas charger trop de modules. Bash arrive avec beaucoup de choses par défaut. Je pense qu’un zsh avec une conf. par défaut est plus léger qu’un bash avec une conf. par défaut. Quand tu commences à charger un certain nombres de modules fantaisistes (du genre le client ftp intégré), là zsh devient effectivement plus lourd.
Perso, je m’en tire aussi bien avec pdksh que je ne m’en tirais avec zsh qui pour le coup est notablement plus léger.

En ce qui concerne Gentoo, tu as soulevé le point important « Après, un gain local suffit à se convaincre (à tort, bien sûr) d'un gain global. ». Sur une machine moderne violemment multicores (il faut bien ça pour survivre aux màj) et sur une utilisation bureautique standard, ce genre de gain local est tellement minime que c’est de la mauvaise fois d’affirmer un gain en vélocité. Perso, je ne suis même pas convaincu d’un gain sur une poignée d’appli, mais tu es plus calé que moi sur le sujet donc tu as sans doute raison. :p

Dargor> C’est vraiment du beau boulot. Le malloc d’OpenBSD est clairement l’un des aspects dont ils peuvent être le plus fier.

"Le malloc d’OpenBSD est clairement l’un des aspects dont ils peuvent être le plus fier. "

Avec la gestion du multiprocesseur

La pile réseau (ce qui inclut pf) est un élément que j'aurais mis avant le malloc, mais oui c'est clairement impressionnant.

"Sur une machine moderne violemment multicores (il faut bien ça pour survivre aux màj) et sur une utilisation bureautique standard, ce genre de gain local est tellement minime que c’est de la mauvaise fois d’affirmer un gain en vélocité"

Et encore, à l'heure actuelle tu es plus souvent limité par GCC que par ta machine.
En supposant qu'il y ait un réel gain de vitesse, il faut vouloir se taper plus de 5 heures de compilation par semaine (même si j'ai roulé en Gentoo pendant plusieurs années je ne sais pas si j'aurais encore le courage de l'utiliser). Avec FreeBSD j'ai en moyenne 1 heure par semaine, ça va encore...

C'est quoi le truc de génie d'OpenBSD, expliqué à quelqu'un de pas vraiment connaisseur mais pas complètement débutant non plus ?

Tu sais ce que c'est qu'un malloc ?

La fonction en C permettant d'allouer un bout de mémoire ?

dash et bash sont tres tres different. j'ai du faire un effort non negligeable pour rendre dash compatible certain de mes script que je pensais etre sh compliant mais en fait non.

XKCD: bien. Je laisse les openbsdistes t'expliquer les détails à partir de là.

godrik: ok, ça devait être toi le "On".

Chris : Ah zut j'y croyais

Pour faire simple le kernel a deux moyens de fournir de la mémoire aux applications : sbrk(2) et mmap(2). malloc est une fonction en espace utilisateur qui peut utiliser l’une ou l’autre ou même les deux de ces appels systèmes pour fournir de « façon intelligente » de la mémoire aux applications demandeuses. Le « de façon intelligente » est défini par la qualité de l’implémentation du dit malloc et celle d’OpenBSD est particulièrement bonne.
Sans rentrer dans les détails, les principales qualités du malloc(3) d’OpenBSD sont à mon sens :
1— L’excellent qualité du code. Compare le malloc.c d’OpenBSD avec ceux d’autres OS, c’est le jour et la nuit en termes de lisibilité ;
2— L’excellente qualité de la « randomisation » des pages mémoires utilisées. Cela passe par un allocateur basé exclusivement sur mmap(2) et des techniques élaborées sur la gestion des pages mémoires. Un très gros point positif en termes de sécurité ;
3— Des features très sympa comme ce valgrind intégré fraîchement commité.

la vrai question est, est ce que malloc est thread safe et scalable ? De nos jours le nerfs de la guerre est la. Et de ce que j'ai vu des BSD ils ont un support des architectures multicoeur qui a 5 ans de retard sur les autres OS...

Le nerf de la guerre d'OpenBSD c'est de marcher, et ça il le fait très bien.

Si tu veux des race conditions, tu utilises un autre OS.