Ça faisait un bail que je ne m’y était pas intéresse et là je viens d’aller voir le site. Ils sont passé sous git, ils ont un nouveau site (je sais pas depuis combien de temps) et le dernier commit date de novembre. Alors certes ce n’est pas comme linux, mais ça bouge ! Ça vie encore !
gnu.org/software/hurd/
c’est super…
mais est ce que c’est toujours envisageable sous Debian ?
Bien sur :smt003 tout comme le portage du noyau BSD, le gros avantages c’est que Debian ce dirige tout doucement vers la possibilité de laisser le choix à l’installation du type de noyau à l’administrateur de la machine.
Visiblement c’est même possible de l’avoir sous debian actuellement, il y a un lien pour un guide d’installation sur la page wikipedia.
à vrai dire, ça me tenterait bien de tester ça un jour. Cependant, qu’y a t’il à y gagner comparé au noyau linux? Car il semble que ce ne soit pas encore parfait au niveau des performances.
Vous avez des infos?
Pas de gestion USB, pas de window manager … Le pied !
Où est l’interet de ce noyau alors?
T’a pas eu la curiosité d’aller sur les pages des deux projets lire rapidement la description ?
Je trouve par contre le projets Hurd très ambitieux même si ça n’avance définitivement pas (sans doute dût au manque cruel de développeurs ), pour ce qui est du portage Freebsd, là c’est du énorme ( il fait véritablement la nique en quelques mois au projet antérieur de portage de netbsd ) il donnera la possibilité surement sous la prochaine stable ( squeeze théoriquement mais j’en doute, je verrai bien la prochaine ) donner la possibilité de choisir son noyau au choix.
L’intérêt c’est avant tout de finir un vieux rêve, permettent de développé un système d’exploitation qui s’installe sur toute les machines ( ARM, SPARC, PC, etc … ); mais cela à un coup, un coup en développement.
Je voit mal de tel projet avancer aussi vite que le noyau actuel développé par linus torvald.
Si jamais tu cherche des informations plus complètes regarde de ce côté : http://fr.wikipedia.org/wiki/Noyau_de_syst%C3%A8me_d%27exploitation
L’avantage c’est que tu pourras enfin travailler avec GNU et plus avec GNU/Linux
Aucun pour toi si tu pose la question, il faut s’y intéresser pour que ça ai un intérêt.
[quote=“thuban”]Visiblement c’est même possible de l’avoir sous debian actuellement, il y a un lien pour un guide d’installation sur la page wikipedia.
à vrai dire, ça me tenterait bien de tester ça un jour. Cependant, qu’y a t’il à y gagner comparé au noyau linux? Car il semble que ce ne soit pas encore parfait au niveau des performances.
Vous avez des infos?[/quote]
T’es marrant tu te dis que tu aimerais bien l’installer avant de connaitre ses fonctionnalités/différences avec ce que tu connais.
S’ils font une annonce officielle (debian.org/News/2009/20091007), kfreebsd sera dispo pour squeeze, même si cela retarde la sortie de squeeze, le port n’est pas compliqué dans la mesure ou ce n’est pas une nouvelle architecture matérielle. Et c’est une bonne nouvelle pour les vieilles bécanes qui supportent mal linux 2.6 
Mais revenons sur GNU/Hurd, vu que c’est le sujet 
Le vrai interêt du Hurd, au delà d’avoir un système GNU tout seul, c’est d’avoir un micro noyau, ce qui s’avère bien supérieur à Linux (monolithique) dans des applications critiques… qui d’entre vous n’a pas :
- eu besoin des magic sysrq, parce qu’une erreur d’entrée/sortie sur un disque secondaire a semi-gelé le système (je considère ça inacceptable…)
- eu besoin de tester à la barbare les options noacpi, noapic, irqpoll, modifier hwclock
- etc.
? Ben ça, sous Hurd, tu oublies (presque) ça, je me suis même amusé à mettre un disque dur complétement pourri, contrairement à Linux, Hurd ne fige pas lors des erreurs d’entrée sortie lors d’un simple dd 
Rien que ça, c’est formidable !
Ce qui est dommage c’est que grub est nécessaire, et c’est super compliqué comparé à lilo 
Et ouais, surtout pour l’USB… le reste emacs sait le faire, voire plus 
(sans oublier GNU screen - qui fait office de bon pseudo WM quand tu n’utilises que des applications en console)
[quote=“MisterFreez”][quote=“thuban”]Visiblement c’est même possible de l’avoir sous debian actuellement, il y a un lien pour un guide d’installation sur la page wikipedia.
à vrai dire, ça me tenterait bien de tester ça un jour. Cependant, qu’y a t’il à y gagner comparé au noyau linux? Car il semble que ce ne soit pas encore parfait au niveau des performances.
Vous avez des infos?[/quote]
T’es marrant tu te dis que tu aimerais bien l’installer avant de connaitre ses fonctionnalités/différences avec ce que tu connais.[/quote]
Ben oui, je voudrais l’installer pour voir la différence et comparer les performances, etc… Sinon j’ai bien lu sur wikipedia les avantages que ça avait au niveau matériel, mais pour le simple utilisateur comme moi qui ne comprend pas forcément tout ce langage technique très bien, je me fie à ce que je vois, donc je teste 
.
[quote=“Knucky”][quote=“Clochette”]il donnera la possibilité surement sous la prochaine stable ( squeeze théoriquement mais j’en doute, je verrai bien la prochaine ) donner la possibilité de choisir son noyau au choix.
[/quote]
S’ils font une annonce officielle (debian.org/News/2009/20091007), kfreebsd sera dispo pour squeeze, même si cela retarde la sortie de squeeze, le port n’est pas compliqué dans la mesure ou ce n’est pas une nouvelle architecture matérielle. Et c’est une bonne nouvelle pour les vieilles bécanes qui supportent mal linux 2.6 
[/quote]
Ils avaient aussi parlaient de dash par défaut sous lenny.
Ça c’est du domaine du troll, parle en à Linus tu comprendras. Pour lui il y a de gros problèmes de performances avec les micro noyau du fait que presque tout se passe en espace utilisateur.
Et ouais, surtout pour l’USB… le reste emacs sait le faire, voire plus 
(sans oublier GNU screen - qui fait office de bon pseudo WM quand tu n’utilises que des applications en console)[/quote]
J’ai pas eu le temps de bien regarder mais il semble que la bibliothèque pthread ne soient pas totalement portée. Ma formation d’ici juin devrait me permettre d’apprendre comment on fait pour l’implémenter (autant voir comment modifier le noyau que d’écrire la lib). Donc peut être que je vais enfin contribuer 
(doux fantasme…)
J’avais testé hurd il y qcq années mais avec grub. Je pense que je vais réessayer mais as tu des renseignements sur l’entrée qu’il faut mettre avec grub2?
[quote]
Et ouais, surtout pour l’USB… le reste emacs sait le faire, voire plus [/quote]Peut on éditer un texte avec emacs?
edit: mince je suis trahi par ma signature. :smt003
[quote=“limax”]
Et ouais, surtout pour l’USB… le reste emacs sait le faire, voire plus Peut on éditer un texte avec emacs?
edit: mince je suis trahi par ma signature. :smt003[/quote]
[explosion de rire] le retour du troll emacs / vim [/explosion de rire]
Ok, mais j’essaie de rester positif 
Bien sûr, et il aura tout à fait raison. Seulement, un discours basé sur la performance ne va pas me convaincre, tout comme ceux qui sous-utilisent leurs ressources matérielles, qui préféreront la fiabilité - je dirais pas que c’est un troll, mais un ensemble d’interêts divergeants qui font que Linux depuis quelques temps (surtout depuis la 2.6) ne correspond plus aux besoins de certains.
Quand je parle d’erreurs d’E/S bloquantes, et a la vue de ce que tu avances, tu sais mieux que moi ce qui se passe à ce moment là, et que quand je dis qu’un simple secteur défectueux dans un disque secondaire (données pures, rien à voir avec l’OS) peut freezer temporairement voire plus une machine tournant sous Linux, tu sais que je raconte pas de bêtises. Je l’ai vécu pas plus tard que ce matin, et je peux sortir le syslog si ma crédibilité est mise à mal
Ce qui s’est passé c’est bien simple - au lieu d’arreter toute opération de correction d’erreur d’E/S au premier échec sur un disque qui n’était pas vital au système - Linux s’amuse à vouloir corriger le problème, et ce en boucle (heureusement) finie. Je comprends que ma “solution” demanderait de tuer l’ensemble des processus utilisant le périphérique, mais l’accepte si cela permet de conserver mon système de base stable Parce qu’en attendant tout ce que j’ai vu c’est kflushd et kjournald qui pompent le CPU. Après ben démerdes toi avec une machine qui freeze de façon complétement aléatoire !
Pas un mot dans le syslog ou dans le tty pour me dire clairement que suite à une erreur d’E/S qui ne peut être résolue, je devrais lancer un ‘fsck’ (le -c -c j’ai trouvé moi même) sur les partitions. L’erreur est nommée “DRDY” - quand tu vois ça tu penses au cable/la nappe, pas aux secteurs, donc j’ai pas mal cogité… bref la galère sans infos pertinentes ni une gestion d’erreur tolérante. J’ai perdu une demi heure le temps de changer les cables, vérifier un éventuel faux contact etc., alors que le problème était très commun et simple à résoudre !
Bien entendu les alternatives que je propose là, seraient refusées, et j’ai pas les compétences pour modifier libata de façon appropriée, donc je critique (constructivement), mais je t’avouerais que je peux pas faire grand chose 
FreeBSD me cause pas d’ennuis au niveau noyau, mais aimant Debian par dessus tout, faudrait peut être que j’arrête d’écrire ce pavé et que je songe à migrer vers kfreebsd, car cette erreur a fait déborder le vase
Après l’interface chaise/clavier a peut être aussi fait une erreur, peut être que cette gestion est paramétrable, mais je vois ça nulle part dans la doc fournie avec les sources :’(
[quote]
il semble que la bibliothèque pthread ne soient pas totalement portée. [/quote]
J’ai testé en début d’année 2008 si je me rappelle bien et c’est ce qui était dit, tout comme toi j’ai pas trop suivi
J’utilise vim (d’ailleurs j’écris ce post avec vim via w3m…), donc je sais pas, mais il paraît qu’emacs peut même faire le café, alors ça doit être possible
(vim/emacs c’est trop gros, passera pas 
)
Aucune idée, vu que grub2 n’a pas le thème tasse à café et, plus sérieusement, me fout mon framebuffer en l’air malgré les modifications effectuées selon un post que j’avais lu ici et qui ont marché pour tout le monde sauf moi. Je garde donc le bon vieux lilo, qui ne m’a jamais trahi
[quote=“Knucky”][quote=“MisterFreez”]Ça c’est du domaine du troll, parle en à Linus tu comprendras. Pour lui il y a de gros problèmes de performances avec les micro noyau du fait que presque tout se passe en espace utilisateur.
[/quote]
Bien sûr, et il aura tout à fait raison. Seulement, un discours basé sur la performance ne va pas me convaincre, tout comme ceux qui sous-utilisent leurs ressources matérielles, qui préféreront la fiabilité - je dirais pas que c’est un troll, mais un ensemble d’interêts divergeants qui font que Linux depuis quelques temps (surtout depuis la 2.6) ne correspond plus aux besoins de certains.
Quand je parle d’erreurs d’E/S bloquantes, et a la vue de ce que tu avances, tu sais mieux que moi ce qui se passe à ce moment là, et que quand je dis qu’un simple secteur défectueux dans un disque secondaire (données pures, rien à voir avec l’OS) peut freezer temporairement voire plus une machine tournant sous Linux, tu sais que je raconte pas de bêtises. Je l’ai vécu pas plus tard que ce matin, et je peux sortir le syslog si ma crédibilité est mise à mal
Ce qui s’est passé c’est bien simple - au lieu d’arreter toute opération de correction d’erreur d’E/S au premier échec sur un disque qui n’était pas vital au système - Linux s’amuse à vouloir corriger le problème, et ce en boucle (heureusement) finie. Je comprends que ma “solution” demanderait de tuer l’ensemble des processus utilisant le périphérique, mais l’accepte si cela permet de conserver mon système de base stable Parce qu’en attendant tout ce que j’ai vu c’est kflushd et kjournald qui pompent le CPU. Après ben démerdes toi avec une machine qui freeze de façon complétement aléatoire !
Pas un mot dans le syslog ou dans le tty pour me dire clairement que suite à une erreur d’E/S qui ne peut être résolue, je devrais lancer un ‘fsck’ (le -c -c j’ai trouvé moi même) sur les partitions. L’erreur est nommée “DRDY” - quand tu vois ça tu penses au cable/la nappe, pas aux secteurs, donc j’ai pas mal cogité… bref la galère sans infos pertinentes ni une gestion d’erreur tolérante. J’ai perdu une demi heure le temps de changer les cables, vérifier un éventuel faux contact etc., alors que le problème était très commun et simple à résoudre !
Bien entendu les alternatives que je propose là, seraient refusées, et j’ai pas les compétences pour modifier libata de façon appropriée, donc je critique (constructivement), mais je t’avouerais que je peux pas faire grand chose FreeBSD me cause pas d’ennuis au niveau noyau, mais aimant Debian par dessus tout, faudrait peut être que j’arrête d’écrire ce pavé et que je songe à migrer vers kfreebsd, car cette erreur a fait déborder le vase
Après l’interface chaise/clavier a peut être aussi fait une erreur, peut être que cette gestion est paramétrable, mais je vois ça nulle part dans la doc fournie avec les sources :’( [/quote]
Je n’ai pas dis que tu avais tord ou raison je dis juste que ce thème est parfaitement capable d’embraser les foules (genre la lkml).
[quote=“MisterFreez”]
Je n’ai pas dis que tu avais tord ou raison je dis juste que ce thème est parfaitement capable d’embraser les foules (genre la lkml).[/quote]
On s’était bien compris Je vais pas aller discuter de ça sur la lkml - en tant que simple utilisateur comme moi, tu manques vite d’argument, mais je pense tout de même avoir pointé du doigt un dysfonctionnement qui pourrait être au moins mitigé pour un coût réduit, avertir l’utilisateur via un message approprié ça ne reste qu’un printk() si mes souvenirs sont bons !
Il me semble avoir lu quelque part qu’on pouvait arriver à faire tourner un semblant d’interface graphique…
Un des gros avantages de Hurd c’est quand même les translator: des serveurs qui gerent les entrées sorties d’un fichier. Et comme c’est en espace utilisateur et que ça ne requiert pas de privilège spéciale (puisque 'un translator s’occupe uniquement des fichiers auxquels il est associé, il n’y a pas besoin de privilège administrateur), on peut faire pas mal de chose facilement : il suffit d’une commande pour associer ou désassocier un translator à un fichier dynamiquement.
Concrètement vous pouvez choisir ce qu’il se passe quand vous essayez d’acceder à un fichier en particulier.
[quote=“limax”]as tu des renseignements sur l’entrée qu’il faut mettre avec grub2?[quote]Je me répond car os-prober trouve tout seule l’entrée qu’il faut.
normalement Je vire /etc/grub.d/30_os-prober et je me fais moi même dans /etc/grub.d/40_custom
menuentry "GNU/Hurd (on /dev/sda3)" {
insmod ext2
set root=(hd0,3)
search --no-floppy --fs-uuid --set 64f02ef6-3bcf-4e05-b2f6-f2e31412b842
multiboot /boot/gnumach.gz root=device:hd0s3
module /hurd/ext2fs.static ext2fs --readonly \
--multiboot-command-line='${kernel-command-line}' \
--host-priv-port='${host-port}' \
--device-master-port='${device-port}' \
--exec-server-task='${exec-task}' -T typed '${root}' \
'$(task-create)' '$(task-resume)'
module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)'
}