Est-ce que tu penses qu'on fait fonctionner Gnome sans pilote IDE (ni SCSI, chipottez pas !) ? :-) GNU/Hurd, lorsqu'il utilise GNU Mach, supporte très bien IDE et SCSI, et toute une variété d'HBA (bon, aucun U160 ou U320, mais je suis en train de backporter un driver).
Et oui, un pilote IDE, ça tombe. En fait, ça m'est arrivé y a encore quelques semaines, et c'est arrivé à une assoce de mon entourage aussi. Lorsqu'une machine dispose de pas mal de disques, et que le disque qui s'occupe d'une partition de données pas vitale au système (celle qui contient le pr0^W^Wles vieux logs) crashe, tu aimerais fortement qu'il n'y ait pas d'interruption totale de service. Or il est extrêmement rare que ton noyau résiste à ça : soit tu te prends des Oops et une machine qui lagge tellement qu'elle est inutilisable (cas le plus rare dans mon expérience), soit la machine panic()e vite. C'est quelque chose de très désagréable sous GNU/Linux (vécu sous NetBSD aussi).
Et pour les autres types de pilotes, c'est encore plus courant. Disons, au hasard : les pilotes complètement instables non officiels ou fournis par votre constructeur mais pas intégrés à Linux. Je me souviens par exemple d'un portable où le noyau panic() ait dès qu'on utilisait en même temps le modem et le son. J'aurais apprécié perdre soit la connexion, soit le son, mais pas devoir attendre le reboot à -chaque- fois. Je pense pas que ce soit un avantage si négligeable, donc, en particulier en production.
[^] # Re: La montre qui fait tout mais ne donne pas l'heure
Posté par Manuel Menal . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 10.
Et oui, un pilote IDE, ça tombe. En fait, ça m'est arrivé y a encore quelques semaines, et c'est arrivé à une assoce de mon entourage aussi. Lorsqu'une machine dispose de pas mal de disques, et que le disque qui s'occupe d'une partition de données pas vitale au système (celle qui contient le pr0^W^Wles vieux logs) crashe, tu aimerais fortement qu'il n'y ait pas d'interruption totale de service. Or il est extrêmement rare que ton noyau résiste à ça : soit tu te prends des Oops et une machine qui lagge tellement qu'elle est inutilisable (cas le plus rare dans mon expérience), soit la machine panic()e vite. C'est quelque chose de très désagréable sous GNU/Linux (vécu sous NetBSD aussi).
Et pour les autres types de pilotes, c'est encore plus courant. Disons, au hasard : les pilotes complètement instables non officiels ou fournis par votre constructeur mais pas intégrés à Linux. Je me souviens par exemple d'un portable où le noyau panic() ait dès qu'on utilisait en même temps le modem et le son. J'aurais apprécié perdre soit la connexion, soit le son, mais pas devoir attendre le reboot à -chaque- fois. Je pense pas que ce soit un avantage si négligeable, donc, en particulier en production.