La taille d'un noyau compilé reflète mieux la complexité du noyau.
Noyau 2.4.37 allnoconfig: vmlinux:590 Ko
Noyau 3.1 allnoconfig: vmlinux:1885 Ko
Rapport: 3,2
Ça représente le code inertiel du coeur du système (gestion de la mémoire et du CPU), sans aucune gestion matérielle.
Noyau 2.4.37 avec support matériel minimal (generic ATA + VGA console + AC97 + RTL8139 + IPv4 + UHCI+OHCI+HID + SMP) sur ma machine: vmlinux:1382 Ko
Noyau 3.1 compilé avec les mêmes options: vmlinux: 4571 Ko (et seulement 4056 Ko si on vire SMP)
Rapport: 3,3
Ça représente le code inertiel des sous-systèmes de base: PCI, entrées/sorties disque, VFS, pile réseau, ATA, USB.
Ces sous-systèmes ont l'air d'avoir augmenté dans les mêmes proportions que le coeur du système.
Enfin, le code complet:
Taille de linux-2.4.37.tar non comprimé: 175 Mo
Taille de linux-3.1.tar non comprimé: 454 Mo
Rapport: 2,6
Paradoxalement, bien que le code central du noyau (coeur+sous-systèmes de base) soit en proportion, beaucoup plus petit que le code des pilotes (4571 Ko de code binaire correspond peut-être à 3 ou 4 fois plus en taille source, soit, au maximum une vingtaine de méga sur 454, soit moins de 5% du code total) il semblerait que la complexité d'un noyau basique (facteur environ égal à 3.3) ait un peu plus augmenté que le nombre (multiplié par la taille) des pilotes gérés (facteur environ égal à 2.6).
Tous ces chiffres sont à prendre avec des pincettes, mais j'espère que ça donne une idée de l'évolution.
En effet, 95% des bogues et plantages que je subis ne sont pas dus au noyau mais à l'espace utilisateur, qui n'a pas de raison d'être meilleur sous MINIX que sous Linux.
Il arrive que des noyaux Linux aient des bogues assez graves à leur sortie, parce que le rythme de développement est très rapide, et donc les tests pas assez poussés, mais, si on décide de n'utiliser que des noyaux avec support à long terme comme la 2.6.16, 2.6.27 ou 2.6.32, on ne rencontre plus vraiment de bogues non matériels, au prix d'un support matériel un peu en retard, mais qui a de toute façon 15 ans d'avance sur MINIX.
En plus, les micro-noyaux ne corrigent pas les bogues magiquement. Par exemple, un des bogues les plus graves de la Linux 3.1 est un problème de gestion des disques de secours dans le RAID software, qui serait toujours présent si Linux était un micro-noyau.
Un autre bogue de deadlock dans XFS sur les mono-coeurs dans la 2.6.30, dont j'avais fait les frais à l'époque, serait aussi présent (en fait, pas sous MINIX puisqu'il ne gère que les systèmes mono-coeurs de toute façon).
L'unique "bénéfice" de stabilité d'un micro-noyau est qu'un pilote qui crashe, plutôt que de faire un Kernel Panic, redémarre, en priant pour que ça ne bousille pas encore plus le système. D'ailleurs, plus le système est complexe, et les interactions entre modules complexes, plus le redémarrage d'un module est dangereux pour la fiabilité du système entier.
Exemple: Si X.org plante, on pourrait imaginer qu'il puisse redémarrer et que les applications graphiques puissent être récupérées. Si on rajoute les extensions GLX, ça devient plus dur.
Fait tourner un UNIX avec une GUI et une suite bureautique du niveau d'Office 4.3 sur un 80286 à 6 Mhz et 2 méga-octets de RAM et on en reparlera.
Windows 3.0 sacrifiait le design technologique afin d'obtenir quelque chose de complet et à peu près fonctionnel en un espace RAM minuscule. Il n'y a qu'AmigaOS qui réussisse à nécessiter moins de RAM pour quelque chose d'aussi complet.
Le succès de MS-DOS est très fortement lié au fait qu'il était pré-installé alors que DR-DOS était prohibitivement cher, alors que le succès (inattendu) de Windows 3.0 est dû au fait, à mon avis, que c'était la meilleure GUI disponible sur PC en ce temps. D'ailleurs je n'ai toujours pas trouvé mieux sur 286 ou 386.
Ensuite, la position dominante de Windows s'est imposée de plus en plus, avec, néammoins, toujours un niveau de compétence de Microsoft suffisant pour que les gens ne se tournent pas vers d'autres solutions, notamment par une bonne rétro-compatibilité et des fonctions de plus en plus dignes d'un OS moderne. Cette position dominante est sans cesse affirmée par les OEM qui pré-installent Windows, mais, je crois que si Linux devient indéniablement supérieur à Windows pour Mme Michu, alors, les OEM commenceront à réellement vendre beaucoup de machines avec GNU/Linux préinstallé.
Sérieusement, c'est très difficile de faire un OS pour le desktop. Il faut une très bonne infrastructure matérielle et énormément de travail de support et déboguages de pilotes (le matos est toujours très bogué), ainsi qu'une infrastructure logicielle en espace utilisateur complète et adaptée à toutes les configurations possibles.
MINIX ne fait toujours pas partie des OS sérieusement utilisables sur le desktop. GNU/Linux, Windows et dans une moindre mesure FreeBSD et peut-être un jour Haiku (dont le développement est super-rapide et productif) me semblent être les seules options vraiment viables sur le desktop.
Je ne crois pas qu'aujourd'hui un micro-noyau puisse être intéressant sur le desktop, parce que ça rend difficile les communications complexes entre composants du noyau et ralentit la vitesse d'évolution des interfaces internes du noyau, et pourtant, ces interfaces et évolutions sont nécessaires pour gérer le matos moderne, et, vu à la vitesse à laquelle le hardware évolue, on a intérêt à ne pas prendre de retard.
Fait comme tous les utilisateurs Debian expérimentés:
Grave ou achète le pack complet de DVD-ROM, binaires et source, et porte les en collier autour du cou, jour et nuit.
En priant pour que totoro.deb et totoro-dev.deb soient dans les dépôts de Debian.
Il y a des gens qui se contentent des dépôts de base de leur système. Sous Fedora, ça fait environ 3000 paquetages.
Par contre, sous NetBSD, le problème que j'ai eu n'est pas tellement le manque de paquetages, mais plutôt un support matériel beaucoup plus limité que Linux ou FreeBSD sur PC. L'ACPI est indispensable pour gérer le routage des interruptions sur les machines modernes (indispensable pour gérer le matériel PCI ou PCIe) mais est très mal géré par NetBSD. Il faut dire que ça demande un gros boulot de contournement de bogues que Linux arrive tout juste à faire.
En gros, le noyau NetBSD plante au démarrage sur la plupart de mes machines.
De mon expérience, même OpenBSD est plus utilisable que NetBSD sur PC.
Je ne suis pas convaincu que le succès de Linux soit dû à la licence copyleft. Je crois que c'est surtout dû au fait que les mainteneurs principaux (à commencer par Linus Torvalds), incluent très facilement et rapidement des patches, quel que soit le motif raisonnable d'inclusion (amélioration des performances, support de matériel fréquent ou rare, besoins spécifiques ou généraux), du moment que la qualité du code est bonne, alors que les *BSD ont tendance à refuser des choix techniques qui ne correspondent pas à leurs idéaux, ce qui explique pourquoi les *BSD ont forqué plusieurs fois.
D'ailleurs, le noyeau Linux, dès le début de son développement a eu énormément de succés et a reçu de nombreuses contributions. De son côté, MINIX refusait l'inclusion de fonctions "inutiles" comme un pilote de système de fichiers multi-thread.
Je crois que Linux était déjà un grand succès quand la GPL a commencé à "obliger" des contributeurs à donner leur patches. D'ailleurs, même comme ça, seules les sociétés s'investissant activement dans le libre font des patches de qualité acceptable. Si on regarde le code des pilotes OEM des tablettes Android, c'est tellement abominable comme code, que l'on est pas beaucoup plus avancé que si on avait rien (je pense en particulier aux pilotes du SoC WM-8505).
Il ne faut pas croire que si BSD avait eu une licence GPL, Mac OS X serait en GPL! Je crois qu'Apple se serait simplement passé du code, et aurait entièrement codé son système de son côté.
Sous Windows, il y a K-meleon qui utilise Gecko avec une GUI Win32 native.
Sous GNU/Linux, il y a epiphany utilisait GTK+Gecko, mais maintenant il utilise WebKit.
Histoire de tout environnement bureautique GNU/Linux:
[année 0] Béta super-instable et incomplète mais assez prometteuse. API propre et intéressante. Utilisé par quelques fans.
[année 2] Système devenant fonctionnel et relativement complet. Utilisable pour le grand public.
[année 4] Système au point. Stable, fonctionnel. Prèsque plus de bogues. Tout le monde l'aime sauf ses propres développeurs.
[année 5] Les développeurs en ont marre de ne faire que corriger des bogues mineurs par ce que ce n'est pas "fun". Ils décident de réécrire un nouveau système "vachement plus mieux" à partir de zéro. Surtout que les correctifs de bogues et ajouts de fonctions ont fini par rendre le système moins beau et propre du point de vue de l'utopie programmatique, brisant les fantasmes paradigmatiques perfectionnistes des programmeurs.
[année 6] abandon du vieil environnement. Sortie d'un nouveau système. GOTO [année 0].
Le [GOTO année 0], ça fait toujours mal aux utilisateurs, même si les développeurs adorent ça.
Le "temps" de démarrage du BIOS, c'est uniquement le temps du POST (Power-On Self Test), qui est très très variable en durée.
J'ai vu des machines pour lesquelles c'était une ou deux secondes, et d'autres où c'est 30 secondes.
Après, une fois que ça a chargé le MBR, le temps de chargement du bootloader dépend un peu de la qualité d'implémentation de la fonction de lecture de disque INT 13h/AH=42h, mais, changer l'interface ne va pas améliorer les performances, parce qu'elle est déjà bien conçue (possibilité de lire plusieurs blocs contigus en un seul appel). De toute façon, ça nécessite souvent moins d'une seconde.
Quand au "secure boot", c'est aussi du BS marketing. Prèsque aucun malware ne modifie le fichier de démarrage de l'OS. L'objectif est uniquement de rendre plus difficile l'ajout de pilotes non signés pour les gens qui veulent contourner les DRM.
Ce qui est super avec la spécification EFI, c'est qu'elle ne s'arrête pas à la gestion de la configuration matérielle, mais elle s'étend à des choses purement logicielles comme le boot loader.
Plutôt que d'utiliser un BOOT loader débuggé et universel comme GRUB, pourquoi ne pas faire une spécification et une implémentation différente sur chaque BIOS, avec bien sûr, bon nombre de bogues jamais corrigés, comme ça tout le monde va pouvoir en baver?
La leçon que j'ai tirée de mon expérience avec les BIOS c'est que l'on devrait réduire ça au strict minimum vital
Mon rêve:
BIOS réduit a des simples tables descriptives (p.e. pour le routing des IRQ) + un boot-loader ultra-minimaliste juste capable de charger une flash contenant un OpenBIOS indépendant de la machine ou, si une touche magique ou cavalier est activé, démarrer un OpenBIOS de référence depuis une ROM, pour éviter que l'on ne brique la machine.
Matthew Garrett (développeur du noyau Linux pour Red Hat), a très bien expliqué ce qu'est EFI en quelques mots:>
> UEFI stands for “Unified Extensible Firmware Interface”, where “Firmware”
> is an ancient African word meaning “Why do something right when you can
> do it so wrong that children will weep and brave adults will cower before you”,
> and “UEI” is Celtic for “We missed DOS so we burned it into your ROMs”.
–Matthew Garrett
L'amorce placée sur le MBR "standard" (introduit avec MS-DOS 2.0), qui charge le Volume Boot Record de la partition active traite lui-même la table de partition, et non pas le BIOS. Par exemple, le MBR de MS-DOS 7.1, appelle INT 13H/AH=02h ou INT 13h/AH=42h, en fonction d'un flag à 0x0002.
La vieille API CHS du BIOS limitait les disques à 8.4 Go. La nouvelle API LBA/EDD, monte cette limite à 2^64 blocs, soit 8 Zebi-octets.
Le BIOS est agnostique du partitionnement. Si tu trouves une fonction du BIOS sur la RBIL qui ne le soit pas, peux-tu me la donner?
Si on y réfléchit, Windows 3.11 était en fait une 3.1.1 (ben oui, il n'y a pas eu 10 versions intermédiaires). Du coup, la 3.1.1, qu'on aura probablement d'ici une ou deux semaines, sera l'équivalent de Windows 3.11.
Le noyau Linux a donc 19 ans de retard technologique^Wversionologique.
Maintenant on a plus qu'à attendre Linux 2000.
Un vieux K6-2 datant de 1998, originellement à 333 Mhz, upgradé à 550 Mhz, avec initialement 64 MiO de RAM, mais maintenant 448 MiO. Toujours fidèle au rendez-vous.
Plutôt que de créer un nouveau langage, on peut optimiser le langage existant.
D'ailleurs, Google a déjà fait pas mal de boulot de ce côté là, avec les "classes implicites", la compilation de JavaScript en code natif et un ramasse-miettes générationnel.
En plus, pour l'optimisation d'espace mémoire des tableaux, on a déjà les "tableaux typés".
Je n'arrive pas à retrouver l'article, mais j'avais vu un article montrant que pour un calcul brut comme la multiplication de matrice, V8 était seulement 3 fois plus lent que le C++. Ce n'est pas garanti que l'on puisse faire beaucoup mieux avec Draft.
Si on rajoutait l'inférence statique de type, il serait possible d'obtenir des performances assez proche du code natif pour un programmeur un peu expérimenté écrivant du code se prêtant à ces optimisations. Ça me paraît plus facile que de développer en parallèle une version Draft et une version JavaScript de la même application.
Après, là où il y a encore énormément de boulot, que ce soit en JavaScript ou Draft, c'est au niveau du Document Object Model et canevas, mais là, les performances dépendent plus du moteur HTML/CSS que du JavaScript lui-même.
En effet, il ne faut pas oublier les plus grandes contributions d'UNIX (dont certaines viennent en fait de Multics), qui sont celles que l'on ignore souvent parce qu'elles sont devenues universelles.
1) Les fichiers sous formes de gros blocs binaires, "opaques" au système d'exploitation.
En contraste, un protocole comme FTP en mode ASCII va bousiller tous les retours charriots et SMTP va déconner sur les lignes trop longues, parce que ces protocoles "gèrent" le texte.
2) Code et données des programmes, et même du noyau, sous forme de fichiers comme les autres, avec un joli chemin d'accès compréhensible pour un humain^Wgeek, dans un système de fichiers hiérarchique.
L'état du système peut être ainsi entièrement sauvegardé sous forme d'une archive TAR.
Les programmes (pas trop dégeu) peuvent être simplement copiés d'une machine à l'autre.
En contraste, on pourrait imaginer un système où tous les programmes soient stockés dans une partition spéciale, non hiérarchique, avec un identifiant 128 bits et un blob binaire pour chaque programme.
3) Abstraction totale du médium sous-jacent pour le système de fichiers.
Ainsi, même la taille des blocs du médium n'importe pas pour lseek/read/write, contrairement à CP/M dont l'API utilisait des RECORDS de 128 octets.
4) Système de fichiers hiérarchiques, avec de dossiers non ordonnés, sans données au noeud du dossier.
Tous les systèmes modernes ont, dans une certaine mesure, un certaine interopérabilité, parce qu'ils sont tous plus ou moins inspirés d'UNIX.
Même si je ne le connais pas vraiment personnellement, j'ai toujours grandement admiré Dennis Ritchie, de par le pragmatisme qu'il montra en contribuant à la création d'UNIX et de C.
Et disponible avec ça! Je me souviens de lui avoir envoyé un e-mail au sujet d'une faute d'OCR dans son scan du manuel du langage B. Il m'avait répondu dans les 48 heures.
Sans compter que grâce aux mises à jour des applications Web, on se rend compte tous les mois que:
1) L'interface utilisateur a changé. Il faut la réapprendre. Parfois elle devient toute pourrie.
2) Ton navigateur n'est plus supporté.
3) Faut activer une nouvelle bouse^Wfeature comme "local storage" ou WebGL.
4) Ça bouffe encore plus de bande passante.
5) Il faut réécrire tous tes scripts qui extrayaient tant bien que mal les données utiles du service.
6) Des nouveaux bogues sont implémentés.
Plusieurs technologies pour la même chose (JavaScript, NaCl, Dart), c'est que le Web est en train de montrer des signes de vieillesse. Si Dart s'impose, il est bien certain que les navigateurs devront supporter à la fois JavaScript et Dart, pour cause de rétro-compatibilité.
Au final avec WebGL, les Canevas, Native Client, AJAX, DOM, CSSv3, le Web a perdu sa valeur initiale de simplicité et universalité, s'opposant aux réseaux fermés et lourds de l'époque.
C'est devenu difficile de surfer sur le Web avec une machine aussi "vieille" qu'un Core 2 Duo disposant d'un système d'exploitation CentOS 5.x de 2007 (pourtant encore supporté) et d'une connexion 512 Kbits/sec.
C'est un cercle vicieux. Comme la majorité parle anglais, la majorité des chercheurs publient en anglais.
On peut parler de cercle vicieux ou d'effet boule de neige...
Le fait est que c'est la combinaison de
(1) beaucoup de gens qui parlent l'anglais.
(2) beaucoup de science dans les pays anglophones.
(3) beaucoup de gens qui apprennent l'anglais sans trop de difficultés.
Qui ont permis à la langue de s'imposer.
Donc, ça s'est naturellement imposé pour que la transition se fasse avec le moins d'efforts possible.
"Et pourquoi 99% des gens continuent à utiliser Windows? Vous avez raison, quand tout le monde choisit la pire solution elle devient la meilleure."
Maintenant que j'ai un peu d'expérience en dehors de l'univers des PC, pour expérimenter celui des tablettes tactiles et téléphones intelligents, je sais que Windows n'est pas du tout le pire choix. Somme toute, c'est même un système pas trop fermé (bien sûr Linux, FreeBSD, Haiku et autres systèmes libres sont bien plus ouverts)
1) On peut développer ses propres applications personelles sans demander l'avis à qui que ce soit. L'API est même plutôt bien documentée et de documentation librement accessible (contrairement à OS/2 par exemple).
2) On peut développer ses propres pilotes.
3) On peut distributer les applications et pilotes selon le modèle et la licence que l'on souhaite, sans demander l'avis de Microsoft.
4) L'API est native (code machine natif, et pas machine virtuelle pourrie), ce qui veut dire que l'on peut exploiter assez largement les capacitées de la machine.
5) Microsoft conserve une assez bonne rétro-compatibilité, ce qui permet de bénéficier du pouvoir effectif de développer ses propres applications.
6) C'est un système moderne: Multitâche pré-emptif, gérant le SMP, une bonne API de communication inter-processus, les entrées-sorties parallèles, de stabilité acceptable, modulaire, gérant quand même beaucoup de matériel et de performance satisfaisante. Bon, la procédure de démarrage est indéniablement pourrie comparée à celle de Linux.
7) Indépendant du vendeur matériel, on peut installer le même OS sur des machines de marques différentes.
8) Nombreux outils de développement indépendants (MinGW, OpenWatcom, etc.), bons débogueurs, éditeurs hexa. Tout ce qu'il faut pour qu'un développeur se sente à l'aise.
9) Famille d'API pas si éloignée d'UNIX que ça (par exemple, gestion des disques durs comme des fichiers, système de fichiers hiérarchiques, tuyaux de communication inter-processus).
(Pourtant, je suis un Linuxien convaincu)
Si on considère concrètement l'ultime paramètre: "Être maître de sa machine", alors Windows n'est pas trop mauvais. On peut installer prèsque tous les logiciels qu'on veut dans toutes les configurations que l'on souhaite, conserver ses données personelles où on veut, comme on veut, scripter toutes les tâches répétitives, exploiter son matériel dans prèsque toutes ses capacités.
Maintenant, comparez à:
iOS
RIM (l'OS des Blackberry)
MS-DOS (quelle abstraction matérielle!)
Windows Phone 7 (Tout en .NET, monotâche, tout sur une AppStore)
Les divers WebOS où toutes les données personnelles sont sur des serveurs américains, surveillées par le gouvernement.
Même Android, bien que "libre" (enfin, juste le noyau pour la version 3.0), avec ses applications Java, son manque cruel d'accès aux tripes du système, me paraît plus limité que Windows NT 4/5/6. Quand j'ai voulu mettre un serveur Web dessus, je me suis aperçu qu'il n'est pas possible d'écouter sur un port < 1024 parce qu'on est pas root de sa PROPRE machine!
Si Windows 9 devient une bouse pareille à Windows Phone 7 ou iOS, crois moi, Linux va prendre son essor à une vitesse incroyable.
[^] # Re: Taille du noyau
Posté par NanoTech . En réponse à la dépêche Entretien avec Linus Torvalds sur ZEIT ONLINE. Évalué à 9.
La taille d'un noyau compilé reflète mieux la complexité du noyau.
Noyau 2.4.37 allnoconfig: vmlinux:590 Ko
Noyau 3.1 allnoconfig: vmlinux:1885 Ko
Rapport: 3,2
Ça représente le code inertiel du coeur du système (gestion de la mémoire et du CPU), sans aucune gestion matérielle.
Noyau 2.4.37 avec support matériel minimal (generic ATA + VGA console + AC97 + RTL8139 + IPv4 + UHCI+OHCI+HID + SMP) sur ma machine: vmlinux:1382 Ko
Noyau 3.1 compilé avec les mêmes options: vmlinux: 4571 Ko (et seulement 4056 Ko si on vire SMP)
Rapport: 3,3
Ça représente le code inertiel des sous-systèmes de base: PCI, entrées/sorties disque, VFS, pile réseau, ATA, USB.
Ces sous-systèmes ont l'air d'avoir augmenté dans les mêmes proportions que le coeur du système.
Enfin, le code complet:
Taille de linux-2.4.37.tar non comprimé: 175 Mo
Taille de linux-3.1.tar non comprimé: 454 Mo
Rapport: 2,6
Paradoxalement, bien que le code central du noyau (coeur+sous-systèmes de base) soit en proportion, beaucoup plus petit que le code des pilotes (4571 Ko de code binaire correspond peut-être à 3 ou 4 fois plus en taille source, soit, au maximum une vingtaine de méga sur 454, soit moins de 5% du code total) il semblerait que la complexité d'un noyau basique (facteur environ égal à 3.3) ait un peu plus augmenté que le nombre (multiplié par la taille) des pilotes gérés (facteur environ égal à 2.6).
Tous ces chiffres sont à prendre avec des pincettes, mais j'espère que ça donne une idée de l'évolution.
[^] # Re: Un peu déçu
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 4.
par opposition, la GPL est féconde car la liberté ne se referme jamais.
Jusqu'au jour ou une nouvelle licence copyleft apparaît et crée de nouvelles barrières d'espèce.
Sérieusement, les projets en licence permissives me paraissent féconds: Apache, X.org, PostgreSQL, FreeBSD, Haiku.
[^] # Re: Fiabilité
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 2.
En effet, 95% des bogues et plantages que je subis ne sont pas dus au noyau mais à l'espace utilisateur, qui n'a pas de raison d'être meilleur sous MINIX que sous Linux.
Il arrive que des noyaux Linux aient des bogues assez graves à leur sortie, parce que le rythme de développement est très rapide, et donc les tests pas assez poussés, mais, si on décide de n'utiliser que des noyaux avec support à long terme comme la 2.6.16, 2.6.27 ou 2.6.32, on ne rencontre plus vraiment de bogues non matériels, au prix d'un support matériel un peu en retard, mais qui a de toute façon 15 ans d'avance sur MINIX.
En plus, les micro-noyaux ne corrigent pas les bogues magiquement. Par exemple, un des bogues les plus graves de la Linux 3.1 est un problème de gestion des disques de secours dans le RAID software, qui serait toujours présent si Linux était un micro-noyau.
Un autre bogue de deadlock dans XFS sur les mono-coeurs dans la 2.6.30, dont j'avais fait les frais à l'époque, serait aussi présent (en fait, pas sous MINIX puisqu'il ne gère que les systèmes mono-coeurs de toute façon).
L'unique "bénéfice" de stabilité d'un micro-noyau est qu'un pilote qui crashe, plutôt que de faire un Kernel Panic, redémarre, en priant pour que ça ne bousille pas encore plus le système. D'ailleurs, plus le système est complexe, et les interactions entre modules complexes, plus le redémarrage d'un module est dangereux pour la fiabilité du système entier.
Exemple: Si X.org plante, on pourrait imaginer qu'il puisse redémarrer et que les applications graphiques puissent être récupérées. Si on rajoute les extensions GLX, ça devient plus dur.
[^] # Re: Avis de Linus Torvalds sur les micro-noyaux
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 10.
Fait tourner un UNIX avec une GUI et une suite bureautique du niveau d'Office 4.3 sur un 80286 à 6 Mhz et 2 méga-octets de RAM et on en reparlera.
Windows 3.0 sacrifiait le design technologique afin d'obtenir quelque chose de complet et à peu près fonctionnel en un espace RAM minuscule. Il n'y a qu'AmigaOS qui réussisse à nécessiter moins de RAM pour quelque chose d'aussi complet.
Le succès de MS-DOS est très fortement lié au fait qu'il était pré-installé alors que DR-DOS était prohibitivement cher, alors que le succès (inattendu) de Windows 3.0 est dû au fait, à mon avis, que c'était la meilleure GUI disponible sur PC en ce temps. D'ailleurs je n'ai toujours pas trouvé mieux sur 286 ou 386.
Ensuite, la position dominante de Windows s'est imposée de plus en plus, avec, néammoins, toujours un niveau de compétence de Microsoft suffisant pour que les gens ne se tournent pas vers d'autres solutions, notamment par une bonne rétro-compatibilité et des fonctions de plus en plus dignes d'un OS moderne. Cette position dominante est sans cesse affirmée par les OEM qui pré-installent Windows, mais, je crois que si Linux devient indéniablement supérieur à Windows pour Mme Michu, alors, les OEM commenceront à réellement vendre beaucoup de machines avec GNU/Linux préinstallé.
Sérieusement, c'est très difficile de faire un OS pour le desktop. Il faut une très bonne infrastructure matérielle et énormément de travail de support et déboguages de pilotes (le matos est toujours très bogué), ainsi qu'une infrastructure logicielle en espace utilisateur complète et adaptée à toutes les configurations possibles.
MINIX ne fait toujours pas partie des OS sérieusement utilisables sur le desktop. GNU/Linux, Windows et dans une moindre mesure FreeBSD et peut-être un jour Haiku (dont le développement est super-rapide et productif) me semblent être les seules options vraiment viables sur le desktop.
Je ne crois pas qu'aujourd'hui un micro-noyau puisse être intéressant sur le desktop, parce que ça rend difficile les communications complexes entre composants du noyau et ralentit la vitesse d'évolution des interfaces internes du noyau, et pourtant, ces interfaces et évolutions sont nécessaires pour gérer le matos moderne, et, vu à la vitesse à laquelle le hardware évolue, on a intérêt à ne pas prendre de retard.
[^] # Re: Pas assez bien
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 1.
Fait comme tous les utilisateurs Debian expérimentés:
Grave ou achète le pack complet de DVD-ROM, binaires et source, et porte les en collier autour du cou, jour et nuit.
En priant pour que totoro.deb et totoro-dev.deb soient dans les dépôts de Debian.
[^] # Re: Pas assez bien
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 3.
Il y a des gens qui se contentent des dépôts de base de leur système. Sous Fedora, ça fait environ 3000 paquetages.
Par contre, sous NetBSD, le problème que j'ai eu n'est pas tellement le manque de paquetages, mais plutôt un support matériel beaucoup plus limité que Linux ou FreeBSD sur PC. L'ACPI est indispensable pour gérer le routage des interruptions sur les machines modernes (indispensable pour gérer le matériel PCI ou PCIe) mais est très mal géré par NetBSD. Il faut dire que ça demande un gros boulot de contournement de bogues que Linux arrive tout juste à faire.
En gros, le noyau NetBSD plante au démarrage sur la plupart de mes machines.
De mon expérience, même OpenBSD est plus utilisable que NetBSD sur PC.
[^] # Re: Ou pas
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 8.
Je ne suis pas convaincu que le succès de Linux soit dû à la licence copyleft. Je crois que c'est surtout dû au fait que les mainteneurs principaux (à commencer par Linus Torvalds), incluent très facilement et rapidement des patches, quel que soit le motif raisonnable d'inclusion (amélioration des performances, support de matériel fréquent ou rare, besoins spécifiques ou généraux), du moment que la qualité du code est bonne, alors que les *BSD ont tendance à refuser des choix techniques qui ne correspondent pas à leurs idéaux, ce qui explique pourquoi les *BSD ont forqué plusieurs fois.
D'ailleurs, le noyeau Linux, dès le début de son développement a eu énormément de succés et a reçu de nombreuses contributions. De son côté, MINIX refusait l'inclusion de fonctions "inutiles" comme un pilote de système de fichiers multi-thread.
Je crois que Linux était déjà un grand succès quand la GPL a commencé à "obliger" des contributeurs à donner leur patches. D'ailleurs, même comme ça, seules les sociétés s'investissant activement dans le libre font des patches de qualité acceptable. Si on regarde le code des pilotes OEM des tablettes Android, c'est tellement abominable comme code, que l'on est pas beaucoup plus avancé que si on avait rien (je pense en particulier aux pilotes du SoC WM-8505).
Il ne faut pas croire que si BSD avait eu une licence GPL, Mac OS X serait en GPL! Je crois qu'Apple se serait simplement passé du code, et aurait entièrement codé son système de son côté.
Bon, je n'ai pas non plus de preuve.
[^] # Re: Et sinon Gecko il est où ?
Posté par NanoTech . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 2.
Sous Windows, il y a K-meleon qui utilise Gecko avec une GUI Win32 native.
Sous GNU/Linux, il y a epiphany utilisait GTK+Gecko, mais maintenant il utilise WebKit.
[^] # Re: Trop tard
Posté par NanoTech . En réponse à la dépêche Trinity, fork de KDE 3.5. Évalué à 10.
Histoire de tout environnement bureautique GNU/Linux:
[année 0] Béta super-instable et incomplète mais assez prometteuse. API propre et intéressante. Utilisé par quelques fans.
[année 2] Système devenant fonctionnel et relativement complet. Utilisable pour le grand public.
[année 4] Système au point. Stable, fonctionnel. Prèsque plus de bogues. Tout le monde l'aime sauf ses propres développeurs.
[année 5] Les développeurs en ont marre de ne faire que corriger des bogues mineurs par ce que ce n'est pas "fun". Ils décident de réécrire un nouveau système "vachement plus mieux" à partir de zéro. Surtout que les correctifs de bogues et ajouts de fonctions ont fini par rendre le système moins beau et propre du point de vue de l'utopie programmatique, brisant les fantasmes paradigmatiques perfectionnistes des programmeurs.
[année 6] abandon du vieil environnement. Sortie d'un nouveau système. GOTO [année 0].
Le [GOTO année 0], ça fait toujours mal aux utilisateurs, même si les développeurs adorent ça.
[^] # Re: temps de démarrage
Posté par NanoTech . En réponse à la dépêche UEFI, à la découverte du nouveau BIOS. Évalué à 3.
Le "temps" de démarrage du BIOS, c'est uniquement le temps du POST (Power-On Self Test), qui est très très variable en durée.
J'ai vu des machines pour lesquelles c'était une ou deux secondes, et d'autres où c'est 30 secondes.
Après, une fois que ça a chargé le MBR, le temps de chargement du bootloader dépend un peu de la qualité d'implémentation de la fonction de lecture de disque INT 13h/AH=42h, mais, changer l'interface ne va pas améliorer les performances, parce qu'elle est déjà bien conçue (possibilité de lire plusieurs blocs contigus en un seul appel). De toute façon, ça nécessite souvent moins d'une seconde.
Quand au "secure boot", c'est aussi du BS marketing. Prèsque aucun malware ne modifie le fichier de démarrage de l'OS. L'objectif est uniquement de rendre plus difficile l'ajout de pilotes non signés pour les gens qui veulent contourner les DRM.
[^] # Re: Une série de trois.
Posté par NanoTech . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 1.
John McCarthy, le papa de LISP, est décédé le 25/10/2011.
Un mois d'octobre bien triste.
# DOS gravé dans le marbre
Posté par NanoTech . En réponse à la dépêche UEFI, à la découverte du nouveau BIOS. Évalué à 10.
Ce qui est super avec la spécification EFI, c'est qu'elle ne s'arrête pas à la gestion de la configuration matérielle, mais elle s'étend à des choses purement logicielles comme le boot loader.
Plutôt que d'utiliser un BOOT loader débuggé et universel comme GRUB, pourquoi ne pas faire une spécification et une implémentation différente sur chaque BIOS, avec bien sûr, bon nombre de bogues jamais corrigés, comme ça tout le monde va pouvoir en baver?
La leçon que j'ai tirée de mon expérience avec les BIOS c'est que l'on devrait réduire ça au strict minimum vital
Mon rêve:
BIOS réduit a des simples tables descriptives (p.e. pour le routing des IRQ) + un boot-loader ultra-minimaliste juste capable de charger une flash contenant un OpenBIOS indépendant de la machine ou, si une touche magique ou cavalier est activé, démarrer un OpenBIOS de référence depuis une ROM, pour éviter que l'on ne brique la machine.
Matthew Garrett (développeur du noyau Linux pour Red Hat), a très bien expliqué ce qu'est EFI en quelques mots:>
> UEFI stands for “Unified Extensible Firmware Interface”, where “Firmware”
> is an ancient African word meaning “Why do something right when you can
> do it so wrong that children will weep and brave adults will cower before you”,
> and “UEI” is Celtic for “We missed DOS so we burned it into your ROMs”.
–Matthew Garrett
[^] # Re: table des partitions
Posté par NanoTech . En réponse à la dépêche UEFI, à la découverte du nouveau BIOS. Évalué à 5.
L'amorce placée sur le MBR "standard" (introduit avec MS-DOS 2.0), qui charge le Volume Boot Record de la partition active traite lui-même la table de partition, et non pas le BIOS. Par exemple, le MBR de MS-DOS 7.1, appelle INT 13H/AH=02h ou INT 13h/AH=42h, en fonction d'un flag à 0x0002.
La vieille API CHS du BIOS limitait les disques à 8.4 Go. La nouvelle API LBA/EDD, monte cette limite à 2^64 blocs, soit 8 Zebi-octets.
Le BIOS est agnostique du partitionnement. Si tu trouves une fonction du BIOS sur la RBIL qui ne le soit pas, peux-tu me la donner?
Références:
http://thestarman.pcministry.com/asm/mbr/MSWIN41.htm
http://www.ctyme.com/intr/rb-0607.htm
http://www.ctyme.com/intr/rb-0708.htm
[^] # Re: Encore 10 sorties
Posté par NanoTech . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 3.
Si on y réfléchit, Windows 3.11 était en fait une 3.1.1 (ben oui, il n'y a pas eu 10 versions intermédiaires). Du coup, la 3.1.1, qu'on aura probablement d'ici une ou deux semaines, sera l'équivalent de Windows 3.11.
Le noyau Linux a donc 19 ans de retard technologique^Wversionologique.
Maintenant on a plus qu'à attendre Linux 2000.
# Une vieille machine
Posté par NanoTech . En réponse au sondage Quel type de serveur perso utilisez-vous ?. Évalué à 5.
Un vieux K6-2 datant de 1998, originellement à 333 Mhz, upgradé à 550 Mhz, avec initialement 64 MiO de RAM, mais maintenant 448 MiO. Toujours fidèle au rendez-vous.
[^] # Re: Ça pue…
Posté par NanoTech . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 0.
s/Draft/Dart/g
Désolé.
[^] # Re: Ça pue…
Posté par NanoTech . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 2.
Plutôt que de créer un nouveau langage, on peut optimiser le langage existant.
D'ailleurs, Google a déjà fait pas mal de boulot de ce côté là, avec les "classes implicites", la compilation de JavaScript en code natif et un ramasse-miettes générationnel.
En plus, pour l'optimisation d'espace mémoire des tableaux, on a déjà les "tableaux typés".
http://code.google.com/intl/fr/apis/v8/design.html
Je n'arrive pas à retrouver l'article, mais j'avais vu un article montrant que pour un calcul brut comme la multiplication de matrice, V8 était seulement 3 fois plus lent que le C++. Ce n'est pas garanti que l'on puisse faire beaucoup mieux avec Draft.
Si on rajoutait l'inférence statique de type, il serait possible d'obtenir des performances assez proche du code natif pour un programmeur un peu expérimenté écrivant du code se prêtant à ces optimisations. Ça me paraît plus facile que de développer en parallèle une version Draft et une version JavaScript de la même application.
Après, là où il y a encore énormément de boulot, que ce soit en JavaScript ou Draft, c'est au niveau du Document Object Model et canevas, mais là, les performances dépendent plus du moteur HTML/CSS que du JavaScript lui-même.
[^] # Re: C'est une honte
Posté par NanoTech . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 3.
Qui voudrait ça? Un Mac, ça sert à faire tourner Linux, comme toute machine qui se respecte, grille-pains y compris.
:)
[^] # Re: Respect...
Posté par NanoTech . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 10.
En effet, il ne faut pas oublier les plus grandes contributions d'UNIX (dont certaines viennent en fait de Multics), qui sont celles que l'on ignore souvent parce qu'elles sont devenues universelles.
1) Les fichiers sous formes de gros blocs binaires, "opaques" au système d'exploitation.
En contraste, un protocole comme FTP en mode ASCII va bousiller tous les retours charriots et SMTP va déconner sur les lignes trop longues, parce que ces protocoles "gèrent" le texte.
2) Code et données des programmes, et même du noyau, sous forme de fichiers comme les autres, avec un joli chemin d'accès compréhensible pour un humain^Wgeek, dans un système de fichiers hiérarchique.
L'état du système peut être ainsi entièrement sauvegardé sous forme d'une archive TAR.
Les programmes (pas trop dégeu) peuvent être simplement copiés d'une machine à l'autre.
En contraste, on pourrait imaginer un système où tous les programmes soient stockés dans une partition spéciale, non hiérarchique, avec un identifiant 128 bits et un blob binaire pour chaque programme.
3) Abstraction totale du médium sous-jacent pour le système de fichiers.
Ainsi, même la taille des blocs du médium n'importe pas pour lseek/read/write, contrairement à CP/M dont l'API utilisait des RECORDS de 128 octets.
4) Système de fichiers hiérarchiques, avec de dossiers non ordonnés, sans données au noeud du dossier.
Tous les systèmes modernes ont, dans une certaine mesure, un certaine interopérabilité, parce qu'ils sont tous plus ou moins inspirés d'UNIX.
# Mes condoléances
Posté par NanoTech . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 10.
Même si je ne le connais pas vraiment personnellement, j'ai toujours grandement admiré Dennis Ritchie, de par le pragmatisme qu'il montra en contribuant à la création d'UNIX et de C.
Et disponible avec ça! Je me souviens de lui avoir envoyé un e-mail au sujet d'une faute d'OCR dans son scan du manuel du langage B. Il m'avait répondu dans les 48 heures.
Je sens un vide dans la force.
[^] # Re: au point ou on en est
Posté par NanoTech . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 2.
La grosse différence c'est que pour les applications "lourdes", on a le choix de rester à l'ancienne version ou de passer à la nouvelle.
Surtout pour le logiciel libre pour lequel on peut continuer à recompiler et modifier selon ses goûts l'ancienne version.
[^] # Re: au point ou on en est
Posté par NanoTech . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 1.
Sans compter que grâce aux mises à jour des applications Web, on se rend compte tous les mois que:
1) L'interface utilisateur a changé. Il faut la réapprendre. Parfois elle devient toute pourrie.
2) Ton navigateur n'est plus supporté.
3) Faut activer une nouvelle bouse^Wfeature comme "local storage" ou WebGL.
4) Ça bouffe encore plus de bande passante.
5) Il faut réécrire tous tes scripts qui extrayaient tant bien que mal les données utiles du service.
6) Des nouveaux bogues sont implémentés.
[^] # Re: Ça pue…
Posté par NanoTech . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 9.
Plusieurs technologies pour la même chose (JavaScript, NaCl, Dart), c'est que le Web est en train de montrer des signes de vieillesse. Si Dart s'impose, il est bien certain que les navigateurs devront supporter à la fois JavaScript et Dart, pour cause de rétro-compatibilité.
Au final avec WebGL, les Canevas, Native Client, AJAX, DOM, CSSv3, le Web a perdu sa valeur initiale de simplicité et universalité, s'opposant aux réseaux fermés et lourds de l'époque.
C'est devenu difficile de surfer sur le Web avec une machine aussi "vieille" qu'un Core 2 Duo disposant d'un système d'exploitation CentOS 5.x de 2007 (pourtant encore supporté) et d'une connexion 512 Kbits/sec.
Est-il temps de revenir au Web 1.0 ?
[^] # Re: La question du choix
Posté par NanoTech . En réponse à la dépêche Est‐il démocratique, adapté et rentable que l’anglais soit la langue internationale ?. Évalué à 1.
On peut parler de cercle vicieux ou d'effet boule de neige...
Le fait est que c'est la combinaison de
(1) beaucoup de gens qui parlent l'anglais.
(2) beaucoup de science dans les pays anglophones.
(3) beaucoup de gens qui apprennent l'anglais sans trop de difficultés.
Qui ont permis à la langue de s'imposer.
Donc, ça s'est naturellement imposé pour que la transition se fasse avec le moins d'efforts possible.
[^] # Re: La question du choix
Posté par NanoTech . En réponse à la dépêche Est‐il démocratique, adapté et rentable que l’anglais soit la langue internationale ?. Évalué à 9.
"Et pourquoi 99% des gens continuent à utiliser Windows? Vous avez raison, quand tout le monde choisit la pire solution elle devient la meilleure."
Maintenant que j'ai un peu d'expérience en dehors de l'univers des PC, pour expérimenter celui des tablettes tactiles et téléphones intelligents, je sais que Windows n'est pas du tout le pire choix. Somme toute, c'est même un système pas trop fermé (bien sûr Linux, FreeBSD, Haiku et autres systèmes libres sont bien plus ouverts)
1) On peut développer ses propres applications personelles sans demander l'avis à qui que ce soit. L'API est même plutôt bien documentée et de documentation librement accessible (contrairement à OS/2 par exemple).
2) On peut développer ses propres pilotes.
3) On peut distributer les applications et pilotes selon le modèle et la licence que l'on souhaite, sans demander l'avis de Microsoft.
4) L'API est native (code machine natif, et pas machine virtuelle pourrie), ce qui veut dire que l'on peut exploiter assez largement les capacitées de la machine.
5) Microsoft conserve une assez bonne rétro-compatibilité, ce qui permet de bénéficier du pouvoir effectif de développer ses propres applications.
6) C'est un système moderne: Multitâche pré-emptif, gérant le SMP, une bonne API de communication inter-processus, les entrées-sorties parallèles, de stabilité acceptable, modulaire, gérant quand même beaucoup de matériel et de performance satisfaisante. Bon, la procédure de démarrage est indéniablement pourrie comparée à celle de Linux.
7) Indépendant du vendeur matériel, on peut installer le même OS sur des machines de marques différentes.
8) Nombreux outils de développement indépendants (MinGW, OpenWatcom, etc.), bons débogueurs, éditeurs hexa. Tout ce qu'il faut pour qu'un développeur se sente à l'aise.
9) Famille d'API pas si éloignée d'UNIX que ça (par exemple, gestion des disques durs comme des fichiers, système de fichiers hiérarchiques, tuyaux de communication inter-processus).
(Pourtant, je suis un Linuxien convaincu)
Si on considère concrètement l'ultime paramètre: "Être maître de sa machine", alors Windows n'est pas trop mauvais. On peut installer prèsque tous les logiciels qu'on veut dans toutes les configurations que l'on souhaite, conserver ses données personelles où on veut, comme on veut, scripter toutes les tâches répétitives, exploiter son matériel dans prèsque toutes ses capacités.
Maintenant, comparez à:
iOS
RIM (l'OS des Blackberry)
MS-DOS (quelle abstraction matérielle!)
Windows Phone 7 (Tout en .NET, monotâche, tout sur une AppStore)
Les divers WebOS où toutes les données personnelles sont sur des serveurs américains, surveillées par le gouvernement.
Même Android, bien que "libre" (enfin, juste le noyau pour la version 3.0), avec ses applications Java, son manque cruel d'accès aux tripes du système, me paraît plus limité que Windows NT 4/5/6. Quand j'ai voulu mettre un serveur Web dessus, je me suis aperçu qu'il n'est pas possible d'écouter sur un port < 1024 parce qu'on est pas root de sa PROPRE machine!
Si Windows 9 devient une bouse pareille à Windows Phone 7 ou iOS, crois moi, Linux va prendre son essor à une vitesse incroyable.