NetBSD 2.0 vient de sortir.

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
0
10
déc.
2004
NetBSD
Depuis le 6 décembre l'ISO de la version 2.0 du système NetBSD est disponible (l'annonce officielle vient seulement de paraître sur le site).
NetBSD est un système d'exploitation libre complet dont la philosophie générale est la compatibilité la plus large possible avec les différents types de matériels existants. Il appartient à la famille des BSD qui se caractérise par une licence plus permissive que la GPL de GNU/Linux (pas de Copyleft) et qui comprend OpenBSD (orienté sécurité) et FreeBSD (plus généraliste).

Les nouveautés sont nombreuses dans cette version 2.0 et concernent principalement:
  • Les performances générales (support des native threads et mécanisme de Scheduler Activation) ;
  • La montée en charge (scalabilité) ;
  • Le nouveau système de fichier UFS2 (déjà utilisé par FreeBSD 5.x) ;
  • La sécurité (signature des exécutables, chiffrement des disques, contrôle des appels système avec systrace) ;
  • La compatibilité Java ;
  • Nouvelle chaîne de compilation basée sur GCC 3.3.3 ;
  • Les nouveaux ports (AMD64, SMP pour les i386, les SPARC et les MacPPC).

  • Il est à noter que sur le site de NetBSD il n'est pas fait mention du port du système vers les architectures PPC64 ou Itanium ce qui semble étrange et quelque peu décevant. Le portage vers Acorn32 ou Dreamcast, aussi enthousiasmant soit-il, reste très marginal et ne saurait suppléer à l'absence des deux architectures majeures d'IBM et Intel sur un OS dont la portabilité est le but affiché.
    Néanmoins la conception même de NetBSD facilitant les portages nul doute que nous verront très vite arriver ces processeurs dans l'arbre de NetBSD.

    Aller plus loin

  • # Hum

    Posté par  . Évalué à -10.

    Ca va encore partir en troll ca...
  • # durée des RC

    Posté par  . Évalué à 2.

    ca fait pas 6 mois ou plus que netBSD 2 est en beta test / RC ?
    • [^] # Re: durée des RC

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

      C'est probable, en tout cas ça fait plus d'une semaine que la 2.0 est taguée dans le CVS. http://www.feyrer.de/NetBSD/blog.html#20041129(...) (trouvé sur gcu.info)
      En attendant c'est le premier changement de version majeur en 10 ans.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: durée des RC

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

        sachant que le premier Itanium (Merced) est sorti y'a plus de 4 ans je crois qu'on aurait pu s'attendre à un port vers ce CPU.
        c'est quand même ultra-bizarre que ce soit toujours pas dispo non ? Intel ne fournit pas une babasse de test aux devs de NetBSD ?

        je sais je sais : si je veux le port je bosse et j'envoie un patch et toussa...
        • [^] # Re: durée des RC

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

          ben si tu veux un port, donne leur un itanium, c'est aussi simple que ça. S'ils en ont pas, ils peuvent pas le faire, et faut pas attendre que intel ne donne quoique ce soit...
          • [^] # Re: durée des RC

            Posté par  . Évalué à 2.

            Et pourquoi Intel ne donnerait pas un Itanium à l'équipe de NetBSD ? Bon OK c'est pas un des OS les plus utilisés, mais ça ne leur couterait pas cher. Je suis prêt à parier que les contribs du kernel ont eu droit au leur. Tiens ça ma donne envie d'envoyer un mail à Intel.
            • [^] # Re: durée des RC

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

              surtout qu'il suffit d'un vieux CPU même plus vendu puisque c'est l'arcitecture qui compte !
              Intel y gagne : la pub qui sera faite sur leur don + le portage d'un OS d'excellente qualité.
              • [^] # Re: durée des RC

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

                ben apparemment ils s'en foutent. Il suffit de voir le peu de dons faits par les entreprises pour des projets comme openbsd et freebsd.

                A part 2-3 exceptions, toutes les donations sont faites par des particuliers.
                • [^] # Re: durée des RC

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

                  petite estimation :
                  un vieux serveur itanium monoprocesseur d'il y a 2-3 ans doit couter à peine quelques milliers de dollars (2000 ?) donc ça ne représente que quelques minutes du budget marketing annuel d'Intel donc le directeur marketing d'Intel est un gros connard incapable qui pour économiser 2000 dollars se prive d'une bonne pub et d'un bon OS.
                  petite conclusion :
                  Il faut qu'Intel vire son directeur marketing.
                  • [^] # Re: durée des RC

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

                    petite estimation
                    petite conclusion

                    ma conclusion a moi, est plutot que tu penses trop petit.
                    • [^] # Re: durée des RC

                      Posté par  . Évalué à 5.

                      Pas toujours ! ;)
                      le directeur marketing d'Intel est un gros connard incapable

                      Sinon pour moi quelques secondes du budget marketing annuel d'Intel suffiront, merci ;)
                  • [^] # Re: durée des RC

                    Posté par  . Évalué à 7.

                    il est marrant de lire:

                    Le directeur marketing d'Intel est un gros connard sur le fait qu'Intel n'aurait pas donne de machine Itanium au projet, alors qu'on ne sait pas si Intel l'a fait ou pas....

                    Par contre, pour avoir vu le nombre de machines Itanium donnees par Intel et autres pour ce genre de developpement, si NetBSD n'en a pas recu, c'est qu'ils ont reellement loupe la vague.

                    Je me souvient plus de quel projet *BSD il s'agissait, mais il y a quelques annees nu des developeurs kernel Linux pour IA64 faisait mention des developeurs BSD pour Itanium. La question n'est pas de savoir ce qu'il disait, mais le fait est qu'il y avait une equipe de portage a cette epoque.
                  • [^] # Re: durée des RC

                    Posté par  . Évalué à 8.

                    t'es gentil, ce n'est pas le coût du matériel qui compte ici, mais le coût de la prise de décision et les coûts de suivi des relations NetBSD/Intel ensuite.

                    des tas de gens impliqués pour des tas d'heures, ça ne sera pas $ 2000.
    • [^] # Re: durée des RC

      Posté par  . Évalué à 4.

      C'était peut être en RC depuis quelques mois, mais je pense que faire une news pour annoncer le tag RELEASE est une bonne chose (même si là c'est un peu tardif) :

      a) ca limite le nombre de news (on va pas annoncer chaque étape du release engineering de Free/Net/Open/BSD).
      b) des releases de NetBSD, ça n'arrive pas tous les ans non plus.
      c) ca permet "aux jeunes" de découvrir d'autres choses.
      • [^] # Re: durée des RC

        Posté par  . Évalué à 1.

        c'etait plus ppour signaler mon etonnement face a la sortie. je penser (oui c'est mal ;)) que la release etait deja sortie il y a quelque mois vu que il y a 6 mois minimun ils en etaient déja aux RCs.

        c'etait pas une critique mais un étonnement.
        • [^] # Re: durée des RC

          Posté par  . Évalué à 1.

          Certes, mais n'oublions pas que -RELEASE n'est apposé que pour la... release ;)

          Avant, on a pu voir différents tags RC, comme par exemple : netbsd-2-0-RC5, netbsd-2-0-RC4, netbsd-2-0-RC3, netbsd-2-0-RC2, netbsd-2-0-RC1; à chaque étape du processus de release engineering pour la version 2.0.

          Par contre, je comprends tout à fait ton étonnement, d'après l'annonce [1] du début du process de release engineering, c'était prévu pour la fin mai... 2004 ;)

          [1] : http://mail-index.netbsd.org/netbsd-announce/2004/03/28/0000.html(...)
  • # ça ou LFS

    Posté par  . Évalué à -6.

    News a rapprocher de celle de LFS.

    Sur des machines exotiques ou avec peu de RAM... ben on peu installer LFS ou NetBSD par exemple (il existe quelque autres distro linux avec ulibc une slackware par exemple ou LEAF).
    • [^] # Re: ça ou LFS

      Posté par  . Évalué à 6.

      Je ne comprends pas bien en quoi il faut rapprocher ça de LFS, ou même de slackware.

      Combien d'architecture sont supportées par LFS et Slack ? NetBSD en supporte quand même pas mal http://www.netbsd.org/Releases/formal-2.0/NetBSD-2.0.html(...)

      LFS est une "distribution" Linux à faire sois même pendant des heures, pas Netbsd, qui est un ...BSD (D'ailleurs on est pas sur linuxfr ici ? :) )

      Et que vient faire la ulibc ici ?? Netbsd utilise la libc BSD si je ne m'abuse ?
      • [^] # Re: ça ou LFS

        Posté par  . Évalué à 1.

        De plus NetBSD est fait pour tourner même avec très peu de RAM et des CPU très faibles (25 Mhz par exemple), et que quand bien même une LFS tournerait sur des erchitectures exotiques, il audrait plusieurs semaines pour le compiler !!!
        • [^] # Re: ça ou LFS

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

          T'es pas forcment obliger de compiler sur la machine ou t'installe... tu cross-compile, t'installe sur un montage NFS. Mais apres je garantie pas que toute la build tool-chain soit dans la norme LFS ;-)
      • [^] # Re: ça ou LFS

        Posté par  . Évalué à 2.

        J'ai pas été clair on dirait:

        > Je ne comprends pas bien en quoi il faut rapprocher ça de LFS, ou même de slackware.

        parce que les deux tournent sur des petites configs

        > Combien d'architecture sont supportées par LFS et Slack

        beaucoup vu que tu construis toi même toolchain, distrib et tout et tout, tu dois pouvoir supporter la liste des platformes de gcc:
        http://gcc.gnu.org/install/specific.html(...)

        > Et que vient faire la ulibc ici

        Elle apporte quelques platformes en plus, et permet d'avoir un linux de la même empreinte (footprint) que NetBSD

        > LFS est une "distribution" Linux à faire sois même pendant des heures, pas Netbsd

        Là je suis d'accord :)

        HS: J'en profite pour noter une bizarrerie pour ceux qui veulent pas attendre la fin de la compilation: uwoody, une debian woody en ulibc (x86): http://uclibc.org/news.html(...)
        • [^] # Re: ça ou LFS

          Posté par  . Évalué à 6.

          Dire que la liste des architectures suportées par LFS est la liste des plateformes de gcc est un peu rapide. Tellement rapide que ça ressemble fortement à une grosse erreur...
          • [^] # Re: ça ou LFS

            Posté par  . Évalué à 0.

            Bien sûr que c'est très rapide, d'ailleurs j'ai usé du conditionnel.

            Ceci dit, si le CPU est supporté par:
            - le noyeau
            - une libc
            - le compilateur gcc

            alors je vois pas ce qui empêche d'avoir un système qui tourne.

            Reste à voir comment et avec quoi ça tourne;
            - matériel 1ère partie: le CPU; des CPU avec et sans MMU n'offrent pas les mêmes possibilités
            - matériel 2ème partie; le reste (tout ce qui est sur la carte mêre ou qui se branche d'une manière ou d'une autre sur la machine); si par exemple, le contrôleur réseau, d'une machine n'est pas reconnu, c'est gênant... tout dépend ce qu'on considère comme un système fonctionnel
            - logiciel; à la liste noyeau, libc, gcc, j'ajouterai busybox pour avoir un minimum d'interaction avec la machine

            C'est cette partie logicielle qui fait qu'effectivement une architecture supportée par gcc ne l'est pas *forcément* par LFS... LFS n'utilise pas BusyBox et il faudrait voir la liste de paquets nécessaire à LFS (chapitre 3) et les patches qui vont avec, rien ne dit que ça va tourner sur toutes les platformes du strict trio noyeau,libc et gcc, ni que tel paquet ne va pas systématiquement crasher une platforme sans MMU.

            Mais je serais heureux de savoir si je me trompes (j'essaie peut-être en vain de mettre linux sur un vieu routeur de récup' :).

            Ref.:
            http://kernel.org/(...) --- scroll down to "What is Linux?"
            http://gcc.gnu.org/install/specific.html(...)
            http://gcc.gnu.org/gcc-3.4/buildstat.html(...)
            http://www.kniggit.net/wwol26.html(...)
            http://www.linuxfromscratch.org/(...) --- chap. 3 du livre
            http://uclibc.org/about.html(...)
            http://busybox.net/FAQ.html#arch(...)
        • [^] # Re: ça ou LFS

          Posté par  . Évalué à 3.

          Bof, je ne suis toujours pas convaincu...

          Les deux tournent sur de petites configs ? ah ben faut rapprocher ca de Openbsd alors, ou de palmOS tant qu'on y est...

          Je ne pense pas que le fait de tourner sur de petites configuration soit spécifique à LFS, mais est plutot du au noyaux linux. Dans l'absolu, rien ne m'empeche de prendre une grossse distrib genre Suse, et de la degrossir au maximum pour qu'elle tourne sur une petite machine.

          Ensuite pour le nombre d'architectures supportés, il me semblait (peut être que je me trompe) que le noyaux Linux ne tournait que sur vingtaine de d'architectures differentes (je ne trouve plus d'info là dessus d'ailleurs, si quelqu'un a un lien...), Netbsd est lui plus proche de la cinquantaine, et je ne comprends pas bien en quoi la ulibc rajouterais des architectures à celles supportés par le noyaux ? Le rapport avec Gcc n'est pas si simple a mon avis.
          • [^] # Re: ça ou LFS

            Posté par  . Évalué à 4.

            Pour ce qui est du nombre d'architecture supportée, il faut
            faire attention car debian (entre autre) et NetBSD n'ont pas
            la même définition. Ainsi plusieurs architectures NetBSD peuvent
            correspondre à une seule architecture debian
  • # traduction

    Posté par  . Évalué à 1.

    * La montée en charge (scalabilité).

    En général, une meilleure traduction de scalability est (aptitude au) passage à l'échelle. Ce n'est pas vraiment la même chose que la montée en charge ...
    • [^] # Re: traduction

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

      c'est sans doute une meilleure traduction mais j'y pige que pouic !
      Qu'est-ce que tu entends par "aptitude au passage à l'échelle" ?
      C'est le fait que quand on ajoute des CPU alors la puissance augmente linéairement ?
    • [^] # Re: traduction

      Posté par  . Évalué à 4.

      Je comprend pas pourquoi on veut toujours traduire les termes techniques. Personnellement, je trouve que ça ne fait qu'embrouiller les gens et on finit par ne plus parler du même sujet. Je ne comprend pas "monté en charge" en encore moins "aptitude au passage à l'échelle", et pourtant c'est exactement ce dont je me préoccupe en ce moment.

      Pour moi, scalibility ou éventuellement scalabilité sont les seuls termes que j'utiliserais.
      • [^] # Re: traduction

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

        Heu... C'est marrant, mais moi, c'est exactement l'inverse... Tu me dis scalability, je vois même ce que c'est censé évoquer. Alors que si tu me dis montée en charge, je vois de quoi tu parles.
        C'est dommage, parce que les jargons ne servent au final qu'à exclure les autres.
  • # Thread

    Posté par  . Évalué à 4.

    enfin des thread qui marchent, snif c'est trop beau
    • [^] # Re: Thread

      Posté par  . Évalué à 3.

      Enfin des Threads qui marchent pour NetBSD, ou alors au sens plus généraliste et tout os confondu genre: Enfin de vrais Threads qui marchent! Je ne connais pas NetBSD, donc loin de moi l'idée de troller.
      • [^] # Re: Thread

        Posté par  . Évalué à 3.

        C'est enfin des thread qui marche sous netbsd ;-)
        Car il est vrai que les thread sous netbsd n etait pas
        top sur les NetBSD version 1.5/1.6 sur lesquels j ai pu
        developper.
  • # LiveCD

    Posté par  . Évalué à 9.

    A noter qu'il existe également un livecd pour l'architecture x86 ( je ne sais pas pour les autres).
    De quoi tester Netbsd sans toucher à son disque dur.

    ftp://iso.fr.netbsd.org/pub/NetBSD/iso/2.0/i386live.iso(...)
    ftp://iso.fr.netbsd.org/pub/NetBSD/iso/2.0/i386live.iso.torrent(...)
    • [^] # Re: LiveCD

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

      Et pour ceux qui veulent pas graver un CD, il y a QEMU (ou Xen ou VMWare ou ...).

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Détails techniques

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

    A noter également un pdf très intéressant (avec des graphiques montrant que Net BSD 2.0 roxe des mamans ours par rapport à la version 1.6) que j'ai omis de mettre dans les liens :

    http://2004.eurobsdcon.org/uploads/media/EBSD04_28.pdf(...)

    (il pèse 150 ko alors pourquoi se priver ?)
    • [^] # Re: Détails techniques

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

      http://2004.eurobsdcon.org/uploads/media/EBSD04_28.pdf(...)

      Je trouve que les nouvelles fonctionnalités ressemblent *beaucoup* à FreeBSD 5.x (kqueue, systrace, ...). A ce que j'en ai compris, ils ont repris du code et l'ont rendu portable sur un max. d'architectures. C'est classe ça ! Ce serait encore mieux si FreeBSD et NetBSD deviennaient un SuperBSD qui serait la combinaison des forces de chacun ... Bon, c'est pas pour demain.

      J'suis trop fort, j'ai retrouvé le bench' en question :
      http://linuxfr.org/2003/10/19/14323.html(...)

      En gros, ça montre en image que Linux 2.6.x et FreeBSD 5.x supportent sans problème une forte monté en charge.

      ---

      Je ne dis pas : "boûh les vilains ! ils repompent FreeBSD !". Au contraire, c'est super que voir que tous les OS libres évoluent dans le bon sens :-)

      @+ Haypo
      • [^] # Re: Détails techniques

        Posté par  . Évalué à 2.

        D'ailleurs, sur la page en question, le gars se dit impressionné
        par l'équipe NetBSD qui a tenu compte de ses remarques et qui
        a gommé presque tous les problèmes en quelques semaines.
  • # Logo

    Posté par  . Évalué à -2.

    C'est quand même domage de gacher du si beau code par un logo si moche

    http://netbsd.org/images/NetBSD-smaller.png(...)
    • [^] # Re: Logo

      Posté par  . Évalué à -1.

      t'as qu'a en faire un!
    • [^] # Re: Logo

      Posté par  . Évalué à 2.

      En tout cas, il est beaucoups, beaucoups mieux que l'ancien, le reste c'est une question de goût.
      • [^] # Re: Logo

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

        "En tout cas, il est beaucoups, beaucoups mieux que l'ancien, le reste c'est une question de goût."

        J'aurais pas dit ça comme ça :
        "En tout cas, le choix d'un logo c'est une question de gout, certains le trouvent mieux que l'ancien, d'autres l'inverse".
  • # Pilote de disque crypto

    Posté par  . Évalué à 1.

    Je me demandais s'il existait sous linux l'equivalent du "cryptographic disk driver" ou pilote de disque crypté en francais dans le texte ?

Suivre le flux des commentaires

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