Sortie de NetBSD 5.0

Posté par  . Modéré par patrick_g.
Étiquettes :
25
30
avr.
2009
NetBSD
C'est après plus de 2 ans de dur labeur et d'acharnement que la communauté NetBSD est heureuse et fière de vous annoncer la sortie de sa petite dernière, la NetBSD 5.0. Bien que moins connu que ses autres cousins BSDs, NetBSD a su continuer sa route vers la modernité, tout en gardant le cap qu'il s'était fixé à son origine: un système léger, sûr, performant, et portable (plus de 60 plate-formes et architectures supportées par l'OS).

Après une ré-écriture quasi intégrale d'éléments clés du noyau (ordonnanceur, système de mémoire virtuelle, systèmes de fichiers), cette 13ième version apporte son grand lot de nouveautés, en posant de nouvelles bases qui font de cette version 5.0 une des plus importantes, si ce n'est la plus importante, du projet. Une grande partie du noyau a été ré-écrite, dans l'optique d'un meilleur support des architectures informatiques actuelles et à venir, notamment avec l'apparition des multi-cores et de la généralisation du SMP.

On note en particulier:
  • la refonte de l'ordonnanceur et de la gestion des processus, avec un bien meilleur support des LWPs (Processus_léger)
  • le système de mémoire virtuelle ré-écrit en granularité fine
  • le modèle de threads, qui passe d'un modèle M:N (basé sur les scheduler activations) à un modèle 1:1, inspiré de Solaris, plus proche de POSIX, et surtout, plus facile à maintenir que l'ancienne implémentation.
  • des systèmes de fichiers retouchés, afin de les adapter aux nouvelles primitives de synchronisation
Les nouveautés ne s'arrêtent pas là. Entre autres (liste non exhaustive):
  • amélioration (très) importante de performances sur machine multicore, avec l'apparition d'allocateurs tenant compte de la topologie des caches CPUs
  • FFS journalisé (via WAPBL)
  • support de l'ACPI
  • un framework complet de gestion de l'énergie
  • préemption complète du noyau pour les threads temps réel
  • I/O asynchrones POSIX
  • support des extensions temps-réel POSIX
  • concepts de sets CPUs, affinités, offline/online (similaire à Solaris)
  • support de FUSE (via PUFFS)
  • jemalloc() en standard
  • un énorme framework de test de régressions sur le noyau (via ATF, automated testing framework)
  • support de Xen 3.3 sur i386 et amd64
  • passage de Xfree vers X.org sur la plupart des ports, dont l'x86 (i386 et amd64)
  • support UDF en écriture (pour les DVD surtout)
  • et pleines d'autres (opérations atomiques, algorithmes lockless, etc.)
La réécriture du noyau a été très fastidieuse, et surtout réalisée par Andrew Doran, dont le travail a été en partie subventionné par la fondation NetBSD. Andrew a touché à toutes les améliorations affectant de près ou de loin la performances du noyau et de l'OS. Cette mouture est celle qui rassemble le plus de modifications entre deux versions majeures du système (le patch en rapport à la dernière NetBSD-4 fait plus de 7 millions de lignes!), et vise à poser des bases robustes pour la suite du projet.

La version 6, sur laquelle le travail a déjà commencé, devrait apporter le support des NUMA, de ZFS, une pile réseau remise à neuf, le support du PCI-passthrough et du save/restore de Xen, une grande modularité dans le noyau, et le support de patchs binaires.

Aller plus loin

  • # Hmmm...

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

    C'est bon ça... ça sent la migration ce week-end ;)
    Espérons que les montées de versions soient toujours aussi simples.
  • # Benchmark

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

    Avec la sortie de cette nouvelle version de NetBSD, la sortie demain d'OpenBSD 4.5, le fait que FreeBSD 7.2 est en RC et va sortir en version stable bientôt je pense qu'on a une conjonction assez rare et qu'il faudrait en profiter.
    Ce qui serait vraiment utile c'est que quelqu'un fasse un bon gros benchmark de tous ces BSD contre le dernier noyau Linux stable afin de voir ou on en est.

    Un peu comme ce qu'on avait eu ici à l'époque : http://bulk.fefe.de/scalability/

    En tout cas merci pour la belle news.
    • [^] # Re: Benchmark

      Posté par  . Évalué à 2.

      Oui, c'est sur, un bon benchmark des familles qui veut rien dire pour pouvoir troller à l'aise tout le weekend !! :)
      • [^] # Re: Benchmark

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

        un bon benchmark des familles qui veut rien dire

        Avant d'affirmer que cet éventuel benchmark futur ne voudrait rien dire peut-être faudrait-il l'examiner techniquement et juger de sa représentativité et de la pertinence de ses conclusions ?
        Ou alors tu rejettes les futures conclusions par avance parce que tu soutiens aveuglément l'un des OS en course...OpenBSD au hasard ?

        Enfin bon tant qu'une bonne âme ne se lance pas dans ce travail de benchmark tout ça reste hypothétique.

        A noter qu'un des liens de la news propose un tel benchmark : http://www.netbsd.org/~ad/50/
        Évidemment comme c'est un test réalisé par un dev de NetBSD il faut se méfier un peu mais bon ça reste intéressant.
        • [^] # Re: Benchmark

          Posté par  . Évalué à 1.

          Oui, c'est sur qu'on se base uniquement sur les performances pures pour choisir un OS.. le reste (ie le système de packaging, la politique de mise à jour, la politique de sécurité, l'intégration des logiciels tiers avec le système de base, l'intégration dans un environnement existant, la communauté, la documentation, etc.. ) à peu d'importances..
          Personnellement, quand je dois choisir un OS pour une tâche particulière, je ne me base pas sur des graphes, mais je les essaie, et j'expérimente.

          Quand a ton 'attaque personnelle' sur OpenBSD, c'est tellement bas... à ma connaissance il n'est pas 'en course' avec les autres. C'est tellement important d'avoir la plus grosse de nos jours après tout...
          • [^] # Re: Benchmark

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

            >>> c'est sur qu'on se base uniquement sur les performances pures pour choisir un OS.

            Ou est-ce que j'ai dit ça ? On se base sur un bon benchmark pour comparer les performances c'est tout.
            Il est évident, comme tu le souligne, qu'il y a beaucoup d'autres critères pour choisir un OS que les performances pures.
            Dans mon post initial j'ai juste souhaité un comparatif "afin de voir ou on en est" (sous-entendu sur les performances). Je n'ai jamais dit que ce benchmark désignerait le meilleur OS tout critère confondus.

            Concernant OpenBSD ce n'était en aucun cas une attaque personnelle. J'aime beaucoup cet OS, bien plus que FreeBSD par exemple (je ne connais pas du tout NetBSD) et je pense que sur son créneau particulier il est quasi-imbattable.
          • [^] # Re: Benchmark

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

            Lorsque tu expérimentes un O.S (ou un logiciel) tu ne lis pas ce que d' autres ont déjà écrit afin d' améliorer éventuellement ta visibilité sur le sujet ? Tu es très fort.
          • [^] # Re: Benchmark

            Posté par  . Évalué à 5.

            Oula, je ne sais pas si les benchmarks sont une si bonne idée : ils n'ont pas encore été lancés, ils sont à peine évoqués, et ça s'échauffe déjà...

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Benchmark

          Posté par  . Évalué à 0.

          C'est bien connu, les « kernels » BSD sont supérieurs à Linux, moins de « blah-blah » [1], surtout NetBSD.

          Je n'ai aucune connaissance pour pouvoir affirmer, que l'un est supérieur aux autres, mais simplement une nette préférence dans les systèmes BSD, en tant que desktop. Pour moi NetBSD reste la référence au niveau des BSD (peut être, du fait qu'il a été le premier système que j'ai installé).

          [1] à chaque fois de nouveaux drivers pas forcément bien aboutis.
          • [^] # Re: Benchmark

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

            moi j' aurais tendance à vouloir ça comme benchmark :
            tu prends un bout de code du kernel netbsd, un autre faisant une tache similaire sur openbsd et enfin un autre (toujours pour une tache similaire) à linux.
            Puis tu files ce bout de code à 1.groupe d' étudiant. 2.groupe de nerds. Sans leur dit d' où ça vient mais juste ce que ça fait.
            Ensuite tu ramasses les copies :p

            Blague à part, une phrase apprise lorsque j' étais bien jeune, educ spé, toussa :
            "un test ne teste que ce qu' il teste, au moment où il le teste"
            con, non ? et pourtant, marrant ça s' applique pas qu' au wisk ou swiz mais aussi ici :p
      • [^] # Re: Benchmark

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

        Il y a deux types de benchmarks. Ceux fait à la va-vite par des fanboyz de tel ou tel système, destinés à faire mousser leur système préféré, bardés de mensonges et d'omissions volontaires. Et ceux fait avec rigueur, faciles à reproduire et se basant sur des faits pour en sortir plusieurs conclusions, et énumérer les forces et faiblesses de chaque système (comme celui-ci http://people.freebsd.org/~kris/scaling/mysql.html qui est désormais célèbre, et a permis aux devs Linux de corriger un gros problème d'ordonnanceur).
        De tels tests rigoureux entre systèmes permettent à tout le monde d'avancer, si on sait se projeter au delà du concours de celui qui à la plus grosse (performance).
        • [^] # Re: Benchmark

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

          Au hasard... les tests de phoronix ? :p

          Bon allez je sors de votre news avec mes 2 blagues pourries à 2 balles. Désolé. Et merci pour cette dépêche claire et concise. Moi qui ne connait pas du tout NetBSD ça donne envie d' aller voir.
    • [^] # Re: Benchmark

      Posté par  . Évalué à 4.

      Une présentation de NetBSD 5.0 (html et pdf) avec des benchmarks a été faite par Andrew Doran est
      disponible ici http://www.netbsd.org/~ad/50/ via l'excellent webblog de
      Hubert Feyrer : http://www.feyrer.de/NetBSD/blog.html/nb_20090430_0022.html

      Dans la sortie des systèmes *BSD, j'ajoute que la Libellule fait parti de la fête avec une nouvelle version de
      DragonFlyBSD en 2.2.1: http://www.shiningsilence.com/dbsdlog/2009/04/29/4135.html
  • # OldSchool

    Posté par  . Évalué à 3.

    Dans cette sombre période ou Linux fusionne avec Xorg alors même que le fait que windows ait été tellement critiqué pour ça, dans cette sombre période ou une base de registre fait son apparition dans les postes de travail sous Linux (gconf), dans cette sombre période ou l'installe des logiciels dont il est dit pas leur créateur qu'il faut leur faire confiance (SELinux) pour gérer la sécurité du poste, dans cette sombre période NetBSD est un refuge pour pouvoir bosser comme je l'aime, c'est à dire dans un système que je comprend et qui ne souhaite pas se mettre en avant à travers des trucs en 3D partout.

    Vive les BSD, vive NetBSD.

    ps : et vive Linux quand même ! :)
  • # NetBSD Desktop Project

    Posté par  . Évalué à 3.

    N'en déplaise aux vieux geeks à l'esprit tordu, cela semblera l'évidence à tout être doué d'un minimum de jugeotte que la gestion des logiciels et paquets pour les différents *BSD est plutôt vraiment pourrie.

    Alors bien sûr, on va avoir les vieux geeks (ou bien les jeunes geeks qui aiment se torturer l'esprit) qui vont argumenter, "pkg_add -r logiciel" c'est trop super (super de piocher au petit bonheur la chance pour espérer trouver le nom correct des paquets, et dans le meilleur des cas de récupérer un paquet obsolète). Ah ben non sinon, il faut taper cd /usr/ports/chemin_complet/du_logiciel puis make && make install et 25 minutes après on a un beau paquet sdl tout neuf...

    Et puis pour tout mettre à jour, portupgrade et compagnie, bref, autant de méthode différentes, longues, hasardeuses pour celui qui souhaite avoir rapidement des logiciels unix à jour (sauf quand on veut faire un bête serveur http).

    L'idée des ports et de pkgsrc c'est bien, mais c'est pas très pratique et moderne quand on compare à apt-get de Debian ou pacman (yaourt) de Archlinux. Et quel dommage de ne pas avoir des paquets binaires à installer de façon conviviale comme dans ces 2 exemples de distributions linux. (sur archlinux yaourt n'existe qu'en version console, et pourtant c'est un plaisir à utiliser)

    Pour preuve que chez NetBSD on n'a pas que de vieux geeks aigris ou de jeunes geeks masochistes, car ils cherchent à sorti NetBSD des années 1980, et souhaitent fournir un installateur moderne et pratique pour l'utilisateur des années 2009.

    Ces pistes de réflexions se trouvent ici, dommage que cela n'ait pas l'air de bouger depuis février dernier : http://wiki.netbsd.se/Desktop_Project

    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: NetBSD Desktop Project

      Posté par  . Évalué à 3.

      c'est pas très pratique et moderne quand on compare à apt-get de Debian
      Debian/kNetBSD ?
    • [^] # Re: NetBSD Desktop Project

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

      cool, je suis un jeune geek masochiste !
      mais puffy et beastie font ça tellement bien...

      ps: fais gaffe à tes gosses, on les bouffe

      ps2: vendredi avant l'heure, hein ?

      ps3: très bonne initiative que "Desktop project" pour NetBSD, et pour la mise à jour avec un apt-like, je fais de la pub à Imil: http://www.gcu.info/tag/pkg_dry/
    • [^] # Re: NetBSD Desktop Project

      Posté par  . Évalué à 2.

      Je préfère largement le pkg_add rustique de NetBSD à un mélange moribond de couches telles que apt/dpkg/je ne sais quoi à la debian, ou RPM/URPMI/YUM à la Redhat/Mandriva.

      C'est sur que ça nécessite un peu plus de réflexion et de bien réfléchir à ce que l'on fait, mais travaillant dans la production, ce côté "prudent" est une habitude pour moi ....

      Pour ma part je fais mes mises à jour en recompilant la totalité des programmes en environement chrooté, et lorsque j'upgrade j'ai toujours la possibilité de faire un retour arrière car je garde mes anciens packages.

      A ce jour je n'ai jamais eu de problème, mais c'est peut etre aussi parce que je n'utilise pas les monstres GNOME/KDE sur mes machines en NetBSD.
    • [^] # Re: NetBSD Desktop Project

      Posté par  . Évalué à 1.

      Attention, on parle de NetBSD, le répertoire /usr/ports/ n'existe pas (c'est plutôt FreeBSD et OpenBSD).

      On parle plutôt de /usr/pkgsrc/, donc pour pouvoir comparer avec tel ou tel gestionnaire de paquets, il faudrait être plus rigoureux.
      • [^] # Re: NetBSD Desktop Project

        Posté par  . Évalué à 1.

        c'est pour cela que j'ai bien précisé que le problème de ces gestionnaires de paquets vétustes concernait tous les *BSD (tous dans le même panier).
        On parlait d'ergonomie dans un autre journal (là par exemple => http://linuxfr.org/comments/1028789.html#1028789 ), et bien les gestionnaires de paquets (si on peut vraiment appeler cela "gestionnaire") ne sont pas du tout ergonomiques. Je vois 2 raisons principales à cela :
        - historiquement, pour ne pas changer les bonnes vieilles habitudes
        - techniquement, peut-être qu'ils préfèrent consacrer leurs forces à travailler sur d'autres choses que sur cela.

        Pourtant, cela ne change rien au fait que tous les gestionnaires de paquets ou logiciels que j'ai pu utiliser sur *BSD ne donnaient pas trop envie d'avoir à gérer cela au quotidien. À la rigueur comme dit plus haut sur un serveur de prod, on installe les logiciels un fois pour toute (presque), et on les fais évoluer très lentement. Sur un bureau, si je dois installer une dépendance pour un logiciel de dessin dont j'ai besoin tout de suite, je n'ai pas envie de passer 15 ou 25 minutes à la compiler.

        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: NetBSD Desktop Project

      Posté par  . Évalué à 6.

      Je résume ton point de vue :

      C'est vraiment de la merde pkgsrc par rapport à apt/yum !

      Je prétend que le but n'est pas le même.

      NetBSD compile sur tout un tas d'architecture et ce depuis tout un tas d'architecture. Et ce en deux ou trois commande simple.

      Tu peux compiler un NetBSD pour ton petit pc pas puissant à base de CPU arm à partir de ton gros pc puissant à base de xeon qui lui est sous Linux.

      Déjà, ça, je ne sais pas si beaucoup (ou même une) de distribution à base de apt/yum le fait.

      Ensuite, tu a installé sur ton petit pc à base d'arm ton netbsd. Et tu veux koffice. Tu va avoir besoin, grosso-modo, de Xorg, qt, kdelibs, koffice*. Je pense que pour compiler ça, tu en as pour une semaine, au moins.

      Mais comme tu utilise pkgsrc, tu rallume ton gros PC sous linux et grace à pkgsrc, tu compile tes paquets pour ton NetBSD/arm en deux heures le tout.

      Et tu le pousse sur ton arm et ça marche.

      Biensur, je pense qu'apt et yum permettent ça.
      Ah non... Ba comment on fait ? On jete les super nouveau portables arm à la poubelle en attendant que debian et redhat fournissent des dépôts pour arm.

      Ou alors, avec les paquets créée plus tot avec ce naze de pkgsrc pour ton pc/arm tu créer un dépôt afin que tes 20 collègues qui ont le même pc/arm que toi puisse installer à l'aide de ce naze de pkg_add les binaires produits à partir de ton gros pc.

      Maintenant, supposons que tu t'en fiche, tu n'utilise que du 686.
      Quelle est l'avantage de pkgsrc et pkg_add ?

      Ba supposons que tu veuille compiler un application avec une option de compilation, ba avec pkgsrc, tu fais ton petit paquet avec son option de compilation, chose qui est automatisé grâce au nombreuses pkg_option. Une fois que tu à fais ton paquet, tu le mets dans ton dépôt ou dans ton PKG_PATH (ou les deux) et tout tes collègues profiteront de ton paquet fait avec amour.

      Mais supposons que tu t'en fiche des options de compilation, apres tout, tu utile apt ou yum, non ? :)

      Mais quelle est l'avantage alors me dira tu ?

      Pendant ton temps libre, tu as écris un magnifique bout de code (en licence BSD bien sur !). Tu l'as écris proprement, en évitant les trucs lié à la plateforme cpu ,les GNUseries et les Linuxeries. Et bien en le mettant dans pkgsrc/wip (pour work in progress), les milliards de personnes qui utilisent NetBSD sous les differentes architectures proposé pourront l'utiliser, arm, vax, ppc, alpha, dreamcast, playstation2 et même zaurus ! Et si tu es un être profondément bon, tu pourras créer un paquet pour que toute cette foule de processeur criant le nom de ton appli en cœur puisse installer ton logiciel avec ce naze de pkg_add, sans même avoir besoin de le compiler. Et tu pourras en théorie le faire depuis ton gros pc, avec ton gros xeon qui a plus de cache L1 que certaine architectures de RAM.

      Le bon vieux pkg_add couplé aux puissant pkgsrc sont capable de bien plus que yum et apt.

      Et je ne suis pas un vieux geek aigri ( bon, un peu aigri, je suis juste en train d'attendre un tech FT en salle informatique... :) ), mais les besoins des utilisateurs de NetBSD ne sont pas les mêmes que ceux de Fedora (par exemple). Les besoins de Fedora sont... devenir windows ! Je schématise, mais le but, au delà de la 'vitrine' redhat, c'est bien de gagner des parts de marché. Les besoins de NetBSD sont rester simple et modulaire. On s'en fou des parts de marché. On en veux pas. Et si le

      J'utilise Fedora sur le portable du boulot et je suis désolé, mais des fois, j'ai envi de le jeter par la fenêtre quand X plante (souvent) et que je ne peux pas récupérer la main m'obligeant à redémarrer. J'ai envi de le jeter par la fenêtre quand il me demande de confirmer mes actions. J'ai envi de le jeter par la fenêtre quand SELinux m'interdit de lancer netbeans en me sortant des logs incompréhensible qui veulent dire 'tu aurais déjà du me mettre en mode disable, cretin'.

      Sinon yum rencontre le même problème que pkg_add. Si je tape yum -y install openoffice, ça ne fonctionne pas. Il veut yum -y install openoffice.org

      Et le http://wiki.netbsd.se/Desktop_Project, c'est à coté de la plaque. C'est n'est pas comment améliorer NetBSD, c'est juste créer un CD avec certaines choses préinstallé dessus. Ce n'est pas un projet officiel de NetBSD d'ailleurs. C'est peu Mais ça ne modifie pas NetBSD. Par defaut, un iso NetBSD, c'est un noyau, un userland basique et en option X avec twm. Et ça restera ça, à peu de chose près. A chacun de choisir précisément ce qu'il veut.
      • [^] # Re: NetBSD Desktop Project

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

        >>> On s'en fou des parts de marché. On en veux pas. Et si le

        C'était quoi la suite ?
        • [^] # Re: NetBSD Desktop Project

          Posté par  . Évalué à 3.

          Je sais pas, je postais sous Fedora (vrai en plus) et X a encore planter (pas vrai pour une fois). :)
      • [^] # Re: NetBSD Desktop Project

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

        T'as un lien sympa pour la crosscompilation de packages pkgsrc ?
        ça m'intéresse, et je croyais que c'était pas ça encore...

        pour le kernel et le basesys, sinon, c'est clairement poutrant !
        <3 build.sh
        • [^] # Re: NetBSD Desktop Project

          Posté par  . Évalué à 3.

          En fait, tout n'est ma crosscompilable dans pkgsrc, mais le gros du travail ainsi que l'infrastructure sont la. Mais si toi, pars exemple tu produit un code "propre", ça devrait le faire sans problème.
          Si des bonnes âmes veulent s'investir dans un projet à taille humaine avec plein de gens gentil autour pour rendre tout pkgsrc crosscompilable ( il doit bien y avoir une bonne demi-heure de boulot ! :) ), il n'y a qu'a s'inscrire à la mailling netbsd !

          http://www.netbsd.org/cgi-bin/subscribe_list.pl?list=tech-pk(...)

          sinon http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/doc/HOWTO-cr(...) est l'exemple pour quelqu'un qui crosscompil du code pkgsrc de sparc vers alpha si je ne me trompe pas.

          Je me souviens avoir utilisé des options dans le mk.conf à base de pkg_target je crois. Mais ça remonte à au moins 2 ans...
      • [^] # Re: NetBSD Desktop Project

        Posté par  . Évalué à 2.

        Sniff, mon beau trollometre tout neuf...
        • [^] # Re: NetBSD Desktop Project

          Posté par  . Évalué à 3.

          Je suis désolé, mais il ne faut pas me faire lire des choses qui critique NetBSD sinon je m'énerve :)

          Je t'en rachèterais un tout beau pour que tu puisses lire la news OpenBSD !
          • [^] # Re: NetBSD Desktop Project

            Posté par  . Évalué à 5.

            Perso j'ai rien (mais vraiment rien) contre Net (ou autre BSD), ce qui a fait peter mon trollometre, c'est les passages du genre a ignorer completement ARM fait partie des archi officielles Debian depuis 9 ans. Ce qui me fait penser que soit tu ne sais pas de quoi tu parles, soit tu trolles.
            • [^] # Re: NetBSD Desktop Project

              Posté par  . Évalué à 2.

              Je ne troll jamais et je ne savais pas qu'ARM est un port de Debian.
              Mea Culpa.
              Mais tu peux remplacer ARM par un cpu non supporté par Debian.
      • [^] # Re: NetBSD Desktop Project

        Posté par  . Évalué à 5.

        Hmmm j'aime bien les *BSD, NetBSD compris, mais en toute bonne fois il faut reconnaitre que les gestionnaires de ports, pkgsrc et paquets sont *très* loin de l'ergonomie, du nombre de fonctionnalités, etc. de dpkg/apt (je ne compare pas à yum, qui est lui aussi passablement nul).

        Franchement, quitte à vouloir faire partager son goût pour les *BSD, autant parler de leurs vrais atouts (de la même façon, j'ai beaucoup de peine pour ceux qui cherchent à promouvoir Fedora en parlant de yum au lieu d'évoquer son superbe support SELinux, le travail avec l'upstream, le LVM par défaut, le grand nombre de paquet fournissant les symboles de débogguage, les outils de gestion de masse comme Cobbler, Spacewalk, Func, FreeIPA, libvirt & co).

        Si je voulais faire partager les plaisirs d'un linux à un bsdiste, par exemple, je chercherais pas à mettre en avant la documentation et les pages de man (surtout pas la doc des drivers), je ne parlerais pas de l'intégration, l'unification et la relecture systématique au niveau du code source / de la ligne de code du système de base, je ne m'aventurerais pas sur la possibilité de recompiler simplement l'intégralité du système de base après un changement d'API, j'éviterais de parler de la très unixienne beauté par la simplicité, etc...

        > Tu peux compiler un NetBSD pour ton petit pc pas puissant à base de CPU arm à partir de ton gros pc puissant à base de xeon qui lui est sous Linux.
        > Déjà, ça, je ne sais pas si beaucoup (ou même une) de distribution à base de apt/yum le fait.

        Il existe bien entendu une méga foultitude de façon de faire ça avec Debian, par ex. et entre autres :
        http://www.linux.codehelp.co.uk/apt-cross/re01.html
        http://psas.pdx.edu/DebianCrossCompilerHowto/

        L'élégance de NetBSD est ailleurs.

        > Ba supposons que tu veuille compiler un application avec une option de compilation,
        > ba avec pkgsrc, tu fais ton petit paquet avec son option de compilation, chose qui
        > est automatisé grâce au nombreuses pkg_option.

        Là aussi, les autres systèmes offrent évidement diverses options. Comme simplement renseigner la variable d'environnement DEB_BUILD_OPTIONS, ou pour une modif plus radicale, éditer le fichier de rêgles de compil et reconstruire le .deb ainsi :

        apt-get build-dep foo
        apt-get source foo
        cd ./foo-0.1/
        vim debian/rules # ajouter ses options de compil'
        dch -i
        dpkg-buildpackage -rfakeroot -uc -b

        Et puis pour être honnête, il faudrait penser à indiquer pourquoi NetBSD propose si peu de paquet pré-compilés pour les architectures minoritaires... (et aussi, rappeler ce que Debian et OpenBSD pensent de la cross-compilation systématique par opposition à la compilation native).

        Enfin, dans tout les cas le fait que pkgsrc permette la compilation croisée ou la personnalisation est une bonne chose, mais il n'est pas le seul, et surtout cette fonctionnalité ne devrait pas masquer les lacunes pour les cas d'utilisation plus courants (0 subtilité pour la gestion des conflits, gestion des dépendances rudimentaire, par ex.).

        > Sinon yum rencontre le même problème que pkg_add. Si je tape yum -y install
        > openoffice, ça ne fonctionne pas. Il veut yum -y install openoffice.org

        Oui, je crois que son commentaire était relatif à l'absence de "yum search" dans pkg_add. Ce qui était stupide, parce qu'il suffit de grepper dans l'index des ports ou pkgsrc pour connaitre le nom du paquet que l'on cherche (ou pour chercher à partir de la description, etc.).
        • [^] # Re: NetBSD Desktop Project

          Posté par  . Évalué à 3.

          il suffit de grepper dans l'index des ports ou pkgsrc pour connaitre le nom du paquet que l'on cherche (ou pour chercher à partir de la description, etc.)

          on parle d'une façon conviviale de le faire. Je ne vois pas l'intérêt de taper des commandes à rallonge juste pour obtenir une fonctionnalité qui me semble être la base d'un gestionnaire de paquet.

          Pour le reste, ok le fait que netbsd supporte beaucoup d'architectures c'est indéniable, par contre cela ne remplace pas le fait qu'il manque quand même une gestion plus KISS des paquets, et des paquets binaires récents pour les architectures les plus courantes. (je reviens encore sur la simplicité de pacman sur archlinux à ce niveau, de plus il est possible de recompiler les paquets existants en rajoutant des options de compilation avec ABS: http://wiki.archlinux.org/index.php/ABS_-_The_Arch_Build_Sys(...) ).

          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: NetBSD Desktop Project

            Posté par  . Évalué à 5.

            Peut etre que ta vision du KISS n'est pas la même que celle de NetBSD.
            Keep It Simple, ça ne veut peut être pas dire Laisse un script python faire je ne sais quoi avec des fichiers XML dans /etc/yum/yum.d/ et /etc/yum/yum.[nom du repo] et lire des fichiers XML, etc. KISS, ça veut peut être dire que je comprend TOUT ce que fait pkg_add facilement, c'est à dire, suivre le PKG_PATH, lister le répertoire pour matcher la chaine passer en argument, telecharger le paquet puis le detarer, lire les dépendances et recommencer si il y en a.

            Sinon, si faire grep koffice pkgList est trop dur pour toi, je peux t'ecrire, en exclusivité pour toi, et oui, je suis comme ça, un pkg_search

            #! /bin/sh
            grep $1 /path/to/pkgList


            Prend, c'est cadeau :)


            Il y a des paquets binaires pour toute les archis courante !

            Et la notion de pacquage récent est relative. NetBSD utilise les paquets récent quand c'est possible.
        • [^] # Re: NetBSD Desktop Project

          Posté par  . Évalué à 2.


          Ce qui était stupide, parce qu'il suffit de grepper dans l'index des ports ou pkgsrc pour connaitre le nom du paquet que l'on cherche

          D'ailleurs, chaque fois que pkgsrc gèle (4 fois par ans) je récupère le listing du répertoire en local en premier.
      • [^] # Re: NetBSD Desktop Project

        Posté par  . Évalué à 4.

        Ah non... Ba comment on fait ? On jete les super nouveau portables arm à la poubelle en attendant que debian et redhat fournissent des dépôts pour arm.
        Il me semble que Debian fournit un dépôt pour arm…

        Si je tape yum -y install openoffice, ça ne fonctionne pas. Il veut yum -y install openoffice.org
        yum -y install openoffice doit je pense compléter le nom du paque sur un shell digne de ce nom ?
  • # On en oublierait le plus important...

    Posté par  . Évalué à 1.

    Quid de l'évolution du super des grille-pains ? =p
    (et surtout, du contrôle de celui-ci en ssh ! )

    Bon, c'était trop tentant... Il n'empêche que le fait de fonctionner sur ce genre de plateforme illustre bien la portabilité de netBSD.
    Y a-t-il d'autres OS fonctionnant sur des architectures aussi extravagantes ?

Suivre le flux des commentaires

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