Journal FreeBSD 9 pointe le bout du nez

Posté par  (site web personnel) .
Étiquettes :
22
1
août
2011

YO !

Ken Smith vient juste d'annoncer la sortie de la première beta de FreeBSD 9.0
annonce

Bon, qu'est ce qui change dans une installation basique (sous VirbualBox) ?

  • Nouvel installateur.

Au lieu de l'ancien sysintall (enfin !). Il intègre un mode LiveCD (pour dépanner) et une procédure d'installation assez simple et sans surprise (essai dans une VirtualBox). Par contre il n'y a pas d'option sur les medias utilisés (par exemple je ne vois pas comment faire une install en NFS ?).

  • Nouveau bootloader.

Les options sont maintenant des drapeaux que l'on peut basculer. Ça simplifie le menu. Ouf y'a toujours beastie (loader_logo="beastie").

Le disque est reconnu en ada(4) au lieu de ad(4).

  • Sofupdate journalisées par défaut (papier)

Et ce même pour la racine /, les soft-updates n'étaient pas activées sur la racine (pour d'obscures raisons, jamais trop compris pourquoi).

Après un reboot sauvage (du à des em0 timeout - c'est une béta -) ça démarre très vite. Ça c'est cool. Fini les fsck qui durent des plombes, fini gjournal ?

  • Moins de GNU, plus de BSD.

Il est maintenant possible de compiler le système avec CLANG/LLVM. Cela ne concerne pas les ports même s'il y a des tentatives en ce sens clang compiling ports, take 2.

  • Packet Filter mis à jour à la version de OpenBSD 4.5

Par contre je ne vois pas pflow(4) ?

  • Plein d'autres trucs.

Voir la page d'Ivan Voras What's cooking for FreeBSD 9

Mais certaines choses sont déjà disponibles en 8.2 (par exemple le geom scheduler gsched)

  • # BSD vs GNU

    Posté par  . Évalué à -10.

    Moins de GNU, plus de BSD.

    Est-ce vraiment une bonne chose ? De plus je ne crois pas que LLVM/CLANG fasse partie intégrante du projet, donc il n'y a pas plus de BSD.

    • [^] # Re: BSD vs GNU

      Posté par  . Évalué à 10.

      Il est toujours bon d'avoir de la concurrence. Si ça marche mieux que les outils GNU, tant mieux pour eux et ça profitera aux autres également.

    • [^] # Re: BSD vs GNU

      Posté par  . Évalué à 9.

      Moins de GNU, plus de BSD.

      Est-ce vraiment une bonne chose ?

      Pour un projet qui se base sur la license BSD, j'imagine que oui!
      Après le troll GPL/BSD habituel, bof: on n'est pas Vendredi.

      De plus je ne crois pas que LLVM/CLANG fasse partie intégrante du projet, donc il n'y a pas plus de BSD.

      LLVM/CLANG est sous license BSD, donc plus de BSD est correct.

      Pour en revenir à FreeBSD 9, une grande nouveauté pour moi c'est l'intégration de capsicum! Enfin un OS "grand public"(*) qui fournit des capabilites!

      Et puis il y a des développeurs d'OpenBSD qui semblent intéressé, ça aussi c'est une bonne nouvelle car je peux très bien imaginer les développeurs d'OpenBSD utilisant les capabilities autant qu'ils le peuvent dans leurs outils, d'ailleurs apparemment il y en a qui portent OpenSSH sur capsicum.

      Linux est en retard sur ce coup la(**), quand on voit les bidouilles infâmes que sont obligés de faire les développeurs de Chrome pour avoir un bac à sable sur Linux (ils sont obligés d'intégrer un dé-assembleur x86! ).. Et c'est un vrai problème, car plus c'est sale:
      1) moins ça a de chance d'être adopté par d'autre logiciels
      2) plus ça a de chance d'être buggé..

      *: par rapport à KeyKOS, EROS, CapROS, Coyotos, FreeBSD est grand public!
      **: Linux a les POSIX capabilites, mais pas les capabilites ce qui n'est pas du tout la même chose.

      • [^] # Re: BSD vs GNU

        Posté par  . Évalué à -10.

        LLVM/CLANG est sous license BSD, donc plus de BSD est correct.

        Aux temps pour moi, j'étais intimement persuadé que LLVM/CLANG était distribué avec la Gpl. Alala ... Moinssez moi jusqu’à ce que mort s'ensuive..

      • [^] # Re: BSD vs GNU

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

        Enfin un OS "grand public"(*) qui fournit des capabilites!

        De ce que j'ai compris il va falloir modifier toutes les applications pour qu'elles tirent parti de ces capabilities proposées par l'OS. C'est bien ça ?
        Si c'est le cas alors ça va être super long de modifier ainsi les ports de FreeBSD...et tant que ce ne sera pas fait il n'y aura pas d'avantage à utiliser Capsicum.

        • [^] # capsicum

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

          De ce que j'ai compris il va falloir modifier toutes les applications pour qu'elles tirent parti de ces capabilities proposées par l'OS. C'est bien ça ?

          Oui.

          Si c'est le cas alors ça va être super long de modifier ainsi les ports de FreeBSD

          Il n'est pas question de toucher aux ports mais seulement la base de l'os (tcpdump, inetd, ntpd, ...). Y a eu un fil sur des idées d'applis à convertir :
          http://freebsd.1045724.n5.nabble.com/Capsicum-project-Ideas-needed-td4563310.html

          les pixels au peuple !

          • [^] # Re: capsicum

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

            mouais...finalement je préfère le paradigme de SELinux ou TOMOYO. On ne modifie pas le code des applis (contrairement à Capsicum) et les distributions peuvent définir des politiques de sécurité pour de nombreuses applications au lieu de se restreindre à quelques outils de base de l'OS.

            • [^] # Re: capsicum

              Posté par  . Évalué à 10.

              Bof, la sécurité ce n'est pas rétro-actif, tu ne peux pas l'appliquer ensuite par des droits d'administrations, enfin tu peux essayer, mais le résultat est inférieur a ce que tu obtiens si tu prends en compte ce besoin lors de la conception..

              Sendmail vs Postfix/Qmail, Firefox vs Chrome: tout dans un processus contre une décomposition en processus avec séparation des privilèges, le résultat n'est pas le même et ajouter une politique de sécurité par dessus ne résous pas tout.

              • [^] # Re: capsicum

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

                Certes...mais avec Capsicum il n'est pas question de réécrire complètement les applications ! Il s'agit de faire une opération chirurgicale sur une appli existante pour lui implanter un pacemaker le support des capabilities.

                • [^] # Re: capsicum

                  Posté par  . Évalué à 2.

                  Et bien ça dépend: si ton application est déjà conçue de manière à limiter l'"abus de privilège" alors le portage est normalement relativement simple, sinon ça peut être compliqué..

                • [^] # Re: capsicum

                  Posté par  . Évalué à 4.

                  Quand tu applique la séparation des privilèges, ça simplifie beaucoup le travail.

                  De plus les LSM est empirique : tu ne peux jamais être sûr que tu donne suffisamment de droits ou pas assez à chaque programme. Le développeur a une meilleure connaissance de ce que fait sont programme, il est aussi probable qu'il fasse des tests qui couvrent plus de code que ce que fait l'administrateur.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: capsicum

              Posté par  . Évalué à 2.

              ... et je me retrouve à désactiver SELinux parce que je ne sais pas le configurer et que si j'utilise la MKL d'Intel, ben le soft plante au moment de l'exécuter. C'est ballot.

            • [^] # Re: capsicum

              Posté par  . Évalué à 2.

              https://bugzilla.redhat.com/show_bug.cgi?id=527147#c3

              Moi j'adore. :)

              Sedullus dux et princeps Lemovicum occiditur

  • # Pas de pflow

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

    Par contre je ne vois pas pflow(4) ?

    Y'a pas :(

    pflow est une sonde netflow qui utilise les états de Packet Filter. C'est très léger comparé à une sonde netflow en userland.

    les pixels au peuple !

Suivre le flux des commentaires

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