Le reste est exécuté en tant que processus utilisateurs, en majorité des processus pour chaque pilote de périphérique et serveur.
Si un pilote plante, il est automatiquement remplacé par une nouvelle copie, sans l'intervention de l'utilisateur (ni même qu'il le sache) et sans affecter les programmes actuellement exécutés.
Il y a peu d'autres systèmes qui peuvent résister à des erreurs fatales dans des composants de système critique de manière continue.
Le but des systèmes fiables sera achevé quand :
- aucun ordinateur n'aura de bouton RESET
et
- aucun utilisateur n'aura connu de plantage ni même ne connaîtra quelqu'un dans son entourage ayant expérimenté ce désagrément.
NdM : Cette dépêche est une traduction en français de la page MINIX sur le Google Summer of Code 2009. MINIX 3 gère l'interface POSIX et environ 500 programmes UNIX standards y ont été portés, ce qui comprend X11, gcc, perl, python, ghostview, mplayer, la collection des outils GNU et bien plus encore. Il y a également un environnement graphique utilisateur basique (EDE). Néanmoins il reste beaucoup à faire.
Les développeurs souhaitent continuer le développement pour démontrer que bâtir un système à partir de petits composants interchangeables conduit à une conception extrêmement robuste qui est bien plus simple à comprendre et maintenir que des systèmes avec des millions de lignes de code noyau.
Si de bonnes performances sont importantes, ce n'est plus un critère aussi déterminant que par le passé.
Si la plupart des utilisateurs ordinaires se voyait offrir le choix entre le système le plus rapide possible et un autre 10 à 20% plus lent mais qui ne plante jamais, les développeurs de minix pensent qu'une large proportion d'utilisateur choisirait le second.
Pour de nombreuse entreprises (ex : banques, sites de commerce en ligne), avoir un système qui fonctionne 24h/24, 7j/7 sans la moindre erreur est la première des priorités.
Les systèmes embarqués sont un autre secteur où la grande fiabilité est importante. Les gens ne s'attendent pas à ce que leur télé et leur caméra numérique leur affiche un écran bleu, sauf pour afficher les images d'un beau ciel bleu.
En résumé, les développeurs de Minix 3 tentent de bâtir un système d'exploitation modulaire, fiable (et sécurisé) à partir de composants qui peuvent être remplacés à la volée et ils recherchent de l'aide dans cette optique.
Vous pouvez consulter le document qui présente MINIX 3 et son architecture plus en détail. Plus de détails sont également disponibles dans la page de documentation en ligne.
Au passage, signalons que MINIX 3 n'est pas la même chose que les précédents MINIX.
En effet, les versions antérieures étaient des projets à but pédagogique mais depuis cela a grandement évolué vers un système léger se concentrant sur la fiabilité (et la sécurité).
En tant que projet libre, il est plutôt populaire. Pas moins de 1,3 million de visiteurs ont consulté le nouveau site internet (mis en ligne il y a 3 ans). Actuellement 12 000 personnes téléchargent l'image CD-ROM chaque mois pour l'installer.
Résumé des projets de l'an dernier
De la participation au SoC de 2008 on peut mentionner le projet qui s'est le plus distingué, le projet sur le RAID logiciel.
Le but de ce projet était d'améliorer MINIX 3 avec le support pour les pilotes de filtres qui pourraient s'insérer de manière transparente entre le système de fichiers et le pilote de périphérique bloc.
En particulier, les développeurs de MINIX ont demandé à l'étudiant d'implémenter un processus serveur faisant des sommes de contrôle de toutes les données et pouvant faire le "mirroring" des données pour permettre les copies de sauvegarde de partitions.
De cette façon, il est devenu possible de détecter et restaurer les corruptions de données dues à des permutations de bits sur le disque ou d'un pilote bogué.
L'étudiant n'a pas seulement implémenté la fonctionnalité, mais a également mesuré les performances du framework résultant. Le projet a été un fort succès et a même conduit à une publication co-écrite par l'étudiant qui a récemment été présentée à une conférence internationale.
Profil recherché pour le SoC
Les idées du projet ci-dessous s'échelonnent du plus simple au plus difficile.
Toutes requièrent que vous soyez un(e) programmeur/programmeuse C expérimenté(e).
Pour certaines d'entre elles il serait utile que vous ayez déjà lu le livre MINIX, par exemple dans un cours que vous avez suivi à l'université.
Étant donné la difficulté de ces projets, les mentors attendent des personnes prêtes à travailler à plein temps tout l'été. Cela veut dire aucun travail à côté de cela et ne pas suivre de cours pendant ce temps.
Comme il s'agit d'un projet libre, de nombreuses personnes étudieront le code plus tard.
Pour cette raison il est essentiel que vous soyez quelqu'un qui est fier de son travail et qui veut produire du code :
- propre,
- efficace,
- élégant
- et bien documenté
Faire simplement quelques hacks rapides pour que cela fonctionne la plupart du temps ne suffit pas.
Les gens doivent admirer votre code et même envier votre capacité à écrire un code si bon.
Si vous êtes un(e) programmeur(programmeuse) C expérimenté(e) qui s'y connait en système d'exploitation et capable d'écrire du code clair, bien documenté, jetez un œil aux idées ci-dessous et au formulaire d'inscription.
Liste des idées proposées
Les idées ci-dessous sont des suggestions, mais vous pouvez en proposer d'autres.
Pour vous lancer dans les projets liées au noyau vous devez avoir de l'expérience dans ce domaine.
Pour réaliser les pilotes, vous avez besoin d'une solide expérience en programmation et d'au moins un minimum de connaissances en développement noyau.
Le troisième groupe ne nécessite pas d'expérience en développement noyau.
MINIX 3 est diffusé sous licence BSD. En vous inscrivant, vous acceptez de diffuser votre code sous cette licence.
Projets noyau
- Utilisation de mémoire virtuelle.
Une implémentation de mémoire virtuelle a récemment été faite, mais elle n'est pas beaucoup utilisée pour le moment. Dans le cadre de ce projet vous pourriez développer, par dessus cette implémentation, une mémoire partagée du modèle POSIX. Ce projet n'est pas pour les débutants.
- Gestion du calcul à virgule flottante matérielle.
MINIX ne gère actuellement pas l'utilisation de cette extension matérielle. À la place une gestion logicielle est utilisée. Pour gérer le matériel, il est nécessaire de sauvegarder et restaurer les registres et un certains nombre d'autres choses. Ce projet nécessite une expérience avancée en développement noyau.
Projets de pilotes de périphérique
- Adaptateur NDIS.
Tous les systèmes d'exploitation libre ont des difficultés pour l'écriture de pilotes. Une approche possible serait d'utiliser les pilotes binaires conçus pour d'autres systèmes et de les adapter pour les rendre utilisables avec le système cible. Cela a été réalisé pour des pilotes de carte Wi-Fi pour Linux mais pas encore pour MINIX 3. Dans ce projet l'étudiant fera la même chose pour MINIX 3. Ce projet ne devrait être tenté que si vous possédez une grande expérience dans les pilotes Linux, BSD ou Windows.
- Implémenter les commandes AHCI.
MINIX 3 gère les disques IDE mais pas les disques AHCI. C'est la raison pour laquelle lorsque vous l'installez sur une nouvelle machine vous aurez souvent à paramétrer le BIOS pour utiliser l'émulation IDE au lieu de l'interface AHCI native. Une modification du pilote de disque pour utiliser les commandes AHCI de manière native serait donc intéressante. Une expérience avec les périphérique E/S et leurs pilotes est nécessaire pour ce projet.
- Porter ou écrire des pilotes de périphériques.
Tous les pilotes de périphérique sont les bienvenus. À peu prêt tout ce à quoi vous pouvez penser serait utile. Il devrait être possible de porter des pilotes d'autres systèmes, mais l'expérience montre qu'en pratique cela est extrêmement difficile car chacun des pilotes doit être lancé comme un processus utilisateur différent en dehors du noyau. Il est généralement mieux d'étudier un pilote existant pour voir comment cela fonctionne et d'en écrire ensuite un nouveau à partir de zéro. La plus haute priorité est mis sur les pilotes de carte gigabit Ethernet (par ex. Intel Pro/1000). Vous devriez avoir un minimum de compétences dans ce domaine pour vous présenter à ce projet.
- Gestion de débogueur distant.
MINIX 3 s'implante dans le monde de l'embarqué. Cela signifie qu'il devient nécessaire de pouvoir déboguer des machines sans périphérique d'affichage ni clavier. Il faut donc créer un petit module qui peut prendre les commandes à travers le port série depuis un débogueur distant, tel que gdb et de les exécuter.
Autres projets
Aucun des projets suivants ne nécessite d'expérience dans le développement noyau,
mais requiert tout de même de bonnes compétences en C.
- Écrire les systèmes de fichiers /proc et /dev.
Ce projet se divise en deux sous-projets très liés.
- Tout d'abord, MINIX 3 ne possède pas encore de système de fichier /proc qui fournit les informations sur les processus. Dans ce projet, vous devrez implémenter un nouveau serveur de système de fichiers qui peuple le répertoire /proc avec des informations par processus, permettant ainsi à 'ps' de les interroger. Une autre fonctionnalité pourrait être, par exemple, /proc/meminfo pour des statistiques sur l'utilisation mémoire et /proc/modules pour une liste des serveurs et des pilotes chargés.
- Deuxièmement, MINIX 3 alloue actuellement tous les nodes de périphérique de manière statique dans le périphérique racine (NdT : root). Une meilleure solution serait d'utiliser un système de fichiers /dev où les pilotes de périphérique peuvent enregistrer dynamiquement leurs périphériques. Une implémentation d'un nouveau serveur de système de fichiers /dev qui fournirait une interface pour les pilotes et modifierait le système pour l'utiliser serait donc à écrire.
- Tout d'abord, MINIX 3 ne possède pas encore de système de fichier /proc qui fournit les informations sur les processus. Dans ce projet, vous devrez implémenter un nouveau serveur de système de fichiers qui peuple le répertoire /proc avec des informations par processus, permettant ainsi à 'ps' de les interroger. Une autre fonctionnalité pourrait être, par exemple, /proc/meminfo pour des statistiques sur l'utilisation mémoire et /proc/modules pour une liste des serveurs et des pilotes chargés.
- Amélioration des performances.
Aucun effort n'a été fait pour mesurer les performance du système et l'améliorer jusqu'à présent. Il y a cependant quelques outils disponibles et porter et utiliser les outils Pmc de BSD devrait être possible. Ce projet consiste à mesurer les performances, trouver les goulots d'étranglement, et si possible les faire disparaitre. Vous devriez commencer par trouver et porter les outils de mesure existants sur les autres systèmes et écrire des scripts pour les utiliser et collecter les résultats automatiquement. - Porter les utilitaires BSD sur MINIX 3.
Des centaines de logiciels utilitaires ont été écrits spécifiquement par les contributeurs de MINIX. Les utilitaires GNU ont également été portés. Cependant, certaines personnes préfèrent les versions BSD de ces utilitaires, qui ne sont actuellement pas disponibles pour ce système. Le projet consiste simplement à réaliser ces ports. - Test de stress de MINIX 3.
De nombreux tests de stress, qui poussent le système dans ses retranchements et tentent de le faire s'écrouler, ont été écrits pour d'autres systèmes . Le projet consiste ici à porter certains d'entre eux sous MINIX 3 et à écrire les scripts pour automatiser leur mise en œuvre. Si vous parvenez à faire planter MINIX 3, vous devrez également tenter de découvrir ce qui a produit le plantage. - Porter des logiciels applicatifs vers MINIX 3.
Plus de 500 logiciels applicatifs ont déjà été portés, mais davantage encore seraient les bienvenus. Porter des logiciels Linux ou FreeBSD demande quelques efforts malgré la disponibilité de cc et gcc et de la conformité POSIX, les appels systèmes de Linux et FreeBSD ne sont pas gérés, et l'arborescence des fichiers d'en-tête est organisée différemment, etc. La seule chose à savoir est que les choses les plus simples ont déjà été faites. Les ports restant à faire sont plus gros et plus complexes.
Les programmes fonctionnels petits et rapides sont tout spécialement appréciés, en particulier pour les environnements (mobiles) aux ressources limitées, mais les bons logiciels de bureautiques, les frameworks et autres bibliothèques sont également utiles.
Quelques exemples :- le navigateur web Dillo
- Le serveur web Lighttpd
- Le framework logiciel Qt
- les programmes réseau comme Tcpdump, Traceroute, Netcat, nslookup, etc.
L'équipe est ouverte à toutes les suggestions pour le port d'autres programmes. Dans certains cas, les ports peuvent être suffisamment simples pour que vous puissiez en proposer plusieurs. - le navigateur web Dillo
- Améliorer la portabilité.
Tenter de faire tourner les commandes de MINIX 3 sous Linux ou FreeBSD (pour des motifs de comparaison) s'avère extrêmement difficile malgré leur écriture en C ANSI et la conformité POSIX. Les problèmes sont souvent liés à la structure et au contenu des fichiers d'en tête (par ex. ce qui est précisément défini dans types.h) et comment les Makefiles sont organisés. Ce projet consiste donc à travailler sur les fichiers d'en tête de MINIX 3 et les Makefiles des applications pour faciliter l'utilisation de gcc et pour facilement porter les programmes de MINIX 3 sous Linux et FreeBSD.
Vous pouvez aussi regarder la liste des requêtes sur le wiki de MINIX 3.
Les membres du projet sont ouverts aux suggestions de projets alternatifs.
Gardez en tête que la date limite pour postuler est le 3 avril.
Conclusion
Même si vous n'êtes pas intéressé par le SoC, essayez MINIX 3. Vous pourriez être surpris. Par exemple, il peut se compiler lui même, le noyau, tous les serveurs et les pilotes, etc. – 125 compilations – en seulement 6 secondes sur un PC moderne. Et si vous voulez aider le projet en dehors du SoC, vous êtes le(la) bienvenu(e).
Aller plus loin
- La page à l'origine de cette dépêche (10 clics)
- Liste de diffusion du projet (12 clics)
- Wiki du projet (24 clics)
- Site du Summer of Code (11 clics)
- Formulaire d'inscription (7 clics)
# Usenet
Posté par Thierry . Évalué à 10.
# Plantage
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
* aucun ordinateur n'aura de bouton RESET
et
* aucun utilisateur n'aura connu de plantage ni même ne connaîtra quelqu'un dans son entourage ayant expérimenté ce désagrément.
Qu'est-ce que c'est un "plantage" sémantiquement parlant ?
Ok, le kernel ne plante jamais, c'est super. Sauf que si c'est une application en userland qui monopolise le clavier et la souris et qui part en cacahuètes, bin on est mal, malgré la robustesse parfaite du noyal. Et là, est-ce qu'on peut dire que la machine est "plantée" ? Comment reprendre la main ? Bref, laissez-nous le bouton reset, même sur des systèmes fiables ;) (quitte à affecter la fonction "détruit tout le user land en laissant tourner le noyau" à ce bouton).
[^] # Re: Plantage
Posté par psychoslave__ (site web personnel) . Évalué à 1.
Contrairement à un noyau monolithique, le fait qu'un pilote entre dans une erreur fatale, cela n'a pas de répercussion sur les autres processus.
[^] # Re: Plantage
Posté par Nitchevo (site web personnel) . Évalué à 6.
Ok tu peux passer par un autre ordinateur via ssh mais bon....
[^] # Re: Plantage
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: Plantage
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Mouais.
[^] # Re: Plantage
Posté par psychoslave__ (site web personnel) . Évalué à 1.
Enfin entre demander au système de désactiver la prise en compte des entrées et monopoliser toutes les ressources en compromettant l'utilisabilité du système, y a une marge.
[^] # Re: Plantage
Posté par volia . Évalué à 6.
Donc, un noyau très intelligent pourrait détecter un certain nombre de ce type de dysfonctionnements, mais, par principe, pas tous.
[^] # Re: Plantage
Posté par psychoslave__ (site web personnel) . Évalué à 3.
En fait je ne sais pas si la gestion de la priorité des processus est géré dans le micro-noyau où en dehors. Ça soulève d'autres questions et possibilité intéressantes.
Enfin c'est vrai que l'image de la suppression du bouton reset est peut être exagéré, mais comme elle n'est pas de moi, je m'en dédouane. :P
[^] # Re: Plantage
Posté par Badeu . Évalué à 3.
Après je ne pense pas que le projet minix cherche à détecter la moindre erreur sur un flux de donnée d'une application quelconque, mais bien quand un programme serveur par dans le décor pour le relancer.
[^] # Re: Plantage
Posté par peck (site web personnel) . Évalué à 3.
- ssh
- magic keys
Il y a quand même des solutions !
[^] # Re: Plantage
Posté par Sarcastic . Évalué à 2.
Parce que la console sur le port série, ça devient de plus en plus rare. Pour SSH, faut d'abord qu'il soit activé. Non, SSH n'est pas activé par défaut au démarrage partout (et heureusement, d'ailleurs).
Et au final, les magic keys, soit taper 3 combinaisons absconses (Personnellement, je m'en souviens jamais quand j'en ai besoin) s'avère etre une des solutions les plus évidentes. Constat amer, j'ai envie de dire.
[^] # Re: Plantage
Posté par peck (site web personnel) . Évalué à 0.
Après on parle bien d'un bug grave (dans X ou dans la console linux parce que sinon ctrl-alt-Fx et c'est reparti) et donc tout de même rare.
[^] # Re: Plantage
Posté par santos . Évalué à 3.
[^] # Re: Plantage
Posté par peck (site web personnel) . Évalué à 2.
Plus de crl-alt -> peut-etre un bug dans X
Plus de réponse ssh -> peut-etre un bug dans le noyau
A moins que flash fasse une fork bomb, mais j'en doute.
Plus de magic key -> bug dans le noyau
[^] # Re: Plantage
Posté par Psychofox (Mastodon) . Évalué à 3.
[^] # Re: Plantage
Posté par peck (site web personnel) . Évalué à 2.
[^] # Re: Plantage
Posté par IsNotGood . Évalué à 2.
Ssh et magic key ne marchent plus. Probablement un problème noyau (qui a peut-être été cause par Xorg).
[^] # Re: Plantage
Posté par Mouns (site web personnel) . Évalué à 3.
Ctrl+Alt+Suppr
je suis déjà dehors ->[]
[^] # Re: Plantage
Posté par octane . Évalué à 10.
Le driver se plante. OK.
Minix relance le pilote sans planter. Super.
Mais bon, rien n'empeche le driver de se revautrer dans la milliseconde.
Et minix va le relancer. Etc...
Sur le principe, je me dis qu'un pilote qui se vautre, ça signifie que ça sent mauvais. Dans certains cas, on peut vouloir que le driver qui part dans les étoiles n'embarque pas avec lui le reste de ma machine (si mon scanner USB se gamelle, je ne veux pas que mon noyau décide de faire harakiri en emportant les 10 lignes de textes non sauvegardées super importantes)
Mais pour d'autres, je ne vois pas; genre le driver disque. Pouf, ça redémarre, mais ça va chercher une copie du driver sur le disque, qui lui-même, pouf, etc, etc..
Mais le principe est intéressant, quelqu'un sait il comment minix gère ce cas?
[^] # Re: Plantage
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Et minix va le relancer. Etc...
Ça ne se passe pas tout à fait comme ça. Tu peux choisir de ne plus relancer le pilote après N échecs voir déclencher des actions après M échecs, etc.
J'avais lu un papier où ils ont téléchargé une image ISO avec wget en tuant le pilote réseau toutes les 10 secondes. Bah ça fonctionne : l'ISO est chargée sans erreur ! La question est du genre : préfères-tu abandonner le téléchargement de ton image ISO et corriger le problème (ouvrir un rapport de bug et rebooter) ? Ou alors redémarrer stupidement ton pilote et arriver à terminer ton téléchargement ? Comme Mathieu l'a indiqué : ils y a beaucoup de machines où tu ne peux même pas intervenir (embarqué) ou qui a besoin d'une très haute disponibilité et fiabilité (banque).
Bien sûr, y'a la solution d'écrire des pilotes sans bug, hum hum.
[^] # Re: Plantage
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Plantage
Posté par Guillaume D. . Évalué à 8.
page 12, chapitre 5
[^] # Re: Plantage
Posté par Victor STINNER (site web personnel) . Évalué à 4.
J.N. Herder et al., "Modular System Programming in MINIX 3," Usenix;
http://www.usenix.org/publications/login/2006-04/openpdfs/he(...)
Mais il me semble que c'était pas celui-là. Un jour je noterai qq. part les papiers intéressants que j'ai lu ;-)
[^] # Re: Plantage
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Roadmap to a Failure-Resilient Operating System by Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S. Tanenbaum
http://www.usenix.org/publications/login/2007-02/openpdfs/he(...)
[^] # Re: Plantage
Posté par IsNotGood . Évalué à 3.
Bof.
C'est quoi "tuer le pilote" ?
Tu peux plus ou moins faire ça avec Linux, par exemple en branchant et débranchant une carte réseau USB. Wget fera le nécéssaire pour relancer une connexion (ce qu'il a très probablement fait avec Minix 3).
Les drivers ont toujours une tolérance aux erreurs.
> Bien sûr, y'a la solution d'écrire des pilotes sans bug, hum hum.
Pourquoi pas. Ce n'est pas plus irréaliste que de faire un micronoyau hypra souple et capable de gérer toutes les erreurs (voire de faire de l'auto-guérison comme le dit la dépêche). Le principe de Minix 3 supose qu'il y a une partie (assez grosse) sans bug.
C'est pareil avec GNU/Linux, sauf que la partie sans bug est plus grosse. Mais comme c'est moins compliqué, il n'est pas dit que l'un soit intrasèquement moins fiable que autre.
Pour une solution complète, c'est la fiabilité de l'ensemble qui compte. Minix 3 peut ne pas avoir d'erreur, mais si le driver réseau plante toutes les millisecondes c'est sans intérêt. Si la libc déconne, c'est sans intérêt. S'il y a un bug dans wget, c'est sans intérêt.
C'est louable de faire un noyau hyper fiable. Mais il ne faut pas compter sur ça pour corriger ou compenser les erreurs qui sont ailleurs.
[^] # Re: Plantage
Posté par Sylvain AVRIL (site web personnel) . Évalué à 4.
> Pourquoi pas. Ce n'est pas plus irréaliste que de faire un micronoyau
> hypra souple et capable de gérer toutes les erreurs (voire de faire
> de l'auto-guérison comme le dit la dépêche). Le principe de Minix 3
> supose qu'il y a une partie (assez grosse) sans bug.
> C'est pareil avec GNU/Linux, sauf que la partie sans bug est plus
> grosse. Mais comme c'est moins compliqué, il n'est pas dit que l'un
> soit intrasèquement moins fiable que autre.
Je ne sais plus quel scientifique démontrait que les logiciels sans bugs sont une utopie. Quelque soit la qualité des développeurs, il y aura toujours des bugs (même si ce sont les très qualifiés développeurs du kernel).
Le kernel linux a atteint une telle taille que je suis impressionné qu'il puisse tout simplement marcher. Si cela avait été fait dans un mode propriétaire/commercial avec des contrainte de temps/budget, il aurait fait parti des nombreux projets abandonnés (car l'une des forces de l'open source AMHA c'est de mettre les techniciens au centre des décisions et qu'elles sont les plus justes et pérennes).
Donc même si l'approche ultime/idéaliste est de dire qu'il ne vaut mieux ne pas avoir de bug est juste, l'approche de redémarrer le code fautif est aussi une solution ... court terme, efficace mais qui ne justifie aucunement de ne pas corriger le bug.
[^] # Re: Plantage
Posté par Dr BG . Évalué à 3.
[^] # Re: Plantage
Posté par IsNotGood . Évalué à 6.
La longueur du code compte mais ne me semble pas le facteur le plus important.
Ajouter des drivers à Linux augmente le nombre de bug dans les sources du noyau, chaque driver pouvant apporter son lot de bug. Mais tous les drivers de Linux ne sont pas utilisés en même temps, donc ajouter un driver ou un système de fichier ne diminue pas la fiabilité de Linux.
Par contre la complexité est vraiment un paramètre important sur la qualité.
On peut faire un programme fleuve (par exemple les programmes avec interface graphique riche) sans beaucoup de bug mais surtout assez facile à trouver. Dans le cas de programme comme un noyau, avec des optimisations un peu partout, avec du multi-thread, etc ça peut tourner au cauchemar.
J'avais vu un blog "marrant". Un développeur esprimait sa joie d'avoir enfin supprimé un bug de Linux après 4 mois d'effort à le chercher !
Une fois j'ai passé 2 semaines à seulement chercher un bug (plantage aléatoire en moyenne toutes les 4 heures) dans un de mes programmes. C'est vraiment creuvant à faire et on passe par des "grands moments de solitude".
[^] # Re: Plantage
Posté par IsNotGood . Évalué à 2.
Je n'ai pas voulu dire que faire un driver sans bug était réaliste (quoique pour seulement un driver ça doit être possible), mais que faire un noyau Linux sans bug est aussi irréaliste que faire un micro-noyau sans bug. Ou que les deux peuvent être aussi fiable.
[^] # Re: Plantage
Posté par Badeu . Évalué à 4.
Même sans bug, faut pas oublier qu'en dessous du logiciel il y a du matériel et que lui non plus n'est pas exempt d'erreurs (aussi bien transitoires que fatales), donc un système bug-free ne résoudrai rien.
[^] # Re: Plantage
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 1.
A moins d'être capable de faire de la redondance, si un service n'est plus disponible, quelle qu'en soit la raison, évidemment, aucun de ses clients ne peut plus fonctionner.
En pratique, si je développe un système de fichiers, ça me permet de faire des essais sur un serveur Web massivement utilisé sans altérer la disponibilité du service Web.
Quand on touche au matériel en revanche, ça se complique. L'accès à la configuration d'un DMA, par exemple, offre de facto des privilèges à l'entité qui l'utilise.
[^] # Re: Plantage
Posté par het . Évalué à 2.
[^] # Re: Plantage
Posté par IsNotGood . Évalué à 3.
Le ctrl-alt-del pour se logguer c'est très limité.
Un programme ne peut détecter ctrl-alt-del (il n'y a que le noyau sous win qui peut le faire), mais il suffit de faire une mire de login qui ne détecte que des touches ctrl et alt. Je suis sûr que ça marchera au moins 19 fois sur 20.
[^] # Re: Plantage
Posté par Littleboy . Évalué à 2.
Vu que des que t'as presse la combinaison, ca switche sur la mire de login, meme si tu affiches 1/4s ta mire bidon, ca va pas marcher. Et si t'esperais rester en plein ecran, pas de chance ca repasse en fenetre (ou bien reduit la tache) quand tu sors de la version securisee. Pas tres discret donc...
[^] # Re: Plantage
Posté par IsNotGood . Évalué à 2.
Si je peux ?!?
Je ne peux pas, j'ai dit une connerie.
Désolé, j'aurai dû réfléchir un peu plus.
> Vu que des que t'as presse la combinaison, ca switche sur la mire de login
Bien vu.
Ce système est moin con que je ne le croyait.
Pour info, on peut virer la demande ctrl-alt-suppr au login. Il faut évidemment être admin.
[^] # Re: Plantage
Posté par het . Évalué à 1.
[^] # Re: Plantage
Posté par IsNotGood . Évalué à 2.
[^] # Re: Plantage
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Plantage
Posté par Anonyme . Évalué à 3.
[^] # Re: Plantage
Posté par IsNotGood . Évalué à 2.
Xorg ne plante jamais sous Red Hat. Si ce n'est pas le cas sur ta distrib, fout la à la poubelle.
[^] # Re: Plantage
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Plantage
Posté par IsNotGood . Évalué à 2.
Sinon évidemment qu'il y a des plantages avec Red Hat comme ailleurs.
[^] # Re: Plantage
Posté par Anonyme . Évalué à 0.
[^] # Re: Plantage
Posté par IsNotGood . Évalué à 4.
Va voir un psy.
[^] # Re: Plantage
Posté par Anonyme . Évalué à -1.
# L'avis de Linus
Posté par patrick_g (site web personnel) . Évalué à 10.
Je pense qu'il est interessant d'en faire une traduction partielle afin de comprendre pourquoi il n'aime pas cette architecture. J'ai traduit les passages qui me semblent importants (j'ai charcuté donc) mais vous êtes invités à aller lire les posts complets pour vous faire une vraie idée de ses arguments.
Résumé du début du post : Il explique qu'il se fiche des questions d'implémentations et de vocabulaire et que la seule chose importante, la différence réelle et cruciale entre les noyaux monolithiques et les micro-noyaux c'est l'adressage mémoire. Il est séparé pour les micro-noyaux alors qu'il est commun pour les noyaux monolithiques. La seule vraie barrière dans les noyaux classiques c'est celle qui existe entre les applications utilisateurs et le noyau. Les micro-noyaux eux, mettent des barrières partout
Traduction du reste :
"Maintenant le vrai problème avec cette séparation n'est pas la question des performances (qui existe pourtant) mais plutôt le problème de la complexité. Il est risible de voir les partisans des micro-noyaux proclamer que leurs systèmes sont "plus simples" que les noyaux traditionnels. Ce n'est pas le cas. Ils sont bien plus compliqués du fait de cette barrière qui existe entre les structures de données.
Le résultat fondamental de cette séparation de l'adressage mémoire est que vous ne pouvez pas partager les structures de données. Cela veut dire que vous ne pouvez pas partager les verrous, cela veut dire que vous devez copier toutes les données partagés et cela implique que vous avez énormément de mal à gérer la cohérence.
Fondamentalement tous vos algorithmes deviennent des algorithmes distribués.
Et celui qui vous dit que les algorithmes distribués sont "plus simples" à la tête tellement rempli de m*rde que ce n'est même plus drôle.
Les micro-noyaux sont bien plus difficiles à écrire et à maintenir exactement pour cette raison. Vous pouvez faire les choses simples assez facilement - en particulier quand vous n'avez à passer l'information que dans un sens - mais tout le reste est incomparablement plus difficile parce qu'il n'y a pas de partage d'état (par design). Et en l'absence de ce partage vous avez une sacré quantité de problèmes pour prendre une décision qui concerne plus d'une entité dans le système.
Et je ne suis pas juste en train de blablater. C'est un fait. Un fait qui a été montré en pratique encore et encore, et pas seulement dans le domaine des noyaux. Mais cela s'est vérifié aussi pour les noyaux et pas qu'une seule fois. Tout l'argument "les micro-noyaux sont plus simples" c'est juste de la connerie et le fait que ce soit de la connerie se voit quand on compare la vitesse de développement d'un micro-noyau et d'un noyau traditionnel. Le noyau traditionnel gagne. Et avec une marge énorme en plus.
Tout l'argument disant que les micro-noyaux sont "plus sécurisés" ou "plus stables" est aussi totalement grotesque. Le fait que chaque pièce individuelle soit simple et sécurisée ne fait pas que leur aggrégation soit simple et sécurisée. Et l'argument que vous pouvez "simplement relancer" un serveur défaillant sans emporter tout le système est également fautif.
Quiconque a déjà fait de la programmation distribuée devrait savoir maintenant que quand un noeud se vautre le reste se vautre aussi. Ce n'est pas toujours vrai (mais il n'est pas toujours vrai aussi qu'un crash de pilote fasse tomber à chaque fois un noyau monolithique), mais c'est souvent le cas s'il y a une dépendance mutuelle ou un problème de cohérence.
Et dans le domaine des systèmes d'exploitations il y sacrément peu de trucs qui n'ont pas de problème de cohérence. Si il n'y avait pas de problème de cohérence sela ne serait pas dans le noyau de tout façon !".
Le second post ou il réponds à quelqu'un lui disant que certaines personnes pensent que les avantages des micro-noyaux compensent les inconvénients :
"Et bien jusqu'à présent ces personnes n'ont même pas été capables de nommer ces avantages hypothétiques.
J'ai vu des affirmations grotesques à propos de la "facilité" (en fait c'était l'argument des années 80 et 90) et j'ai même été convaincu à une époque. Depuis j'ai appris ce qui est facile et ce qui est difficile - et j'ai vu les gens échouer avec leurs micro-noyaux encore et encore - Il est devenu évident pour moi que l'argument de la simplicité était faux.
L'an dernier le dernier argument magique c'était la "sécurité". C'est tout aussi grotesque que la "facilité et pour les mêmes raisons. Les bugs de sécurité sont souvent dans les interactions de deux sous-systèmes et plus difficile c'est à écrire et maintenir, plus difficile c'est à sécuriser.
Je suis certain que dans dix ans il y aura d'autre arguments. Il y a toujours une excuse.
Au final (et c'est je pense décisif) le vrai argument pour les micro-noyaux n'a rien à voir avec la vitesse, la facilité, la sécurité ou le reste.
La vraie raison pour laquelle les gens font des micro-noyaux (et vont probablement continuer de le faire en inventant de nouvelles bonnes raisons prouvant que c'est la meilleure solution) c'est que le concept lui-même est si séduisant. J'ai été séduit moi aussi !
Toute cette histoire de "petits modules indépendants" sonne vraiment comme la manne tombée du ciel quand vous êtes confronté à la tâche gigantesque de créer un OS et que vous réalisez à quel point c'est une tâche énorme.
Cette idée des "micro-noyaux qui sont merveilleux" vient de ce souhait désespéré que le monde devrait être plus simple qu'il ne l'est réellement. C'est pourquoi les micro-noyaux sont si populaires dans les cercles académiques ou personne ne peut se permettre de mettre un gros team de développement et ou il est donc absolument nécessaire que le problème soit simple.
La réalité n'a rien à voir avec les micro-noyaux. C'est l'inverse en fait. Le vrai but des micro-noyaux c'est d'échapper à la réalité du fait que le design et l'implémentation d'OS complet est difficile et que c'est beaucoup de travail".
Le premier post est ici : http://www.realworldtech.com/forums/index.cfm?action=detail&(...)
Le second là : http://www.realworldtech.com/forums/index.cfm?action=detail&(...)
Et il y en a d'autres dans le thread....de la lecture pour ce vendredi pluvieux !
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 2.
Va aussi falloir qu'il se fasse une raison Linux, le noyau Linux et le nombre de drivers qu'il y a dedans devient plus que conséquent, la complexité de ces drivers est croissante (ex : les drivers graphiques), et ca paraît un peu dépassé comme conception de croire qu'on peut faire tourner ce joli monde sans barrière avec le même niveau de fiabilité.
[^] # Re: L'avis de Linus
Posté par Troy McClure (site web personnel) . Évalué à 3.
(on peut aussi se dire que ce n'est pas cette fonctionnalité qui va encourager ATI a faire des pilotes moins merdiques)
[^] # Re: L'avis de Linus
Posté par Badeu . Évalué à 6.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 1.
Mouaif. Ou ça a été fait car MS n'arrivait pas à gérer la qualité et donc a un conçu un truc pour gérer un truc merdique (c'est une supposition).
> un petit tressautement visuel et je peux continuer de jouer avec mon jeu préféré sans interruption.
Je ne connais pas l'architecture de Windows, mais il est possible qu'il ne sache réinitialiser qu'une partie du driver graphique. D'autres parties ne devant pas planter. Je ne crois pas que le driver soit déchargé et rechargé à la volé.
De plus il semble avoir lu que beaucoup des problèmes avec vista sont liés aux drivers graphiques. Donc le système qui supporte les plantages graphiques et les sépare du reste du système n'est manifestement pas au point.
> Va aussi falloir qu'il se fasse une raison Linux, le noyau Linux et le nombre de drivers qu'il y a dedans devient plus que conséquent
???
Les drivers/modules sont chargés que s'il y a le matos qui correspond.
> la complexité de ces drivers est croissante (ex : les drivers graphiques)
Pour Linux, ce n'est pas le problème du moins pour la qualité (ou plantage).
Le problème actuellement est :
- faible support des constructeurs (mais ça s'améliore).
- architecture qui a beaucoup changé sans être encore finalisée (KMS, Gem, Xorg, etc).
- les moyens de Linux pour tout ce qui est desktop est sans commune mesure avec MS.
Avec les faibles moyens qu'a Linux, je pense que ça serait une erreur de faire une usine à gaz qui gère les plantages des drivers.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 9.
Mon dieu MS n'arrive pas à gérer la qualité de ce que fait NVidia ATI ou Intel ! Heuresement, le kernel Linux, lui il sait gérer ça. C'est pour cela qu'on a pas besoin de barrière, les drivers graphiques sous linux qui plantent, ca n'existe pas, car Linux sait gérer la qualité.
Je ne crois pas que le driver soit déchargé et rechargé à la volé.
Si.
De plus il semble avoir lu que beaucoup des problèmes avec vista sont liés aux drivers graphiques.
Ce qui était également le cas de XP. Constat de MS : la plupart des plantages sont directement imputables aux drivers. Idée : mettre une barrière. Constat : ca plante beaucoup moins.
Les drivers/modules sont chargés que s'il y a le matos qui correspond.
Le problème c'est pas tant le nombre de driver chargé à un instant donné, mais la capacité au projet dans son ensemble à croire qu'il est possible de maintenir un aussi grand nombre de drivers de qualité, sans avoir besoin de mettre de barrière.
Pour Linux, ce n'est pas le problème du moins pour la qualité
Désolé, c'est le problème de Linux. C'est lui qui fourni l'infrastructure pour les drivers, et c'est de sa faute si un driver a un impact aussi important qu'un crash d'une application voir le plantage total du kernel.
faible support des constructeurs (mais ça s'améliore).
- architecture qui a beaucoup changé sans être encore finalisée (KMS, Gem, Xorg, etc).
- les moyens de Linux pour tout ce qui est desktop est sans commune mesure avec MS.
Y'a sans doute pleins de bonne raisons pour expliquer ces problèmes. Tout problème a une ou plusieurs origines, on en conviendra. Y'a des solutions pour limiter l'impact de ces problèmes, les micro-noyaux sont une partie de cette solution, il paraît donc un brin prétentieux de la part de Linus de dire que ces solutions n'apportent rien au niveau qualité. La stabilité est une qualité.
Avec les faibles moyens qu'a Linux, je pense que ça serait une erreur de faire une usine à gaz qui gère les plantages des drivers.
Je penses pas que ce soit une question de moyen. Je penses que le problème c'est la vision de Linus.
[^] # Re: L'avis de Linus
Posté par patrick_g (site web personnel) . Évalué à 5.
Linux ne se traine pas des boulets de compatibilité comme Windows.
Donc moi je crois que "le projet dans son ensemble" s'en sort mieux que Windows...c'est pas Greg KH qui disait que Linux est l'OS le plus compatible de tous les temps ?
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 1.
Aucune raison de ne pas faire ce qu'arrive à faire Microsoft alors !
Bizzarement, c'est Microsoft qui révolutionne son modèle de driver graphique, et c'est Linux qui reste ancré dans son modèle d'API de driver à l'ancienne, alors qu'ils ventent justement la possibilité d'évoluer, cherchez l'erreur !
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
On n'a peut-être pas envis de le faire. MS n'est pas toujours un exemple à suivre.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Je peux aussi dire que les windows manager à la Linux sont pertinent pour Windows ou qu'un vrai (pas cette merde de powershell) shell c'est pertinent pour Windows. Sauf que la culture, les moyens, etc ne sont pas Linux et donc ça ne marchera pas.
S'il te plait, vu le succès de Firefox, dis que la GPL est pertinent pour IE.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 7.
Quand je dis que c'est pertinent, c'est du point de vue utilisateur. C'est pertinent pour la qualité du logiciel, indépendamment de toute question de moyen. Mais ca fait trop mal au cul d'admettre que le kernel commence à avoir une architecture un peu vieillotte : pour certains ca sert à rien ces évolutions, pour d'autre c'est une question de pertinence vis-à-vis des moyens (jolie pirouette)
De plus je croyais que le principal intérêt d'avoir un développement centralisé et monopolistique des drivers avaient pour principal objectif de faciliter les évolutions : ah bah non tiens, finalement ca marche pas, question de moyen tu comprends : c'est pas pertinent ce genre de grosses évolutions.
Les propos de Linus ne font pourtant nullement référence à un problème de moyen : il affirme juste gratuitement que ces barrières de protection ca n'a aucun intérêt, que ca n'apporte rien au niveau qualité (stabilité, fiabilité, sécurité, etc.). Et les ouailles disent amen ou cherchent à justifier ces propos avec d'autres arguments.
Même les catholiques (et pourtant je suis loin de les trouver malins) sont plus critiques envers le pape quand il parle de protection inutiles :)
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Tu cherches à faire un troll de compétition ?
> Quand je dis que c'est pertinent, c'est du point de vue utilisateur.
Et ?
Un windows manager potable pour Windows c'est pertinent et aussi du point de vu de l'utilisateur.
> C'est pertinent pour la qualité du logiciel
Je ne vois pas pourquoi.
> indépendamment de toute question de moyen.
Chez MS ce type de raisonnement est accèptable, mais chez Linux on est obligé de prendre en compte les moyens. Juste comme petit exemple, connais-tu le plus gros contributeur à Xorg ?
C'est Red Hat... Ce n'est pas une distribution dont la vie dépend du desktop, ce n'est pas un fabriquant de hardware ou un éditeur de jeux vendu ($$) en millions d'exemplaires, c'est une boite dont récemment le PDG a dit ne pas savoir faire de l'argent avec le desktop. C'est dire comme les moyens sont ridicules et comme il est difficile d'avoir des développeurs.
Combien fait de pognon MS avec le desktop ? Des milliards, il est normal que MS y mettent des moyen délirant comparé à GNU/Linux, mais logique vu les enjeux financier.
> Mais ca fait trop mal au cul d'admettre que le kernel commence à avoir une architecture un peu vieillotte
De quoi tu parles ? De micro-noyau ?
Ça existe depuis des plombes les micro-noyau. Ça a quoi de moderne ?
Puis Windows n'a pas un micro-noyau, mais un truc bâtard.
> De plus je croyais que le principal intérêt d'avoir un développement centralisé et monopolistique des drivers avaient pour principal objectif de faciliter les évolutions
Oui. Mais où tu veux en venir ?
Parce que c'est exatement ce qu'on voit dans Linux. Actuellement la configuration passe de Xorg au noyau. Tout ce qui est dépendant de l'hardware va être dans le noyau et plus dans Xorg (qui n'aura plus de drivers ; ni d'ailleurs de fichier de configuration ; ni besoin de privilège particulier et pourra s'excuter sans droit root). Il y a aussi du boulot côté gestion mémoire de la carte graphique avec GEM, mais je n'y comprend pas grand chose :-)
Donc oui, ça facilite l'évolution. Mais ce n'est pas le "développement centralisé" (et surtout pas monopolistique) qui fait la différence, mais car c'est du logiciel libre. On peut casser l'API, on a les sources des drivers s'il faut les mettre à jour. D'où Red Hat qui pousse le drivers Nouveau et vire l'obscurci NV.
> ah bah non tiens, finalement ca marche pas
Oui ça marche.
> question de moyen tu comprends
Plus t'as de moyen, mieux ça marche.
Ne crois pas que les méthodes qui marchent chez MS peuvent marcher dans le libre (je ne crois pas l'inverse non plus).
Fais des plans sur la comète et dit que Xorg sera inutilisable durant 1 ans, c'est un excellent moyen pour faire fuire les contributeurs. Fais des plans monstreux avec du UML, les plannings, des tests unitaires, etc et tu fais fuire les contributeurs. Force un projet, et du fait fuire Intel. Etc.
MS n'a pas ce "problème" (qui n'en est pas vraiment un) car MS a d'énorme moyen. MS peut avoir un dictateur qui fixe ce qui doit être développé et peut payé des gens en masse pour tous les trucs rébarbatifs. Pour tenir les délais, MS peut embaucher par centaines (ou payer des boites externes).
Etc.
Etc.
Tous ça ne marche pas dans le libre. Le libre a une autre méthode, elle n'est pas plus mal.
> Les propos de Linus ne font pourtant nullement référence à un problème de moyen
Bullshit.
Les micro-noyaux sont bien plus difficiles à écrire et à maintenir
[...]
j'ai vu les gens échouer avec leurs micro-noyaux encore et encore - Il est devenu évident pour moi que l'argument de la simplicité était faux.
Ce qui est compliqué demande beaucoup de boulot.
> il affirme juste gratuitement que ces barrières de protection ca n'a aucun intérêt, que ca n'apporte rien au niveau qualité (stabilité, fiabilité, sécurité, etc.). Et les ouailles disent amen ou cherchent à justifier ces propos avec d'autres arguments.
Et toi tu affirmes l'inverse gratuitement. Balle au centre. M'enfin, je tendance à croire Linus.
Et il y a des faits :
- Il n'y a pas de micro-noyau en production ! Il n'y a que des trucs qui marchouillent et/ou sont très loins de rivaliser avec Linux. Pourtant ça fait depuis des années (et bientôt des dizaines d'années) que des micro-noyau sont en développement.
- Windows n'a pas un micro-noyau. C'est autant un micro-noyau que MacOS est un micro-noyau.
Si tu penses que faire un micro-noyau est facile, pourquoi il n'y en a pas ? On ne trouve que des trucs pour des niches ou qui marchouille si on veut en faire un OS généraliste.
> Même les catholiques (et pourtant je suis loin de les trouver malins) sont plus critiques envers le pape quand il parle de protection inutiles :)
Linus parle de ce qu'il connait. Le pape n'a jamais baisé (avec ou sans capote).
Linus parle de techniques qu'il faut appliquer. Le pape délivre d'un message (qui n'est pas le sien) d'idéal.
[^] # Re: L'avis de Linus
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Moi je trouve les arguments de chaque part pertinent, même si la façon franche et folklore de parler qu'à Linus à souvent de quoi amener le troll. :)
Concernant le développement de micro-noyau, on peu aussi se demander les moyens qui y sont mis. Comme tu le dis «plus t'as de moyen, mieux ça marche».
Certes la communauté linux n'a pas les moyens de microsoft, mais les développeurs de micro-noyau ont-ils les moyens qu'à linux ? Derrière linux il y a quand même un investissement croissant d'un certain nombre de boites dont certaines ne sont pas des plus petites (au hasard IBM).
Bien sûr au départ linux n'avait pas tout ce soutient, mais il était aussi plus petit.
Maintenant il me semble que MINIX 3 est un projet qui avance bien, peut être pas encore prêt pour la production, mais à priori en bonne voie pour s'y acheminer.
Je ne dit pas que MINIX 3 c'est la seule voie du futur, qu'une fois bien opérationnel tous les autres OS pourront aller se rhabiller avec leur vieille architecture désuète. Exactement comme il y a de la place pour les BSD à coté de Linux, tout comme il y a de la place pour les millions de distributions GNU/Linux.
Même si c'est pour des secteurs de niches, ça peut valoir le coups. Après en faire un système pour le poste de travail, c'est faisable et si on est prêt à sacrifier un peu de performance pour ça, pourquoi pas.
Ce n'est pas parceque Linus parle technique qu'il faut appliquer à la lettre ce qu'il dit. Il peu se tromper comme tout à chacun. C'est peut être Tanenbaum et la communauté MINIX qui à tort de persévérer dans cette voie. Mais d'une part, la forme que ça prend ne donne pas cette impression; et d'autre part, au pire des cas ils auront perdu leur temps à essayer : c'est pas la fin du monde et ils font ce qu'ils veulent de leur temps.
[^] # Re: L'avis de Linus
Posté par Thomas Douillard . Évalué à 3.
T'emballes quand même pas, dit comme ça ça fait presque une distribution par utilisateur, ou plus ;)
[^] # Re: L'avis de Linus
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: L'avis de Linus
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
En effet, dans la roadmap de Xen, ils veulent découper le dom0 en petits bouts pour rendre les morceaux indépendants et que les plantages sur les uns ne touchent pas les autres.
C'est pas du micro-noyau mais c'est un ssytème sur trois ring... Finalement, c'est la virtualisation matérielle qui va nous amener la souplesse promise par les micros noyaux. Après celles des processeurs, et en train d'arriver celle des entrées sorties avec la protection de la mémoire car sans elle, il n'y avait pas de protection réelle.
A mon sens, le projet le plus dynamique en terme de développement sera profiter de cette nouvelle architecture matérielle et je suis persuadé que Linux est ce système.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 4.
Aujourd'hui c'est claire que non.
Mais en 1990 l'écart n'était pas celui d'aujourd'hui. En tout cas, si les micro-noyau étaient aussi prometteurs qu'on le dit, le manque de moyen aurait dû être compensé par la supériorité (prétendue) de l'architecture micro-noyau. Mais ce n'est pas que qu'on a vu.
Notons aussi que Hurd n'a pas créé de micro-noyau, il en a pris des déjà existant. A l'époque Linux a pratiquement tout fait.
> Derrière linux il y a quand même un investissement croissant d'un certain nombre de boites dont certaines ne sont pas des plus petites (au hasard IBM).
MS, Apple (et nextstep), Digital Equipement, pour en citer quelques uns, sont aller sur la voie micro-noyau. Donc les moyens ne manquaient pas et les micro-noyau ont eu leur chance. Au final ils ont fait des trucs "bâtards". En face le petit linux et avec des moyens bien moindre c'est fait une place au soleil.
Pourquoi ils ne sont pas allé au bout de la démarche micro-noyau ? Peut-être car ils ont rapidement constaté que c'était aller droit dans le mur en klaxonnant. Hurd a fait la tête de mule.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 1.
Gnaaa ! J'affirmes pas gratuitement, je pars de la réalité, de la vraie vie, d'exemples concrêts : mon expérience avec les crash graphiques, d'autres que moi ici semble vivre le même genre de problème, je t'ai pointé un doc de stats de MS sur le nombre de plantage récupérés, c'est autant de faits qui montre que ces barrières ont un intérêt, quoiqu'en dise Linus. Point barre.
Tout le reste de ton blabla sur les coûts je suis entièrement d'accord avec, mais pour la dernière fois : ce n'est pas ça l'argumentaire de Linus. Linus préfère dire que les autres sont dans l'erreur plutôt que de dire "ok c'est bien, mais le coût en vaut pas la peine". Mais visiblement il a un problème d'égo.
[^] # Re: L'avis de Linus
Posté par Kangs . Évalué à 1.
Tu affirmes gratuitement que ta vie et la vrai vie, géniale ....
[^] # Re: L'avis de Linus
Posté par Larry Cow . Évalué à 5.
[^] # Re: L'avis de Linus
Posté par Bob . Évalué à 1.
Tu affirmes gratuitement que ta vie est la vrai vie, génial ....
[^] # Re: L'avis de Linus
Posté par windu.2b . Évalué à 4.
Tu affirmes gratuitement que ta vie est la vraie vie, génial ....
:-)
[^] # Re: L'avis de Linus
Posté par Bob . Évalué à 1.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 1.
OK, désolé.
> je pars de la réalité, de la vraie vie, d'exemples concrêts : mon expérience avec les crash graphiques, d'autres que moi ici semble vivre le même genre de problème
Et ?
En passant, je n'ai pas dit que MS avait tord de le faire (faut dire que Windows n'est pas une de mes préoccupations). Je dis qu'une autre voix est possible, que les micro-noyau ne sont pas forcément supérieur dans la pratique.
Donnes à Linux les moyens de MS, le même support des constructeurs, et je serais HYPER supris qu'il y ait plus de plantage du système à cause des drivers graphiques sous Linux que sous Windows.
Les plantages du système à cause du drivers graphique existe sous Windows et sous Linux. Ils ont rares (j'en ai jamais eu sur mes systèmes Linux ; je veux bien croire que j'ai eu de la chance). Je ne crois pas que si Linux avait les même moyens que Windows, ou même seulement un quart des moyens de Windows, Linux aurait plus de plantage système à cause du driver graphique que Windows.
> je t'ai pointé un doc de stats de MS sur le nombre de plantage récupérés, c'est autant de faits qui montre que ces barrières ont un intérêt
Les barrières ne sont pas un truc qui s'ajoute, comme par exemple on ajoute SeLinux à Linux. Elles demandes un grosse réorganisation du noyau, de nouvelles contraintes, etc. C'est l'ensemble qu'il faut juger. Et si on juge l'ensemble (noyau Windows et noyau Linux), les barrières n'ont pas montré un intérêt. Peut-être un intérêt pour le noyau Windows, son organisation, son mode de développement. Pas pour Linux.
T'as pointé une truc qui montre qu'il y a des plantages des drivers graphiques sur Vista. T'as pointé un truc qui montre qu'il y a beaucoup de plantage des drivers graphiques sous Vista. Tu confirmes qu'il y a beaucoup de plantage des drivers graphiques sous Vista. D'autres utilisateurs le confirme. Je le confirme aussi, le drivers graphique Intel (i945) sous Vista plante et ça m'arrivait toutes les semaines. Certes, dans mon cas tous ces plantages ont été récupérés (sauf que parfois je n'avais plus l'interface aero...).
Il y a beaucoup de plantage graphique et 7 % (si j'ai bonne mémoire) de ces nombreux plantages graphiques, aboutisse à un plantage système !
Bref, ce n'est pas la preuve que l'architecture de Vista donne une meilleur fialibité, mais seulement que beaucoup de ses très nombreux plantages graphiques sont récupérés.
Linux ne veut pas récupérer la majorité des plantages du drivers graphiques, Linux veux des drivers graphiques de qualité. Je ne crois pas qu'il sera difficule pour Linux d'avoir 20 fois moins de plantage du drivers graphique que Vista. Et même si chaque plantage graphique aboutit à un plantage système pour Linux, ça fera moins de plantage système que Vista à cause du driver graphique.
> Mais visiblement il a un problème d'égo.
Et toi ?
Ton raisonnement est pourri.
Je vais l'appliquer pour les transports :
- Les airbags des voitures sauvent 30 % de vie
- Les avions n'ont pas d'airbags
- Donc se déplacer en avion est plus dangereux que se déplacer en voiture
C'est ça ton raison. De la merde.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 1.
Forcement, en racontant n'importe quoi, tu peux me faire dire n'importe quoi et conclure n'importe quoi.
Tout ce que je dis, c'est qu'il est vraiment prétentieux pour un constructeur de voiture de dire que les airbags c'est naz ca sert à rien. Alors que y'a des vraies vies qui ont été sauvées. Devant cette évidente contradiction entre la réalité et les propos de ce type, toi t'essai de justifier les propos de ton constructeur préféré (oui fondamentalement il ne doit PAS avoir tord, y'a forcement une bonne raison cachée) en disant que ca va lui coûter trop cher d'adapter sa chaîne de production.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Pour continuer dans l'analogie, mon constructeur ne fait pas des voitures mais des avions.
Sûr qu'on peut ajouter des airbags à un avion et que ça va améliorer la sécurité (de trois fois rien).
Mais on pourrait aussi ne plus rendre l'accès aux routes libre pour les voitures dans ce cas.
Un avion ne prend pas la "route" librement. Un avion doit avoir l'autorisation du contrôle aérienne, et ça sauve des tonnes de vie. On pourrait le faire pour les voitures et ça sauverait des vies et ceux qui s'y opposerait serait des cons (selon toi).
Une solution adaptée pour les avions, n'est pas forcément adaptée pour les voitures et vice versa.
Toi tu dis que non, que ce qui est bon pour l'un l'est forcément pour l'autre et qu'il y a obligation de l'appliquer pour les deux.
Tu vas peut-être dire que comparer des avions et des voitures n'est pas honnètes. On peut comparer les voitures de séries et les voitures de compétition. Ces dernières n'ont pas d'airbag et sont plus sûres. Un airbag n'apporte pratiquement rien à une voiture de compétition.
Je n'ai pas dit que Windows avait tort, mais que ce n'était pas adapté à Linux.
Par contre tu dis que Linux a (forcément) tort.
> Tout ce que je dis, c'est qu'il est vraiment prétentieux pour un constructeur de voiture de dire que les airbags c'est naz ca sert à rien.
Linux est un avion et Windows une voiture. Ou l'inverse si tu veux.
[^] # Re: L'avis de Linus
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Windows et Linux ont des modes de développement différent c'est vrai, et après ? Ça ne nous donne aucune indication sur l'intérêt ou non de Minix.
Minix comme Linux est un logiciel libre, et si il y a une erreur dans le code, on peu la corriger. Ce qui les différencie le plus du point de vue de l'utilisateur (ce qui est sûrement le plus important) :
* Minix est plus lent de par son architecture
* Linux isole moins bien les erreurs de par son architecture
Il n'y a pas de «solution parfaite». C'est plus une question de réponse adapté aux besoins.
Un système à micro-noyau est peut être plus difficile à développer, je n'en sais rien, mais ce qui est sûr c'est qu'il y a une demande. Minix vise à répondre à cette demande et il m'a l'air en très bonne voie pour y parvenir.
Ce qui est plus idiot à mon avis, c'est cette espèce de volonté de se présenter comme l'unique solution à tous les problèmes. Ce désire de la poudre verte, du saint graal de l'unicité est bien sûr très attirant. Comme l'est la théorie des cordes par exemple, pouvoir tout exprimer en un ensemble réduit et cohérent d'équation, c'est assurément séduisant. Cela étant les théories de newton toute approximatives qu'elles soient sont encore bien suffisantes,utiles pour un tas de choses, et souvent même plus adapté.
Je rejoint ici un peu la critique de Linus, mais je n'en tire pas les mêmes conclusions. Je pense qu'il y a de la place pour les deux approches.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Dire ça, c'est comme ne rien dire. Quand quelque chose se crée, c'est qu'il y a une demande.
Quel est le niveau de la demande et pour quel besoin ?
La demande est-elle suffisante pour faire aboutir le projet ?
La demande est-elle seulement de permettre à des hackers de s'éclater ?
Si oui, c'est très bien et on ne peut prédire ce qu'il en sera ensuite.
> Ce qui est plus idiot à mon avis, c'est cette espèce de volonté de se présenter comme l'unique solution à tous les problèmes.
Parle en à TImaniac. Il veut imposer les solutions/méthodes de Windows à Linux. Je ne veux pas imposer les solutions/méthodes de Linux à Windows.
> Je pense qu'il y a de la place pour les deux approches.
Ça aussi c'est ne rien dire.
Quelle place ?
Tu sous-entends que les deux approches sont dans le(s) même(s) périmètre(s).
Pour le périmètres desktop/serveur, j'ai bien du mal à croire que Minix se fera un place ou ira bouffé de la place à Linux/Windows/etc.
Pour l'embarqué, et si Minix reste simple, il a une opportunité (c'est seulement une impression).
> Je rejoint ici un peu la critique de Linus, mais je n'en tire pas les mêmes conclusions. Je pense qu'il y a de la place pour les deux approches.
Je ne crois que Linus ait dit qu'il n'y avait pas de place pour l'approche micro-noyau. Il dit que techniquement ça sucks (ou ne tient ses promesses) et constate que l'histoire n'a pas donné "raison" au micro-noyau (du moins pour les noyaux généralistes).
Dans les années 90, Windows était pourri et OS2 bien meilleur techniquement. On sait maintenant le quel c'est fait une place. A l'époque, à cause du coût de la mémoire, le choix de MS était plus pertinent.
Peut-être qu'un jour les cpu seront surpuissants et qu'on pourra se payer la perte de performance d'un micro-noyau. Ce n'est toujours pas la tendance. Les PC doivent booter en moins de 20 secondes, MS va sortir Windows 7 car Vista est trop lent/jouflu, la recherche d'économie d'énergie (portable, netbook) fait qu'on doit utiliser des cpu moins puissant, l'informatique est maintenant une commodité et donc le prix doit être faible (pour faire des téléphones, etc).
Quel gain apporte les micro-noyau dans ce contexte ?
Pour de l'embarqué qu'on va envoyer sur Mars où les moyens d'intervention sont très limités, les micro-noyau ont évidemment un intérêt.
[^] # Re: L'avis de Linus
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Quel est le niveau de la demande et pour quel besoin ?
La demande est-elle suffisante pour faire aboutir le projet ?
La demande est-elle seulement de permettre à des hackers de s'éclater ?
Si oui, c'est très bien et on ne peut prédire ce qu'il en sera ensuite.
Bah, par exemple google semble intéressé, pour en faire quoi, je ne sais pas. Il y a aussi le conseil européen de la recherche qui à donné 2.5 millions d'euro à Tanenbaum pour travailler sur son projet "Research on Really Reliable and Secure Systems Software."[1]
Ça aussi c'est ne rien dire.
Quelle place ?
Tu sous-entends que les deux approches sont dans le(s) même(s) périmètre(s).
Pour le périmètres desktop/serveur, j'ai bien du mal à croire que Minix se fera un place ou ira bouffé de la place à Linux/Windows/etc.
Pour l'embarqué, et si Minix reste simple, il a une opportunité (c'est seulement une impression).
Et pourquoi pas aussi sur le poste de travail et les serveurs ? C'est comme si tu me disais qu'il n'y avais que de la place que pour Red Hat pour les serveurs linux, ou que les BSD ça sert à rien, linux c'est mieux.
Les gens utiliseront les solutions qui leur paraissent la plus adaptée (ou la plus en vogue dans les soirées mondaines des décideurs).
Après comme c'est du libre, les échanges de code sont permis. Pour MINIX, je me demande dans quel mesure la GPL empêche l'utilisation de pilotes dans un service géré par un micro-noyau BSD.
En dehors de ça, tout ce qui est applicatif libre (espace utilisateur), il «suffit de» faire les ports.
Pour ce qui est des monstres de puissance, les processeurs multicœurs qui se généralisent sur les postes de travail avec de la mémoire vive qui se compte en Go, ça me semble être plutôt le cas.
[1] http://www.minix3.org/news//index.html#425e1cced0668044026e6(...)
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
D'accord. Mais Google semble intéressé par presque tout. Je ne suis pas convaincu que ça soit très pertinent.
Hurd a été 2 ou 3 fois au Google summer of code et Fedora pratiquement toutes les années.
Tu tires des conclusions ? Moi pas.
> Il y a aussi le conseil européen de la recherche qui à donné 2.5 millions d'euro à Tanenbaum pour travailler sur son projet "Research on Really Reliable and Secure Systems Software."[1]
Bon point.
> Et pourquoi pas
Et pourquoi pas...
Dire que tout peut arriver, n'est pas vraiment une opinion.
> Les gens utiliseront les solutions qui leur paraissent la plus adaptée (ou la plus en vogue dans les soirées mondaines des décideurs).
Comme d'hab, rien de nouveau.
> Pour MINIX, je me demande dans quel mesure la GPL empêche l'utilisation de pilotes dans un service géré par un micro-noyau BSD.
Minix a décidé de prendre la BSD (en 2000; avant c'était proprio) alors que Linux était sous GPL depuis plus de 8 ans. C'est le choix de Minix, Minix doit assumer et ne pas faire de gérémiades.
Si tu lis la FAQ de Minix, la BSD a été prise pour faire du proprio. C'est l'intérêt et défaut de la BSD, mais pour Minix les raisons sont claires.
http://www.minix3.ucsc.edu/wikis/minix3/FoireAuxQuestions
1.2.2. Pourquoi n'avez-vous pas utilisé la GPL ?
Nous pensons que la GPL (General Public License) est trop restrictive. Les entreprises qui investissent beaucoup d'argent dans le développement de l'open source ne veulent pas (avec raison) le donner à leurs concurrents.
Pas très convaincu par le libre Tanenbaum... Déjà qu'il a mis plus de 10 ans à mettre Minix en libre...
> Pour ce qui est des monstres de puissance, les processeurs multicœurs qui se généralisent sur les postes de travail avec de la mémoire vive qui se compte en Go, ça me semble être plutôt le cas.
Et ?
Pas sûr que Minix soit multi-cpu aujourd'hui...
C'était Tanenbaum qui trouvait le multi-tâche sans intérêt... Je dis bien multi-tâche et pas seulement multi-cpu. Alors le multi-cpu qui se généralise, il ne l'a pas vu venir...
Afin, c'est quoi le multi-cpu/coeur qui se généralise ?
C'est le preuve que la puissance d'un cpu, pardon d'un coeur, stagne alors que les besoins augmentes. Dans la pratique, 2 cpu ne valent pas un cpu deux fois plus rapide.
Plus globalement, tu n'as pas tord. Mais les avis qui n'en sont pas (pourquoi pas, etc), ça me gonfle.
Je donne "vrai" avis. Il sera peut-être faux (l'histoire en jugera), ça sera l'occasion de vous foutre de ma gueule, et on va bien rigoler, etc.
Mais les "j'enfonce des portes ouvertes", les "l'histoire n'est pas écrite", les "pourquoi pas" comme seule base, ça me gonfle.
Bonne journée :-)
[^] # Re: L'avis de Linus
Posté par allcolor (site web personnel) . Évalué à 3.
C'était Tanenbaum qui trouvait le multi-tâche sans intérêt... Je dis bien multi-tâche et pas seulement multi-cpu.C'est vraiment étrange... il est donc pour une architecture à micro-noyau (forcément multi-tâche par design) et contre le multi-tâche ?
ça n'a aucun sens... soit tu dis ici une bêtise soit Tanenbaum est un imbécile.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
J'ai été "pute". C'était il y a bien longtemps à l'époque du débat entre Linus et Tanenbaum. Linus avait dit que Linux était multi-tâche alors que Minix non et Tanenbaum avait que le multi-tâche ne sert à rien.
Une autre perle de Tanenbaum envers Linu[sx] :
Je persiste à penser que concevoir un noyau monolithique en 1991 est une erreur fondamentale. Estime-toi heureux de ne pas être un de mes étudiants. Tu n'obtiendrais pas une bonne note pour une telle conception :-)
Aujourd'hui c'est à mourrir de rire.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 3.
>Si c'était le seul critère de « bonne qualité » d'un
>noyau, ce serait exact. Ce que vous ne mentionnez pas, c'est
>que minix ne fonctionne pas comme un micro-noyau de manière correcte,
>et pose des problèmes avec le multitâche en temps réel (dans le
>noyau). Si j'avais fait un SE ayant des problèmes avec un système
>de fichiers subdivisé en unités d'exécution, je n'aurais pas été
>aussi prompt à condamner les autres : en fait, j'aurais fait tout
>mon possible pour que les autres oublient ce fiasco.
Un système de fichiers multi-thread est seulement un bitouillage
d'amélioration des
performances. Lorsqu'il y a seulement un processus actif, cas normal
sur un petit PC, cela ne vous apporte rien et ajoute de la complexité
au code. Sur des machines suffisamment rapides pour servir
plusieurs utilisateurs, vous avez probablement assez de mémoire-cache
pour assurer un bon cache à un bon taux, auquel cas le multi-thread
ne vous apporte rien non plus. Cela ne rapporte vraiment que
lorsque plusieurs processus font au même moment des E/S effectives
sur disque. Que ça vaille la peine de rendre le système plus complexe
dans ce cas est pour le moins discutable.
[^] # Re: L'avis de Linus
Posté par reno . Évalué à 1.
http://www.minix3.ucsc.edu/wikis/minix3/FoireAuxQuestions
1.2.2. Pourquoi n'avez-vous pas utilisé la GPL ?
Nous pensons que la GPL (General Public License) est trop restrictive. Les entreprises qui investissent beaucoup d'argent dans le développement de l'open source ne veulent pas (avec raison) le donner à leurs concurrents.
]]
Faut etre gonflé pour faire ce genre d'affirmation! Je crois qu'a l'heure actuelle le kernel qui a le plus de constributeurs est Linux qui est sous GPL..
Je ne veux pas tout dire que tout OS doit etre sous GPL: utiliser une license BSD peut etre vu comme un moyen de se demarquer de Linux, mais ce n'est pas une raison pour dire n'importe quoi dans une FAQ!!
[^] # Re: L'avis de Linus
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Lorsqu'on veut utiliser un programme pour en faire du proprio et profiter du boulot des autres alors oui, la GPL est restrictive. Et tant mieux.
[^] # Re: L'avis de Linus
Posté par dinomasque . Évalué à 2.
Quand on veut comprendre ou lire jusqu'au bout sans s'endormir la licence de son logiciel alors oui la GPL est restrictive. Et tant pis ?
ou alors
Quand on veut utiliser du code libre dans une autre application libre sans risquer d'incompatibilité de licence alors oui, la GPL est restrictive. Et tant pis pour le créateur de logiciel libre.
BeOS le faisait il y a 20 ans !
[^] # Re: L'avis de Linus
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
C'est une blague ? T'as déjà lu une licence Microsoft ?
En verbosité, la GPL s'en tire bien, quand même !
Quand on veut utiliser du code libre dans une autre application libre sans risquer d'incompatibilité de licence alors oui, la GPL est restrictive. Et tant pis pour le créateur de logiciel libre.
Un exemple ? La GPL est compatible avec toutes les licences qui offrent au moins autant de liberté. Si c'est pour profiter à des softs qui offrent moins de liberté, alors OUI tant mieux si elle est restrictive.
[^] # Re: L'avis de Linus
Posté par reno . Évalué à 2.
Donc la GPL n'empeche pas les entreprises de contribuer, affirmer le contraire dans une FAQ c'est très, très tendencieux.
Il y a certes des exception notoires:
-Sun qui a volontairement créer une license incompatible avec l'existant GPL mais compatible avec les OS *BSD, mais est-ce a cause de la GPL ou bien de la concurrence avec RedHat et Novell?
-Microsoft: sans commentaire, enfin si un: l'opposition de Microsoft a la GPL est un très bon argument *en faveur* de la GPL.
Mais le fait demeure, le noyau qui a le plus de contributeurs est sous GPL..
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 2.
- Windows a des crash liés à la partie graphique : software buggué (driver) et parfois hardware défaillant (carte graphique).
- Linux a des crash liés à la partie graphique : software buggué (aucun driver linux n'est parfait, google t'aidera à trouver plein de monde qui ont eu des problème si c'est pas ton cas), et parfois hardware défaillant (carte graphique, qui sont les mêmes sous Linux et Windows il me semble)
- Les crash Linux et Windows (quand ils ne sont pas récupérés) sont tout aussi violents.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Je n'ai pas dit ça.
L'approche de Windows pour gérer les problèmes graphique doit-elle s'imposer à Linux comme tu l'"exige" ?
J'en doute. Les modèles de développement (produit vs projet ; proprio vs libre ; dictature vs ouverture), les racines (Unix/Posix vs Win32/COM, patch vs anti-virus) et les moyens (surtout pour ce qui est carte graphique et driver) n'ont rien à voir. Tu nies ces différences pour faire la conclusion qui te convient.
Les solutions MS s'imposeront d'autant plus à Linux qu'il n'y a pas de différence. Mais il y a des différences et elles sont énormes.
Ce n'est pas la première fois ni la dernière que tu nous imposes ça (nier les différences).
Tu veux valider la pertinence du choix de Microsoft avec Linux. C'est con, personne n'a remis en cause le choix de MS pour Windows.
Le choix d'avoir des anti-virus/malware pour Windows est peut-être très bien.
Ça ne veut pas dire que c'est un bon choix pour Linux.
Idem pour le choix de MS de récuperer au mieux les plantages graphiques.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 3.
C'est ce que tu laisses entendre en comparant voiture de compet et voiture "standard" : à part le fait qu'elles ne sont pas utilisées pour faire la même chose, je ne vois pas ce qu'apporte ta remarque dans ce cas.
Tu nies ces différences pour faire la conclusion qui te convient.
Tu me fais dire n'importe quoi pour conclure n'importe quoi.
Je ne dis absolument pas que le choix de MS concernant les barrières mises en place pour les drivers graphiques doit s'imposer à Linux.
Tout ce que je dis, c'est uniquement que les affirmations de Linus sont purement trollesque (la preuve en est notre conversation) et dénués de toute argumentation (la preuve en est tes tentatives d'argumentation), et en l'état tout simplement prétentieuses. Il y a 1000 raisons de ne pas faire pareil sous Linux, mais Linus n'en donne pas une seule.
Tu ne démontre à aucun moment que de telles barrières n'apporteraient rien à Linux : tout ce que tu dis c'est "ça a un coût non négligeable", ce qui est vrai, mais ca n'enlève en rien l'intérêt du truc.
Ce qui est sûr, c'est que Linux et Windows sont suffisament proches pour que, par nature (ce sont des composants conçus par des humains, donc buggués), les protections qui sont pertinentes pour l'un sont pertinentes pour l'autres, quand les symptômes sont identiques.
Ta comparaison avec les virus pourraient être pertinente, mais les symptômes ne sont clairement pas identique : Linux est pour de nombreuses raisons qu'on ne va pas énumérer ici, mais qui est vérifiable par simple mesure, moins sujet à des attaques par virus : la fréquence des symptômes ne sont clairement pas identiques. Concernant la partie graphique, ma petite expérience et celles de nombreuses autres personnes ici (ou google si t'as des doutes) montre que face aux bugs, Windows et Linux sont à la même enseigne.
Ton seul argument recevable, c'est le coût. Et c'est pas celui de Linus.
Bon alors maintenant j'arrête ou alors on fait abstraction des propos de Linus et on essai de voir en quoi ce ne serait pas pertinent de mettre ces barrières sous Linux (en dehors du coût, qui est un argument qui peut vite s'effacer si un "dictateur" dit que "c'est la voie").
Ce qui me fait rire, c'est que je ne doute pas un instant que dans les années à venir nous allons voir ce type de barrière sous Linux, avec des drivers qui se retrouvent "isolés" du noyau pour des question de fiabilité/stabilité/sécurité. Et là comme par hasard, le discours sera tout autre, les moyens seront apparus par miracle, et ca sera même ouachement mieux que ce que propose Microsoft.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Admettons.
> C'est ce que tu laisses entendre en comparant voiture de compet et voiture "standard" : à part le fait qu'elles ne sont pas utilisées pour faire la même chose, je ne vois pas ce qu'apporte ta remarque dans ce cas.
Tu changes ta façon de raisonné au cas par cas.
On peut dire qu'une voiture et un avion servent à la même chose : se déplacer.
On peut dire que Windows et Linux servent à la même chose : utiliser des programmes, le hardware.
On peut dire qu'un voiture et un avion ne servent pas à la même chose : l'un est pour se déplace sur terre et l'autre dans les airs.
On peut dire que Windows et Linux ne servent pas à la même chose : l'un est pour utiliser des programme Windows, l'autre des programmes Linux/Unix.
Les deux sont vrais, ça dépend à quelle distance on se met.
De loins Windows et Linux c'est la même chose. De prêt, non.
Quand on considère la mise en oeuvre de la partie graphique de Windows ou Linux, on n'est pas dans une perspective lointaine, on est dans les détails. Dans les détails Windows et Linux n'ont pas grand chose à voir.
> Je ne dis absolument pas que le choix de MS concernant les barrières mises en place pour les drivers graphiques doit s'imposer à Linux.
Mouaif.
De toi :
la complexité de ces drivers est croissante (ex : les drivers graphiques), et ca paraît un peu dépassé comme conception de croire qu'on peut faire tourner ce joli monde sans barrière avec le même niveau de fiabilité.
Mais il est vrai que plus tard tu étais plus flou.
> Tu ne démontre à aucun moment que de telles barrières n'apporteraient rien à Linux : tout ce que tu dis c'est "ça a un coût non négligeable", ce qui est vrai, mais ca n'enlève en rien l'intérêt du truc.
De quel intérêt ?
Sur le papier il y a un intérêt. Oui indiscutablement.
Mais dans la pratique, quand il faut implémenter (et batailler avec du vrai code et pas seulement faire un joli schéma), quand il faut prendre en compte les ressources disponibles, etc c'est beaucoup plus discutable.
Sur le papier les micro-noyau c'est bien.
Pourtant Hurd a eu plus de moyen que Linux à ses débuts et est un échec (je ne crois pas que le mot soit trop fort).
Pourtant il y a eu OSF/1 qui est devenu un noyau hybride.
Pourtant MS devait faire un micro-noyau et a fait un noyau hybride.
Pourtant Apple a pris un micro-noyau pour faire un noyau hybride.
Linus avance des arguments (que tu ne veux pas entendre). L'histoire (et MS :-)) donne raison Linus. Mais qu'importe pour toi, tu trouves Linus prétentieux, sans arguments etc.
Tu ne crois pas que tu pousses le bouchon un peu loin ?
> Ce qui est sûr, c'est que Linux et Windows sont suffisament proches pour que, par nature (ce sont des composants conçus par des humains, donc buggués), les protections qui sont pertinentes pour l'un sont pertinentes pour l'autres, quand les symptômes sont identiques.
Sûr ?
Quel argument tu avances pour dire ça ?
Que de loin Windows et Linux c'est la même chose et conçu par des humains. C'est maigre.
> les protections qui sont pertinentes pour l'un sont pertinentes pour l'autres, quand les symptômes sont identiques.
Symptômes : ma bécane est crackée.
Solutions Windows : un anti-virus
Solutions Linux : blinder la sécurité
Dans le principe, ton raisonne se tient. Mais seulement dans le principe en faisant fi de tout un tas de détail dont l'ensemble n'est plus du tout un détail.
> Ta comparaison avec les virus pourraient être pertinente, mais les symptômes ne sont clairement pas identique : Linux est pour de nombreuses raisons qu'on ne va pas énumérer ici
Marrant.
Pour de nombreuses raisons que tu veux bien voir dans le cas des anti-virus mais pas dans le cas des barrières.
> [Linux est] moins sujet à des attaques par virus
Intéressant non ?
En fait, Linux est sujet à des attaques de virus. Mais Linux n'a pas de virus.
Linux veut être moins sujet aux plantages graphiques. Il ne veut pas les gérer comme MS gère les virus avec un anti-virus.
Que Linux ait moins (voire pas) de virus n'implique pas que les virus ne soient pas une haute préoccupation de Linux. Bien au contraire. Jamais Linux n'aura un navigateur avec ActiveX ou équivalent, par exemple, afin éviter les virus. Plein de décisions sont prises pour éviter les virus.
Accèpter les virus est un choix de concèption de Windows (c'est de moins en moins vrai). Accèpter le support ActiveX dans IE est un choix que MS savait favorable aux virus (ou alors MS est bien con).
J'imagine, car je ne suis pas dans le secret des "dieux", que MS a fait un choix de concèption pour les cartes graphiques qui rend nécessaire un système de récupération. Peut-être pas un choix direct, MS c'est peut-être rendu compte trop tard que son système graphique est trop complexe pour que la fiabilité soit satisfaisante. Où peut-être qu'il y a des races conditions que MS n'a peu corriger. Mais au-lieu de corriger le problème en amont, MS a fait un système de récupération.
Il est aberrant, notamment vu les moyens de MS, que les pilotes graphiques Vista plantent pratiquement chez tout le monde (tu le confirmes) sans que ça soit "accèpté" par MS. Faire un système de récupération le montre.
Linux ne veut pas se retrouver dans une situation où les plantages graphiques sont le lot de tout le monde. Linux ne veut pas se retrouver dans l'obligation de faire un système de récupération. Peut-être que les choix de Linux ne permettra pas de rivaliser avec certains rafinements de Windows (comme FF c'est passé du "rafinement" d'avoir ActiveX). Mais j'ai foutrement du mal à croire que Linux (sa communauté) accèpte de faire un truc qui crée des plantages chez pratiquement tout le monde.
> Concernant la partie graphique, ma petite expérience et celles de nombreuses autres personnes ici (ou google si t'as des doutes) montre que face aux bugs, Windows et Linux sont à la même enseigne.
Et ?
> Ton seul argument recevable, c'est le coût.
C'est important.
> Et c'est pas celui de Linus.
C'est aussi, en parti, celui de Linus.
Il dit que c'est passablement compliqué, ce qui est compliqué est cher. Ça doit être la troisième fois que je dis grosso-modo ça, mais tu fais exprès de ne pas entendre manisfement.
> en dehors du coût, qui est un argument qui peut vite s'effacer si un "dictateur" dit que "c'est la voie"
Si ce "dictateur" à la fortune de Microsoft...
Hurd est la volonté de la FSF et RMS, c'était "la voie", Hurd a eu des moyens respectables (supérieurs à ceux de Linux à ses débuts), ben Hurd n'a pas marché.
La voie de Windows NT était un micro-noyau ... Tu connais la suite et ça ne te met toujours pas la puce à l'oreille.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 3.
De toi :
la complexité de ces drivers est croissante (ex : les drivers graphiques), et ca paraît un peu dépassé comme conception de croire qu'on peut faire tourner ce joli monde sans barrière avec le même niveau de fiabilité.
Oué bah oué, c'est pas contradictoire : je persiste à croire que ces barrières apportent un bénéfice en terme de fiabilité/stabilité, concrêtement à Windows aujourd'hui, pourquoi pas à Linux demain. C'est pas pour ça que je dis que c'est une nécessité et une voie obligatoire que doit prendre Linux. Y'a peut être d'autres priorités, d'autres paramètres, etc. Mais nié que ca pourrait avoir un impact sur la fiabilité/stabilité comme le fait Linus, c'est malhonnête envers les gens qui ont des expériences concrêtes à des années lumières de ses affirmations.
Linus avance des arguments (que tu ne veux pas entendre).
Si tu peux les répéter, les siens, pas les tiens, avec citation, je veux bien.
Que de loin Windows et Linux c'est la même chose et conçu par des humains. C'est maigre.
ben c'est pourtant fondamentalement ce qui les rapproches sur un point essentiel : la fiabilité. Aucun driver ne peut se prétendre "sans bug", encore moins vu la complexité des drivers graphiques. De plus je l'ai déjà dis, les cartes graphiques ne sont pas exempts de bug non plus, et je vois pas comment Linux peut "améliorer" ce problème.
Pour de nombreuses raisons que tu veux bien voir dans le cas des anti-virus mais pas dans le cas des barrières.
Les faits, bordel, les faits :
- Un Windows se fait défoncer la tête en quelques minutes connecté à Internet sans protection. Linux tient de nombreux jours.
- Un Windows crash de temps à autre à cause du driver graphique. Idem sous Linux. Si t'y crois pas, google.
Les symptômes sont clairement pas identique, il est donc normal qu'on adapte les solutions. Concernant les drivers graphiques, jusqu'à preuve du contraire, un Linux est pas mieux loti qu'un Windows (de ma pauvre expérience et de l'expérience d'autres utilisateurs).
Plein de décisions sont prises pour éviter les virus.
Comme éviter d'avoir plus d'1% de parts de marché ? \o/ humour humour
que MS a fait un choix de concèption pour les cartes graphiques qui rend nécessaire un système de récupération.
C'est pas MS qui conçoit les cartes graphiques il me semble.
que les pilotes graphiques Vista plantent pratiquement chez tout le monde (tu le confirmes) sans que ça soit "accèpté" par MS.
Comme quoi c'est un problème insolvable, même avec les moyens de MS. Alors je vois pas comment sous Linux ils vont y arriver.
Que MS l'accepte ou non, quand la carte graphique bug (ca arrive hein, ca chauffe ces conneries), ben t'auras beau mettre toute la qualité dans le code que tu veux, boum.
Linux ne veut pas se retrouver dans une situation où les plantages graphiques sont le lot de tout le monde.
Vouloir c'est une chose, pouvoir en est une autre. Là encore, c'est de la prétention : croire qu'on va faire mieux que MS, avec comme tu le dis si bien, beaucoup moins de moyens, des specs de cartes graphiques incomplètes, du matos "grand public" et donc à la fiabilité "grand public".
Ça doit être la troisième fois que je dis grosso-modo ça, mais tu fais exprès de ne pas entendre manisfement.
Mais j'entend très bien tes propos, qui ne sont pas ceux de Linus. T'essai juste de justifier son absence d'argumentation en inventant la tienne.
La voie de Windows NT était un micro-noyau ... Tu connais la suite et ça ne te met toujours pas la puce à l'oreille.
Gni ? WinNT a toujours été un noyau hybride.
Enfin en tout cas tu rejoins quelque part Linus : tu sembles persuadé que y'a pas besoin de barrière, suffit de faire du code de meilleur qualité. Prétention quand tu nous tiens...
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 1.
patrick_g a donné deux liens, il te suffit de les lire.
Le problème est que tu réfutes l'argument de la complexité ou de la charge de travail. M'enfin, ça varie selon tes postes.
Tant que tu nies le problème de la complexité (et des moyens), tu diras que les arguments de Linux sont nuls. Pire, tu diras qu'à chaque problème il y a une solution du moment qu'on veut les surmonter (suffit d'un dictateur et d'une voie comme tu dis). Du moins je suppose, c'est l'impression que tu m'as donné.
> ben c'est pourtant fondamentalement ce qui les rapproches sur un point essentiel : la fiabilité.
Je ne comprend pas.
> De plus je l'ai déjà dis, les cartes graphiques ne sont pas exempts de bug non plus, et je vois pas comment Linux peut "améliorer" ce problème.
Sur quoi tu fais cette affirmation ?
Rien.
Certes Linux sucks actuellement au niveau graphique pour des raisons que j'ai déjà donnée. M'enfin, si tu suis l'actualité Linux tu ne peux nier que les choses ont beaucoup changéee. Le travail d'une fiabilisation en profondeur va commencer (l'architecture se stabilisant (enfin)).
> Comme éviter d'avoir plus d'1% de parts de marché ? \o/ humour humour
Même si c'est de l'humour, c'est assez fondé.
MS a fait des choix riqués, voire con (d'où les virus) mais qui ont séduit le public.
Ce sont des hommes qui font Windows et Linux, mais pas les mêmes, qui ne pensent pas pareil.
> Comme quoi c'est un problème insolvable
Si tu le "décrètes", alors affectivement tu as besoins d'un système de récupération.
Il y a des tonnes de bécane sous Linux qui tourne des jours, des mois, sans le moindre plantage graphique. Sous Windows avec Vista ça n'existe plus (pourtant ça existait avec XP...).
Ceux qui font de la CAO sous Unix n'ont aucun problème et n'envisage même pas qu'il puisse y avoir un problème graphique.
Avant on nous expliquait que Linux (ou FF) allait avoir des virus car Windows avait des virus et c'était inéluctable. C'était des foutaises.
Maintenant que Windows a fait un truc graphique qui plante tous les jours, on veut nous perçuader que ça va être de même pour Linux.
FOUTAISES !
> même avec les moyens de MS
Je n'ai pas parlé d'un problème de moyen pour MS, mais d'un choix de MS. Comme MS a fait le choix d'un OS "pourri" qui demande un anti-virus (choix que n'a pas fait Linux/Unix), MS a fait le choix d'une achitecture graphique qui demande un système de récupération.
Système trop compliqué ? Race conditions ? Je n'en sais rien. Mais une architecture graphique qui plante tous les jours chez tout le monde, même si c'est récupérable, est une architecture qui sucks.
> Alors je vois pas comment sous Linux ils vont y arriver.
Comme Linux (ou FF) est arrivé à ne pas avoir de virus alors que les fans Windows disait qu'obligatoirement Linux (ou FF) allait avoir des virus.
> Que MS l'accepte ou non, quand la carte graphique bug (ca arrive hein, ca chauffe ces conneries), ben t'auras beau mettre toute la qualité dans le code que tu veux, boum.
Avant Vista, il n'y avait pas de boum du driver graphique tous les jours sur pratiquement tous les PC.
> Là encore, c'est de la prétention
Non.
> croire qu'on va faire mieux que MS
Linux a fait mieux que MS pour les virus. Linux fait mieux pour la virtualisation. Linux fait mieux pour les serveurs.
Ce que Linux ne peut pas faire mieux que MS, c'est de concurrencer MS dans son modèle de développement. Or ce que tu veux est que Linux suive le modèle de développement de MS en bossant sur des trucs foutrement compliqué. T'es un malin :-)
> beaucoup moins de moyens, des specs de cartes graphiques incomplètes, du matos "grand public" et donc à la fiabilité "grand public".
Donc Linux ne doit pas faire comme Windows. Merci pour la démonstration.
> Mais j'entend très bien tes propos, qui ne sont pas ceux de Linus.
Exemple :
So in a traditional kernel, you usually would share the
address space, but you'd have protection issues and some
semantic differences that mean that the kernel and user
space can't access each other freely. And that makes for
some really big issues, but a traditional kernel very much
tries to minimize them. And most importantly, a traditional
kernel shares the access space across all the basic system
calls, so that user/kernel difference is the only
access space boundary.
Now, the real problem with split access spaces is
not the performance issue (which does exist), but the
much higher complexity issue. It's ludicrous how micro-
kernel proponents claim that their system is "simpler" than
a traditional kernel.
The fundamental result of access space separation is that
you can't share data structures. That means that you can't
share locking, it means that you must copy any shared data,
and that in turn means that you have a much harder time
handling coherency. All your algorithms basically end up
being distributed algorithms.
And anybody who tells you that distributed algorithms
are "simpler" is just so full of sh*t that it's not even
funny.
Microkernels are much harder to write and maintain
exactly because of this issue.
Mais j'image que pour, par exemple, "distributed algorithms", tu vas dire que ce n'est pas compliqué du moment qu'on l'a fait une fois, etc blablabla.
Linus a argumenté et l'histoire lui donne raison.
> Prétention quand tu nous tiens...
Tu peux me traiter de prétentieux. Mais traiter Linus de prétentieux...
Je te fais le pari que Linux ne plantera pas tous les jours ni tous les mois pour les cartes supportés (Intel et ATI).
En passant, j'ai aussi un hp6530b (puce intel), le driver Windows plante toutes les semaines, mais sous Linux j'ai 0 problème.
J'ai le driver nouveau chez moi depuis 1 ans et j'ai 0 problème (OK, je n'ai pas de 3D).
Arrête de faire croire que les plantages de carte graphique va être le lot de tout le monde, surtout depuis que c'est le lot de Vista...
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 2.
Forcement, on fait pas tourner FutureMark2012 GPU overclock edition sur un serveur de prod ^^
Avant on nous expliquait que Linux (ou FF) allait avoir des virus car Windows avait des virus et c'était inéluctable. C'était des foutaises.
Ben Linux a toujours 1% de part de marché, donc bon normal que ca change pas. Pour FF, on voit clairement qu'il y a une évolution avec ses parts de marché : le nombre de failles critiques qui le concerne devient largement comparable à IE, les "barrières" anti-neuneu font leurs apparitions avec des voyants rouges dans tous les sens, des addons plus que douteux apparaissent, etc.
Ceux qui font de la CAO sous Unix n'ont aucun problème et n'envisage même pas qu'il puisse y avoir un problème graphique.
Jusqu'au jour où z'ont un problème :) Et puis bon, je suppose que tu parles de stations graphiques "pro" ala SGI, des trucs qui tournent avec du matériel spécialisé, fiable. Pas une carte 3D de supermarché que tu fais chauffer à coup de jeux ou effets compiz à la con.
Maintenant que Windows a fait un truc graphique qui plante tous les jours, on veut nous perçuader que ça va être de même pour Linux.
FOUTAISES !
Mais y'a des gens qui ont Windows sans bug graphiques (genre moi j'en ai pas eu depuis 2 ou 3 mois, depuis que je joues plus à Simcity). Et y'a des gens qui ont des bugs graphiques sous Linux.
Sous Windows avec Vista ça n'existe plus
FOUTAISES ! :-p
Avant Vista, il n'y avait pas de boum du driver graphique tous les jours sur pratiquement tous les PC.
Faut que t'arrête de fumer, c'est pas parcque ca arrive à certains utilisateurs qu'il faut généraliser !
Comme MS a fait le choix d'un OS "pourri" qui demande un anti-virus (choix que n'a pas fait Linux/Unix)
Joli troll, mais branle toi la nouille avec argument, tant qu'on aura pas des parts de marché comparable entre les 2 OS, on pourra jamais vérifier les dires des uns et des autres.
Système trop compliqué ? Race conditions ? Je n'en sais rien.
C'est ça ton problème, c'est que tu n'y connais rien, donc tu supposes, tu affirmes, et conclus.
Windows a fais une refonte de son architecture de driver graphique pour Vista. Si cette architecture s'appui sur un système de récupération, c'est à cause de constats fait sous XP : les drivers sont la cause principal des crashs sous cet OS.
Comme Linux (ou FF) est arrivé à ne pas avoir de virus alors que les fans Windows disait qu'obligatoirement Linux (ou FF) allait avoir des virus.
FF est autant une porte ouverte aux virus que IE, IE n'est plus la passoir qu'il était, et FF a des parts de marché qui le mette en position d'être un vecteur comme IE. Dans tous les cas les virus attaquent l'OS derrière, et la plupart d'entre eux utilisent les failles dans le l'interface chaise/clavier.
Linux a fait mieux que MS pour les virus.
Méthode Coué c'est ca ?
Donc Linux ne doit pas faire comme Windows. Merci pour la démonstration.
Ben au contraire : je montre qu'il y a pleins de facteurs qui montre qu'il est loin d'être évident de faire des drivers de qualité pour Linux... donc qu'une barrière n'est pas négligeable.
Microkernels are much harder to write and maintain
exactly because of this issue.
Oué bah oué, d'où les kernel hybrides, plus pragmatiques :)
Linus a argumenté et l'histoire lui donne raison.
L'histoire lui donne au contraire tord :
- Vista a moins de plantage graphiques grâce à son nouveau système de récupération
- Linux fait face à un beau bordel actuellement pour la partie graphique.
Bon allez stop j'arrête ca devient lourdingue, on changera pas de position ni l'un ni l'autre :)
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Marrant, tu nies les différences entre Windows et Linux, mais ici tu t'empresses de tout mettre sur le dos d'une différence.
Où est le "Windows et Linux sont faits par des humains et c'est une justification suffisante pour dire qu'ils sont pareils ou du moins demandent les mêmes solutions" ? Il a disparu dans le cas des virus. Ces dernièrs sont faits par des mutants, c'est connu, et ils ne s'intéressent qu'à Windows et aux virus.
> C'est ça ton problème, c'est que tu n'y connais rien, donc tu supposes, tu affirmes, et conclus.
Admettons, mais toi tu fais pareil alors.
> Oué bah oué, d'où les kernel hybrides, plus pragmatiques :)
Si tu vas par là alors Linux est un noyau hybride puisqu'il y a fuse.
> > Donc Linux ne doit pas faire comme Windows. Merci pour la démonstration.
> Ben au contraire
Que non. Voir Novell qui couche avec MS, qui s'éreinte à courrir àprès Windows, et ça ne lui apporte rien.
Le Windows touch avec Linux n'est pas bon.
> L'histoire lui donne au contraire tord :
> - Vista
L'une des caractéristiques des micro-noyau est d'avoir très peu de code qui s'exécute en en mode privilégié. La majorité du code noyau de Vista doit s'exécuter en mode privilégié et dans le même espace d'adressage. Bref, Vista reste un plébiscite pour les noyau monolithique.
[^] # Re: L'avis de Linus
Posté par Anonyme . Évalué à 3.
Si c'est vrai c'est une avancé et chose que je suis sur que j'aimerai avoir dans linux. 90% du temps les problème que j'ai sont lié aux drivers graphiques et j'utilise la version libre et ils ont la doc, maintenant, mais bon cela continue à freezer sur certaines applications (la plus classique étant googlearth). Après les moyens, la façon dont c'est développé on s'en tape pas mal. Microsoft malgré tous ses moyens à pris 4 ans de retard et a sorti un OS plus que moyen dont personne ne veut.
[^] # Re: L'avis de Linus
Posté par Krunch (site web personnel) . Évalué à 0.
Quel rapport ? La licence de Firefox c'est la MPL.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 3.
Tu disais que Vista arrivait à se démerder avec des drivers pas terrible. Ce n'est pas le cas ?
Faut croire que non.
> Heuresement, le kernel Linux, lui il sait gérer ça.
Ce n'est pas ce que j'ai dit.
> C'est pour cela qu'on a pas besoin de barrière, les drivers graphiques sous linux qui plantent, ca n'existe pas, car Linux sait gérer la qualité.
Ce n'est pas ce que j'ai dit, je n'ai pas caché qu'il y avait des problèmes avec Linux.
Mais pour toi, avec Windows et ses barrières magiques il n'y a pas de problème.
Avec Vista on ne doit avoir un plantage à cause d'un driver, on ne doit pas avoir ça :
http://www.youtube.com/watch?v=zFx62_Iadjg
Ooops.
Si tu trouves que les barrières sont indispensables, mets des barrières pour la pile TCP/IP (si elle plante elle est déchargée et rechargée), sur le FS, sur lvm, etc.
Si on a des moyens infinis, autant faire des barrières, des tests exhautif de regression systématique, etc.
Ce n'est pas le cas de Linux.
Windows avec ses mignonnes barrières et ses moyens délirants ne plante pas moins qu'un Linux.
Tu m'expliques ça ?
En tout cas Linus donne une très bonne explication (c'est le commentaire un peu plus haut si tu l'as raté).
Ce n'est pas car Linux n'a pas des mignonnes barrières que Linux est fragile au moindre problème matériel ou de driver. On est nombreux a avoir eu un problème de driver ou hard sans que ça plante tout le reste. On est nombreux à faire tourner Xorg des semaines de suite sans problème. Un driver merde, on le corrige. On ne met pas 20 ingénieurs à plancher durant 2 ans pour faire un truc qui atténu le problème. Linux préfère corriger directement le problème.
> > Je ne crois pas que le driver soit déchargé et rechargé à la volé.
> Si.
Ça m'étonnerais grave mais admettons.
> Ce qui était également le cas de XP.
C'est toujours le cas avec Vista. Un driver graphique mal écrit peu faire planter Vista.
> mais la capacité au projet dans son ensemble à croire qu'il est possible de maintenir un aussi grand nombre de drivers de qualité, sans avoir besoin de mettre de barrière.
En quoi ajouter des barrières va aider à maintenir plus de driver. Je ne vois pas ou tu veux en venir.
C'est même le contraire. Avec les barrières il y a plus de complexité et il faut plus de moyen pour maintenir l'ensemble.
> Désolé, c'est le problème de Linux. C'est lui qui fourni l'infrastructure pour les drivers, et c'est de sa faute si un driver a un impact aussi important qu'un crash d'une application voir le plantage total du kernel.
Je suis d'accord avec ça, mais le problème de Linux n'est pas l'absence de barrière (Vista avec des barrières plante aussi), mais principalement le manque de moyen (peu de soutient des fabriquants de hardware) et qu'actuellement la partie graphique de Linux est en plein bouleversement.
Je dois insister sur les faibles moyens de Linux. Compte tenu des failbles moyens et qu'il y a des priorités très élevées (virer nv pour utiliser Nouveau, finaliser KMS, virer les vieilleries dans Xorg, etc), ajouter des barrières n'apporte pratiquement rien et ne va pas résoudre ces problèmes. Si le driver Nouveau ne gère pas la carte bidule, ajouter des barrières ne va pas ajouter le support de la carte bidule et donner un support nickel 3D pour les cartes NVidia.
Même si la situation était bonne chez Linux, je ne suis pas convaincu que d'ajouter des barrières serait un plus significatif. Ça complexifie beaucoup, etc.
> Y'a des solutions pour limiter l'impact de ces problèmes
Quand un driver ne marche pas, il ne marche pas. Ajouter des barrières n'y changera rien. Je suis sûr qu'on va assiter à une amélioration énorme de la qualité globale de Linux sur la partie graphique dans les quelques mois à venir (au moins pour Intel et ATI). Et ça sera sans barrière.
> les micro-noyaux sont une partie de cette solution, il paraît donc un brin prétentieux de la part de Linus de dire que ces solutions n'apportent rien au niveau qualité. La stabilité est une qualité.
T'es bien prétentieux de contredire Linus.
> Je penses pas que ce soit une question de moyen.
Dit le à MS. MS sera content de savoir qu'il a des économies à faire.
Dit le à Hurd qui après des années et des années n'arrive toujours pas à décoller.
Dit le à Minix qui cherche ici des développeurs.
Etc.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 2.
Désolé, c'étais juste du sarcasme.
Mais pour toi, avec Windows et ses barrières magiques il n'y a pas de problème.
Jamais dis ça. Juste que c'est mieux, personne ne prétend que c'est magique. Y'a encore plein d'effort à faire pour sortir des trucs en userland, que ce soit dans le kernel NT que Linux.
Ooops.
Bah oué, c'est comme les capotes hein, c'est pas magique, des fois ça marche pas, faut-il pour autant s'en passer ? A part par conviction religieuse (Linus l'a dit : ca ne sert à rien)...
i tu trouves que les barrières sont indispensables, mets des barrières pour la pile TCP/IP (si elle plante elle est déchargée et rechargée), sur le FS, sur lvm, etc.
Ben oué et pouquoi pas ? C'est ce que fait minix pour TCP/IP, c'est ce que fait fuse pour les FS, c'est ce qu'explore MS avec Singularity, etc. En fait tout le monde est d'accord sur le principe, le seul soucis, c'est l'existant : pour des questions de performances (et pour pas se faire chier à s'enmerder), on a mis pleins de trucs prêt du kernel, trop prêt. Même dans Vista pour les drivers graphiques c'est pas "parfait", y'a encore un bout qui tourne avec les droits du kernel, mais l'objectif est clairement de limiter au maximum la quantité de code qui tourne dans cet espace.
Ça m'étonnerais grave mais admettons.
Mais où est la difficulté ? Même le kernel Linux est capable de charger et décharger dynamiquement des modules ! La seule différence, c'est dans quel espace ils tournent...
"If a WDDM driver hangs or encounters a fault, the graphics stack will restart the driver. A graphics hardware fault will be intercepted and if necessary the driver will be reset. Drivers under Windows XP were free to deal with hardware faults as they saw fit either by reporting it to the user or by attempting to recover silently. With a WDDM driver, all hardware faults cause the driver to be reset and the user
will be notified by a popup; this unifies the behavior across vendors."
http://en.wikipedia.org/wiki/Windows_Display_Driver_Model
En quoi ajouter des barrières va aider à maintenir plus de driver. Je ne vois pas ou tu veux en venir.
Mais je prétend pas que ca va aider à maintenir plus de driver, je dis juste que ca va éviter à un driver buggé (aucun driver n'est exempt de bug) de faire tomber le système.
mais le problème de Linux n'est pas l'absence de barrière (Vista avec des barrières plante aussi)
Argument totalement fallacieux. La question n'est pas de savoir si ca plante ou non : aucune protection n'est parfaite, aucun logiciel et donc barrière logicielle n'est exempt de bug et de plantage.
Ce qui est sûr, c'est que dans la vraie vie, de nombreux plantage de driver graphique sous Vista sont récupérés proprement. C'est autant de plantage en moins : la barrière montre tout son intérêt.
ajouter des barrières n'apporte pratiquement rien et ne va pas résoudre ces problèmes.
On est d'accord, y'a un problème de moyen, faut faire des priorités, je ne remets même pas en cause ces choix de priorité (je préfères avoir Nouveau on est d'accord). Mais affirmer comme le fait Linus que ca sert rien, que c'est inutile, c'est du foutage de gueule.
Avec les barrières il y a plus de complexité et il faut plus de moyen pour maintenir l'ensemble.
Ca a un coût et demande des moyens pour être mis en place, certes. Mais c'est pas "plus complexe" pour moi. Une fois mis en place, c'est pas plus dur à maintenir. Le plus dur, c'est la transition avec l'existant. C'est d'ailleur pourquoi tous les projets de kernel comme Hurd Mach ou Minix vont direct sur ce type de segmentation : c'est pas plus dur, parcqu'ils s'enmerdent pas avec l'existant.
Quand un driver ne marche pas, il ne marche pas.
Encore une fois, c'est pas une question de "ca marche"/"ca marche pas". C'est des logiciels informatiques : y'a des bugs, qui apparaîssent dans certaines conditions, pas chez tout le monde, avec une fréquence plus ou moins élevée, ca peut aussi être un problème hardware ponctuel, etc.
Faut s'y faire, rien n'est parfait. Les barrières permettent juste à l'utilisateur de ne pas vivre une mauvaise expérience au moment où ca part en vrille.
Je suis sûr qu'on va assiter à une amélioration énorme de la qualité globale
Quand la solution concurrente améliore la qualité de son système, c'est pas possible puisque "ca marche ou ca marche pas". Et là tout à coup c'est l'inverse ? :)
T'es bien prétentieux de contredire Linus.
Ah oui on peut pas contredire le pape. C'est vrai que Linus n'est pas du tout réputé pour être un trolleur aux idées bien arrêtés. C'est pas parcqu'ils a de nombreuses qualités (techniques et leadership) qu'il a la vérité absolue.
Dit le à MS. MS sera content de savoir qu'il a des économies à faire.
Ben infine, pour MS, le but est de limiter les coûts de maintenance/support et d'image : quand l'OS tombe à cause d'un driver, l'utilisateur il voit un écran bleu et peste après Microsoft. Là MS se "protège" des drivers qu'il ne maîtrise pas : au final ils font des économies.
De toute façon je suis bien d'accord que c'est en partie un problème de moyen. Mais quand le chef dit que de toute façon ca sert à rien, la question des moyens se pose même pas puisque le chef a dit.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
> Ben oué et pouquoi pas ?
Si c'est si indispensable que ça, pourquoi ça n'a pas été fait ?
Depuis combien de temps existe Windows ?
Oublions Win16 et Win 9*. Mais le noyau d'aujourd'hui descend directement de Windows 2000. En presque 10 ans ça n'a pas été fait alors que MS (ou que toi) ne juge que par les micro-noyau, n'y voit que des avantages, pense que ça ne demande pas plus de moyen à faire qu'un noyau classique, etc. Et en plus MS a des moyens délirant.
Expliques moi ça ?
> c'est ce que fait fuse pour les FS
Fuse c'est bien mais c'est lent et ça le restera très probablement.
> En fait tout le monde est d'accord sur le principe
Non. Sinon "tout le monde" dans le libre se serait précipité sur Minix ou Hurd. NB: ça existait avant que Linux soit commercialement utilisé.
> > Ça m'étonnerais grave mais admettons.
> Mais où est la difficulté ? Même le kernel Linux est capable de charger et décharger dynamiquement des modules !
Tu ne peux pas décharger un module Linux s'il est utilisé. En fait, on peut, mais s'il n'y a pas une explosion après, c'est un coup de chance. le "rmmod --force" n'est pas supporté (les rapports de bug sur ses conséquences seront refusés).
Le problème, à mon avis qui n'est pas celui d'un expert, n'est pas principalement côté noyau, mais côté userland. Les applis peuvent écrire directement dans la mémoire de la carte graphique (par exemple une texture) et surtout sans le savoir (avec Direct3D on sait que tout peu disparaitre à tout moment et donc le développeur le gère). Elles ont l'adresse de la texture et peuvent l'utiliser. Comment tu fais si tu vires tout le driver et donc tout ce qui a été alloué par la carte graphique ?
C'est de l'informatique on peut trouver une solution. Mais bonjour la quantité de boulot à faire seulement pour un gain théorique de fiabilité. Surtout que cette quantité de boulot serait plus efficace pour la fiabilité s'il était mis sur la fiabilité des drivers au-lieu de singer un micro-noyau.
> http://en.wikipedia.org/wiki/Windows_Display_Driver_Model
Cool.
Combien d'année homme il a fallu ? Linux préfère les mettre ailleurs.
> > mais le problème de Linux n'est pas l'absence de barrière (Vista avec des barrières plante aussi)
> Argument totalement fallacieux.
Il ne l'ai pas. Windows n'a pas de barrière pour TCP/IP, etc et si tu expliques pourquoi je ne vais pas rétorquer systématique "Argument totalement fallacieux".
Ici tu dis que MS n'a aucun excuse de ne pas avoir encore fait de barrière pour le réseau, les systèmes de fichier, etc.
Si Linux est un connard de ne pas l'avoir fait pour les cartes graphiques, MS est un double connard. MS croit aux barrières, Linux non (et donc n'est pas un double connard).
> C'est autant de plantage en moins : la barrière montre tout son intérêt.
Je vais me répéter, je n'ai pas dit que ce n'était pas bien, mais que :
1- dans le cas de Windows un driver graphique peut toujours faire plante tout le système
2- Linux a d'autres priorités
> On est d'accord, y'a un problème de moyen, faut faire des priorités, je ne remets même pas en cause ces choix de priorité (je préfères avoir Nouveau on est d'accord).
Merci.
> Mais affirmer comme le fait Linus que ca sert rien, que c'est inutile, c'est du foutage de gueule.
Windows n'a pas un micro-noyau. Répète après moi et lentement : "Win-dows n'a pas un mi-cro-noy-au".
Certes on trouve des trucs qui ressemble à un micro-noyau mais Windows n'a pas fait, ni le peu, la démontration qu'un micro-noyau est mieux qu'un noyau classique.
> c'est du foutage de gueule.
Le foutage de gueule, c'est toi qui le fait. Tu dis que les micro-noyau c'est mieux, que ça ne demande pas de moyen suplémentaire pour les faire, pousse Windows comme exemple de micro-noyau alors que ce n'est pas un micro-noyau, pire, tu dis que tout le monde est d'accord sur ça, mais ... il n'y a pas de micro-noyau de qualité pour les OS généraliste.
Pour le foutage de gueule, tu sais y faire.
De loins la théorie peut te donner la raison, mais l'histoire donne raison Linus et la position de Linus s'est faite avant que l'histoire en est jugé.
> Ca a un coût et demande des moyens pour être mis en place, certes.
C'est bien de le reconnaitre enfin. Merci.
> C'est d'ailleur pourquoi tous les projets de kernel comme Hurd Mach ou Minix vont direct sur ce type de segmentation : c'est pas plus dur
Hurd a 18 ans ! Hurd a débuté avant Linux ! Soyons gentil, en même temps que Linux.
Je ne sais pas exactement dans quel état il est, mais je ne serait pas étonné qu'il soit aujourd'hui moins fonctionnel qu'un Linux 2.0 qui est sorti il y a plus 10 ans.
Bref, tu dis n'importe quoi.
> Quand la solution concurrente améliore la qualité de son système, c'est pas possible puisque "ca marche ou ca marche pas". Et là tout à coup c'est l'inverse ? :)
Tu refuses de considérer l'ensemble du problème. Un projet n'est pas que la somme des atouts théorique loin des réalités. Un projet est un compromis entre différentes contraintes et c'est l'équilibre du tout qui fait la qualité du projet. Les micro-noyau, théoriquement et sans considérer les contraintes (complexité, difficulté à optimiser), c'est bien. Mais un projet qui n'est maîtrisé que par une poignée de personnes et accèpte une pénalité en performance de 30 % (a performance équivalente il faut acheter du matos plus cher) pour éviter un plantage pour les 36 du mois à quelques bécanes non critiques est un mauvais projet.
> > T'es bien prétentieux de contredire Linus.
> Ah oui on peut pas contredire le pape.
Rires. C'est toi qui traitait Linus de prétentieux :
- "il paraît donc un brin prétentieux de la part de Linus"
Linus est un pointeur et tu lui fais la leçon.
C'est mortel de rire.
> Ben infine, pour MS, le but est de limiter les coûts de maintenance/support et d'image : quand l'OS tombe à cause d'un driver, l'utilisateur il voit un écran bleu et peste après Microsoft. Là MS se "protège" des drivers qu'il ne maîtrise pas : au final ils font des économies.
Avec l'historique de Windows, il y a de quoi rire.
Si MS était si soucieux des désagréments des utilisateurs, MS n'aurait pas fait la niche a virus qu'est Windows (ou IE ou Outlook etc).
Les choses s'arrange (très lentement), mais pitié, ne nous fait pas du violon.
> Mais quand le chef dit que de toute façon ca sert à rien, la question des moyens se pose même pas puisque le chef a dit.
C'est du libre. Si le chef déconne, il est viré. Linus ne sait pas auto-proclamé chef, les développeurs l'y ont mis et il a largement fait ses preuves comme "dictateur" (d'une dictature douce sinon il est viré) d'un des projets les plus regardé et dont les enjeux sont énormes.
Que tu ne sois d'accord avec lui, OK, mais tu lui dois plus de respect et aussi aux développeurs qui accèptent librement (contrairement aux développeurs Windows) d'avoir Linus comme "dictateur".
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 2.
Parcque je l'ai déjà dis : y'a l'existant. Changer a un impact non négligeable sur les mentalités, sur les coûts, etc.
Combien d'année homme il a fallu ? Linux préfère les mettre ailleurs.
Cet argument est recevable. Bien plus que celui de Linus qui est "de toute façon ca sert à rien c'est nul", qui est le seul objet de ma critique.
Windows n'a pas un micro-noyau. Répète après moi et lentement
J'ai jamais dis que c'était un micro-noyau. C'est un espèce de truc hybride, qui récupère certains concepts des micro-noyau, et forcé de reconnaître que le chemin pris par MS va dans le sens des micro-noyaux là où Linux poursuit son chemin dans la direction opposée.
Le foutage de gueule, c'est toi qui le fait. Tu dis que les micro-noyau c'est mieux, que ça ne demande pas de moyen suplémentaire pour les faire
Ah bah non en fait, c'est toi qui qui le fait le foutage de gueule :) J'ai écris noir sur blanc que j'étais tout à fait d'accord que ca demandait des moyens pour être mis en place. Encore une fois, ce que je critiques, c'est les arguments totalement bancales de Linus.
Bref, tu dis n'importe quoi.
Non, Linux a eu du succès parcqu'il est vite devenu opérationnel et qu'il a su fédérer les développeurs. Il a maintenant une base très importante de drivers ce qui fait son succès. C'est pas pour autant que le choix d'architecture fait y'a 15 ans est toujours aussi pertinent.
Si les autres noyaux n'ont pas de succès, c'est pas pour des problèmes d'architecture, c'est pour des problèmes de moyens comme tu le répètes très bien : un noyau sans drivers n'aura pas d'utilisateurs, c'est un cercle vicieux.
n projet n'est pas que la somme des atouts théorique loin des réalités.
C'est justement le point initial de ma critique : dans la vraie vie, quand je joue à simcity 4 sur un poste Vista, j'ai environ un crash graphique toutes les 2h de jeu (c'est spécifique à cette appli me demande pas pourquoi). Hop je le vois mais ca me gène pas. Ca c'est la vraie vie, et un constat clair : cette fonctionnalité de Vista est un confort indéniable. Linus s'obstine à dire que ca sert à rien quand des gens s'en servent dans la vraie vie. Qui est éloigné de la réalité ? (en tout cas des évolutions du marché ?)
Rires. C'est toi qui traitait Linus de prétentieux :
Oui je dis qu'il est prétentieux, et j'essai d'argumenter. Toi tu me dis que je peux pas, par respect pour je-sais-pas-quoi. On peut pas critiquer les propos d'un demi-dieu c'est ca ?
Avec l'historique de Windows, il y a de quoi rire.
Visiblement y'a en tout cas de quoi les faire se bouger le cul.
C'est du libre. Si le chef déconne, il est viré.
Le pape déconne, il est toujours là.
[^] # Re: L'avis de Linus
Posté par auve . Évalué à 2.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Théoriquement c'est possible d'avoir la fonctionnalité.
> Linux s'achemine visiblement vers un modèle hybride
Non. Que la libc ne soit pas dans le noyau ne fait pas de Linux un noyau hybride.
Un noyau hybride est quand ce qui devrait être en userland pour un micro-noyau est mis en privilégié (dans le même espace d'adressage du micro-noyau) pour des raisons de performances.
Pour un micro-noyau, le FS doit être en userland.
Par exemple pour un read on a :
- mode normal (l'appli)
- mode privilégié (le micro-noyau)
- mode normal (le FS)
- mode privilégié (le micro-noyau)
- mode normal (l'appli)
Avec un noyau hybride ou monolithique on a :
- mode normal
- mode privilégié ((micro-)noyau qui fait FS)
- mode normal
C'est bien plus rapide.
Dans les deux cas, l'appli et le FS n'ont pas le même espace d'adressage pour des raisons de sécurité.
> des bouts en espace utilisateur (drivers Gallium / DRI / ...).
Rien à voir avec l'architecture d'un micro-noyau.
Tout ce qui peut être fait en userland (par exemple un cache) avant de passer en mode privilégié ou après avoir quitté le mode priviligé doit être fait. Que ça soit un noyau monolithique ou un micro-noyau. En fait, quelque soit le noyau :-)
Tout ce qu'à de micro-noyau Linux, est FUSE.
[^] # Re: L'avis de Linus
Posté par auve . Évalué à 2.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 1.
XFree/Xorg est un cas particulier jusqu'à maintenant car il fait/faisait driver (il accédait directement au hardware) et c'est pour ça qu'il doit être root (c'est aussi pour ça qu'il peut planter tout le système même s'il n'y a pas de bug dans le noyau).
Mais ça va changer avec KMS/DRM puisque Xorg ne demandera plus d'être root pour être utilisé.
M'enfin DRI peut/doit être considéré comme un driver puisqu'il tient compte du driver DRM (et donc du hardware). DRI est le driver de haut-niveau et DRM le driver de bas-niveau.
Notons qu'un driver qui accède à du hardware dans un micro-noyau, même s'il tourne en mode non privilégié (dans un service), fait parti du noyau.
DRI ne fait pas parti du noyau. S'il était porté sur un micro-noyau il ne serait pas un service, ni évidemment dans le micro-noyau. Il serait une librairie.
Donc ton précédent "Linux s'achemine visiblement vers un modèle hybride pour les cartes graphiques, avec des bouts dans le noyau (mode-setting, DRM) et des bouts en espace utilisateur (drivers Gallium / DRI / ...)" est faux :-)
NB :
Noyau monolithique : tout ce qui tourne dans le noyau est en mode privilégié (ring 0) et dans le même espace d'adressage (même pour les processus noyau).
Micro-noyau : idem noyau monolithique
Service micro-noyau : en mode non privilégié (ring > 0), chaque service a son espace d'adressage.
On dit souvent (moi aussi) que les services micro-noyau sont dans l'espace utilisateur, mais c'est à tord. Sa particularité est d'avoir son propre espace mémoire et de ne pas utiliser le mode privilégier (en tout cas pas ring 0). Mais ça n'a pas grand chose à voir avec l'espace ou le mode utilisateur (sauf ring != 0).
D'où peut-être ton erreur.
PS: je ne connais pas très bien DRI/DRM/etc. N'hésitez pas à mon corriger.
[^] # Re: L'avis de Linus
Posté par auve . Évalué à 2.
(Oh, et, on écrit « tort » pas « tord », « :-) ».)
[^] # Re: L'avis de Linus
Posté par Larry Cow . Évalué à 2.
Ça "pourrait" permettre d'expérimenter des voies alternatives à X à moindre frais, si la partie dépendante du matériel n'est plus à réimplémenter...
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Une démo vaut mieux qu'un long discourt :
http://hoegsberg.blogspot.com/2008/12/two-x-servers-and-micr(...)
Wayland : http://groups.google.com/group/wayland-display-server
FAQ : http://groups.google.com/group/wayland-display-server/web/fr(...)
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 3.
Linus dit ça des micro-noyau alors qu'il parle de l'architecture d'un noyau.
Et comme Windows n'est pas un micro-noyau, Microsoft ne lui donne tord. Microsoft a écrit de 0 Windows NT et n'a pas choisi de faire un vrai micro-noyau car Microsoft pense grosso-modo la même chose que Linus.
> reconnaître que le chemin pris par MS va dans le sens des micro-noyaux
Mouaif. Ben ça ne va pas vite en plus de 15 ans (?) d'existance de Windows NT.
> c'est les arguments totalement bancales de Linus.
Pourquoi ils son bancales ?
Ils sont confirmés par la réalité. En 1990 si tu disais qu'ils étaient bancales, je n'aurais rien dit. Mais aujourd'hui... Faut arrêter le délire.
Certes Linus le dit brutalement, on peut penser qu'il exagère, etc. Mais l'histoire lui a donné raison. Tu peux ajouter "jusqu'à maintenant".
> Non, Linux a eu du succès parcqu'il est vite devenu opérationnel et qu'il a su fédérer les développeurs. Il a maintenant une base très importante de drivers ce qui fait son succès.
Donc il a eu raison. Fin.
> C'est pas pour autant que le choix d'architecture fait y'a 15 ans est toujours aussi pertinent.
Non, presque rien n'a changé !
Je peux aussi dire que faire un noyau en Java ou C# est un avantage et blablabla.
Honte à Microsoft, Microsoft ne veut pas faire son noyau en C# alors que c'est irréfutablement un avantage !
Sur le papier c'est un avantage. Dans la réalité non. Idem pour les micro-noyau.
> Si les autres noyaux n'ont pas de succès, c'est pas pour des problèmes d'architecture, c'est pour des problèmes de moyens
Les micro-noyau ont eu des moyens et même beaucoup plus que Linux à l'époque des débuts de Linux. MS avec WinNT, Apple/Nextstep, Digital. Mais, ils n'ont pas fait de vrai de micro-noyau...
Pourtant à l'époque le concèpte de micro-noyau était plus séduisant qu'aujourd'hui : les micro-noyau était l'avenir et les noyaux monolithique était destiner à disparaitre.
Aujourd'hui les choses sont encore moins en faveur pour les micro-noyau alors j'ai bien du mal à croire qu'aujourd'hui il est plus pertinent de faire un micro-noyau qu'il y a 15 ans.
> un noyau sans drivers n'aura pas d'utilisateurs, c'est un cercle vicieux.
Le problème des micro-noyau n'est pas que là. L'histoire l'a montré.
> j'ai environ un crash graphique toutes les 2h de jeu
Sous Linux on corrige le driver, on ne met pas en place une infrastructure pour récupérer le driver.
Je ne vois absolument pas en quoi l'une des deux démarches est supérieure à l'autre.
> Hop je le vois mais ca me gène pas.
Hop je ne vois pas de problème sous Linux, ça ne me gène pas.
> Ca c'est la vraie vie
Ça c'est la vraie vie
> un constat clair : cette fonctionnalité de Vista est un confort indéniable.
Quand on a un driver pourri. Oui. Mais Linux ne veut pas de driver pourri pour les cartes graphiques comme Windows ne veut, ni ne peut tolérer, de driver pourri pour les disques, pour le réseau, pour le son, pour le gestionnaire de mémoire, pour l'ordonnanceur, etc.
> Linus s'obstine à dire que ca sert à rien quand des gens s'en servent dans la vraie vie.
Si tu décides qu'il ne faut pas corriger le driver, ça sert à quelque chose. Si tu décides corriger le driver ça ne sert à rien. Le logiciel libre a les sources, le logiciel libre corrige les bugs.
> Qui est éloigné de la réalité ?
Tu ne veux entendre que la réalité de Windows.
Écoute la réalité de Linux.
Je n'ai pas dit que Windows avait tord, mais que ça ne me semble pas bon pour Linux dont le contexte de développement, ses méthodes, etc n'ont pratiquement rien à voir avec Windows qui a le culte du binaire et des API figées. Si l'API Linux sucks, on l'a change et on met à jour tous les drivers (on a les sources). Si l'API Windows sucks ? Ben on prie que le système de récupération fasse son job.
Essaie de comprendre la réalité de Linux qui n'est pas celle de Windows. Peut-être que tu penseras toujours que Linux a tord, mais tu dois au moins reconnaitre que Linux a moins de raison de faire des barrières pour les drivers graphiques que Windows.
> Oui je dis qu'il est prétentieux, et j'essai d'argumenter. Toi tu me dis que je peux pas, par respect pour je-sais-pas-quoi.
Tu as dit : "Mais quand le chef dit que de toute façon ca sert à rien, la question des moyens se pose même pas puisque le chef a dit. "
Que tu le traites de prétentieux me fait seulement rire.
Que tu remettes en cause la position de leader de Linus (comme s'il avait été parachuté "chef"), ça ne me fait pas rire.
Que tu traites les développeurs linux d'idôlatrer Linus (ils suiveraient aveuglement Linus), ça ne me fait pas rire.
Linus peut être viré à tout moment. Il est le leader de Linux car il le mérite et qu'il n'y a pas meilleur que lui pour ce job actuellement. Il n'est pas le chef car une autorité supérieur lui en a donnée mandat, mais car les développeurs le veulent (jusqu'à maintenant).
> Le pape déconne, il est toujours là.
T'es con ou tu le fais exprès ?
Le pape est nommé à vie. Linus non.
[^] # Re: L'avis de Linus
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Je peux aussi dire que faire un noyau en Java ou C# est un avantage et blablabla.
Honte à Microsoft, Microsoft ne veut pas faire son noyau en C# alors que c'est irréfutablement un avantage !
Sur le papier c'est un avantage. Dans la réalité non. Idem pour les micro-noyau.
Tu ne sembles pas connaitre singularity. Si Microsoft n'a pas encore sortie ça de ses labos, c'est assurément parceque pour l'instant ils ont plus à gagner à se trainer le poids de la rétrocompatibilité qu'à partir sur de nouvelles bases plus propres.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Je ne connaissais pas. C'est très intéressant, et pas seulement sur le choix du language.
SIPs [Software Isolated Processes] rely on programming language type and memory safety for isolation, instead of memory management hardware.
On peut l'utiliser sans protection du cpu/mmu. C'est-à-dire en ring 0 et tout dans le même espace d'adresse par exemple.
Mais ça me fait passer à des projets de noyau en Java. Quelqu'un pour confirmer ?
> c'est assurément parceque pour l'instant ils ont plus à gagner à se trainer le poids de la rétrocompatibilité qu'à partir sur de nouvelles bases plus propres.
C'est surtout car c'est un projet de recherche.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 2.
http://www.blogeek.ch/index.php?2007/08/14/2483-l-origine-de(...)
Je vais t'épargner la comparaison avec le taux de fiabilité du préservatif.
[^] # Re: L'avis de Linus
Posté par RB . Évalué à 9.
A partir du moment ou l'ensemble est composé de drivers libres, les plantages réguliers doivent être fixés et complètement disparaitre rapidement. Il n'y a aucune raison de tolérer des drivers de mauvaise qualités (a part quand on sait qu'il sont de mauvaises qualité parce que les dev n'ont pas les infos pour bien les terminer) pour justifier des barrières supplémentaires, c'est une mauvaise approche. Si tu masques certains plantages aux gens, moins de gens vont faire l'effort de les corriger.
Linux est vraiment super stable avec les drivers ouverts, c'est clair que la partie graphique est un peu "chaude" avec les restructurations actuelles, mais sinon durant toutes ces années je vois pas ce que je peux reprocher a un système que je reboot jamais... (a part parfois les suspend/resume imparfait....)
[^] # Re: L'avis de Linus
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: L'avis de Linus
Posté par TImaniac (site web personnel) . Évalué à 3.
Dans la vraie vie, les drivers graphiques, ca plante.
[^] # Re: L'avis de Linus
Posté par Littleboy . Évalué à 2.
Apres, vu la vitesse ou tout ca evolue (1995 l'annee du desktop Linux avec des drivers graphiques potables!), c'est pas pret d'arriver.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Ces parties (réseau, fs, etc) font parti du noyau. Avec un micro-noyau elles tournent en mode non-privilégié, mais elles font parti du noyau.
Un micro-noyau seul est sans intérêt.
Quand je vois une comparaison du nombre de ligne de Linux et d'un micro-noyau, ça m'énerve toujours. Ajoutes des drivers, une pile tcp/ip, un fs, etc à un micro-noyau pour en faire un noyau utilisable et il y a autant de ligne qu'un Linux avec les même fonctionnalités.
Linux est un noyau monolithique modulaire. Accoler "monolithique" avec "modulaire" fait bizarre. Ici "monolithique" indique seulement que tout ce qui est noyau s'exécute en mode privilégié.
Charger un module Linux peut être vu comme charger un service à un micro-noyau. Les deux ajoutes dynamiquement des fonctionnaités au noyau.
Il est même très probable qu'à fonctionnalité équivalente Linux ait moins de ligne de code puisqu'il n'a pas à se farcir des communications très complexes entre les différentes modules comme un micro-noyau doit le faire avec ses services.
> 1995 l'annee du desktop Linux avec des drivers graphiques potables!
Windows NT est sorti en 1993 je crois. C'est en 1994 que Linux 1.0 est sorti. C'est seulement en 1999 que Gnome 1.0 est sorti. Alors en 1995 ça ne risquait pas d'être l'année du desktop Linux.
Il ne faut pas écouter les "zealiot".
[^] # Re: L'avis de Linus
Posté par Anonyme . Évalué à 3.
Il faudrait arreter de croire que desktop sous linux rime avec Gnome. KDE existait avant et tournait déjà très bien, fwhm est encore plus vieux, wmaker aussi et j'en passe. Reduire le desktop à Gnome c'est franchement une vue étroite du sujet.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à -2.
Réduire le desktop à Gnome ou KDE aussi.
[^] # Re: L'avis de Linus
Posté par Anonyme . Évalué à 2.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
Il n'existait pas en 1995 :-)
KDE 1.0 est sorti en 1998.
J'ai pris Gnome 1.0 car c'était le premier bureau potable et libre. KDE avait des problèmes avec la licence Qt.
[^] # Re: L'avis de Linus
Posté par Sylvain Sauvage . Évalué à 3.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 1.
Je vous présente TWM ! tata !
On ne peut pas mettre de fichier sur le bureau, mais on s'en fout bash c'est bien mieux.
Demain je vous apprendrais à utiliser Vi (pas Vim, il est bloated) afin d'ajouter un menu au clique droit de la sourie.
-- Sylvain Sauvage, l'autre expérience utilisateur --
[^] # Re: L'avis de Linus
Posté par Anonyme . Évalué à 1.
[^] # Re: L'avis de Linus
Posté par IsNotGood . Évalué à 2.
[^] # Re: L'avis de Linus
Posté par Anonyme . Évalué à 1.
[^] # Re: L'avis de Linus
Posté par Hugues (site web personnel) . Évalué à -6.
PATRIIIIIIIIIICK !!!!!!!!!
Donc :
merci patrick :-))
[^] # Re: L'avis de Linus
Posté par karteum59 . Évalué à 2.
J'imagine qu'un certain nombre de choses complexes pourraient peut-être aussi être sorties du noyau : par exemple : est-il nécessaire que les filesystems soient en kernel-space ? (le rôle du noyau ne pourrait-il pas se borner à abstraire le device physique sous-jacent et le présenter dans /dev, en gérant les accès concurrents, les interruptions, les droits d'accès, etc. Charge à un processus serveur (ou une lib) en userland de jouer le rôle du FS).
Idem, la stack IP ne pourrait-elle pas être en userland, le kernel se bornant à abstraire l'interface réseau physique ? Etc...
Autre chose : plutôt que d'avoir une approche où un processus serveur fait le boulot (cas des micro-noyaux), est-ce qu'il y a moyen de faire que le code d'une lib (et juste ce code là, pas le reste du code de l'appli qui est linkée dessus) ait des droits spécifiques (pour accéder directement au matériel, ou plus simplement à un service/fichier spécial donné) ?
(Par exemple, il me semble que le ring est défini au niveau de chaque page de code, un jmp dans une page de code ring0 permettrait donc de fonctionner dans ce mode ?). Si c'était possible, une appli lambda aurait juste besoin d'être linkée à la "libfs" (qui accéderait directement à /dev/sda*), et on éviterait les IPC (cas des micro-noyaux) et/ou bon nombre de "int 0x80" (noyau Linux actuel) pour les appels au fs...
P.S.: c'est une question ouverte, pas un troll ! (j'espère d'ailleurs que je suis assez clair dans ma question... :)
P.S.2: ah si, le petit troll de rigueur qui vient avec : si le noyau Linux était sous licence LGPL (ou BSD), on pourrait explorer ce type de voie en partant de ce dernier. Mais il est sous licence GPL => impossible de copier-coller du code du noyau Linux (des algos qu'on trouverait intéressants, par exemple) pour les mettre dans des libs userland, ou sinon seules les applis GPL pourront s'y linker... Dommage que la GPL restreigne l'usage du code sur un tel critère technique...
# La compilation de la mort
Posté par Gui13 (site web personnel) . Évalué à 2.
Je tombe sur cet article sur DLFP, et, très intéressé par l'idée de faire tenir un noyau sur 5000 lignes, je me rends sur le site de MINIX 3.
Les sources sont disponibles dans un fichier d'un peu moins d'1Mo en dessous des isos du CD d'installation, magnifique.
Je m'empresse de télécharger, et je commence à regarder quelques fichiers source dans le kernel.
La présence d'un fichier Makefile à la racine m'incite à tenter un make.. quelle ne fut pas mon erreur.
Voici les traces:
Phobos:src gui13$ make
Master Makefile for MINIX commands and utilities.
Root privileges are required for some actions.
Usage:
make world # Compile everything (libraries & commands)
make includes # Install include files from src/
make libraries # Compile and install libraries
make cmds # Compile all, commands, but don't install
make install # Compile and install commands
make depend # Generate required .depend files
make clean # Remove all compiler results
Run 'make' in tools/ to create a new MINIX configuration.
Phobos:src gui13$ make world
cd include && exec make - install gcc
rm -rf /usr/include
rm: /usr/include/_locale.h: Permission denied
rm: /usr/include/_structs.h: Permission denied
rm: /usr/include/_types.h: Permission denied
rm: /usr/include/_wctype.h: Permission denied
rm: /usr/include/_xlocale.h: Permission denied
rm: /usr/include/aio.h: Permission denied
rm: /usr/include/alloca.h: Permission denied
rm: /usr/include/amber.h: Permission denied
rm: /usr/include/apache2/ap_compat.h: Permission denied
rm: /usr/include/apache2/ap_config.h: Permission denied
rm: /usr/include/apache2/ap_config_auto.h: Permission denied
rm: /usr/include/apache2/ap_config_layout.h: Permission denied
rm: /usr/include/apache2/ap_listen.h: Permission denied
rm: /usr/include/apache2/ap_mmn.h: Permission denied
rm: /usr/include/apache2/ap_mpm.h: Permission denied
[snip de 2000 lignes]
rm: /usr/include/zconf.h: Permission denied
rm: /usr/include/zlib.h: Permission denied
rm: /usr/include: Permission denied
make[1]: [install] Error 1 (ignored)
mkdir -p /usr/include
cpdir . /usr/include
make[1]: cpdir: Command not found
make[1]: *** [install] Error 127
make: *** [includes] Error 2
Hein????
Depuis quand un Makefile est-t-il censé toucher à mon /usr sans que je lui dise spécifiquement "make install"??
C'est du commentaire brouillon, mais je trouve hallucinant qu'un kernel fasse ce genre de chose à la compilation.. heureusement que j'était pas en root..
[^] # Re: La compilation de la mort
Posté par B16F4RV4RD1N . Évalué à 4.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: La compilation de la mort
Posté par fenril . Évalué à 4.
[^] # Re: La compilation de la mort
Posté par fenril . Évalué à 2.
Cela semble habituel dans le monde BSD. Y a-t'il des adorateurs de la bête* dans le coin pour confirmer?
*Beastie, la mascotte des systèmes BSD. en tout cas de freeBSD puisque netBSD a simplifié son logo. Et en plus on est 'dredi.
[^] # Re: La compilation de la mort
Posté par lolop (site web personnel) . Évalué à 5.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# La fiabilité n'est pas le seul avantage des micro-noyaux...
Posté par neologix . Évalué à 2.
A votre avis, qu'est-ce qui est le plus simple à coder et à débuger ?
Un noyau que l'on doit recompiler et relinker à chaque modification, ou alors des serveurs qui tournent en userland ?
Sous Linux, pour modifier la pile TCP/IP, on doit recompiler le noyal, redémarrer, et prier pour que la machine ne crashe pas. Si elle crashe, bonjour pour débugger.
Sous un micro-noyau, hop, on compile un serveur qui tourne en espace utilisateur, et que l'on peut débugger comme n'importe quelle application (gdb), et c'est parti. Pareil pour les modules : même si on peut les compiler et les charger à la volée, et bien ils peuvent toujours planter tout le système, et le débuggage n'a rien d'évident.
Avec la complexité croissante des architectures et pilotes modernes, je préfère avoir des centaines de milliers de lignes de code qui tournent en espace utilisateur qu'en mode noyau : on peut retourner le problème dans tous les sens, mais personne ne me fera trouver acceptable qu'un bug dans le pilote de ma webcam puisse planter ma machine ou flinguer le contenu de mon disque dur.
Et puis bon, pour soutenir ma thèse sur la facilité de développement, j'ai deux exemples de grand succès : Hurd et Minix :-)
[^] # Re: La fiabilité n'est pas le seul avantage des micro-noyaux...
Posté par brazz . Évalué à 2.
Des fois je me dis que la communauté, on s'est un peu laissé embarquer... Mais on ne refait pas plus l'histoire qu'on se baigne deux fois dans le même fleuve!
[^] # Re: La fiabilité n'est pas le seul avantage des micro-noyaux...
Posté par Hippie Geek (site web personnel) . Évalué à 1.
Il semblerait que la virtualisation peut aider au débugage kernel. Rebooter c sympa, déboguer par console série aussi, mais faut pas se compliquer la vie.
# Feature request
Posté par santos . Évalué à 3.
Vivement qu'ils fassent un portage de flash en 64 bits ! :D
[^] # Re: Feature request
Posté par psychoslave__ (site web personnel) . Évalué à 2.
# Velu du vendredi ?
Posté par brazz . Évalué à 2.
Par ailleurs, je me souviens de ce livre pamphlet "La cathédrale et le bazar" qui opposait effectivement 2 conceptions architecturales et deux modes de développement. Et bien, à présent, avec le temps, Linux, c'est à dire le noyau monolithique, ressemble de plus en plus à une cathédrale...
On ne sait pas très bien combien de temps il faudra pour qu'on comprenne que parfois, dans les plus grands projets, il n'est pas forcément bon que le gourou fondateur s'incruste à la place de Dieu!
En attendant, ma version de Minix, importée en 87 via l'AFUU et pas mal upgradée depuis, pour finir en Minix 3, tourne tranquille, c'est vrai seulement pour le fun. Mais à l'époque j'étais sysadmin Unix et non étudiant, donc je n'avais pas le temps à passer là dessus, dommage!
Et en attendant, je garde mon bouquin de Tannenbaum présenté par cet autre incapable de Brian Kerninghan :)
[^] # Re: Velu du vendredi ?
Posté par Sylvain AVRIL (site web personnel) . Évalué à 3.
Il faut éviter le troll avec Windows qui n'est pas vraiment un micro-noyau.
Je pense aussi qu'il ne faut pas considérer la parole de Linus comme celle du messie. Il a fourni de bons arguments pour le monolithique (facilité de développement, ...) mais il a aussi rejeté des arguments pour le micro-noyau sans réelles justifications (stabilité, sécurité).
Le micro-noyau apporte plus de sécurité et de stabilité 'by-design'. Il n'y a qu'à compter le nombre d'exploits noyau pour Linux, ils suivent une courbe exponentielle. Bien sûr on ne peut pas comparer avec des systèmes peu utilisés mais pour la sécurité, la séparation des espaces mémoire se justifie.
Bien sûr on peut faire aussi bien en monolithique en peaufinant le code, en résolvant les bugs... Mais plus la complexité du système augmente plus ceci devient coûteux alors que l'isolation dans des systèmes étanches permet de limiter le périmètre impacté par les bugs.
[^] # Re: Velu du vendredi ?
Posté par IsNotGood . Évalué à 2.
Sûr, il y a QNX. Je n'ai pas dit que les micro-noyau sont obligatoirement mauvais, mais qu'ils n'ont rien démontré lorsqu'il sagit d'un OS généraliste (desktop et serveur). S'ils ont démontré quelque chose, c'est la quasi inadaption des micro-noyau pour faire un OS généraliste.
> mais il a aussi rejeté des arguments pour le micro-noyau sans réelles justifications (stabilité, sécurité).
Il l'a justifié, le problème est la complexité.
> Le micro-noyau apporte plus de sécurité et de stabilité 'by-design'.
Ce n'est pas le design de haut-niveau qui compte, c'est la réalité.
Un petit exemple :
http://fr.wikipedia.org/wiki/Noyau_de_système_d'exploitation
D’un point de vue théorique, le grand nombre de lignes de code exécutées en mode noyau engendre des problèmes de portabilité. La pratique contredit largement la théorie et les noyaux modulaires sont aujourd’hui les plus portés.
> Il n'y a qu'à compter le nombre d'exploits noyau pour Linux,
Mauvais argument. Compile un Linux pour l'embarquer (en virant le maximum de chose) et il n'y a qu'un très petit nombre de bug de Linux qui t'affecte. Les bugs qui t'affectent peuvent être plus probablement trouvé et plus vite si tu utilises un système très diffusé/audité.
> suivent une courbe exponentielle
Exponentielle par rapport à quoi ?
> Mais plus la complexité du système augmente plus ceci devient coûteux alors que l'isolation dans des systèmes étanches permet de limiter le périmètre impacté par les bugs.
L'argument se tient. Mais faire "des systèmes étanches" est compliqué, pas simple. Et dans quelle mesure sont-ils étanches ? Un serveur web, même dans un micro-noyau, n'est pas isolé du reste. Il doit récupérer des fichiers (donc intération avec le FS, le pilote des disques), accéder au réseau (intéraction avec la pile TCP/IP), etc.
Linus répond à ton argument, ça commence par "Tout l'argument disant que les micro-noyaux sont "plus sécurisés" ou "plus stables" est aussi totalement grotesque".
Le "grotesque" est un peu fort, mais on sait comment s'exprime Linus.
Ici chaque solution a ses avantages et inconvéniants pour la stabilité et sécurité.
Notons que Linus est dans l'objectif de faire un OS généraliste. Pas un OS qui sacrifie tout pour conserver la pureté du design.
Chercher les performances à un coût :
http://fr.wikipedia.org/wiki/Noyau_de_système_d'exploitation#Syst.C3.A8mes_.C3.A0_micro-noyaux (on y trouvera aussi des conneries :-))
Le grand nombre d’appels système et la communication sous-jacente sont un défaut inhérent à la conception des micro-noyaux. Dans L4, il a été résolu en plaçant encore plus de services en espace utilisateur. La rapidité de traitement des IPC a pu être améliorée en simplifiant les communications au maximum, par exemple en supprimant toute vérification des permissions, laissant ce soin aux serveurs externes.
Es-ce le cas de QNX ?
Si oui, l'avantage sécurité est très discutable pour ne pas dire qu'il disparait.
[^] # Re: Velu du vendredi ?
Posté par Émilien Tlapale . Évalué à 1.
[^] # Re: Velu du vendredi ?
Posté par IsNotGood . Évalué à 1.
[^] # Re: Velu du vendredi ?
Posté par Anonyme . Évalué à 0.
Un exemple d'un autre micro-noyau, enfin il me semble, qui se débrouille pas si mal c'est Darwin. Les MacOSX sont légions et semble plutôt stable dans l'ensemble.
[^] # Re: Velu du vendredi ?
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Velu du vendredi ?
Posté par Anonyme . Évalué à 1.
[^] # Re: Velu du vendredi ?
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Cela dit, outre l'exemple de QNX, MINIX 3 me semble vraiment en bonne voie. Certes ce n'est peut être pas encore prêt pour la production, mais il y a déjà un bon paquets de ports. Autant hurd ne me donne vraiment pas l'air de décoller, autant MINIX me donne l'impression de bien progresser.
Hurd avait aussi été accepté au SoC de l'an dernier, mais pas cette année semble-t-il, ce qui semble confirmer que :
* il y a une demande en micro-noyau (je doute que google financent des projets auxquels il ne voient aucun intérêt)
* MINIX est le plus crédible des projets libres à micro-noyau
Bref, ça me semble plus être une réalité émergente qu'un fantasme irréalisable.
# oui mais,
Posté par thedidouille . Évalué à 3.
Il faudra sans doute aussi adapter les applications pour qu'elles puissent gérer le cas ou le driver est relancer. il ne s'agit pas de réessayer une connexion réseau comme si le câble a été débranché, il faudra recréer toutes les connexions (dans le cas d'une carte réseau).
# Vous avez tout faux
Posté par riri le breton (site web personnel) . Évalué à 6.
haaaa, ça faisait longtemps.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.