Non, Hurd n'a tjs pas avancé, Hurd est tjs pas stable, il a même l'air d'avoir de la peine à avancer.
Un journal ça sert à lancer une discussion donc pour ceux qui connaissent mieux le projet que moi, j'ai une question:
Pourquoi donc ce projet ne décolle-t-il pas?
Je vous rassure, je ne viens pas de découvrir le projet, mais qu'elle n'a pas été ma surprise quand j'ai vu que l'annonce par la FSF du lancement du projet datait de... 1991!!!
Le projet est vieux et pourtant aucune entreprise n'a osé se lancer dedans, personne n'en fait réelement quelque chose ,Debian n'est pas une entreprise, et si qqun veut en faire un business, qu'il me dise qui ca m'intéresse.
Le truc c'est que Hurd est vraiment une nouvelle idée. Mon problème avec tous les Unix like c'est qu'en fin de compte ils reprennent une idée vieille de 40 ans. Quand on regarde en arrière, on voit que les OS qui sont sur le marché ne sont en rien révolutionnaire.
La on a un système qui est stable par design ce qui veut dire que nous avons un système qui ne peut, théoriquement, pas complètement planté. On a également plus besoin de redémarrer, on peut utiliser plusieurs versions d'un même driver en même temps et le maintient du noyau est bien plus facile parce que la question est-ce qu'il faut oui ou non implémenter tel ou tel fonctionnalité n'existe pas vraiment. On arriverait dans la même situation que celle d'une distribution. Chacun développe sa partie, chacun est responsable de son code et tout le monde est content.
Conclusion, je n'ai ni les connaissances ni l'argent pour pouvoir réelement aider ce projet mais je crois qu'un système comme celui-là qui viendrait à être utilisable en production serait un gros coup de pouce pour l'open source car, pour la première fois depuis longtemps, l'open source aura devancer la concurrence.
Voila voila, bonne lecture, bon commentaires
# Malheureusement...
Posté par pasBill pasGates . Évalué à 9.
Ca ne serait rien de nouveau, cherches QNX sur Google et tu trouveras un OS qui fait deja quasiment tout cela si ce n'est tout, qui a plus de 10 ans, ... Il est notamment utilise pour certains composants de la navette spatiale, pour gerer des centrales atomiques, ... Bref, un sacre jouet.
[^] # Re: Malheureusement...
Posté par mobutu . Évalué à 8.
Aujourd'hui tu ne fais pas booter le noyau 2.6 sur cette même disquette :x
[^] # Re: Malheureusement...
Posté par bartman . Évalué à 7.
En effet, QNX est comme Hurd basé sur un microkernel, n'ent déplaise à Linus Torvald, je pense aussi que c'est l'avenir car bien mieux structuré qu'un monolithe kernelistique (ou un kernel monolite je sais plus) .
Seulement voilà, QNX est pleinement POSIX certains s'amusent par exemple à recompiler The Gimp dessus pour le prouver... dans la version téléchargeable. Car il y a la version payante et elle l'est méchament : programmeur de systemes embarqués je me suis renseigné chez QNX pour connaitre le prix d'exploitation du bijou. Il faut savoir qu'en plus des royalties que l'on doit verser sur chaque vente, le prix des licences est exhorbitant.....en plus de la formation obligatoire (évidemment). Malgrè cela il reste, depuis longtemps, la rolls des OS, et non pas pour la killing démo sur la disquette.
Alors pour revenir à The hurd : je le suit aussi depuis longtemps, et je regrette bien qu'il ne soit resté qu'à ce stade, je pense qu'un jour quelques personnes vont se réveiller et on aura alors tout d'un coup un envollée parceque ce sera le best mieux OS, et je vous promet
de beaux trolls.....
[^] # Re: Malheureusement...
Posté par Jérôme Pinot (site web personnel) . Évalué à 2.
Et si :-)
J'avais fait un "live-floppy" autour d'un linux 2.6 :
http://linuxfr.org/~ngc891/17088.html
Pour le code :
http://ngc891.blogdns.net/pub/projects/jnuxband/0.2/
La première version utilisait un 2.6.9-rc2. Je vais peut-être m'y remettre, d'ailleurs.
[^] # Re: Malheureusement...
Posté par kolter (site web personnel, Mastodon) . Évalué à 3.
De plus QNX est propriétaire, ce qui en fait un "jouet" bien moins intéressant, si tu vois ce que je veux dire ... :p
M.
[^] # Re: Malheureusement...
Posté par B16F4RV4RD1N . Évalué à 1.
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: Malheureusement...
Posté par Fabimaru (site web personnel) . Évalué à 7.
http://en.wikipedia.org/wiki/Hard_real-time
[^] # Re: Malheureusement...
Posté par kraman . Évalué à 2.
Leur boulot, c'est des os pour les particuliers et le desktop pour le business, pas des systemes ultracritique...
[^] # Re: Malheureusement...
Posté par Marc Poiroud (site web personnel) . Évalué à 3.
^_^
[^] # Re: Malheureusement...
Posté par Calim' Héros (site web personnel) . Évalué à 4.
[^] # Re: Malheureusement...
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Par ailleurs, son support s'arrètera avant 2010 ;-(
Bref, on n'aime ou on n'aime pas les centrales mais on n'aime pas XP !
[^] # Re: Malheureusement...
Posté par pasBill pasGates . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Malheureusement...
Posté par pasBill pasGates . Évalué à -1.
Brack said the lab is not centrally managed and therefore lends itself well to using a mix of varied operating systems. Aside from Windows and several flavors of Linux, the lab also runs HP Unix, Mac OS and Solaris, he said.
...
"Our personal view is that Linux, period, is only for the desktop. We don't run our main servers on Linux, because there are too many flaws in main Linux kernel," he said.
Bref, ils ont du Windows, Linux, Mac, ... et ils n'utilisent Linux que comme Desktop et rien d'autre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Malheureusement...
Posté par kraman . Évalué à -3.
Marrant, je crois qu'il fallait etre intelligent pour rentrer la bas.
Ou au moins avoir un cerveau
Que tu fasses ton guignol sur MS je vuex bien (tu es paye pour)
hehe, c'est toujours mieux que de faire le guignol contre ms gratuitement, hein.
'fin j'dis ca...
lui au moins, il argumente ces propos.
Pis surtout, il passe pas son temps a regarder ce que font les mecs d'en fasse pour s'empresser d'aller pondre un journal sur windowsfr.org en disant "hé hé hé, zavez vu? en face c'est des cons"
/me, chaud comme une baraque a frite pendant la canicule en ce moment.
[^] # Re: Malheureusement...
Posté par pasBill pasGates . Évalué à 1.
Je me doutes bien qu'ils ont des serveurs sous Linux qqe part comme a peu pres tous les environnements academiques/recherche, je m'amusais simplement a pointer le fait que l'article que tu donnes dis exactement l'inverse de ce que tu pretends.
[^] # Re: Malheureusement...
Posté par Richard Braun . Évalué à 3.
# Pourquoi faire simple quand on peut faire compliqué ?
Posté par Grumbl . Évalué à 6.
Parce que ceux qui auraient le talent de le faire ne parviennent pas à se convaincre que ça leur serait utile à quoi que ce soit. J'avoue d'ailleurs à titre personnel ne toujours pas comprendre à quoi "me" servirait quelque chose de plus complexe qu'Unix.
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Tom . Évalué à 6.
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par kowalsky . Évalué à 5.
Unix marche pas trop mal, que se soit dans son parfum linux ou même (et surtout :)) BSD, donc je ne vois pas
trop trop pourquoi il faudrait rediviser les "forces" en redevellopant tout les drivers
et autre userland...
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par David Roon . Évalué à 1.
Les raisons sont:
1.On entend de plus en plus que le noyau devient difficilement maintenable.
2.Ca serait clairement un système qui pour les entreprises serait intéressant et pour les particuliers aurait l'avantage d'être plus flexible. Le truc c'est que je vois quelque chose avec un potentiel énorme.
Disons que je vois dans Hurd le système d'exploitation le plus adapté à la communauté du libre car il est à l'image d'une communauté; un nombre incalculable de donneur de services de part le monde :)
Je pense également que la raison pour laquelle personne ne s'est lancé là-dedans c'est que personne n'a encore essayé de se faire de l'argent dessus. Je ne sais même pas si dans les universités il y a des projets pour améliorer Hurd? Je sais que le noyau est développé par l'université du Michigan mais à part ça...
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par kowalsky . Évalué à 5.
Je ne vois pas hurd decoller dans les 10 ans à venir.
1°/ Le nombre de personne qui boss sur l'existant est tout bonnement inimaginable...!
Je suis abonné à plusieur mailing NetBSD, le traffic y est de 100 ou 300 mails environ,
post par jour, ce qui n'est rien du tout comparé à d'autre liste. Mais même la, le nombre
de probleme soulevé et traité est enorme. Des truc inimaginable parfois... Sur des trucs
dont je ne soupsonnais même pas l'existance, même si je suis relativement pauvre
techniquement, des fois, vraiment, ça va chercher loin... Sur du materiel d'une diversité
folle, même juste pour l'archi x86...
Je veux dire par la, la somme de travail pour un projet "petit en communauté" comme NetBSD
est IMMENSE.
Alors imagine toi, trouver du jour au lendemain, des gens competent, qui n'ont pas
peur de bosser "pour rien", créer un truc tout nouveau.
C'est à dire sans support d'USB, sans support reseau, sans support de quasi
rien du tout en fait. Donc sans utilisateur. Donc sans une tripoté de beta teseur acharné.
Je pense que la masse nescessaire à tout ça est deja prise à plein d'autre chose.
Non, franchement, je ne dis pas jamais, mais c'est pas avant un bon bout de temps
que le hurd sera pret pour le lamba des informaticiens bidouilleurs. Alors imagine
pour le monde de l'entreprise...!
2°/ Tout ça pour quoi...? Pour pas grand chose en fait. Même si Linux le noyau etait 200%
plus rapide, ton "systeme" ne serais pas 200% plus rapide. Ou alors chez hurd, ils vont
tout réecrire, du ls à gcc en passant par X et apache...?
Et même la, le jeu en vaudrait il la chandelle ?
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Sylvain Briole (site web personnel) . Évalué à 6.
J'en doute, surtout que les micro-noyaux ont relativement mauvaise presse dans pas mal de situations par rapport à un bon vieux noyau monolithique.
Ce que je vois de plus intéressant, c'est ce système de micro-noyau qui ne fait que l'essentiel, qui est donc théoriquement plus facile à maintenir, permettant à tout un chacun de rajouter des greffons dessus sans forcément compromettre la stabilité du système dans l'ensemble.
Un système peut-être plus facile à appréhender intellectuellement qu'un Linux par exemple, où le ticket d'entrée pour maîtriser le noyau et tout ce qu'il met en jeu est relativement élevé.
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par fabien . Évalué à 3.
puis,
de totue evidence, cette question est la plus importante a tes yeux, mais j'aimerai que tu soit plus explicite, ou est-ce qu'on entent de plus en plus que ce noyeau devient difficilement maintenable à la fin ?
J'en ai jamais entendu parlé moi. et en tout cas pas par des personnes qui justement le maintiennent...
T'as des infos a ce sujet ? ou des liens par exemple ?
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Sylvain Briole (site web personnel) . Évalué à 3.
Les raisons sont:
1.On entend de plus en plus que le noyau devient difficilement maintenable.
De quel "noyau" ou variante d'Unix veux-tu parler?
Linux? FreeBSD? NetBSD? OpenBSD? ... Minix?
En ce qui concerne par exemple le dernier, j'ai quand même des doutes qu'on le qualifie de "difficilement maintenable" ;-).
Ou alors faut se préparer à une belle "flamewar" avec Tanenbaum ;-).
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Vincent (site web personnel) . Évalué à 2.
Le micro noyaux Mach+des bouts de BSD , y'a pas déja des gens qui ont essayé d'en fait un Unix user-friendly ?
http://fr.wikipedia.org/wiki/XNU
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Grumbl . Évalué à 1.
# En même temps Linux...
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Si Hurd ne décolle pas, c'est sûrement qu'il n'y a pas assez de développeurs et qu'ils passent plus de temps dans des discussions interminables qu'à coder. Je sais pas, mais j'ai l'impression que tous les ans ils remettent tout à plat... Après avoir *enfin* réussi à se décider de quitter le micro-noyau Gnu Mach (qui était vraiment vieux, genre années 70 je crois) pour L4... ben ils parlent de quitter L4. Merdeu, il faudrait savoir ce que vous voulez :-)
On parle souvent de Linux, mais l'autre noyau qui a l'air vraiment très intéressant, c'est celui de FreeBSD !
http://linuxfr.org/~grom/22938.html
Haypo
[^] # Re: En même temps Linux...
Posté par briaeros007 . Évalué à -4.
[^] # Re: En même temps Linux...
Posté par ʭ ☯ . Évalué à 2.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: En même temps Linux...
Posté par kraman . Évalué à 2.
couillu l'caribou, couillu...
[^] # Re: En même temps Linux...
Posté par GCN (site web personnel) . Évalué à 6.
[^] # Re: En même temps Linux...
Posté par ʭ ☯ . Évalué à 2.
Pour info, si ton pilote IDE est chargé comme comme un module, tu peux faiure du hot-plug IDE en déchargeant / rechargeant le pilote. Mais là, vaut mieux pas avoir / sur un disque IDE ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: En même temps Linux...
Posté par briaeros007 . Évalué à 2.
Un dd ne reset pas comme ca pour faire plaisir.
Et si c'est si faux que ca, (et je pose la question a TOUS les moinsseurs )
Tu peux m'expliquer pourquoi :
1°) j'ai paumé 10h ce samedi parce que j'avais un dd qui me faisais un reset quand on utilisait trop le dma, ce qui avait comme effet de freezer le noyau (meme si ce n'est pas le dd systeme)
2°) pourquoi quand tu fais une requete nfs , que tu la monte sans option particulière, et que tu enleve le cable alors qu'une appli utilise le nfs, tu ne pourras plus rien faire avec ton appli (non meme pas la tuer)
.Faudra attendre que le nfs envoie les données à l'appli pour que ca se remette a marcher.
Et avant de me dire 'c'est faux c'est ton noyau qui est pas bon' j'ai essayé ce we avec un noyau 'classique' (le 2.6.12 venant de base avec ma deb) avec un 2.6.17 'vanilla' et un 2.6.18 - real time ...
Ben les trois me pété dans les mains quand mon dd faisait son reset.
Encore une fois un reset c'est un VRAI reset, au cours d'une requete, c'est pas arreté un disque quand on ne l'utilise pas (et pour cela hdparm -y ton_dd est préférable)
Essaie de faire la meme chose en plein lancement de ton xawtv (avant qu'il soit en mémoire) et donne moi les nouvelles ;)
[^] # Re: En même temps Linux...
Posté par kraman . Évalué à 1.
ya pas un timeout ou equivalent dans les options de montage nfs?
ca peut etre une piste, j'ai deja experimente ce genre de pb.
Quand au fait de ne pouvoir tuer l'appli, j'ai eu la meme chose avec des dvds foireux (disque mort) ou un disque dur a la rue (taquet de secteurs deffectueux).
Faut attendre un certain temps (long. surtout quand t'es comme n con devant la console a faire ctrl c ctrl c ctrl c kill -9 kill -9) pour qu'il accepte de killer.
[^] # Re: En même temps Linux... est un LL
Posté par chtitux (site web personnel) . Évalué à 2.
Report the bug.
Un bug reproductible, identifiable, qui embête le monde et qui fait planter tout, c'est à mon avis LA chose à faire quand ça arrive.
Alors ça prend 10 minutes (voire plus), faut assurer un suivi derrière, mais ça peut aider des milliers (au moins :) de personnes derrière toi.
À mon avis, c'est aussi à cause de ça que Hurd n'avance pas à la vitesse de croisière. Peu de contributeurs, peu d'utilisateurs, peu de feedbacks, peu d'amélioration, peu d'utilisateurs, peu de developpeurs, peu de fonctionalités, peu d'utilisateurs, peu de feedback, beaucoup de problèmes, peu d'utilisateurs ...
Si ya bien une chose à faire pour faire avancer le Gnou, c'est d'en mettre un chez soi ...
[^] # Re: En même temps Linux... est un LL
Posté par briaeros007 . Évalué à 1.
Le problème est archi connu , c'est exactement le meme type de probleme qu'en nfs.
La seule possibilitée serait de redémarrer le systeme dma - ou faire un watchdog sur les requetes dma - Loin d'etre simple, et surtout avec un surcout non négligeable.
(et puis je t'avouerais qu'actuellement j'ai autre chose à faire que de faire un bug report, d'autant plus qu'il ne suffit pas de 'lancer gdb et récup la trace' vu qu'il n'y a PAS de trace, il ne peut plus faire d'i/o donc ...)
Mais bon je regarderais ca un peu plus en détail t'inquiète ;)
Pour kraman, oui il y a une option timeout en nfs, c'est pour ca que j'ai dis 'que tu la monte sans option particulière' ;)
[^] # Re: En même temps Linux... est un LL
Posté par tomachaka . Évalué à 3.
Tu peux retirer le câble, l'appli va bloquer, et quand tu rebrancheras elle reprendra au même endroit comme si de rien n'était. Ce qui peut-être utile dans certains cas.
Si tu veux une erreur I/O et donc que l'appli s'arrête dès que la connexion est perdue il faut le demander explicitement au montage.
[^] # Je m'y colle...
Posté par fabien . Évalué à 3.
Ben pourquoi tu ne l'utilise pas alors ?
"Ouais, tu te rends compte, il a sauté sans son parachute, et ben à la fin son parachute ne s'est pas ouvert, il s'est crashé en bauté, c'est trop nul..." :)
[^] # Re: Je m'y colle...
Posté par briaeros007 . Évalué à 2.
peut etre tout simple que quand je monte un nfs en vitesse pour faire des tests j'ai autre chose a faire que me taper le man pour trouver 'la bonne option qui vas bien' ?
En outre je vois pas en quoi le fait d'etre médisant fait avancer le schimblick, mais visiblement faut etre agressif pour paraitre intelligent ...
[^] # Re: En même temps Linux...
Posté par Anonyme . Évalué à 3.
Et bien linux se porte comme un charme, bon certes tous les processus demandant un accès disque se bloquent en attente d'I/O (un brin emmerdant) mais a part ca tout fonctionne.
[^] # Re: En même temps Linux...
Posté par briaeros007 . Évalué à 2.
[^] # Re: En même temps Linux...
Posté par Olivier Serve (site web personnel) . Évalué à 10.
[^] # Re: En même temps Linux...
Posté par iug . Évalué à 1.
En fait la plupart des bugs de modules sont invisibles pour l'utilisateur. C'est déjà assez rare que dans ce cas le module soit "planté" et de là à ce qu'il plante le reste du noyau y'a une marge. Attention je dis pas que c'est impossible, le driver ayant accès à tout l'espace d'adressage du noyau, il peut toujours tout faire merder.
Par exemple j'ai un noyau patché avec le patch Realtime de Ingo Molnar, et mon driver de carte son le supporte pas au mieux. Assez souvent un bug du driver module doit me faire relancer mon application. De temps en temps, ma carte son n'est plus utilisable et je dois rebooter.
A lire troll sur troll les gens ont un peu trop l'habitude de faire l'erreur de raisonnement:
théoriquement ça peut planter => ça marche pas du tout
Théoriquement, il y a une bonne probabilité pour qu'à chaque accès mémoire, tu doivent recharger une ligne de cache et perdre plus de temps que s'il n'y en avait pas. C'est vraiement de la merde les caches, on devrait les supprimer.
[^] # Re: En même temps Linux...
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
En même temps, l'un des trucs géniaux de Hurd était la possibilité à l'utilisateur de rajouter lui-même ses devices (genre FTPfs ou NFS). Avec fuse, Linux a comblé son retard "théorique" :-)
[^] # Re: En même temps Linux...
Posté par Stéphane Davy . Évalué à 1.
# Parallélisme, nouveau défi
Posté par Ontologia (site web personnel) . Évalué à 3.
Cela risque de se généraliser, dixit intel themselves (aller, au hasard : http://www.x86-secret.com/popups/articleswindow.php?id=125 ) avec des architectures masivement multicoeurs.
Le problèm est que le niveau technique des programmeurs pour gérer le massivement multi thread ne va pas évoluer exponentiellement lui.
Et les archi d'Os actuelles vont rapidement trouver leur limite (ceux qui me connaissent vont comprendre, "suivez mon regard", oui je sais, mais mon propos n'est pas de défendre ma crèmerie, simplement de faire un constat).
Ils ont à mes yeux deux défauts :
- Ils sont basés sur une architecture paginés, même pas segmentée, mais paginée. Hors une archi paginée tue le parrallélisme : elle oblige à passer très souvent par le noyau, avec tous les problèmes que cela comporte.
- Ils sont essentiellement architecturés pour être procéduraux et ne permettent le fonctionnement de logiciel émergent (architecture Com/Dcom et maintenant .Net chez kro, et Kpart chez Kde) que par l'intermédiaire de bidouille plus ou moins "crade".
Alors Hurd ? Ben j'y crois pas.
Le problème du Hurd est que son micronoyau possède peu d'info, et qu'il a donc du mal à optimiser.
Et en plus c'est encore écrit dans un langage à pointeur ce qui le rend amha trop complexe à gérer.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Parallélisme, nouveau défi
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Il est clair que le Hurd est intéressant mais ne décolle pas. D'un autre coté, l'informatique a bien évolué depuis 15 ans. Quittes à faire autre chose, autant le faire dans un autre langage que le C qui montre quand même ses limites aujourd'hui.
Pourquoi pas dans un langage à prototype qui parait très bien adaptés à la problèmatique. Pourquoi pas en Lisaac ?
Bon, pour faire cela, il faudrait que l'INRIA joue pour une fois vraiment le jeu de l'opensource avec IsaacOS. L'INRIA a une carte à jouer, c'est à elle d'abattre son jeu si elle souhaite pouvoir un jour remplacer sur nos postes le système Linux. Mais qu'elle ne traine pas trop !
[^] # Re: Parallélisme, nouveau défi
Posté par David Roon . Évalué à 2.
A lire le petit explicatif ça a l'air pas mal mais je ne suis pas sûr de comprendre comment ça marche. Si j'ai bien compris il n'y a pas de noyau mais il y a des objets qui cohabitent. Je ne comprends juste pas comment ça marche, c'est à dire qui décide quel est le niveau de sécurité de chaque objet? C'est un objet?
Sinon c'est vrai c'est intéressant. Affaire à suivre également
[^] # Re: Parallélisme, nouveau défi
Posté par Ontologia (site web personnel) . Évalué à 4.
Ca veut dire que Inode peut hériter de Controleur_DD ou controleur_USB, comme ça quand tu fais des appels vers le parent, ça va au bon endroit.
Le noyau est "émergent" : tu as quelques objets "noyau", le sheduler, le gestionnaire mémoire, et comme ils ont tendance à naturellement communiquer en permanence, ça forme un noyau.
Pour la sécurité, pour le moment, il n'y en a pas. Ca sera aux futur devs de IsaacOs de se préoccuper de ce genre de chose.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Parallélisme, nouveau défi
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Parallélisme, nouveau défi
Posté par kolter (site web personnel, Mastodon) . Évalué à 3.
moi je le vois évoluer tous les jours, dernièrement un dev à fait fonctionner du pcmcia et du wifi ....
>Quittes à faire autre chose, autant le faire dans un autre langage que le C qui montre quand même ses limites aujourd'hui.
tu peux expliquer ? que conseille tu comme langage pour programmer un OS ?
>Pourquoi pas dans un langage à prototype qui parait très bien adaptés à la problèmatique. Pourquoi pas en Lisaac ?
moi je veux bien, mais lisaac il fait comment pour écrire dans les regsitres de ton controlleur scsi ? je voudrais bien voir le code en lisaac qui fait ça ... et si c'est pour le faire direct et avoir un accès en ring 0, ça doit être beau... si c'est pas le cas il faut bien un noyau même petit ou simili pour faire l'interface sécursié entre le userland et le hardware ...
alors issacos c'est bien joli mais moi hurd, je le démarre et je peux faire l'irc avec, isaacos, je demande à voir ... et puis hurd pêche par le nombre de dev mais même si isaacos est le truc conceptuel le meilleur du monde si les dev ne sont pas intéressés par le langage et par porter des applications dessus ça ne décollera pas plus voir même jamais ...
M.
[^] # Re: Parallélisme, nouveau défi
Posté par Ontologia (site web personnel) . Évalué à 3.
Heureusement, ça fait tou même 15 ans qu'il existe !
tu peux expliquer ? que conseille tu comme langage pour programmer un OS ?
Lisaac puisqu'il a été principalement conçu pour ça.
http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
Page 48.
En gros l'astuce consiste à inliner du C dans une section INTERRUPT (qui sera donc compilé en fonction), et quitte à inliner du C, inlinons directement de l'ASM.
En particulier pour une interruption tu ouvres une section __BEGIN_INTERRUPT__
Tout l'IsaacOs a été codé comme ça, et sont écris en Lisaac le driver du controleur disque, le driver vidéo, clavier, souris, etc...
Pour ce qui concerne la sécurité, l'OS est conçu pour utiliser les 4 ring des processeurs intel, mais ça n'a pas été implémenté pour faciliter le port sur des processeurs sans ring.
Tu trouveras toutes les explications ici :
http://isaacos.loria.fr/papers/cfse.pdf
alors issacos c'est bien joli mais moi hurd, je le démarre et je peux faire l'irc avec, isaacos, je demande à voir ... et puis hurd pêche par le nombre de dev mais même si isaacos est le truc conceptuel le meilleur du monde si les dev ne sont pas intéressés par le langage et par porter des applications dessus ça ne décollera pas plus voir même jamais ..
Ce sont des OS qui n'ont pas du tout le même age, et le deuxième n'est pas encore libéré, rien n'est comparable.
On en reparle dans deux ans !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Parallélisme, nouveau défi
Posté par Ontologia (site web personnel) . Évalué à 10.
Donc comme on aime faire bien les choses, on le fera quand le compilo fonctionnera bien, que la doc de la lib sera faite, et surtout qu'on réussira à faire tourner IsaacOS dans un qemu, le tout dans un distrib assurant au dev d'être à l'aise.
Je suis contre (et Benoit aussi) le fait de lancer dans la nature un Os qui compile pas, avec une lib pas documentée, etc... Ca donnerait une très mauvaise image au projet qui raterait ainsi son décollage.
Tout cela étant dit, je pense que ça sera prêt dans moins de 6 mois (j'espère) :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # lisaac
Posté par pikapika . Évalué à 2.
[^] # Re: Parallélisme, nouveau défi
Posté par patapon . Évalué à 2.
Amha :
- C'est les architecture memoire des machines qui sont basées sur la pagination, l'os ne fait que s'adapter. La majorité des problèmes se trouvent au niveau hardware (synchronisation du/des cache(s))
- La pagination permet d'offrir un espace d'adressage propre à chaque processus, et je vois mal comment faire du parrallèlisme sur sans cet espace d'adressage unique.
- Quelque soit l'os (considéré comme preemptif), on passera toujours par le noyau pour gerer l'ordonnancement et la priorité des processus (c'est son role !), un ou n processeurs embarqués sur la machine ne changent rien à cet etat de fait. La contrainte introduit par la pagination sur l'os est le comportement à adopter en cas de defaut de page, et ça releve plus d'une insuffisance matérielle (pas assez de memoire) que d'un defaut de conception de l'os.
[^] # Re: Parallélisme, nouveau défi
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Le temps que la R&D finisse tout ça et on aura ça dans nos machines. A priori, même pour les machines bas de gamme, ce sont les processeurs mono-coeur qui vont se faire rares d'ici quelques mois.
[^] # Re: Parallélisme, nouveau défi
Posté par iug . Évalué à 1.
Une bonne question aux aficionados des micronoyaux est "comment allez vous donner un accès matériel ala DRM/DRI aux applications ?"
[^] # Re: Parallélisme, nouveau défi
Posté par Charles-Victor DUCOLLET . Évalué à -2.
[^] # Re: Parallélisme, nouveau défi
Posté par gemegik . Évalué à 2.
http://dri.freedesktop.org/
http://www.google.com/codesearch?q=show:uSI_CHtkHCM:xMKMVx97(...)
[^] # Re: Parallélisme, nouveau défi
Posté par Charles-Victor DUCOLLET . Évalué à 0.
sinon, merci pour l'info, ça m'évitera de dire une connerie la prochaine fois !
# La cathédrale et le bazar
Posté par Joris Dedieu (site web personnel) . Évalué à 8.
Mais au delà de ces questions naturelles, il reste que Linux a su créer l'émulation nécessaire pour attirer, développeurs et utilisateurs et être aujourd'hui à même d'assurer des performances correctes et un excellent support du materiel.
Cela Hurd n'a pas su le faire. Et tout projet Libre, aussi génial soit-il qui ne saura pas développer un minimum d'entousiasme sera fatalement condamné à rester dans sa tour d'ivoire.
Lire ou relire la cathedrale et le bazar.
http://www.linuxfr-france.org.invalid/article/these/cathedrale-bazar/c(...)
[^] # Refaisons le monde
Posté par iug . Évalué à -1.
On est toujours obligé de créer des composants bas-niveau pour les assembler et en faire de plus haut niveau et ainsi de suite. Les systèmes me parraissent pas mal comme couche la plus basse. Evidemment, je parle là du noyau et des quelques outils annexes qui servent à le faire tourner.
Les parties avec lequel on interragit en temps que end-user (X/Gnome) vont devoir évoluer et démultiplier leur nombre de couche avant d'arriver à une interractivité plus humaine.
# Et pourquoi pas !!!
Posté par GoNoGo . Évalué à 6.
Que voit on aujourd'hui, les même fonctionnalités qu'il y a plus de dix ans en informatique :
- la gestion des I/O de plus en plus lourde (les gestionnaires de volumes logique au dessus des disques physique)
- les machines avec plusieurs CPU (tient comme au temps des mainframe)
- les hyperviseurs (encore comme au bon vieux temps des mainframe).
Alors, hurd, vieux ? Cela ne veux rien dire, par contre, la souplesse apportées par hurd, sa "légèreté", sa petite empreinte mémoire (à comparer avec le monolitique mamouth noyau Linux.
Oui il faudrait des développeurs, mais qui peut se lancer dans du développement de noyau ? Pas moi, et pas grand monde parmis les nombreux lecteurs de ce petit message. Pourquoi les entreprises privées, celle qui développe le noyau Linux ne s'y mettent-elles pas (precisément parcequ'elles ont choisit Linux). Reste la communauté, la vraie, qui pourrait faire émerger ce système que beaucoup de monde attend. Avec l'avénement des multi coeurs, de la virtualisation, Hurd a sa carte à jouer, ne voit on pas, parmis les plus gros calculateurs de cette planète, des machines qui fonctionne avec un micro-noyaux !!
L'avenir est devant nous, et nous y tourneront le dos, à chaque fois que nous regarderont le passé. Ne tournons pas le dos à notre futur, et vive les micro-noyaux.
[^] # Re: Et pourquoi pas !!!
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 4.
Maintenant, comme cela a été dit plus haut, le principal problème de Hurd (à mon avis) réside dans le fait qu'il n'arrivent pas à stabiliser leur couche basse. On ne peut pas attirer des bonnes volontés en disant qu'il faut développer Hurd sur gnu-mach mais que bientôt on passera à L4 ou autre. Je pense que les bonnes volontés ont besoin d'une certaine assurance que leur contribution n'est pas vouée à l'oubli. Surtout qu'en faisant ainsi, on divise l'équipe de dev en deux (ceux qui bossent sur L4 et ceux qui bossent sur gnu-mach), réduisant aussi la productivité globale.
Personellement, le message que je lancerai à l'équipe de Hurd c'est de faire un choix et l'assumer (gnu-mach, l4, autre). Par assumer, j'entend éviter de parler d'un RetourAZero avant une version stable qui a ateint le point critique (cité plus haut) en terme de nombre d'adeptes.
[^] # Re: Et pourquoi pas !!!
Posté par kraman . Évalué à 0.
Non, ca c'est clair, c'est pas un probleme en soi.
Le probleme c'est qu'en 15 ans on a toujours rien de stable ni d'utilisable...
Et la, ben faut pas prendre les gens pour des lapins de 3 jours, ca va finir par se voir que ca aboutira jamais...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Résultats de quelques investigations
Posté par psychoslave__ (site web personnel) . Évalué à 6.
Si le hurd n'a pas décollé, c'est entre autre parceque les développeurs trop peu nombreux avait un peu de mal à se fixer un roadmap, notamment avec l'histoire de mach, puis l4, l4.sec, l4-ng, etc. comme expliqué plus haut.
Pour les cotés plus positif, je suis tombé sur hurdfr[1], qui à l'air carrément plus actif que le projet principal. Ils ont mis en place un wiki, ce fixe des objectifs, mettent en place une infrasturture pour soutenir le développement (mise à disposition de machine de test en ssh). Pour l'instant ils développent sous mach, et dans un avenir lointain il passeront peut être à l4-ng (si je me souviens bien), mais ce n'est vraiment pas à l'ordre du jour. Apparement sa code plus que ça ne parle...
[1] http://hurdfr.org
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Résultats de quelques investigations
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Par ailleurs, il faut savoir que la virtualisation résoud aussi un gros problème pour Microsoft vu que sous Windows, tout tourne en root. Avec la virtualisation, Microsoft a une bonne occasion de résoudre ce problème, un service = une machine virtuelle.
Bref, les hyperviseurs ont une force de frappe d'un paquet de développeurs qui sont près à graver une partie de la solution dans le silicium.
Encore une fois, c'est pas forcément le meilleur qui gagne mais ceux qui gagne montrent qu'ils arrivent à s'adapter.
# En fait Hurd est loin d'être tout seul....
Posté par David Roon . Évalué à 1.
Pour les liens:
L4AK Project: http://www.l4ka.org/
DROPS: http://os.inf.tu-dresden.de/drops/ ils ont plusieurs projets
http://l4hq.org/ Et pour avoir des infos sur les différents projets:
Tout ça pour vous dire que je ne soupçonnait pas du tout qu'il y avait autant de projets pour des micro noyaux. ça va m'en faire de la lecture... et moi qui ai encore des examens... Bon ben ça sera pour après :)
Mais ces sites me font penser que Hurd, contrairement à ce que je pensais avant et ce qui a été écrit ici, est loin d'être tout seul. Maintenant on entend surtout parler de Hurd mais je me demande s'il n'y a pas d'autres projets qui ne sont pas plus avancés/mieux foutus.
Pour lancer un nouveau OS, il faudra tout d'abord arriver à s'affirmer comme serveur fiable, et cela a l'air d'être le cas aux USA vu que leur système de votation a tourné sur un OS avec micro kernel et ensuite le reste viendra.
Bon ben moi je vous laisse, j'ai un examen de prog demain et si je veux en plus lire tout ca...
[^] # Re: En fait Hurd est loin d'être tout seul....
Posté par kraman . Évalué à 1.
hehe
je savais pas que macosx, XP ou vista etaient consideres comme des serveurs fiables... :-)
sinon, c'est quoi une votation? le fait de votater?
[^] # Re: En fait Hurd est loin d'être tout seul....
Posté par David Roon . Évalué à 1.
Et Non c'est pas une votation, c'est ce qu'on appelle une reconnaissance du marché. Linux est devenu "fiable" non au moment où le système était stable mais au moment où les décideurs ont cru en ce système. Bref pour lancer un nouveau SE, il faut que les gens qui ont plein d'argent et bien ils aient confiance. Quand une grosse société se dit:"allez, on migre tout notre système vers un nouveau système", il faut qu'il y ait une garantie.
Voili voilou
[^] # Re: En fait Hurd est loin d'être tout seul....
Posté par kraman . Évalué à 1.
Et pourtant, tu connais beaucoup de serveur (de prod, hein, je te parle pas de jean kevin en deug mias dans la cite U de bures sur yvette) sous windows XP ou macos?
[^] # Re: En fait Hurd est loin d'être tout seul....
Posté par finss (site web personnel) . Évalué à 2.
\_o<
[^] # Re: En fait Hurd est loin d'être tout seul....
Posté par kraman . Évalué à 0.
maintenant, si tu lit mon commentaire, je parlais de XP, pas de 2003 server.
bref, cf ma reponse a machin en dessous
[^] # Re: En fait Hurd est loin d'être tout seul....
Posté par David Roon . Évalué à 1.
Je ne vois pas tellement où tu veux en venir...
[^] # Re: En fait Hurd est loin d'être tout seul....
Posté par kraman . Évalué à 1.
Pour lancer un nouveau OS, il faudra tout d'abord arriver à s'affirmer comme serveur fiable
pour autant que j'en sache, 2003 server est sorti apres que XP se soit impose, et macos server doit avori une part de marche egale a celle de linux sur le desktop chez microsoft (1 psote, celui de pbpg :-D )
'fin bref, je vois pas d'ou sort cette affirmation, mise a part d'un chapeau...
[^] # Re: En fait Hurd est loin d'être tout seul....
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Cela dit, si je peux éviter, j'évite...
[^] # Re: En fait Hurd est loin d'être tout seul....
Posté par Vincent (site web personnel) . Évalué à 1.
Y'en a qui s'amusent avec des Xserve et Mac OSX server, tu crois qu'ils vont s'en sortir ?
http://serverlogistics.com/hosting.php
C'est plus au niveau de ce que ça leur coûte sur le matos et les licences, que je m'inquièterai de la fiabilité des boites qui utilisent ce genre de solutions.
# Wikipedia enlarge your point of view
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 2.
Elle liste un certain nombre (voire un nombre certain pour reprendre un jeu de mots bien connu) d'OS libres. Cela permet de se rendre compte que Linux n'est pas la seule alternative.
A lire absolument par tous les curieux.
# Re: Hurd, une si belle idée et pourtant.
Posté par Richard Braun . Évalué à 5.
C'est difficile aujourd'hui, pour une entreprise, d'investir dans la R&D de systèmes d'exploitation. Quand on regarde de près, tous les systèmes actuellement majeurs dans l'industrie sont nés dans des universités (BSD, Mach, même Linux). ce n'est qu'une fois le développement initial terminé qu'ils deviennent rentables, et que les entreprises s'y intéressent. Il y a bien sûr des exceptions.
Pour autant, Hurd n'est pas vieux, il est même trop jeune, puisque les nouveaux concepts n'ont pas encore pu être véritablement éprouvés (et en réalité, on s'est aperçu de quelques défauts très difficiles à corriger dans le Hurd actuel).
> La on a un système qui est stable par design ce qui veut dire que nous avons un système qui ne peut, théoriquement, pas complètement planté.
Non, ça c'est une légende urbaine... Un micronoyau, ça ne fait pas tout. Dès qu'un serveur critique comme le serveur qui s'occupe de l'émulation POSIX ou le serveur d'authentification des messages tombe, tout tombe. Simplement ces serveurs sont isolés, et en général pas trop gros, donc facilement auditables.
> On a également plus besoin de redémarrer,
Plus ou moins. Mis à part les pilotes matériels, on peut en effet tout manipuler sans redémarrage complet du système. Mais je ne considère pas ça comme un véritable avantage du Hurd, simplement un effet secondaire d'une conception de qualité.
> un système comme celui-là qui viendrait à être utilisable en production serait un gros coup de pouce pour l'open source
Le Hurd n'est pas prêt pour la production. Quand bien même la couche basse serait stable, il y a toujours des problèmes de gestion de ressources qui n'en font pas encore un bon système pour la production (on n'est pas loin, mais ça demande une reconception).
Le principal problème, c'est trop de bugs. Il y a également quelques incompatibilités très gênantes avec POSIX. Et trop peu de bons développeurs pour arranger le coup (les bons bossent surtout sur une reconception nécéssaire du Hurd en ce moment). Mais ça va venir ... :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.