Nouvelles versions logicielles du projet GNU avril et mai 2017

Posté par  (site web personnel) . Édité par Davy Defaud, ZeroHeure et Nils Ratusznik. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
66
5
juin
2017
GNU

Le projet GNU publie tous les mois une liste de versions logicielles publiées. Jetons‐y un coup d’œil pour découvrir de nouveaux logiciels inconnus (de moi), des infâmes bogues disparus ou les promesses de solutions à tous nos besoins : soit 33 nouvelles versions annoncées allant de la corrective mineure à la version attendue depuis des années ; et l’on va donc parler de acct, artanis, bc, diffutils, emacs, emms, freedink-data, gcc, global, gnubik, gnupg, gnutls, grub, guile, guile-cv, guile-ncurses, icecat, kawa, less, libcdio-paranoia, libidn2, libmicrohttpd, linux-libre, nano, ocrad, orgadoc et parallel.

Sommaire

acct-6.6.3 (avril)

Il s’agit d’une mise à jour mineure de cet outil d’enregistrement des actions sur le système (nom d’utilisateur et processus), pour incorporer des correctifs venant de SUSE et Red Hat.

artanis-0.2.1 (mai)

On y trouve quelques corrections de bogues et un peu plus de robustesse pour cette boîte à outils pour applications Web (WAF) en Guile Scheme.

bc-1.07.1 (avril)

La version apporte principalement des compléments documentaires et quelques corrections de bogues pour cette calculatrice à précision arbitraire.

diffutils-3.6 (mai)

Cet ensemble d’outils pour comparer des fichiers reçoit une nouvelle fonctionnalité (si un fichier comparé est le début de l’autre), des corrections de bogues et une amélioration de performance sur les gros fichiers.

emacs-25.2 (avril)

Cet éditeur polyvalent a connu une version mineure corrective.

emms-4.3 (mai)

Ce logiciel utilisé pour gérer les fichiers multimédia dans emacs reçoit quelques corrections, affiche plus de métadonnées à l’exécution et moins d’avertissements à la compilation.

freedink-data-1.08.20170409 (avril)

Les données de ce jeu d’aventure et de rôle à la Zelda sont complétées par deux nouveaux sons, une traduction en suédois et des mises à jour des traductions catalane, espagnole et allemande, ainsi qu’une construction reproductible.

Capture freedink

gcc-7.1.0 (mai)

Cette suite de compilateurs a ou aura sa propre dépêche pour détailler les nouveautés.

global-6.5.7 (mai)

Cet outil pour étiqueter du code source reçoit une nouvelle option --nearness, des nouveaux alias GTAGSOBJDIR et GTAGSOBJDIRPREFIX, une nouvelle commande --print, la prise en charge des espaces de noms et traits de PHP 5 et supérieur, et des corrections de bogues.

gnubik-2.4.3 (avril)

Il s’agit d’une mise à jour des traductions et la correction de bogues mineurs pour ce jeu de puzzle de type Rubik’s cube.

Capture gnubik

gnupg-2.1.21 (mai)

Cette suite d’outils autour d’OpenPGP corrige principalement un bogue important introduit par la version précédente, la suppression du squelette de configuration par défaut (remplacé par celui du système), l’installation sans être administrateur sous Windows et divers bogues.

gnutls-3.5.12 (mai)

Cette bibliothèque pour gérer les protocoles SSL, TLS et DTLS connaît une version corrigeant divers bogues (sans changement d’API ou d’ABI).

grub-2.02 (avril)

La précédente version 2.00 de ce chargeur d’amorçage datait de 2012. Cette version apporte notamment des améliorations sur l’interface graphique et la prise en charge de nouvelles plates‐formes comme ARM, ARM64 et Xen, ainsi qu’une meilleure prise en charge de coreboot (en pratique les distributions GNU/Linux utilisaient déjà des pré‐versions de la 2.02 depuis longtemps).
Exemple de thème tiré de la doc Ubuntu (source de l’image)

guile-2.2.2 (et 2.2.1) (avril)

Ce langage de programmation reçoit deux versions correctives (la dernière corrigeant la précédente). Citons notamment l’ajout d’une fonction de bac à sable pour tester du code d’utilisateurs inconnus et l’interdiction sous peine d’exception de modifier des constantes à la compilation ou à l’exécution.

guile-cv-0.1.4 (mai)

Il s’agit de la première version publique de cette bibliothèque de vision par ordinateur pour Guile Scheme, et première version incluse dans le projet GNU.

guile-ncurses-2.2 (avril)

Cette bibliothèque ncurses (interfaces textuelles) pour Guile vise la prise en charge de Guile 2.2.

icecat-52.0.2-gnu1 (avril) et 52.1.0-gnu1 (mai)

Il s’agit d’une version démarquée de Firefox, sans greffon ou extension non libre, qui suit donc les versions produites chez Mozilla.

kawa-2.4 (mai)

kawa implémente du Scheme en Java, et cette version est une corrective mineure.

less-487 (avril)

less permet de visualiser un fichier texte page par page. Cette version apporte des nouvelles commandes ESC-{ et ESC-} pour aller au début et à la fin des lignes affichées, une mise en valeur des recherches qui gère l’option « sans tenir compte de la casse » -i, le passage à Unicode 9.0.0, une option -Da sous Windows pour le mode SGR et des corrections de bogues.

libcdio-paranoia-10.2+0.94+1 (avril)

Cette bibliothèque pour gérer les images CD (mais si, vous savez, les galettes en polycarbonate et alu) reçoit quelques corrections de bogues (la précédente version 10.2+0.93+1 datant de 2014).

libidn2-2.0.1 (avril) et 2.0.2 (mai)

Cette bibliothèque gère le codage et le décodage des noms de domaine internationalisés suivant les spécifications IDNA 2008 et TR 46 (RFC 5890, 5891, 5892, 5893 et TR 46). Ces versions amènent la prise en charge de IDNA 2008 et TR 46 par défaut, et des corrections de bogues.

libmicrohttpd-0.9.53 (avril) puis 0.9.54 et 0.9.55 (mai)

Cette bibliothèque qui évolue visiblement assez vite fournit un micro‐serveur Web en C. Ces versions amènent une meilleure prise en charge de l’en‐tête Upgrade, des options de compilation pour choisir la fonction de polling suivant la plate‐forme, et diverses corrections.

linux-libre-4.10.12-gnu (avril) et 4.11.2-gnu (mai)

Le projet vise à publier et maintenir le noyau Linux 100 % libre. Les principaux blocs binaires (blobs) sont présents dans les pilotes graphiques, mais aussi pour l’accélération cryptographique, l’Ethernet ou l’écran tactile, et chaque nouvelle version du noyau amène en général son lot de nouveaux blocs binaires.

nano-2.8.1 (avril) à 2.8.4 (mai)

L’éditeur de texte nano a connu quatre versions, notamment pour corriger des bogues, des plantages, améliorer les traductions, accélérer les recherches arrières, améliorer la coloration syntaxique en PHP, éviter d’introduire des blancs intempestifs, mieux gérer les caractères de largeur double, etc.

                   :::                         The                   
     iLE88Dj.  :jD88888Dj:                                           
   .LGitE888D.f8GjjjL8888E;        .d8888b.  888b    888 888     888 
   iE   :8888Et.     .G8888.      d88P  Y88b 8888b   888 888     888 
   ;i    E888,        ,8888,      888    888 88888b  888 888     888 
         D888,        :8888:      888        888Y88b 888 888     888 
         D888,        :8888:      888  88888 888 Y88b888 888     888 
         D888,        :8888:      888    888 888  Y88888 888     888 
         D888,        :8888:      Y88b  d88P 888   Y8888 Y88b. .d88P 
         888W,        :8888:       "Y8888P88 888    Y888  "Y88888P"  
         W88W,        :8888:                                         
         W88W:        :8888:      88888b.   8888b.  88888b.   .d88b. 
         DGGD:        :8888:      888 "88b     "88b 888 "88b d88""88b
                      :8888:      888  888 .d888888 888  888 888  888
                      :W888:      888  888 888  888 888  888 Y88..88P
                      :8888:      888  888 "Y888888 888  888  "Y88P" 
                       E888i                                         
                       tW88D             Text Editor Homepage

ocrad-0.26 (avril)

Ce logiciel de reconnaissance optique de caractères (OCR) a connu une nouvelle version de pure maintenance (la dernière publication datant de 2015).

orgadoc-0.9 (mai)

Le logiciel permet de copier et gérer un ensemble de documents sur plusieurs ordinateurs. La précédente version datait de 2004, et il s’agit surtout de mettre à jour les scripts et la documentation pour l’utilisation et l’installation.

parallel-20170422 et 20170522

Cet outil shell permet d’exécuter des tâches en parallèle sur un ou plusieurs ordinateurs. Ces versions sont nommées respectivement Санкт-Петербу́рг (Saint‐Pétersbourg) et Macron (les précédentes étant baptisées TRAPPIST-1, 13769 et George Michael). Санкт‐Петербу́рг abandonne la prise en charge de Perl 5.6 sur IRIX, --halt prend désormais en charge done en plus de success et fail, et parset initialise les variables en Bash. Et Macron n’amène que peu de nouveautés (--timeout accepte s=second, m=minute, h=hour et d=day, tandis que l’alias --dr est ajouté pour --dry-run) et sert donc de version stable.

Logo

Conclusion

Y a‐t‐il un intérêt à écrire une telle dépêche ? Bonne question, je vous remercie de l’avoir posée.

Pour LinuxFr.org, ça fait une dépêche publiée de plus, ce qui est plutôt bien (mais ça fait encore une longue dépêche diront certains, j’aurais dû en faire 33. ;)

Pour moi, ça m’a fait découvrir divers logiciels, donc j’ai trouvé ça plutôt intéressant, même si j’ai un peu de mal avec l’hétérogénéité du projet GNU, avec des annonces par courriel ou non, sur le site du projet ou non, dans les fichiers Changelog ou NEWS de l’archive, etc. Et probablement pas au point de la refaire tous les mois tout seul, parce que ça reste un poil long à rédiger. Des volontaires ?

Pour vous, je ne sais pas, mais si déjà vous lisez ça, c’est que vous êtes allés beaucoup plus loin que la plupart. Bravo, vous gagnez un niveau !

Ah oui, toute bonne conclusion doit terminer sur une ouverture : à voir les écarts de publication entre les versions, on peut se dire que le projet GNU manque de contributeurs (sur le code ou sur les sites des projets visiblement), qu’il est plus facile de pondre un nouveau logiciel que de le maintenir sur des dizaines d’années, qu’il s’attaque à des chantiers immenses (virer les blobs, par exemple). Ou plus positivement, on peut rester admiratif devant ces projets maintenus sur des dizaines d’années, ces très ambitieux projets lancés pour garantir les quatre libertés, la diversité des projets existants, la variété des langues prises en charge et le fait que des gens lisent une telle dépêche.

Aller plus loin

  • # GNU parallel

    Posté par  . Évalué à 10.

    J'utilise GNU parallel dans la suite de test du compilateur OCaml, c'est très pratique pour lancer des commandes en parallèle en (1) séparant proprement les sorties de chaque commande sans les mélanger (contrairement à xargs) et (2) ayant l'option de préserver l'ordre séquentiel des affichages pour rester exactement compatible à un comportement précédent.

    Le code se trouve dans testsuite/Makefile avec un long commentaire qui explique les choix, mais la partie centrale est très simple:

        for dir in tests/$**; do echo $$dir; done \
     | parallel --gnu --no-notice --keep-order \
         "$(MAKE) $(NO_PRINT) exec-one DIR={} 2>&1" \
     | tee _log \

    Cela exécute la commande $(MAKE) $(NO_PRINT) exec-one DIR=$foo 2>&1 pour chaque répertoire de test $foo—en parallèle, mais en préservant l'ordre des sorties.

    Sur ma machine le temps de test est passé de 2 minutes et 30 secondes à 57 secondes.

    • [^] # Re: GNU parallel

      Posté par  . Évalué à 10.

      J'ai découvert GNU Parallel il n'y a pas très longtemps et je suis aussi conquis.

      L'exemple que tu donnes est peut-être un peu compliqué. Un exemple plus simple :

      Au lieu de :

      for i in *.c; do
    ma_commande $i
done

      L'équivalent avec parallel :

      ls *.c | parallel ma_commande

      GNU Parallel peut remplacer certaines boucles, ou remplacer l'utilisation de xargs, avec l'avantage que les commandes s'exécutent en parallèle. Le nombre de commandes qui s'exécutent en parallèle dépend du nombre de cœurs du CPU ; dès qu'une commande a fini, la suivante s'exécute.

      • [^] # Re: GNU parallel

        Posté par  . Évalué à 5.

        GNU Parallel peut remplacer certaines boucles, ou remplacer l'utilisation de xargs, avec l'avantage que les commandes s'exécutent en parallèle.

        Attention, xargs peut aussi exécuter en parallèle :

        printf "1\n2\n3\n" | xargs -P0 -n1 sleep

        Par exemple, ce code exécute trois sleep en parallèle et rendra bien la main en 3 secondes, et non en 3+2+1=6 secondes.

        Cependant, dès qu'un script a besoin d'avoir du parallélisme un peu moins trivial, il me paraît certes intéressant de se pencher sur parallel.

      • [^] # ls * |

        Posté par  . Évalué à 4.

        Je connais quelqu’un qui a un jour lancé une commande du style ls *truc | rm -rf dans un répertoire dont des fichiers contenaient des espaces dans leurs noms, il a eu des problèmes…

        Après, normalement, il n’y a pas d’espace dans les noms des fichiers .c et ça dépend aussi de la façon dont la commande parallel gère ça, mais à défaut de le savoir, je ne ferais pas confiance à une telle commande.

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: ls * |

          Posté par  . Évalué à 6.

          je ne ferais pas confiance à une telle commande.

          Ça prête peut-être à confusion.
          Je ne parle pas de la commande parallel, je veux dire que je ne ferais pas confiance à une construction du style ls * |, à moins d’avoir une parfaite maîtrise de la commande qui suit le pipe.

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: ls * |

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

            Il faut effectivement faire attention aux paramètres (par exemple faire un find -print0|xargs -0 pour se protéger de certains caractères), mais aussi aux effets d'une exécution multiple si le nombre de paramètres est grand (find|tar cvf est une mauvaise idée car si tar est exécuté trois fois, seule la dernière archive sera conservée).

            • [^] # Re: ls * |

              Posté par  . Évalué à 4.

              xargs peut faire des exécutions multiples si la ligne est trop longue, mais dans find | tar cvf, tu ne l’as pas mis. Je suppose que c’est un oubli (sinon, ça ne va pas faire grand chose…). Cela dit, moi aussi, je l’ai oublié dans mon premier exemple, qui aurait dû être ls *truc | xargs rm -rf (ATTENTION : ne pas faire pareil chez vous, c’est l’exemple erroné qui casse des trucs).

              Cela dit, tar a l’option -T qui fait le boulot sans recours à xargs et sans erreur de ligne trop longue au niveau du shell : find -type f | tar cvf fichier.tar -T -

              Il y a intérêt à mettre au moins -type f comme argument de find, sinon chaque répertoire va être inclus avec son contenu, puis son contenu va être réinclus. Cela dit, la commande n’a d’intérêt que s’il y a un autre argument à find (sinon, tar cvf fichier.tar . suffit).

              Bon, à l’essai, parallel semble fiable par rapport aux problèmes d’espaces :
              ls | parallel ls depuis un répertoire contenant un fichier avec des espaces s’en sort bien (je n’ai pas dit que cette commande avait un intérêt), alors que ls | xargs ls indique des erreurs sur les morceaux du nom de fichier avec espace (ls | xargs -d "\n" ls permet de ne pas avoir le problème).

              Du coup, parallel ça a l’air très sympa comme commande.

              « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

              • [^] # Re: ls * |

                Posté par  . Évalué à 4.

                xargs peut faire des exécutions multiples si la ligne est trop longue

                Oui et par défaut il coupe à partir de 4096 arguments passés à la commande. Tu peux faire xargs -n $(getconf ARG_MAX) pour utiliser la valeur max admise par ton OS.

  • # Bonne initiative

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 05 juin 2017 à 02:48.

    Tout le monde utilise le projet GNU, parfois sans le savoir. Mais qui le connaît vraiment ?

    La communication de la FSF n’est pas optimale, à moins peut‐être d’utiliser emacs pour la consulter ?
    Plutôt que d’utiliser man, la FSF a créé info. Nous avons deux sources de documentation de structures différentes. Toutes les deux sont des structures archaïques et même obsolètes.

    Une unification autour d’un schéma XML serait infiniment préférable afin de générer au choix, HTML, PDF, DocBook, ePub, etc.
    On pourrait plus facilement faire des recherches, insérer des exemples, éventuellement des illustrations.

    En attendant cette évolution qui devrait arriver un jour, cet article permet de découvrir des fonctionnalités souvent méconnues (j’utilise UNIX depuis 1989 et GNU/Linux depuis 1995). J’aime beaucoup les articles sur le noyau Linux, mais je ne l’utilise pas directement. En revanche, j’utilise le GNU dès que j’utilise la ligne de commande ou si je fais un script.

    Oui, assurément, cet article est utile et je souhaite voir régulièrement ses successeurs.

    • [^] # Re: Bonne initiative

      Posté par  . Évalué à 6.

      Une unification autour d’un schéma XML serait infiniment préférable afin de générer au choix, HTML, PDF, DocBook, ePub

      Pour information, à partir d’une source en Texinfo on peut déjà générer au choix (en plus de l’info) du HTML, du PDF, du DocBook.

      Et puis, si on voulait une source de base en XML plutôt qu’en Texinfo, pourquoi inventer un nouveau schéma au lieu de partir sur du DocBook qui est quand même fait pour ça ?

      • [^] # Re: Bonne initiative

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

        pourquoi inventer un nouveau schéma au lieu de partir sur du DocBook

        DocBook est un excellent format, sans doute le meilleur. Je pense néanmoins qu'il faudrait faire une petite étude pour voir si il convient en tous points ou si il faudrait lui ajouter quelques extensions.
        N'ayant pas fait ce travail, je me garde bien de dire que j'ai LA solution à un problème que je n'ai pas complètement étudié.

        Ce que j'aimerais, c'est de pouvoir suivre des liens de façon à pouvoir par exemple à partir de sed, avoir le man en français, des exemples avec une coloration syntaxique, un tutoriel, le code source de sed… Il ne faut pas raisonner en terme de solution mais du but à atteindre. Je pense qu'une documentation performante permettrait aux nouveaux venus de faire une approche plus conviviale et plus productive. Les étudiants auraient un bon ouvrage de référence et les développeurs pourraient y trouver des ressources nouvelles.

        Lorsque j'utilise par exemple man:/awk dans konqueror en français man:/usr/share/man/fr/man1/awk.1.xz je vois des caractères tels que "définition" qui sont issus d'une double conversion en utf8. Cela n'arriverait pas en partant d'une structure saine.

        Je n'ai connaissance d'aucun travail d'unification et de modernisation. Avez-vous connaissance d'un travail en cours ?
        Si la réponse est négative, devinez ce que nous devrions faire ?

        • [^] # Re: Bonne initiative

          Posté par  . Évalué à 5.

          Je n'ai connaissance d'aucun travail d'unification et de modernisation. Avez-vous connaissance d'un travail en cours ? Si la réponse est négative, devinez ce que nous devrions faire ?

          On s'y met tous les deux ?
          Moi ausi la doc m'agace. Elle est formatée comme sur du papier.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Bonne initiative

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

            On s'y met tous les deux ?
            Moi aussi la doc m'agace. Elle est formatée comme sur du papier.

            Chiche !

            Rien ne nous empêche de demander de l'aide à des spécialistes en XML par exemple.
            Il me semble que j'avais parlé de cela à RMS il y a une quinzaine d'années. Pour lui info était la panacée.
            Le man date des débuts d'UNIX. Chacun produit sa page de man et les traductions ont été gérées par des bénévoles. Si je prends wget je trouve à la fin du man : Voir aussi L'entrée GNU Info de wget ce qui fait deux documentations pas forcément en accord sans parler des traductions qui peuvent ne pas être à jour.

            Je pense qu'il faut travailler en accord avec le GNU et d'autres structures. Je pense que cela peut s'inspirer de ce qui a été fait pour le Filesystem Hierarchy Standard qui fut lancé par les utilisateurs de GNU/Linux. Les grands constructeurs qui souffraient d'une hétérogénéité des systèmes de fichiers sont alors venus participer aux travaux.

        • [^] # Re: Bonne initiative

          Posté par  . Évalué à 4.

          Ce que j'aimerais, c'est de pouvoir suivre des liens de façon à pouvoir par exemple à partir de sed, avoir le man en français, des exemples avec une coloration syntaxique, un tutoriel, le code source de sed…

          Tous les formats de documentation à l’exception de celui des pages de manuel permettent les liens hypertextes, je ne vois pas ce qui te manque ou ce qu’un nouveau format apporterait.

          Pour avoir de la bonne documentation (avec des tutoriels et « un bon ouvrage de référence »), il faut… écrire de la documentation. Les formats pour ça ne manquent pas. Ajouter un n-ième format ne vas pas automagiquement faire apparaître de la documentation ou subitement faire naître des vocations de rédacteurs.

          • [^] # Re: Bonne initiative

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

            Tous les formats de documentation à l’exception de celui des pages de manuel permettent les liens hypertextes

            C'est bien le premier problème que l'on rencontre.

            Ajouter un n-ième format ne va pas automagiquement faire apparaître de la documentation

            La documentation existe déjà en tant que contenu, c'est sa forme qui est obsolète et incohérente. J'aimerais par exemple générer automatiquement un index des commandes présentes sur ma machine ou dans une distribution. On pourrait étendre cela aux versions des logiciels disponibles et installés avec une courte description et des mots clés permettant de rechercher des instructions ou des programmes relatifs à un sujet donné.
            Je pense à G'MIC ou à ImageMagick dont la visibilité est quasi-nulle mais qui pourraient bien mieux apparaitre si la documentation était mieux structurée.

    • [^] # Re: Bonne initiative

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

      Moi j'aime bien les 'man' (pas les 'info' par contre).

      Les commandes ou il faut faire 'command help', c'est chiant aussi… Il faut être dans la commande. Les manuels, tu peux les formatter le plus souvent comme tu veux s'ils sont écrits dans un méta langage. Et non, stop au XML pour la doc. Personnellement, je fais la doc de tous mes scripts en POD et cela fait un manuel simple et efficace.

      Oui à la diversité dans l'écriture du manuel mais oui aussi dans des moulinettes universelles. Je crois que le HTML et le 'man' sont des standard qui marche bien.

      Non à l'obligation du page web pour lire une doc. Je veux pas de milliard d'instruction CPU pour voir les options d'une commande ! L'informatique ne doit pas oublier de faire des efforts du coté du green IT ;-)

      • [^] # Re: Bonne initiative

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

        Il y a une seule page info que je lis régulièrement c'est latex2e, ça donne une vue synthétique sur toutes les commandes LaTeX, c'est assez pratique.

  • # Gnu R

    Posté par  . Évalué à 9.

    Bonjour,

    Il faut ajouter à cette liste la version 3.4.0 de GNU R qui est sortie le 21/04/2017.
    La liste des changement dans cette version est là : https://cloud.r-project.org/bin/windows/base/NEWS.R-3.4.0.html

  • # Coquille

    Posté par  . Évalué à 2. Dernière modification le 05 juin 2017 à 17:03.

    Bonjour,

    Concernant Grub, il semble qu'il y ait une erreur dans la news :

    La précédente version 2.00 de ce chargeur d’amorçage datait de 2002.

    il fallait à priori lire 2012.

  • # une version démarquée de Firefox

    Posté par  . Évalué à 3.

    [icecat…Il s’agit d’une version démarquée de Firefox

    démarquée -> dégriffée ?

  • # GNU PARALLEL : Macron

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

    Et Macron n’amène que peu de nouveautés

    Ah bah si même GNU PARALLEL le dit ! mais attendons de voir quand même, le code du travail risque de changer, lui !

  • # Il manque un logiciel phare dans cette liste

    Posté par  . Évalué à 5.

    On ne parle pas de GNU Hurd …

    • [^] # Re: Il manque un logiciel phare dans cette liste

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

      On ne parle pas de GNU Hurd …

      J'apprécie l'humour !
      Cependant il ne faut pas jeter l'opprobre sur Hurd. C’était une fausse très bonne idée, quelque peu dogmatique.
      Pour le vérifier, il fallait bien l'essayer !

      Je me souviens d'un article de Microsoft qui annonçait dans les années 1990, une structure en micro-noyaux pour NT. On pensait alors que les noyaux monolithiques seraient supplantés par les micro-noyaux.
      En 2000 et 2001, lors des premières RMLL, les développeurs de Hurd étaient venus pour faire avancer le projet. Malgré tous leurs efforts les résultats avaient été minces et loin des performances de Linux.

      C'est Linus Torvalds qui avec son approche agile et pragmatique qui a réussi. Au moins, on sait maintenant que les micro-noyaux ne sont pas très efficaces.

      Est-ce que quelqu'un relèvera le défi pour une nouvelle tentative ? Ce n'est pas sûr…

      • [^] # Re: Il manque un logiciel phare dans cette liste

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

        Cependant il ne faut pas jeter l'opprobre sur Hurd. C’était une fausse très bonne idée, quelque peu dogmatique.
        […]
        C'est Linus Torvalds qui avec son approche agile et pragmatique qui a réussi. Au moins, on sait maintenant que les micro-noyaux ne sont pas très efficaces.

        Laquelle, de faire un micro-noyau ?
        Techniquement les micro-noyaux, cela fonctionnent. Peut être pas de manière aussi évidente que ne l'annonçait Tanembaum en terme de choix architectural, mais ils n'ont pas disparu au contraire.

        Typiquement Windows et macOS (et dérivés mobiles) reposent sur des micro-noyaux enrichis (c'est à dire que des composants qui pourraient être en espace utilisateur ne le sont pas pour des raisons de performances ou de simplicité) mais restent des micro-noyaux avec les avantages que cela peut procurer.

        Côté libres, les noyaux dominants que sont Linux et les différents *BSD ont évolué aussi depuis les débuts de HURD. Ce sont des monolithiques modulaires, réduisant une partie des inconvénients de pure monolithique que Tanembaum avait reproché à Torvalds à l'origine.

        Les micro-noyaux purs sont assez confidentiels (MINIX est sans doute le plus connu et utilisé) mais les monolithiques purs (comme Linux au début) aussi. Le pragmatisme a gagné entre la souplesse du système, la simplicité d'architecture et les performances.

        Mais je pense que les micro-noyaux purs peuvent encore réussir, en soit MINIX et HURD ont les briques de bases pour s'imposer. Mais il manque clairement une communauté autour.

        HURD n'a pas je pense perdu la guerre à cause de son architecture fondamentale, mais pour des raisons historiques. HURD a perdu beaucoup de temps à ses débuts ce qui a laissé la place de noyau libre de référence à Linux qui était opérationnel plus tôt (car plus simple à faire, mais aussi avec un processus de développement clair et simple, et sans le poids historique et politique que la FSF et RMS ont imposé à HURD).

        Est-ce que quelqu'un relèvera le défi pour une nouvelle tentative ? Ce n'est pas sûr…

        Microsoft et Apple convertiront peut être leur noyau en micro-noyau pur un jour. En tout cas cela est accessible, s'ils trouvent une solution pour les performances et la simplicité de l'architecture de l'ensemble.

        Dans le libre, cela me paraît délicat, le chantier est titanesque. Que ce soit réécrire Linux ou améliorer HURD ou MINIX de sorte à supplanter Linux.

      • [^] # Re: Il manque un logiciel phare dans cette liste

        Posté par  . Évalué à 2.

        J'apprécie l'humour !

        Ce n'est pas que de l'humour. l'idée était aussi d'initier un fil de discussion autour de Hurd pour savoir un peu ce qu'il devient (et ce que deviennent les micro-noyaux en général).

        C'est Linus Torvalds qui avec son approche agile et pragmatique qui a réussi. Au moins, on sait maintenant que les micro-noyaux ne sont pas très efficaces.

        Il me semble que c'est un peu moins tranché que ça : MacOSX, si je me souviens bien est basé sur un micro-noyau hybride (https://fr.wikipedia.org/wiki/XNU). Je n'ai pas eu le temps de lire en quoi il diffère d'un micro-noyau classique, et si vous avez des infos je suis preneur.

        Il me semble aussi que d'autres systèmes ont repris les principes du micro noyau, mais j'avoue que je ne suis pas sûr et que j'ai besoin de chercher un peu.

        • [^] # Re: Il manque un logiciel phare dans cette liste

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

          Il me semble que MacOSX, c'est un bon gros noyau BSD au dessus d'un micro noyau (Mach ?)… Donc pas vraiment du micro-noyau.

          Par contre, le système micro noyau le plus connu me semble être QNX - https://fr.wikipedia.org/wiki/QNX

          • [^] # Re: Il manque un logiciel phare dans cette liste

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

            Il me semble que MacOSX, c'est un bon gros noyau BSD au dessus d'un micro noyau (Mach ?)… Donc pas vraiment du micro-noyau.

            Tu te fourvoies un peu, même si dans l'idée tu as raison.
            Le noyau d'Apple est XNU, son architecture est effectivement un noyau Mach (qui est un micro-noyau) surmonté d'un noyau BSD mais qui réside pour l'essentiel en espace utilisateur.

            En somme, le noyau BSD remplace et unifie les services du micro-noyau (du moins une bonne partie) mais comme le tout réside en espace utilisateur cela colle avec l'aspect du micro-noyau. Mais ce n'est pas un micro-noyau complet, il est plutôt catalogué dans les micro-noyaux enrichis (comme celui de Windows).

            Cela n'a rien à voir avec l'architecture des noyaux de Linux et des BSD qui sont monolithiques modulaires.

      • [^] # Re: Il manque un logiciel phare dans cette liste

        Posté par  . Évalué à 3.

        Est-ce que quelqu'un relèvera le défi pour une nouvelle tentative ?

        Il semble que certains essaient (ou ont essayé). Des gens qui relèvent le défi, je pense qu'il n'en manquera pas. Par contre il ne'est pas sur qu'ils soient en mesure d'aboutir à quelque chose d'utilisable.

        https://openclassrooms.com/forum/sujet/conception-d-un-systeme-d-exploitation-68215

Suivre le flux des commentaires

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