Salut journal,
Je sais qu'on est sur LinuxFr mais je voudrais quand même savoir un peu ce que c'est le Hurd, quels sont ses avantages, ses inconvénients, que mange-t-il a midi, s'il a eu une enfance difficile... Bref je veux tout savoir.
Pourquoi ? Parce que j'ai lu ça : http://linuxfr.org/comments/517501.html#517501(...) et je dois dire que ça m'a assez enthousiasmé... Donc j'ai commencé a RTFMer un peu. Et je vais donc te livrer mes pensées et remarques.
J'ai commencé mon périple sur HurdFr.org [1] et cette page [2] a attiré mon attention, plusieurs points essentiels sont expliqués. Bon c'est bien mais pour avoir une vision plus synthétique, je suis allé faire un tour sur Wikipedia [3,4,5] où j'ai appris les différences entre micro-noyaux, noyaux monolithiques et autres exo-kernels.
Ensuite je suis tombé sur L4[6], Pistachio[7], Fiasco[8] et L4Linux[9].
Et c'est là que j'ai décroché... Quelles sont les différences ? Leur performances ? Leur (possible) avenir ?
Mais avant qu'un bonne âme n'éclaire ma lanterne, il faut que je pose une question : moyennant les baisses de performances qui a priori devraient apparaître avec l'utilisation d'un micro-noyau, pourquoi est-ce que l'utilisation d'un L4Linux qui (si j'ai bien compris) permet de faire tourner un Linux sur un noyau L4, n'est pas plus répandu ?
Avec toutes les capacités promises par Hurd... Ça me fait une sorte de fussoir de voir tout ce potentiel inexploité !
Pour finir, je me demande si l'avenir de Linux n'est pas le Hurd. Je m'explique : il me semble que le modèle de développement de Hurd est plus robuste que celui de Linux. Je crois sincèrement que celui de Linux commence à atteindre ses limites (en tout cas je pense qu'il n'est pas trivialement scalable). De plus, j'aime bien l'idée d'avoir un noyau en C++ (L4), mais c'est vraiment parce que j'ai un a priori favorable pour ce langage (note à ceux qui sont en train de sortir leur appeau à troll sur les langages de progs : je ne dénigre, ni ne fais l'apologie d'un langage en particulier, je dis juste que c'est ma préférence personnelle... Ensuite savoir si c'est le choix le plus judicieux pour un noyau... )
Bon je te laisse journal, je vais essayer de m'installer une Debian GNU/Hurd (m'en fous qu'il n'y ait pas de son sur mon serveur perso :P )
Hurd me voilà !
[1] HurdFr : http://www.hurdfr.org(...)
[2] Doc : http://www.hurdfr.org/index.php?page=pages/doc/strategie(...)
[3] Wikipedia En : http://en.wikipedia.org/wiki/Hurd(...)
[4] Wikipedia En : http://en.wikipedia.org/wiki/Microkernel(...)
[5] Wikipedia Fr :http://fr.wikipedia.org/wiki/Hurd(...)
[6] L4 : http://os.inf.tu-dresden.de/L4/(...)
[7] Pistachio : http://l4ka.org/projects/pistachio(...)
[8] Fiasco : http://os.inf.tu-dresden.de/fiasco(...)
[9] L4Linux : http://os.inf.tu-dresden.de/L4/LinuxOnL4(...)
Journal GNU/Hurd c'est quoi au fait ?
13
jan.
2005
# bah un vaporware pardi !
Posté par udok . Évalué à -2.
[^] # Re: bah un vaporware pardi !
Posté par ccomb (site web personnel) . Évalué à 6.
Le Hurd n'est pas un vaporware, il existe et il fonctionne.
[^] # Re: bah un vaporware pardi !
Posté par nicolassanchez . Évalué à 2.
tout à fait d'accord, mais le fait de ne pas pouvoir utiliser DHCP par exemple peut être gênant...
[^] # Re: bah un vaporware pardi !
Posté par ccomb (site web personnel) . Évalué à 4.
[^] # Re: bah un vaporware pardi !
Posté par Manuel Menal . Évalué à 5.
# Son enfance heuu ...
Posté par MsK` . Évalué à 6.
# ben
Posté par Marc (site web personnel) . Évalué à 3.
[^] # Re: ben
Posté par nicodache . Évalué à 2.
une autre interview, mais de stallman cette fois, cause aussi de hurd, mais la j'ai plus le lien :(
avec ceux-ci (surtout le dernier), tu devrais avoir un avis récent sur hurd, et entre autre apprendre qu'ils ont recommencé le code from scratch ya pas méga longtemps...
[^] # Re: ben
Posté par Manuel Menal . Évalué à 10.
Concernant la prétendue "réécriture", c'est exactement le genre d'imprécisions qui arrivent quand on écoute l'un ou l'autre. C'est simplement faux. Les développeurs du Hurd ont décidé d'utiliser un autre micro-noyau (L4) que celui utilisé originellement (GNU Mach). Les raisons en sont multiples : d'abord, GNU Mach n'est plus maintenu depuis une dizaine d'années ou presque, et il contient un nombre de bugs impressionants qui ont été découvert avec le temps (le matériel et les besoins évoluant, un logiciel parfaitement stable en 1993 peut se retrouver inutilisable dix ans plus tard, on voit ce problème avec les jeux) ; ensuite, GNU Mach est dépassé techniquement, et il ne permet pas aux yeux des développeurs de créer un Hurd qui soit une alternative crédible aux autres systèmes, notamment pour des raisons de performance ; enfin, c'est un micro-noyau de première génération, très éloigné techniquement de ce qui se fait aujourd'hui dans ce domaine, et il serait insensé de sortir une version du Hurd ne tirant pas profit des micro-noyaux dits de "seconde génération" comme L4.
Les différences entre GNU Mach et L4 sont importantes : l'histoire de Mach remonte à 1975, et la version sur laquelle est basée GNU Mach remonte à 1989, et a évolué jusqu'en 1994 environ. Bien qu'il laisse à l'espace utilisateur un grand nombre de tâches (VFS et systèmes de fichiers, gestion des droits, des processus, une partie de la gestion de la mémoire virtuelle), il garde pas mal de tâches en son sein (la plus grosse partie de la VM, l'ordonnanceur, les pilotes de périphériques, il a un système évolué de communication entre les processus, intégrant des systèmes de sécurité, etc.). C'est ce qui en fait un micro-noyau de première génération.
L4, lui, voit les choses différemment (et il le peut car il hérite de quelques années de recherche de plus dans le domaine). Il n'implémente en son sein que des -mécanismes- de base qui nécessitent de toutes façons des droits privilégiés sur le matériel : mapper/démapper une page, changer le thread en cours d'exécution, envoyer un message d'un thread à un autre, accès basique au matériel, ce genre de choses. Ce ne sont plus des bouts entiers du système d'exploitation qui sont dans le micro-noyau, comme avec Mach, mais des outils. Tout ce qui définit la personnalité du système d'exploitation : gestion de la mémoire virtuelle, pilotes de périphérique, ordonnancement (L4 a un mini-ordonnanceur (RR à priorités strictes), mais la partie décisions d'ordonnancement se fait en espace utilisateur (détermination des priorités)), ou tout ce que vous pouvez voir dans un noyau actuel, se trouve en espace utilisateur.
C'est une différence fondamentale, effectivement. Mais ça ne veut certainement pas dire tout réécrire ! Imaginez le Hurd comme un ensemble de pièces de légo associées les une aux autres savamment, avec les parties "basses" elles-mêmes associées à une grosse pièce de légo, GNU Mach. On divise la hauteur de la pièce du bas par deux, et on enlève la partie supérieure. Il va vous falloir de fait recréer une partie supérieure différente, et qui fournisse tant que c'est possible les mêmes attaches avec les pièces situées plus haut. Évidemment, ça ne sera pas toujours possible et du coup, il faudra peut-être modifier quelques pièces basses de la partie supérieure (le Hurd), mais c'est mineur. Là, c'est exactement pareil. Tout ce qui était dans GNU Mach et qui n'est pas dans L4 doit être réécrit totalement différemment (en espace utilisateur, et c'est un avantage énorme). Mais le reste, ce qui existe déjà dans le Hurd, ne bouge pas ou peu.
Pas de réécriture à l'ordre du jour, donc.
[^] # Re: ben
Posté par riri le breton (site web personnel) . Évalué à 2.
En effet, d'après ce que tu dis (le paragraphe consacré à L4), tout se passe en espace utilisateur, il n'implémente en son que des mécanismes (jai noté l'accentuation), des outils. En gros, il gère l'accès aux ressources, pas leur gestion. Et c'est justement la définition d'un exokernel.
Est-ce que je me trompe où c'est vraiment la réalité ?
Je m'intéresse beaucoup aux exo-kernel, et n'ai prêté que peu d'attention à L4, car pour moi, c'était un modèle de micro-kernel comme tant d'autres (je sais, c'est pas bien de faire l'impasse).
# Hum
Posté par cho7 (site web personnel) . Évalué à 3.
[^] # Re: Hum
Posté par nakan (site web personnel) . Évalué à 0.
[^] # Re: Hum
Posté par vincent LECOQ (site web personnel) . Évalué à 1.
# Impressions...
Posté par Bloodshed . Évalué à 10.
[^] # Re: Impressions...
Posté par Michel Pastor . Évalué à 10.
j'ai téléchargé l'iso debian GNU/Hurd
http://www.debian.org/ports/hurd/hurd-cd(...)
J'ai booté le cd et je n'ai pas eu de mal a l'installer grace a l'interface
en curses. Après j'ai installé grub avec un cd de knoppix
Je n'ai pas eu de probleme, le systeme a démarré du premier coup
en <> et j'ai configuré ma carte réseau avec un
settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a -g -m
et mis mon dns dans /etc/resolv.conf
puis j'ai redémarré le système
Arrivé au login et après un 'login root' j'ai testé plusieurs commandes
dans le bash par defaut. Le réseau fonctionnait parfaitement de ce que j'ai testé (ping, apt-get)
J'ai configuré les sources pour apt-get et après une mise a jour de l'arbre de packages j'ai pu installer vim, zsh et d'autres parmis un choix quand même interressant. J'ai lu sur les pages debian qu'il y avait approximativement la moitié des packages dejà portés.
Le système réagissait plutot bien et il n'a pas planté
Je n'ai pas testé XFree mais il est dans les packages et ils disent que ça fonctionnent bien. Je testerais ça bientôt.
Je suis personnelement assez satisfait du test n'ayant eu presque aucune manipulation compliquée pour mettre en place le système, que j'ai pu configurer et utiliser le réseau très simplement et que le tout n'a pas planté tout au long de mes tests. J'ai quand même fait une partition limitée à 1.2Go pour être sur de pouvoir l'utiliser car bien que sur la page du Hurd il soit inscrit que le kernel a été corrigé pour supporter les partitions de plus de 10Go les anciennes versions étaient limitées à l'utilisation de partitions de 1Go à 2Go à cause de l'utilisation d'un mappage complet en mémoire de la partition
Donc je vous encorage a tester tout ça vous même :)
[^] # Re: Impressions...
Posté par Michel Pastor . Évalué à 3.
"Après avoir lu ce journal je me suis lancé dans le test du Hurd"
"a démarré du premier coup en single"
et
settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a ip -g gateway -m netmask
[^] # Re: Impressions...
Posté par Manuel Menal . Évalué à 7.
deb http://packages.hurdfr.org/unstable/binary-hurd-i386(...) ./
Tu peux retrouver ensuite la documentation sur http://www.hurdfr.org/pages/doc/GuideInstall.pdf(...) dont je ne poste que le bout te concernant :
# console -d vga -d xkb ??xkbdir=/etc/X11/xkb ??keymapfile=keymap/hurd \ ??keymap=fr ??repeat=kbd -d pc_mouse ??repeat=mouse -c \ /dev/cons /dev/vcs
... lance la nouvelle console du Hurd (qui supporte différents encoding, le son, les couleurs, différents VTs, tout ça) avec un clavier en français. On crée les liens qui vont bien avec :
# ln -s /dev/cons/kbd /dev/kbd && ln -s /dev/cons/mouse /dev/mouse
... et on configure XFree86 pour utiliser le support souris de la console :
Section "Pointer"
Protocol "osmouse"
Device "/dev/mouse"
EndSection
Et le tour est joué ! Une console en français qui marche parfaitement, et un XFree86 par dessus. Attention, XFree86 est assez lent, du fait du manque de mémoire partagée SysV (shmem). Mais c'est plus que vivable, en fait c'est tout à fait décent. Par contre, plus tu fais tourner de choses sur ton système, plus tu auras des chances de rencontrer un plantage ;-) Pour une utilisation normale sans XFree86, j'ai pu tourner plus d'un mois sans aucun problème, avec une utilisation très "banale" (ouaibe, IRC, ssh, emacs, gcc, tout ça...).
[^] # Re: Impressions...
Posté par Michel Pastor . Évalué à 3.
La FAQ Hurd en français:
http://www.gnu.org/software/hurd/faq.fr.html(...)
Le guide utilisateur GNU/Hurd en anglais:
http://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html(...)
Le "Hurd Hacking Guide":
http://www.gnu.org/software/hurd/hacking-guide/hhg.html(...)
J'espère pouvoir bientôt contribuer au développement de ce noyau que je trouve plutôt innovant parmis les noyau libres existants et qui apportent a mon avis une souplesse dans la gestion du système qui n'est pas atteignable avec un système tournant sur un noyau monolithique comme Linux ou alors par des moyens détournés. Je pense par exemple aux modules noyau permettant d'implémenter des systèmes de fichier en espace utilisateur. Mais ce n'est pas le seul interêt ce ce type de noyau. Encore une fois je ne peux que vous conseiller de jeter un oeil aux documentations sus-citées.
Bon debut de fin de semaine
[^] # Re: Impressions...
Posté par Moule Atarte (site web personnel) . Évalué à -1.
______ [] __________________________________________________________
--------------> (c'est tellement bas que je peux passer sous la porte)
[^] # Re: Impressions...
Posté par Manuel Menal . Évalué à 2.
[^] # Re: Impressions...
Posté par titi toto . Évalué à 2.
http://linuxfr.org/~PGK/9783.html(...)
# Quelques éléments de réponses
Posté par Elly . Évalué à 8.
«Ensuite je suis tombé sur L4[6], Pistachio[7], Fiasco[8] et L4Linux[9].
Et c'est là que j'ai décroché... Quelles sont les différences ? Leur performances ? Leur (possible) avenir ?»
Alors déjà, L4 est une spécification de micro-noyau, Pistachio et Fiasco en sont deux implémentations (je crois que Pistachio implémente une version plus récente de la spécification), et L4Linux est le port de Linux pour le faire tourner au-dessus d'un micronoyau L4. Voilà pour les diférences.
Au niveau performance, je sais juste que L4 est réputé très performant, notamment avec les IPCs ; maintenant j'ai pas de chiffres sous la main, mais il me semble que les performances de L4Linux étaient comparables à celles de Linux, mais c'est pas vraiment un super exemple car ça reste très monolithique (enfin, iirc Linux tourne en mode utilisateur au lieu d'en mode noyau, mais c'est pas multiserveur pour autant, donc il doit pas y avoir des masses d'IPC).
«pourquoi est-ce que l'utilisation d'un L4Linux qui (si j'ai bien compris) permet de faire tourner un Linux sur un noyau L4, n'est pas plus répandu ?»
Tel que je vois les choses, l'intéret principal de L4Linux est surtout de benchmarker/tester L4... Après y'a peut-être quelques possibilités amusantes (du genre faire tourner 2 Linux, ou un Linux et autre chose), mais pour une utilisation quotidienne, ça a pas grand intérêt par rapport à Linux, vu qu'en gros c'est Linux avec une couche au milieu.
[^] # AMHA
Posté par doublehp (site web personnel) . Évalué à 10.
Le but est qu a terme, Linux n accedera plus au hard directement, mais via L4; donc quand tu veut porter Linux pour une archi, ben tu portes pas Linux du tout, mais juste L4. c est pour ca que IIRC dans le CVS de Linux, L4 est bien une archi en tant que telle.
L interret ? une migration en douceur. Une fois L4Linux stabilise, tout le monde pourra avoir un L4, tout en conservant toutes les aplis ( drivers et programmes utilisateur ) en version Linux. Sauf que L4 etant un (u)noyeau, et sachant gerer le multitasking, tu pourra executer dessus en meme temps que Linux, et a cote, d autres programmes ... comme une seconde pile IP, un server Apache ...
Bref cela permet de migrer en douceur, tout de suite sur les aplis qui suportent nativement le Hurd, en douceur en attendant la reecriture des autres.
Les projets Hurd restent toute fois des projets de recherche, et ne constituent en rien actuellement une image de ce que sera le Hurd du futur. Ce sont des versions de test, de demo ... meme pas en version alpha ... n en attends rien de stable ni meme de fonctionnel. Partant dans cette optique, tu sera emmerveille de tout plein de nouveautees ( les trans, les services, les jetons ... ).
Historiquement, un webmaster a decide de passer temporairement un server web sous Hurd pendant une semaine. Etant en version beta, il plantait tres regulierement. en fait, a l epoque, la pile IP etait completement instable; la pile IPv4 crashait en moyenne toutes les 20h. Pourtant, dans les logs d apache, le server n avait enregistre aucune discontinuite de service ... pourquoi ? quand la pile IP plante, elle est reloadee instantanement, et l operation est si rapide qu au pire les routeurs voient une trame perdue; les couches ISO 2 et 3 tentent donc une re-emission de la trame perdue ... dans la miliseconde qui suit, tout remarche parfaitement. La NIC a vue une collision, l application userland n y a vu que du feu.
L implementation pratique du Hurd est extremement instable ( en aout 2003 la VM paniquait toutes les 4h), mais le system de recuperation est si rapide de part sa conception, que le system est globalement stable. Qui prends garde a la mort d une fourmie ? le lendemain la reine a pondu 10 000 oeufs ...
[^] # Re: AMHA
Posté par dinomasque . Évalué à 3.
Quel bordel !
~>[]
BeOS le faisait il y a 20 ans !
# vaporware
Posté par morgendorffer . Évalué à -9.
M'enfin, les gens sont fascinés par ce qui remet en cause les solutions établies. Un relent de la théorie du complot qui veut qu'une solution reconnue ne l'est pas grace à ses mérites et qu'on nous cache une meilleur solution.
Ceux qui "croit" en hurd, boivent les discours sur ses avantages (comme avoirs plusieurs scheduleurs, VM, etc) que même le département vaporware de MS n'ose pas sortir, croit en hurd car ça les flattent. Ils pensent qu'ils sont "uniques" et font parti de l'élite qui comprend les tenants et aboutissants des OS et ne font pas parti du troupeau de mouton qui installe la dernière version de Linux.
Quand j'entends "hurd", je pense à Windows NT. MS aussi avait de jolis discours avec leur micro-noyau et disait qu'Unix était tout pourri d'un point de vu conception. Ben Windows 2000 n'est plus vraiment micro-noyau et les seuls micro-noyau _réel_ (dont Hurd fait parti) qui restent en sont encore au stade pré-alpha alors que l'idée et les tentatives d'implémentations ne sont plus tout fraiches.
Ça fait depuis des années et des années que Hurd fait du vaporware. Maintenant ça me fatigue et je me fous complètement de savoir où il en est, s'il a progressé, s'il remplacera ou pas Linux dans un système GNU.
[^] # Re: vaporware
Posté par doublehp (site web personnel) . Évalué à 10.
et les seuls micro-noyau _réel_ [...] qui restent en sont encore au stade pré-alpha alors que l'idée et les tentatives d'implémentations ne sont plus tout fraiches.
la tu me fais bondire: QNX est le system UNIX le plus connu chez les professionels de l embarque, monde que Windows CE penetre tres timidement.
QNX est en fait le system professionel le plus rapide et le plus plus petit du marcher. Il a un scheduling extreme, configurable, et peut etre stoque sur une ROM de 512k.
Tu imaginais que ton airbag de voiture etait gere par quoi ? WinXP ( 256Mo de RAM minimum) ? Linux ( scheduling a 100Hz par default sur 2.4 - je pense pas qu un seul professionel prenne le risque d un 2.6 sur un produit stable) ? SunOS ? MacOS ( qui ne marche que sur PPC, donc sur des CPU qui consomment enormement ) ?
Ben non ... la plus part des airbags sont geres par QNX. Leger, rapide, bon scheduling, stable, ecriture de driver comme dans un reve ( un driver est un simple programme C auquel le noyeau attribut une priorite haute, et authorise des acces au hard) ...
Je te fais deux dessins:
- Windows a detecte un choc sur votre capot; etes vous sure de vouloir ouvrire votre airbag ?
- sur un choc a 90kmh la vitesse de l impacte doit etre mesuree par un deplacement du parechoc sur 5cm; l enfoncement du pare choc dure donc 10^-7s ( prise de decision); l airbag doit etre deploye avant que l enfoncement ait atteint 1m (il faut que l airbag soit deploye avant que le moteur touche le mur, apres quoi le bloc moteur te rentres dans les jambes) ( je suis gentil - sur une smart, compte 40 cm ); une fois que la decision de deployer l airbag est prise, tu as 10^-5s pour le faire. Avec un Linux schedule a 100Hz, il te faut 9ms pour prendre une decision, et 5ms suplementaire avant que materiel ne soit instruit; soit un total de plus de 10^-2s ... tu as rate l echeance de plus de 3 marches sur l echelle de Richter ... tu est donc encastre dans ton volan.
Bon ... l air bag pourrait etre gere par un firmware, car les operations sont simples, mais si on aborde le sujet des ABS, APS, et re-equilibrage des suspensions dans les virages ( en fonction de la charge du vehicule, du couple sur chaque arbre, de l adherence ...), interviennent des calculs beaucoup plus complexes que pour un airbag ... et qui doivent pourtant etre geres tout aussi rapidement.
Mais j ai consience que le monde des systems embarques et du temps reel n est pas des plus connus, et peut etre un des plus ingrats : ils sont present partout, mais personne n en parles jamais.
[^] # Re: vaporware
Posté par RuleZ . Évalué à 3.
[^] # Re: vaporware
Posté par patrick_g (site web personnel) . Évalué à 5.
gniiii ?
y'a pleins de PPC dans l'embarqué (IBM PPC 401 et autres) car y'a un très bon rapport entre puissance et conso.
[^] # Re: vaporware
Posté par doublehp (site web personnel) . Évalué à 1.
[^] # Re: vaporware
Posté par Maclag . Évalué à 2.
Une partie soft décide après s'il s'agissait bien d'un accident ou d'un passage sur chaussée dégradée (et là, effectivement, il vaut mieux aller vite...). D'où les quelques problèmes de déclenchements intempestifs d'airbags pendant leur jeunesse...
[^] # Re: vaporware
Posté par Captainigloo . Évalué à 7.
Alors que les premier accelérométres étaient complétement mécaniques à échelle macroscopiques la nouvelle génération de capteurs sont maintenant directement intégrés sur silicium aux cotés de la logique du capteur. Ceci permet lors d'un choc brutal de ne pas "casser" le capteur (comme c'était le cas au début) et d'autre part d'avoir un seul et meme chip pour le catpeur et sa logique.
Société française réalisant des MEMS : http://www.memscap.com/fr/aboutmems.html(...)
Accelerométre de ches Analog Device : http://www.analog.com/en/prod/0,2877,ADXL320,00.html(...)
PS : je n'ai d'action chez aucune de ces deux sociétés ;)
[^] # Re: vaporware
Posté par bartman . Évalué à 4.
Il à autant d'expérience que Linux et puisqu'il était dédié d'abord à l'industrie, il me parait réèllement stable et est nativement Temps Réèl
Par contre, contrairement à GNU/Linux, Hurd, il est bien commercial, malgrè la version téléchargeable, moins pratique à mon sens pour le développement (ils doivent vivre quand même).
Et pour l'histoire des proc en embarqué, loin du PPC, il est à noté que de plus en plus d'ARM tournent dedans, et donc QNX vient de s'y mettre depuis peu.
Et ben oui, et d'autant plus que tu parles des airbags et autres ABS, dans cette ingratitude on peut y citer la logique floue.
[^] # Re: vaporware
Posté par doublehp (site web personnel) . Évalué à -1.
oui ... mais la on se comprends parce qu on est aware ... :)
je pense pas que le lecteur moyen de DLFP ait entendu parle de la Fuzzy logic ( desole, mais ca fait 3 ans que j etudie en UK ... je ne connais meme pas les traduction fr des termes techniques que j utilise quotidiennement: spread spectrum, core, wafer ... )
[^] # Re: vaporware
Posté par Cali_Mero . Évalué à 3.
Sous-estimer le lecteur moyen de DLFP : mauvaise idée :-) Je me reconnais dans le portrait du lecteur moyen, et pourtant j'ai eu l'occasion d'entendre un peu parler de logique floue (sur le plan théorique du moins). Certes, c'est plutôt réservé à un public averti, mais la population du site étant du genre technophile, n'hésite pas à discuter sur le sujet... Je te lirai avec attention.
BTW : spread spectrum = large bande, core +-= coeur, wafer = gaufrette.
[^] # Re: vaporware
Posté par Sebastien . Évalué à 8.
http://en.wikipedia.org/wiki/Fuzzy_logic(...)
http://fr.wikipedia.org/wiki/Logique_floue(...)
[^] # Re: vaporware
Posté par doublehp (site web personnel) . Évalué à 1.
ratai : etalement de spectre.
non seulement c est la traduction literale, mais ca corresponds 100 fois mieux a la definition que 'large' ...
justement; le but du SS est d etaler tout le spectre a l interieur d une bande etroite ... mais de le faire uniformement ...
[^] # Re: vaporware
Posté par morgendorffer . Évalué à 2.
Donc tu l'installes sur des serveurs...
> Tu imaginais que ton airbag de voiture etait gere par quoi ?
Il n'est pas géré avec QNX. Je le sais, je bossais dans les crash test.
> Linux ( scheduling a 100Hz par default sur 2.4
Et alors ?
Ça c'est pour le multi-tâche. Ce qui compte, c'est le temps pour délivrer une interruption (dans un contexte multi-tâche ou non).
Sinon tu peux mettre 100 000 Hz si ça te flatte.
> je pense pas qu un seul professionel prenne le risque d un 2.6 sur un produit stable
Ce sont principalement des professionnels qui bossent sur Linux 2.6 et selon toi c'est pour ne pas utiliser le noyau.
Ben voyons...
> la plus part des airbags sont geres par QNX
Non !
Par contre les systèmes de supervision peuvent utiliser QNX (je n'en sais rien).
> bon scheduling
Les airbir font du multitâche... On s'en fout du scheduling pour l'embarqué sur de si petit système (ça doit tenir sur quelques ko pour éviter au maximum la complexité).
> - sur un choc a 90kmh la vitesse de l impacte doit etre mesuree par un deplacement du parechoc sur 5cm
On voit que tu n'y connais rien en crash-test ni en informatique.
> Avec un Linux schedule a 100Hz
Mets le 100 000 Hz si c'est ton pied. Ou tout simplement branche un process sur /dev/rtc qui envoie une interruption toutes les micro-secondes. Tu peux aussi fixer le scheduleur de l'appli à SCHED_RR ou SCHED_FIFO si tu ne veux pas quelle ne soit intérrompue par un autre process. Et voilà l'affaire est dans le sac. Tu peux aussi utiliser rtlinux et mettre les éléments les plus "sensibles" au niveau du noyau pour gagner encore en temps de réponse. Avec un Linux 2.6 "classique" le temps de réponse sur une interruption (jusqu'au passage à l'applie en userlang) est de l'ordre de la micro-seconde.
> mais si on aborde le sujet des ABS, APS, et re-equilibrage des suspensions dans les virages
Là c'est un domaine où QNX peut-être utilisé. Pas dans les airbag.
> Mais j ai consience que le monde des systems embarques et du temps reel n est pas des plus connus
J'ai bossé 2 ans sur des applis temps-réel hard sous Unix et 2 ans en crash-test. Mais si tu le dis c'est que t'es un digne représentant de Hurd.
[^] # Re: vaporware
Posté par GaGadget . Évalué à 3.
Que veut dire cette phrase : "Mais si tu le dis c'est que t'es un digne représentant de Hurd." ?
Je ne comprends pas ...
[^] # Re: vaporware
Posté par RedIsDead . Évalué à 3.
Ben dis nous avec quoi c'est géré! je me suis interressé aux airbag maintenant
[^] # Re: vaporware
Posté par imalip . Évalué à 2.
Et en anticipation des remarques sur la "simplicite" apparente d'un tel systeme :
-ce n'est pas Minardi (qui utilise du Marelli, et je ne sais pas ce qu'il y a la-dedans)
-ca gere tout le chassis : volant, freins, embrayage, boite de vitesse, telemetrie, suspension active, radio, controle de motricite, etc...
[^] # Re: vaporware
Posté par doublehp (site web personnel) . Évalué à 1.
Je prefer moi aussi les firmwares ... mais ou finissent les firmwares ? ou commencent les OS ?
Le system monotache DOS est considere comme un OS ...
Des equipement electromenagers inclues une gestion de materielle, et sont pourtant equipes de firmwares ...
[^] # Re: vaporware
Posté par morgendorffer . Évalué à 0.
[^] # Re: vaporware
Posté par doublehp (site web personnel) . Évalué à 1.
Il est a mon gout trop jeune ... et je connais mille facons de le faire planter ( en jouant un peu avec les piles USB ou FireWire, je te fais paniquer une machine en 3 mn )
On voit que tu n'y connais rien en crash-test ni en informatique.
Alors devepolle je te prie.
Perso, je ne me consider pas comme informaticien; mais comme technicien multicompetances. Et cote bas niveau, je prefere la programmation de firmwares en ASM ... et ce n est pas toujours assez bas niveau pour mes besoins : je compte passer aux FPGAs :)
J'ai bossé 2 ans sur des applis temps-réel hard sous Unix et 2 ans en crash-test.
Alors explique nous la verite :) Je ne suis qu un stupide etudiant.
Mais si tu le dis c'est que t'es un digne représentant de Hurd.
eh :) merci :)
enfin je reste persuade que l embarque et le RTs sont bien moins connus que par exemple l infographie, ou la programmation system ... AMHA.
[^] # Re: vaporware
Posté par ccomb (site web personnel) . Évalué à 1.
Entre 10^-7s et 2ms ça fait une différence, t'as overclocké ta hp ou quoi ?
[^] # Re: vaporware
Posté par doublehp (site web personnel) . Évalué à 0.
ca fait bien 2ms.
# Pour le C++
Posté par Croweye . Évalué à 8.
[Why don't we rewrite the Linux kernel in C++? ]
In fact, in Linux we did try C++ once already, back in 1992.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:
the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.
In general, I'd say that anybody who designs his kernel modules for C++ is either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.
Feel free to make up (d).
Linus
[^] # Re: Pour le C++
Posté par Marc (site web personnel) . Évalué à 5.
[^] # Re: Pour le C++
Posté par Nico C. . Évalué à 7.
apres, chacun peut y voir de l'orgueil si il veut, moi j'y vois plutot de la conviction (bien ou mal placee, la n'est pas le probleme).
Imbolcus
A vot' service
[^] # Re: Pour le C++
Posté par Marc (site web personnel) . Évalué à 3.
In general, I'd say that anybody who designs his kernel modules for C++ is either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.
Feel free to make up (d).
On comprend les points techniques.
Maintenant, imagine que MS fasse le meme genre de declaration en comparant Linux et Windows. Est-ce que tu dirais le meme genre de chose, a savoir:
c'est surtout qu'il ne fait pas certaines choses pour de bonnes raisons (de son point de vue) et qu'il n'hesite pas a exposer ces raisons et les defendre (sans prendre de gant car il s'en fout)
et je doute pas qu'eux aussi ont de la conviction (bien ou mal placee)
Je crois que la difference est qu'ici, un culte a Linus est bien en place, et que personne n'oserait contredire le bonhomme.
In general, I'd say that anybody who designs his kernel modules for C is either
(a) looking for problems
(b) a C bigot that can't see what he is writing is really just ASM anyway
(c) was given an assignment in CS class to do so.
Feel free to make up (d).
[^] # Re: Pour le C++
Posté par Nicolas Bernard (site web personnel) . Évalué à 4.
Pour un noyau c'est très mal (tm) puisque c'est lui qui est censé fournir la base nécessaire à de telles actes (allocations de mémoire en particulier). Il est probable que si C++ était encore comme en 1986, époque où sa philosophie était, comme en C, "rien en runtime, tout pendant la compilation", Linus serait le premier à l'utiliser l'encapsulation et surtout le polymorphisme (l'encapsulation peut être simulée assez facilement en C) pouvant être pratique...
[^] # Re: Pour le C++
Posté par パパフラクス . Évalué à 1.
[^] # Re: Pour le C++
Posté par Paerro Trime . Évalué à 2.
[^] # Re: Pour le C++
Posté par morgendorffer . Évalué à 0.
Lis la lkml. Tout le monde n'est pas d'accord avec Linus et l'exprime. S'il existait un "meilleur Linus que Linus" pour maintenir Linux, il aurait remplacé Linus Torvalds. Ainsi va le logiciel libre.
[^] # Re: Pour le C++
Posté par WH (site web personnel) . Évalué à 1.
[^] # Re: Pour le C++
Posté par WH (site web personnel) . Évalué à 1.
Sinon, y a MenuetOS pour les mordus d'ASM :
http://www.menuetos.org/www/fr/indexfr.htm(...)
[^] # Re: Pour le C++
Posté par Anonyme . Évalué à 2.
Quand tu t'es pris la tête sur un problème et que tu as analysé les différentes solutions correctement, ton choix te parait le meilleur - sinon tu en aurai fait un autre - et les autre solutions possibles te pareesent mauvaises, voire très mauvaises.
Bon, reste qu'il peut y avoir un choix entre solutions équivalentes, mais quand Linus en parle - les rares fois ou j'ai pu voir ca - , il explique sont choix beaucoup moins agressivement.
[^] # Re: Pour le C++
Posté par Marc (site web personnel) . Évalué à 3.
idem qu'au dessus. Imagine que Bill tienne les meme propos quand il parle de linux que Linus quand il parle du Hurd.
Il dis quand meme que le Hurd est une connerie pour droguer, que c'est mal pense, etc etc. Je pense qu'on verait une petite revolution ici =)
[^] # Re: Pour le C++
Posté par Djouxxx . Évalué à 3.
Si Bill Gates argumentait avec des explications techniques derrière comme c'est le cas ici. Cela pourrait être intéresant à mon avis.
Djouxxx
[^] # Re: Pour le C++
Posté par chl (site web personnel) . Évalué à 4.
Bill est (ex?) president/directeur de MS. Il ne joue pas de role technique dans le developpement du (micro?) noyau Windows. Linus, lui est grandement impliqué dans le developpement du noyau Linux.
[^] # Re: Pour le C++
Posté par morgendorffer . Évalué à -1.
Et l'histoire a montré qu'il avait souvent raison. On ne fait pas l'un des meilleurs OS du monde ou le plus respecté en ayant tord. On n'attire pas les développeurs les plus talentueux et intelligents en disant des conneries. Linus n'a rien (pas d'argent, pas de moyen de pression, pas d'exclusivité (sauf sur le nom Linux)). Il est là où il est (mainteneur d'un des OS les plus respecté) car c'est actuellement le meilleur pour cette tache.
[^] # Re: Pour le C++
Posté par morgendorffer . Évalué à -3.
Je dirai que Linus peut avoir cette attitude. Il (avec d'autres) a fait un système extraordinaire. Ça lui donne quelques "privilèges" dont de ne pas macher ses mots.
Il y en a qui n'ont presque rien prouvé et qui font la morale à Linux.
C'est pour ça que Hurd me le pête. Hurd c'est :
- "nous ont a raison, nous ont fait l'OS du 21ième siècle (Ooops, trop tard), Linux c'est has been c'est pour les vieux cons qui ne savent utiliser que le C".
On devrait remercier 1000 fois le pragmatisme et l'indépendance (il n'est pas ou peu influencé par les phénomènes de mode) de Linus qui a permis d'avoir ce formidable noyau. Formidable au moins à l'usage. Si certains le trouve nul sur le papier => Je m'en fous.
[^] # Re: Pour le C++
Posté par Manuel Menal . Évalué à 7.
Concernant L4Ka::Pistachio, s'il est écrit en C++, il évite tout ce qu'on critique généralement sur le C++ : il n'utilise pas d'exceptions, pas de méthodes virtuelles, extrêmement peu d'héritage (quelques classes génériques avec de l'héritage pour les implémentations spécifiques à l'architecture), évidemment pas la STL, pas de templates, ...
Bref, du C avec le sucre syntaxique. Au lieu de faire des struct avec des pointeurs de fonction, il y a quelques class par ci par là. Même moi, qui pourtant ne supporte définitivement pas le C++ (allergie suite à une intoxication, un peu comme les fruits de mer vous voyez ?), je supporte très bien le source de L4Ka::Pistachio. C'est dire ;-)
[^] # Re: Pour le C++
Posté par thecat . Évalué à 4.
>il n'utilise pas d'exceptions,
>pas de méthodes virtuelles,
>extrêmement peu d'héritage
>évidemment pas la STL, (bon la OK ...)
>pas de templates, ...
La question logique qui en découle c'est : mais pourquoi ils utilisent le c++ ... pour faire "aware" ?
[^] # Re: Pour le C++
Posté par Manuel Menal . Évalué à 4.
# Des éléments de réponse plus détaillés
Posté par Manuel Menal . Évalué à 7.
Ensuite je suis tombé sur L4[6], Pistachio[7], Fiasco[8] et L4Linux[9].
Et c'est là que j'ai décroché... Quelles sont les différences ? Leur performances ? Leur (possible) avenir ?
Frédéric a plus ou moins répondu à ça. L4 est une famille de micro-noyaux. À l'origine, c'était le nom d'un micro-noyau que le très regretté Jochen Liedtke a écrit en assembleur pour x86 vers 1995. Jochen a écrit de nombreux papiers à son sujet, et il a également écrit une spécification pour ce noyau. De telle sorte que plusieurs implémentations ont vu le jour dans plusieurs laboratoires d'informatique, principalement en Allemagne (Karlsruhe et le projet L4Ka, Dresden et le projet Fiasco/DROPS) mais également chez nos amis Grands Bretons (Université de York, avec le premier port PowerPC), et même chez les Aussies (University of New South Wales, qui fournit beaucoup de documentations et de cours, et L4/MIPS).
Les spécifications ont évidemment évolué depuis, pour donner les spécifications X.0, puis X.2. L4Ka::Pistachio est l'implémentation de L4 choisie par le Hurd. Elle implémente la spécification X.2, la plus récente. La version précédente était L4Ka::Hazelnut, qui implémentait la spécification X.0. La voie choisie par Fiasco et l'Université de Dresde est différente, puisqu'ils continuent d'utiliser la spécification V2 (avec une compatibilité X.0), et se concentrent plus sur le développement de l'aspect "temps réel" (hard) de L4, dans le cadre de leur projet DROPS[0].
Quant à L4Linux, tout a presque déjà été dit. C'est un projet mené aussi bien par L4Ka que par TU-Dresden, qui vise à porter Linux sur L4. Les deux équipes ont des motivations similaires : pour TU-Dresden, c'est une partie importante de leur projet DROPS, parce que celà leur permet d'avoir la personnalité Linux classique, avec toutes les applications et fonctionnalités déjà existantes (prenez un binaire pour GNU/Linux, déposez le sur L4Linux, ça marche !) en parallèle avec leurs applications temps réel utilisant L4. C'est une façon assez simple de tester leur Fiasco, et surtout de fournir un environnement de développement efficace. Pour L4Ka, l'intérêt est d'avoir un environnement stable et complet pour que les développeurs puissent tester leurs applications pour L4, ou leurs changements dans L4, tout en disposant des fonctionnalités de Linux.
Qui plus est, L4Linux a servi de base aux tests[1] menés par L4Ka. Il est effectivement très intéressant de disposer d'une implémentation de Linux native pour x86 et de la même version, portée sur L4, pour mesurer l'overhead pur lié à l'utilisation d'un micro-noyau. Les tests ont donnés L4Linux 6 à 8% moins performant qu'un Linux natif. C'est extrêmement peu, considérant que Linux n'a jamais été conçu pour un tel usage, et donc pour tirer parti des avantages de L4 et des optimisations possibles. Considérez aussi que ces tests datent de 1997, et que L4 a énormément évolué depuis. Voilà qui ne laisse présager que du bon.
Pour l'auteur du journal, et pour les autres aussi. Cela fera bientôt l'objet d'une news DLFP, mais sachez que HurdFR existe bel et bien et est actif. N'hésitez pas à vous inscrire, posez vos questions, participer sur la liste d'HurdFR[2] (les archives ont été perdues récemment, ne cherchez pas... snif.), ou sur IRC[3]. N'hésitez pas non plus à adhérer ;-)
[0]: http://os.inf.tu-dresden.de/drops/overview.html(...)
[1]: http://l4ka.org/publications/paper.php?docid=650(...)
[2]: https://lists.hurdfr.org/mailman/listinfo/hurdfr(...)
[3]: #hurdfr sur irc.freenode.net
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.