Site de HurdFR de nouveau disponible

Posté par  (site web personnel) . Modéré par Manuel Menal.
Étiquettes : aucune
0
30
juin
2004
GNU
Le site de l'association francophone HurdFR est désormais accessible sous une forme totalement nouvelle. Ce site permettra à toute personne intéressée par le Hurd de partager son expérience.

Ainsi, HurdFR est depuis un an et demi une association loi de 1901 dont l'objet est de promouvoir et de développer le système d'exploitation libre GNU/Hurd. Cette association a pour but l'échange d'information, en physique (ateliers locaux au sein des GULL, réunions sur Paris, province et dans les pays francophones, conférences), ou sur les listes de diffusion (list@hurdfr.org), un canal IRC (#hurdfr sur irc.freenode.net), et également par l'écriture de documentation sur le thème de GNU/Hurd.

Pour ceux qui ne connaissent pas le GNU Hurd, c'est le projet GNU visant à remplacer le noyau monolithique classique d'UNIX. Le Hurd était la seule chose qui manquait en 1991 au projet GNU pour proposer un système d'exploitation complet. Le Hurd est une collection d'applications fonctionnant en espace utilisateur, autour d'un micro noyau (Mach actuellement, mais bientôt L4). Ce type de système est destiné à fournir une plus grande flexibilité d'utilisation et d'applications.

PS : merci à Manuel, eon et Duck qui ont rendu possible la disponibilité de cette nouvelle version du site. (NdM : et merci à Arnaud pour les mêmes raisons.)

Aller plus loin

  • # bug bizarre ...

    Posté par  (site web personnel, Mastodon) . Évalué à 8.

    $ curl -I http://www.hurdfr.org/(...)

    Server: Apache/1.3.29 (Debian GNU/Linux) mod_ssl/2.8.14 OpenSSL/0.9.7b mod_perl/1.29 PHP/4.3.3

    Il faut remplacr GNU/Linux par GNU/Hurd dans /etc/httpd/conf/commonhttpd.conf section response ....

    --------->[okilfébodehor]

  • # Page "Liens"

    Posté par  (site web personnel) . Évalué à 2.

    Surpris de ne pas voir de tribune libre en première page et de ne pas trouver de lien direct vers cette page ô combien primordiale, je suis allé vérifier qu'on pouvait bien y accéder via la page "Liens".
    Et là, c'est le drame : je clique sur http://news.hurdfr.org/(...) et en réponse, Mozilla ouvre une nouvelle fenêtre pour afficher le site. Je déteste ce comportement ! Le webmaster ou qui que ce soit n'a pas à décider à ma place si le lien doit s'ouvrir dans une nouvelle fenêtre ! Ce comportement intrusif a pour conséquence de multiplier inutilement le nombre de fenêtres ouvertes et ça devient le souk en moins de deux, de plus il ne tient pas du tout compte de la navigation par onglets, qui est devenue un standard. Les liens qui s'ouvrent dans une nouvelle fenêtre sont donc à proscrire.
    Je referme donc la fenêtre indésirable... pour constater que la page a également été chargée dans l'onglet que j'utilisais pour découvrir le nouveau site de la Hurd ! J'en reste circonspect, et ma surprise va grandissante quand je décide de regarder le source de la page des liens : premièrement la mise en page est effectuée avec une longue suite de tableaux ! Quelle horreur ! Seconde vision d'horreur, la gueule du lien : <a href="http://news.hurdfr.org(...)" onclick="window.open(this.href)"> http://news.hurdfr.org(...) </a> ! J'ai du mal à saisir l'intérêt du Javascript, à part pour énerver le visiteur.

    • [^] # Re: Page "Liens"

      Posté par  . Évalué à 2.

      Corrigé. Je comprends pas bien comment ça s'est retrouvé là, mais dans tous les cas un petit coup d'emacs, et de tla commit a suffi :)
      Pour ceux qui l'auraient remarqué, http://hurdfr.org(...) marche maintenant (et pas seulement http://www.hurdfr.org(...) donc).

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Page "Liens"

        Posté par  (site web personnel) . Évalué à 2.

        Euh... flemme :p
        Plus sérieusement, j'imagine que ce genre de workarounds doit poser des problèmes avec certains sites, non ? Par exemple avec les liens de vote de dlfp ?

        • [^] # Re: Page "Liens"

          Posté par  (Mastodon) . Évalué à 3.

          Bonne question,
          j'ai testé avec Firefox 0.9.1+ extension singlewindow (qui me met toutes les nouvelles fenêtres dans un nouvel onglet), et ça passe. Le "popup" ne s'ouvre pas dans un onglet et disparait comme prévu.

    • [^] # Re: Page "Liens"

      Posté par  . Évalué à 3.

      Ne serait-il pas bien si on pouvait paramétrer le navigateur pour ne PAS tenir compte du _blank et companie ?
      Ainsi c'est le visiteur qui choisit de continuer à naviger dans le même onglet (clique) ou alors d'ouvrir le lien dans un onglet (clique milieu).
      Parceque la navigation par onglet c'est bien... mais si le moindre lien peut ouvrir une nouvelle fenêtre l'interêt tombe d'un seul coup.

      Remarque : il est possible de dire à firefox de ne pas tenir compte du blank, mais c'est une grosse bidouille dans le fichier de conf (et puis les liens JavaScript ouvrent toujours un nouvel onglet au lieu de continuer dans l'onglet actuel :-/ ).
      Une chtite option dans la fenêtre de préférences ca ne mange pas de pain, non ?

      Ou alors c'est une fonction trop "power user"...

  • # Ou qu'on clique ?

    Posté par  (site web personnel) . Évalué à 3.

    Le Hurd ça fait longtemps que j'en entends parler, mais je n'ai rien de palpable...

    Il est où le lien >> Téléchargements << ?

    -->[ilfébodehors]

  • # Question (pas taper merci, je m'interroge)

    Posté par  (site web personnel) . Évalué à -3.

    Ca sert à quoi le hurd, pouisqu'on a Linux comme noyau ?

    • [^] # Re: Question (pas taper merci, je m'interroge)

      Posté par  (site web personnel) . Évalué à 5.

      Trolleur insid a dit :
      Ca sert à quoi le hurd, pouisqu'on a Linux comme noyau ?

      Tu portes bien ton pseudo toi :)

    • [^] # Re: Question (pas taper merci, je m'interroge)

      Posté par  (site web personnel) . Évalué à 1.

      Ca sert à quoi Linux, puisqu'on a Windows ?
      Ca sert à quoi FreeBsd, puisqu'on a Windows ?
      Ca sert à quoi Windows, puisqu'on a Dos ?

      Je croyait que la philosophie de la variétée et du choix était bien comprisent dans le monde du libre...

      Sans vouloir troller, il y a beaucoup de chose dans le Hurd qui serons mieux que sou linux, à mon avis. Et c'est pour cela que quand une version sufisament utilisable (du système complet) sera disponible, je basculerait probablement.
      Je ne dit pas que le Hurd est mieux que Linux (oups GNU/Linux, desolé RMS) mais Le Hurd à des avantages tels que les translateurs par exemple, qui pour moi justifierons le changement.

      Le problème du Hurd c'est qu'il est quand même long a venir...

      PS: Est-ce que quelqu'un sait si ils se sont débarrasser de la putain de limite de 2Go ?

      • [^] # Réponse au PS

        Posté par  (site web personnel) . Évalué à 1.

        J'avais lu sur hurdfr (je crois) quand il etait encore sous dacode
        que c'etait fait
        ou alors un patch experimental
        je sais plus trop

      • [^] # Re: Question (pas taper merci, je m'interroge)

        Posté par  . Évalué à 1.

        > PS: Est-ce que quelqu'un sait si ils se sont débarrasser de la putain
        > de limite de 2Go ?

        La dernière news que j'ai lu concernant cette limite remonte a plus de 6 mois, elle disait qu'il y avait un patch pour dépasser les 2Go en version beta. Etant donné que je n'ai vu aucune autre news depuis, je suppose qu'il est toujours en version beta ou au mieux en release candidate.

        http://news.hurdfr.org/gen.php3/section/Hurd/63,0,1,0,0.html(...)

        • [^] # Re: Question (pas taper merci, je m'interroge)

          Posté par  . Évalué à 6.

          Tout à fait. Ce patch est une modification importante puisqu'elle change fondamentalement la façon dont sont gérés les systèmes de fichiers sous GNU/Hurd : il est forcément l'objet de débats, donc son inclusion n'est pas chose simple. Il ne faut pas non plus oublier qu'un patch sur une telle partie ne s'applique pas à la légère, puisque des risques de corruption de données sont à la clef. Enfin, il s'inscrit dans un travail plus général réalisé par Ognyan pour implémenter ext3fs sous GNU/Hurd, avec ACLs et tout ce qu'on peut attendre d'un système de fichiers moderne prenant avantage de GNU/Hurd.
          Pour toutes ces raisons, il n'est pas pour l'instant question de l'inclure dans l'ext2fs par défaut. Il est disponible en RC1, ainsi que des paquets le fournissant. À titre personnel, je recommande son utilisation sur des données non sensibles, et pour tous les FS sauf /. De toutes façons, utiliser des données sensibles non backupées sous GNU/Hurd est irresponsable à mon sens :) (vous me direz, des données sensibles non backupées, c'est irresponsable.)

  • # a contre courant

    Posté par  . Évalué à 2.

    il est amusant de voir un noyau ecrit en C++ (L4Ka::Pistachio microkernel) alors que les grands courants vont plutot vers le C voir l'assembleur.

    • [^] # Re: a contre courant

      Posté par  . Évalué à 2.

      PS (pre-scriptum): sautez le dernier paragraphe si vous n'avez pas envie de faire un calin à un gros troll velu! Le reste est sérieux.

      C'est marrant, mais personnellement, le courant je le voyais aller dans l'autre sens : utilisation de langages de plus en plus loin de la machine pour des choses de plus en plus bas niveau.

      Je crois qu'au début d'Unix (qui ne devait pas encore porter ce nom-là, d'ailleurs, mais je m'égare), les auteurs ont failli finir avec la tête au bout de piques parce qu'ils avaient osé coder la bête dans un langage d'un niveau beaucoup trop élevé (le langage C)!

      Bref, ce qui est surprenant, c'est le choix de C++ (qui pue très fort quand même), pas le choix d'un langage de haut niveau.

      Snark

      • [^] # Re: a contre courant

        Posté par  . Évalué à -1.

        Bref, ce qui est surprenant, c'est le choix de C++ (qui pue très fort quand même), pas le choix d'un langage de haut niveau.

        Comme Python? :o)

    • [^] # Re: a contre courant

      Posté par  . Évalué à 8.

      Les choses sont un peu plus complexes que ça, tout de même. La tendance en Osdev n'est toujours pas au retour à l'assembleur qu'on nous prédit depuis de longues années déjà. L'Osdev, comme l'IA, connaît des modes, et conséquemment des retours de mode qu'il est facile de mal interpréter. Ainsi, la mode a été, pendant une grande partie des années 80, jusqu'au début des années 90 - jusqu'à Chorus, Amoeba, ... - au dépérissement des noyaux (si je puis employer cette analogie) : micro-noyaux bien sûr, mais aussi exo-noyaux, nano-noyaux, OS « structurés verticalement », etc. Et évidemment, comme toute mode, on s'emballe, et on finit par être déçu. Du coup, nos prophètes préférés nous annoncent la mort des micro-noyaux, choix idéologique dépassé. Le travail important qui a été fait par le regretté Jochen Liedtke sur L4, relayé par de nombreux autres, la place qu'il a occupée pour ce travail chez IBM me semble montré qu'on est allé un peu vite en besogne.
      Il en va de même pour les langages en Osdev. La deuxième moitié des années 1990 a connu une vague de mode des langages « haut niveau », dont on voit encore les traces aujourd'hui. D'où une prolifération de JavaOS, mais aussi d'OS écrits entièrement en C++, entièrement objets, à base de templates, etc. On finit par se rendre compte que la tentation du « langage unique » n'a pas de sens, et du coup on a tendance à délaisser les langages plus haut niveau en Osdev. D'où une vague de retour aux langages plus bas niveau. Le retour en assembleur est très minime, puisqu'il pose de nombreux problèmes.

      Je pense que le choix de C++ comme langage pour L4Ka::Pistachio est un choix équilibré et raisonnable en fonction des objets que l'équipe s'est fixé. Le but de L4Ka est de créer une implémentation de L4 qui combine au mieux performances et portabilité. En ce sens, l'assembleur était à exclure. L4Ka s'est aussi fixé comme but celui de créer des abstractions suffisantes pour modéliser de façon efficace, simple et concise les fonctionnalités que doit implémenter le micro-noyau. Ils ont jugé le C++ les aiderait à clarifier ces abstractions, et à rendre l'API plus simple. Pour éviter la perte de performances en contrepartie, le choix a été fait de se limiter à un sous-ensemble étudié du C++ : pas de « virtual », pas de templates, très peu d'héritage, rien de dynamique (bien évidemment !). Dans les faits, on se rend compte que les performances sont au rendez-vous, et la clarté aussi.

      On peut ensuite discuter le choix du langage. Je n'aurais pas fait le même choix. Mais comme répond la FAQ de L4Ka::Pistachio à la question « Pourquoi est-ce codé en C++ ? » : « it just is. »

    • [^] # Re: a contre courant

      Posté par  . Évalué à 2.

      t'as des liens ?

      Sinon c'est quand meme un peu normal que les noyaux sont ecrits en language assez bas niveau : ils peuvent pas se permettre de ce trimbaler des tas de lib/VM/... necessaire au languages haut niveau comme java,...
      Ils ont aussi besoin de pouvoir faire des manipulations sur les pointeurs pour pouvoir ecrire en memoire,...

      De plus pour l'assembleur meme s'il est utilisee au minimun tu peux pas y echaper : tu fait comment en C pour recuperer/retourner d'une interuption, sauver les registres, ...
      Mais apres je crois pas que ce soit une tendance de l'utilisee : tu veux quand meme avoir un code lisible et qui puisse etre facilement portabe....

      • [^] # Re: a contre courant

        Posté par  (site web personnel) . Évalué à 5.

        Salut à tous,

        Attention à la confusion habituelle entre sémantique de haut niveau, et programmation de bas niveau.
        Il n'y a pas de contradiction, ce n'est tout simplement pas la même chose.

        Illustration du niveau sémantique du langage. Je veux décaler des éléments d'un tableau a :

        en Ada : 
        a (5..7) := a (10..12);

        Je fait une affectation avec une syntaxe de haut niveau. Mon intention est clairement exprimée par le code, le compilateur vérifie à la compilation que j'affecte bien une tranche de tableau dans une autre de même taille, et que tout tombe bien dans le tableau, sans débordement.

        en C :
        memcpy(a+5, a+10, 3*sizeof(*a))

        Je ne manipule plus un tableau, mais de la mémoire : le niveau sémantique est plus bas. Accessoirement, cela réduit les possibilités d'optimisation du compilateur. Mais surtout, c'est illisible, et pour les contrôles, tiens, fumes!

        Si je dois écrire la gestion de la mémoire d'un OS, on voit tout de suite avec lequel des deux langages le code sera le plus limpide.
        Ceci montre qu'une sémantique de haut niveau est parfaitement indiquée pour faire de la programmation de bas niveau.

        Maintenant, parlons de la programmation de bas niveau. Ada est un langage de haut niveaux, et pourtant c'est aussi l'outils idéal pour faire un OS portable :
        - maitrise totale et portable de la représentation des données en mémoire, contrôle au bit prêt du mapping, contrôle de l'alignement, contrôle de l'adresse, contrôle de la volatilité, contrôle de l'atomicité de l'accès, etc.
        - contrôle de l'allocation mémoire. Possibilité, par exemple, d'avoir des allocateurs dans différents pool mémoire avec des algos différents.
        - contrôle des accès concurrents par les puissants "objets protégés" (pas besoin de manipuler des sémaphore au risque d'oublier d'en libérer un)
        - utilisation des interruptions intégrée dans le langage
        - tasking d'une puissance inégalée ailleurs. Ada est le seul langage à ma connaissance qui te permet d'écrire complètement un ordonnanceur sans appel à une API extérieure type POSIX, même avec des algos complexe genre EDF/LLF, etc.
        - possibilité de faire vérifier par le compilateur des dizaines de restrictions possible (pour des besoins de certification), comme par exemple l'interdiction des allocations dynamiques.
        - possibilité d'insérer de l'assembleur
        etc. etc.

        Et pour finir, un OS est un gros logiciel : c'est exactement ce pourquoi Ada a été conçu. Tu profites donc de tous les "ité" : lisibil, maintenabil, portabil, modular, fiabil, etc :-)
        Par exemple, pour reprendre un point de Manuel, je n'ai jamais vu un projet Ada banir les templates. Ils sont utilisables en toute tranquilité.
        Et pour reprendre un de tes points, la gestion des pointeurs en Ada est un modèle, ils sont utilisable avec une sécurité rare. Pour créer une "dangling référence" en Ada, il faut vraiment le faire exprès.

        Tout ca pour dire qu'il y a au moins un langage de haut niveau doué pour la programmation de bas niveau.

  • # Lien et contenu périmés

    Posté par  . Évalué à 1.

    Guide d'installation de Neal Walfield (version périmée)
    publié sur le site le 27/12/2003 par arnaud, mis à jour le 27/06/2004 par mmenal
    Le guide d'installation officiel de Debian GNU/Hurd. Doublement périmé : il utilise la cross-installation à l'ancienne (alors qu'aujourd'hui crosshurd est recommandé) et la traduction est elle-même obsolète.

    Je me demande l'utilité de mettre à disposition un lien vers un texte qui est périmé et qui est heureusement plus disponible.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.