FreeBSD 10

55
21
jan.
2014
FreeBSD

Le système d'exploitation FreeBSD est arrivé dans sa dixième cuvée. Cette version très attendue apporte notamment la gestion de l'affichage par le noyau (Kernel Mode Setting) pour les pilotes AMD et l'hyperviseur bhyve.

FreeBSD

Sommaire

Matériel

Le Raspberry Pi est désormais pris en charge, et de manière générale le support des architectures ARM a été amélioré.

L'architecture ARM supporte désormais les Superpages, améliorant les performances et la scalabilité du système.

Au passage, un nouvel outil est apparu, Crochet, développé par Tim Kientzle. Il permet de construire des images FreeBSD amorçables pour différents modules embarqués comme le Raspberry Pi, les BeagleBones et quelques autres encore.

L'instruction RDRand des processeurs Intel est désormais supportée. Celle-ci permet de générer des nombres aléatoires directement depuis le CPU. Elle est présente dans les processeurs Ivy Bridge et supérieurs.

Stockage

Le système de fichiers ZFS supporte désormais la commande TRIM (qui était déjà supportée par UFS) et la compression LZ4 (backportée sur 9.2). LZ4 est un algorithme de compression particulièrement rapide qui augmente les performances de 50 à 80% par rapport au défaut LZJB pour un ratio de compression plus élevé (jusqu'à 10% sur de larges blocks). La fonctionnalité NOP-write a également été importée d'Illumos. Celle-ci permet de ne pas réécrire les données si le checksum des nouvelles données est identique à celui des anciennes.

UFS de son côté reçoit le support de l'extension de système de fichiers à chaud sur des partitions montées en écriture. Les nouveaux systèmes de fichiers créés bénéficieront également de meilleures performances lors d'un fsck.

FUSE fait son entrée dans le système de base (précédemment un module noyau était disponible dans les ports).

Une nouvelle pile iSCSI implémentée dans le noyau est disponible.

Système

Une étape dans l'abandon de GCC a été franchie, FreeBSD 10 (pour les architectures i386 et amd64) est intégralement compilé à l'aide de LLVM/CLang. Cette bascule est due à une volonté de libérer la base de FreeBSD de la licence GPL v.3 qui régit les versions récentes de GCC. Remercions au passage Chris Lattner, initiateur et mainteneur de CLang, employé d'Apple. Les autres architectures continuent d'utiliser GCC (4.2.1).

Il est toujours possible de compiler le système avec GCC en passant une option dans le src.conf.

L'installeur permet désormais l'installation du système sur des volumes ZFS

FreeBSD 10 intègre désormais nativement la gestion des initiateurs et cibles iSCSI

Réseau

FreeBSD supporte désormais 65536 tables de routage au lieu de 16.
L'implémentation des interfaces virtuelles carp(4) a été réécrite.

Affichage

Les pilotes graphiques libres Intel et AMD n'étaient plus compatibles avec FreeBSD car ils nécessitent un support de l'affichage géré par le noyau (Kernel Mode Setting ou KMS). Il fallait donc fonctionner avec le pilote VESA ce qui était assez pénible (résolution incorrecte et aucun support de la 2D ou 3D). Avec FreeBSD 9.1 il était possible d'utiliser KMS pour les pilotes Intel mais de manière limitée.

FreeBSD 10 prend désormais en charge KMS pour les cartes graphiques AMD, permettant d'utiliser l'accélération 2D et 3D matérielle des puces graphiques de celles-ci. Pour Nvidia il faut toujours utiliser le pilote propriétaire qui n'exploite pas KMS. Concernant Intel, le support était déjà partiel à partir de la version 9.1 mais bien incomplet. FreeBSD 10 apporte des améliorations sur ce point.

Virtualisation

FreeBSD est connu depuis longtemps pour son système de jails, apparu sous FreeBSD 4 (2000). Cela permet de créer d'autres instances de FreeBSD, partielles ou complètes tout en restant sur la même machine physique. On peut ainsi créer des conteneurs systèmes très facilement, à l'instar des conteneurs LXC sous Linux. Combiné avec le linuxulator, il est même possible, avec quelques limitations, de créer des jails Linux.

Mais pour apporter la prise en charge des autres systèmes d'exploitation et outrepasser certaines limites, FreeBSD se dote désormais d'un véritable hyperviseur. Bhyve (BSD Hypervisor, anciennement BHyVe) est un hyperviseur dit de type 2 (qui s'exécute à l'intérieur d'un système d'exploitation à part entière), libre de tout héritage. Il va rapidement être désigné comme un concurrent à Linux-KVM et utilise déjà des périphériques VirtIO.

Bhyve requiert un CPU Intel avec le support VT-x et EPT. Il est actuellement capable de booter toute version de FreeBSD supportant VirtIO (8.4+) ainsi que GNU/Linux et OpenBSD. Le support de UEFI/BIOS n'étant pas encore implémenté, cela limite le nombre d'OS utilisables, toutefois ce support est une priorité pour le projet.

De fait, Bhyve est encore récent et ne supporte pas toutes les fonctionnalités classiques des hyperviseurs, qui sont prévues dans les versions futures, telles que le suspend/resume ou la live migration. Quelques limitations sont également présentes, comme le nombre de vCPU qui ne peut dépasser 16.

Par ailleurs, FreeBSD 10, tout comme FreeBSD 9.2, intègre des pilotes VirtIO ce qui lui permet de fonctionner de manière optimale dans un hyperviseur Linux-KVM ou VirtualBox (et très bientôt bhyve).

Enfin, beaucoup de pilotes Hyper-V ont été intégrés, permettant notamment un meilleur support des périphériques spéciaux et interaction avec l'hyperviseur (périphériques SCSI, synchronisation horloge, signal d'arrêt, migration à chaud).

Performances

Le pare-feu Packet Filter a été réécrit afin d'utiliser un système de verrous plus fin, améliorant sensiblement ses performances sur des machines multi-cœurs.

Applications

Le système de paquets de FreeBSD est désormais basé sur pkgng. Les anciens outils pkg_* ont été retirés.
Si vous souhaitez passer de FreeBSD 9.X à FreeBSD 10.X, il est suggéré d'installer pkg, puis de taper la commande pkg2ng avant de faire la mise à jour vers FreeBSD 10.

FreeBSD abandonne Bind au profil de LDNS et Unbound. Bind pourra toujours être installé en passant par les ports. Cette décision est l'aboutissement d'un long débat car il s'agit d'un changement important dans les habitudes des utilisateurs (une violation de la POLA) cependant le consensus s'est rapidement établi autour du fait que

  • seul un resolver était nécessaire dans le système de base,
  • Bind pose trop régulièrement des problèmes de sécurité, un remplaçant à la commande host(1) était un préalable absolu. Vitaly Magerya a donc implémenté un remplaçant de host basé sur ldns.

Sécurité

Le périphérique de nombres aléatoires random(4) est devenu plus sélectif, utilisant des sources qualifiées de « haute qualité ». Certaines sources jugées douteuses suite à des suspicions de surveillance de la part de certains gouvernements (mode paranoïa) ont été retirées.

Pourquoi choisir FreeBSD ?

Note : ce paragraphe a été ajouté à titre informatif, nul désir de troller. On ne peut affirmer objectivement que FreeBSD est supérieur ou inférieur à Linux. Les deux peuvent remplir les mêmes fonctions. Mais FreeBSD se démarque tout de même sur certains points :

  • Les jails qui sont matures et intégrés au système, tandis que sur Linux on ne sait pas quelle solution est vraiment pérenne (exemple : Xen retiré de la majorité des distributions, puis finalement intégré dans l'upstream du kernel. OpenVZ déprécié puis finalement en cours d'adaptation pour fonctionner en upstream aussi, etc).
  • La présence d'outils comme NanoBSD pour construire une image read-only du système très facilement.
  • Certains barbus préfèrent le système d'init et de configuration à l'ancienne.
  • Possibilité d'avoir une base stable avec des logiciels additionnels dans leur dernière version, ce qui allie les avantages du stable et du rolling release.
  • Le système de fichiers ZFS, très exigeant mais idéal pour du stockage de fichiers en datacenter.
  • Le système de ports, apprécié par certains barbus également, permet de passer ses propres options de compilation. Poudriere permet aussi de se faire très simplement un serveur de compilation de ports et un dépôt pkgng.

Conclusion

FreeBSD10 apporte beaucoup d'innovations et un souffle nouveau, autant pour les desktops que les serveurs.

  • # après linux, il y a freebsd

    Posté par (page perso) . Évalué à 3.

    ah, j'ai une freebsd 9.2 à mettre à jour alors :) Sympa toutes ces nouveautés !

  • # Par rapport à quoi?

    Posté par (page perso) . Évalué à 2.

    Mais FreeBSD se démarque tout de même sur certains points

    Il y a tellement des éléments que tu donnes qui sont dans des distributions Linux que ta démarque me semble vaine. La seule démarque pour moi est de s'éloigner du Bazar des distributions en s'approchant de la Cathédrale d'une seule distribution pour les satisfaire tous.

    En pratique, FreeBSD n'est pas conseillable pour une utilisation familiale ou professionnelle en poste de travail multi-fonctions, de même que beaucoup de distributions Linux. Il reste du coup cantonné à un usage serveur où il excelle, et geek pour expérimenter/avoir autre chose sur sa machine.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Par rapport à quoi?

      Posté par . Évalué à 10. Dernière modification le 21/01/14 à 15:43.

      Il y a tellement des éléments que tu donnes qui sont dans des distributions Linux que ta démarque me semble vaine.

      Même si mon but n'était pas de créer un troll, reprenons les points :

      • Les jails : pas présent dans Linux. La solution officielle est LXC et tout le monde la déconseille car pas mature, et il n'y a que ubuntu-server qui fait l'effort de l'implémenter proprement (les templates sont cassés sur debian et absents sur fedora).
      • NanoBSD : n'existe pas dans Linux.
      • L'init basique : il ne reste que debian et ubuntu. je suis prêt à parier que dans 3 ans debian passera sur systemd (puisque la mode est de suivre redhat et conspuer Canonical, ils ne vont pas utiliser upstart).
      • Stable + rolling release : à ma connaissance ce mélange n'est pas possible dans les distros Linux, sauf compilation à la main ou utilisation de Gentoo.
      • Les ports : peut-être possible mais pas supporté officiellement, sauf Gentoo encore une fois.

      Du coup je pense que ce que j'ai écrit n'est pas vain :)

      • [^] # Re: Par rapport à quoi?

        Posté par (page perso) . Évalué à 4.

        Je disais qu'il y a l'équivalent de ci de là :

        • Les jails : proxmox me semble rendre le même service.
        • NanoBSD : Debian Live ou Mageia Live que j'ai déjà utilisé le font
        • L'init basique : c'est créer un besoin que de le mettre en avant. Si FreeBSD développait un autre init, tu serais tenté de le défendre parce qu'il n'est pas basique…
        • Stable + rolling release : tu le dis toi-même, utilisation de Gentoo par exemple.
        • Les ports : de même.

        J'ai bien compris que tu ne voulais pas troller, et suis d'accord que tes mentions ne sont pas vaines. Mais il me semble qu'il est bon de reconnaître ses propres œillières, et tes arguments sont " la crémière est plus belle chez nous ", et pas " on a du beurre et pas vous ".

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Par rapport à quoi?

          Posté par . Évalué à 8.

          Oui enfin tu as beau sortir des arguments que tu veux, la sortie de FreeBSD 10 montre bien que la GPL est un échec.

          La preuve, EMACS est un logiciel sous GPL et provoque de l'arthrite, alors qu'un logiciel vraiment libre (comme Vim, bien qu'il soit truffé de publicités ougandaises) est une référénce dans le monde libre.

          En plus Stallman sent des aisselles.

        • [^] # Re: Par rapport à quoi?

          Posté par . Évalué à 4.

          • proxmox permet de créer ou du qemu-kvm pour de la virtualisation "lourde", ou de l'OpenVZ. Mais OpenVZ, tout comme LXC c'est pas fini. Tout le problème de Linux est là dedans : c'est jamais fini !!!
          • l'init est carrément plus simple sur FreeBSD que sur Debian 7, par exemple
          • les ports : ça se voit que t'as jamais monté une poudrière
          • NanoBSD est vraiment simple, contrairement aux outils pour debian, par exemple (jamais testé sur Mageia)
          • Sauf erreur de ma part, Gentoo met à jour le tout, comme Arch, alors que sur BSD, le kernel et les apps sont gérés séparément…
          • [^] # Re: Par rapport à quoi?

            Posté par (page perso) . Évalué à 7.

            Tout le problème de Linux est là dedans : c'est jamais fini !!!

            Comme pour tout développement qui n'est pas abandonné ou passé en correction de bugs seulement.

            FreeBSD n'est pas plus "fini" que Linux, mais il a une démarche plus stable dans le temps, et aussi moins de personnes pour y apporter des nouveautés ou des restructurations profondes, ceci aide un peu à cela.

            Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

          • [^] # Re: Par rapport à quoi?

            Posté par . Évalué à 5.

            tout comme LXC c'est pas fini

            Presque. La version 1.0 est passé en beta2 il y a quinze jour, la finale devrait bientôt sortir et être conseillée.

            Au passage, j'ai découvert récemment docker, une surcouche de LXC à la Proxmox, ça a l'air prometteur.

            Citons aussi Ubuntu qui intègre LXC dans AppArmor, ce qui rend son utilisation beaucoup plus secure.

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

            • [^] # Re: Par rapport à quoi?

              Posté par (page perso) . Évalué à 1.

              LXC est "production ready" depuis peu effectivement, et très simple à utiliser avec docker.
              Même si certains fournisseur de PaaS l'utilise en prod, ca n'a surement pas encore la maturité des jails.

          • [^] # Re: Par rapport à quoi?

            Posté par . Évalué à 2.

            OpenVZ, tout comme LXC c'est pas fini. Tout le problème de Linux est là dedans : c'est jamais fini !!!

            Effectivement, openVZ et LXC sont pas finis. Mais linux-Vserver marche tres bien chez moi, et ce depuis des années.

            Et en parlant de pas fini: la paille et la poutre… parce que bon, un système de conteneurs qui sait pas limiter la RAM, le CPU, le disque (avec un quota, pas un volume/partition dédié(e)) par conteneur…

        • [^] # Re: Par rapport à quoi?

          Posté par . Évalué à 2.

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Par rapport à quoi?

            Posté par (page perso) . Évalué à 9.

            L'init basique : si basique veut dire simple et compréhensible, je préfère systemd à SysV et similaires et leurs scripts. Si basique veut dire limité, j'en ai pas besoin.

            S'il faut dire ça en une phrase, je dirais que basique veut dire ici limité tant que ça reste simple et compréhensible. Par exemple, sous la vm avec OpenBSD que j'ai (j'ai pas de FreeBSD mais ça ressemble peut-être) les scripts d'init sont tous du genre (donc moins de 10 lignes, voire souvent 3 lignes exactement) :

            #!/bin/sh
            #
            # $OpenBSD: sshd,v 1.2 2013/02/05 00:26:31 halex Exp $
            
            daemon="/usr/sbin/sshd"
            
            . /etc/rc.d/rc.subr
            
            rc_reload() {
                    ${daemon} ${daemon_flags} -t && pkill -HUP -f "^${pexp}"
            }
            
            rc_cmd $1

            et tous utilisent un script commun rc.subr qui fait 200 lignes. Le système d'init semble guidé par /etc/rc, script d'un peu plus de 500 lignes. Donc, je dis peut-être des bêtises (les système d'init c'est pas un de mes grands intérêts), mais ça m'a l'air aussi simple qu'on peut espérer niveau implémentation et maintenance si on ne veut que les fonctionnalités start-stop-restart-reload, et il y a moins de chance qu'il y ait un bug dans 700 lignes de shell que dans une centaine de millier en C, d'où l'intérêt.

            Ceci dit, si t'as besoin d'un boot en parallèle ou que sais-je et utilisant des technologies plus complexes ce n'est sans doute pas ce qu'il faut, d'où l'intérêt de systemd aussi (voire d'autres systèmes comme openrc pour ceux qui sont mitigés dans leurs besoins et priorités).

            Ça trolle souvent sur les systèmes d'init, mais j'ai quand même l'impression qu'au final le choix de système d'init devrait juste être déterminé par les besoins spécifiques de chacun, de l'utilisation qu'il en fait, et de ses priorités. Et si l'utilisateur n'a pas d'avis par rapport à ses besoins c'est que n'importe lequel des deux fera l'affaire.

            • [^] # Re: Par rapport à quoi?

              Posté par (page perso) . Évalué à -4.

              Ça trolle souvent sur les systèmes d'init, mais j'ai quand même l'impression qu'au final le choix de système d'init devrait juste être déterminé par les besoins spécifiques de chacun, de l'utilisation qu'il en fait, et de ses priorités. Et si l'utilisateur n'a pas d'avis par rapport à ses besoins c'est que n'importe lequel des deux fera l'affaire.

              Donc si je suis ta logique, c'est mieux de segmenter les systèmes d'init au lieu d'avoir une solution générique et performante ( genre systemd au hasard ) juste que pour l'admin système flemmard d'apprendre autre chose que bash puisse continuer à jouer.

              Implacable logique effectivement.

              • [^] # Re: Par rapport à quoi?

                Posté par . Évalué à -3.

                Embrace and extend. Bienvenue chez MicrosoftW les partisans de systemd.

                • [^] # Re: Par rapport à quoi?

                  Posté par . Évalué à 8. Dernière modification le 24/01/14 à 12:13.

                  Ça n'a rien à voir.

                  La stratégie Embrace, extend and extinguish c'est :

                  • Embrace : Microsoft développe des logiciels substantiellement compatibles avec les produits concurrents, ou implémentant un standard public ;
                  • Extend : Microsoft ajoute et fait la promotion de fonctions non supportées par les produits concurrents, créant des problèmes d’interopérabilité pour les clients souhaitant demeurer « neutres » ;
                  • Extinguish : Les extensions Microsoft deviennent un standard de facto en raison de leur position dominante sur le marché, ce qui marginalise les concurrents et crée un obstacle majeur à d’éventuels nouveaux concurrents.

                  Or,
                  Embrace : les systèmes d'init n'ont jamais été 100% compatibles entre eux (essaie d'utiliser un script pour upstart avec OpenRC pour rire).
                  Extend : systemd ne propose pas d'extensions propriétaires, mais quelque chose de différent et de libre, et propose une couche de compatibilité avec l'existant.
                  Extinguish : Il y a un nouveau système d'init tous les 4 jours… Ce qui fait que Debian a le choix entre pas moins de 4 systèmes d'init, tous incompatibles entre eux.

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Par rapport à quoi?

              Posté par (page perso) . Évalué à 4.

              qu'il y ait un bug dans 700 lignes de shell

              Et combien de ligne de code en C dans ton shell?

              • [^] # Re: Par rapport à quoi?

                Posté par (page perso) . Évalué à 1.

                J'ai regardé, ça fait 20 mil SLOC de C pour ksh (avec sloccount), donc petit pour un shell mais non négligeable. En suivant le même raisonnement, on peut aussi inclure gcc ou clang dans les deux cas, qui explosent facilement tout le reste, et on en conclut que la complexité du système d'init sera de toutes façons noyée dans le reste donc peu importe. Pourtant, ce raisonnement ne me semble absolument pas pertinent, voilà essentiellement pourquoi : le shell et gcc sont testés beaucoup plus amplement, pour des utilisations plus diverses et variées, depuis plus longtemps, et de toutes façons on ne pourra pas s'en débarrasser : pour le compilateur de C c'est clair, et pour le shell, je te laisse le soin d'inventer une évolution réaliste des systèmes à l'héritage Unixien qui nous permette de s'en passer, bonne chance!

                • [^] # Re: Par rapport à quoi?

                  Posté par . Évalué à 4.

                  le shell et gcc sont testés beaucoup plus amplement, pour des utilisations plus diverses et variées, depuis plus longtemps

                  Avec des raisonnements pareils, autant éviter toute évolution ou nouveau développement.

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Par rapport à quoi?

                    Posté par . Évalué à 3.

                    le shell et gcc sont testés beaucoup plus amplement, pour des utilisations plus diverses et variées, depuis plus longtemps

                    Avec des raisonnements pareils, autant éviter toute évolution ou nouveau développement.

                    Si tu veux pas de bugs, oui, c'est l'idée.

                    Please do not feed the trolls

                    • [^] # Re: Par rapport à quoi?

                      Posté par . Évalué à 3.

                      Si tu veux pas de bugs, oui, c'est l'idée.

                      Non si tu ne veux pas de bug faut se tenir éloigné des ordinateurs (ou alors simplement ne rien faire avec).

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

                  • [^] # Re: Par rapport à quoi?

                    Posté par (page perso) . Évalué à 5.

                    Avec des raisonnements pareils, autant éviter toute évolution ou nouveau développement.

                    Loin de moi l'idée de sous-entendre ça, vu le goût que j'ai pour les nouveautés, la recherche, etc… qui sont de très bonnes choses. Mais ça n'enlève pas que dans certains contextes tu n'as tout simplement pas besoin des nouvelles fonctionnalités apportées, ou que pour ton cas elles marchent moins bien que ce que tu as déjà, et enfin, si la stabilité est une des priorités on a le droit de vouloir utiliser un système plus simple et basique et qui a eu plus de temps pour mûrir, je ne pense pas qu'il y ait un mal à cela, ni que ça soit un frein à toute évolution, c'est juste que tout le monde n'innove pas sur les mêmes choses.

                    Il faut des gens pour tester les nouveaux systèmes d'init, d'autres pour tester les nouveaux langages (c'est plus le genre de chose qui m'amuse par exemple), d'autres le dernier tiling wm ou les dernières innovations des gros desktops, etc… ça veut pas dire qu'on doit tous tout tester maintenant, ni peut-être jamais, et que même si on teste une nouveauté on n'utilise pas aussi parallèlement d'autres bons vieux trucs qui marchent aussi.

            • [^] # Re: Par rapport à quoi?

              Posté par . Évalué à 5.

              Ceci dit, si t'as besoin d'un boot en parallèle ou que sais-je et utilisant des technologies plus complexes ce n'est sans doute pas ce qu'il faut, d'où l'intérêt de systemd aussi (voire d'autres systèmes comme openrc pour ceux qui sont mitigés dans leurs besoins et priorités).

              C'est je pense ce qui a échappé à pas mal (au moins au début) : « Pourquoi passer à quelque chose que je ne connais pas alors que la solution actuelle me convient ? »

              Quand on est sur un PC fixe avec une utilisation qui n'a au final pas beaucoup évolué depuis le début des années 90, c'est sur que l'évolution ne sert à rien, mais si tu es dans un environnement embarqué et que tu lance pas les même services en fonction de si tu as une connexion wifi, 3/4G ou pas du tout et si tu est sur batterie, sur secteur ou que ta batterie a un niveau de charge inférieur à un seuil donné,… alors je te garantis que les OpenRC, Sysvinit, rc.d et autres ne te sont d'aucune utilité. C'est dommage parce que c'est aujourd'hui le marché en haute progression (PC portable, téléphone mobile et tablette).

              Et comme souvent alors plus de possibilités permet d'imaginer de nouvelles utilisation. Par exemple la capacité de systemd à connaître l'état des deamon pourrait permettre à des solution de supervision de s'auto-configurer ou de reposer sur systemd pour remplacer ou améliorer certaines sondes.

              Je ne dis pas qu'il faut passer à systemd, personnellement je n'en ai pas besoin et je n'en aurais pas besoin de si tôt (je me fou de l'init que j'utilise, c'est à mon avis un peu plus simple de faire du systemd propre que du sysvinit, mais à part ça). Je dis juste que c'est un peu plus que des besoins très spécifiques et/ou marginales.

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

              • [^] # Re: Par rapport à quoi?

                Posté par (page perso) . Évalué à 1.

                Je suis d'accord, et je suis sûr aussi que si autant de code a été écrit pour systemd c'est parce qu'il y avait des besoins réels.

                Par exemple la capacité de systemd à connaître l'état des deamon pourrait permettre à des solution de supervision de s'auto-configurer ou de reposer sur systemd pour remplacer ou améliorer certaines sondes.

                Peut-être, c'est sûr que ce n'est pas le système d'init d'OpenBSD qui va te permettre de faire ce genre de choses. Mais en l'occurrence tu trouveras que les gens OpenBSD n'ont réalisé encore aucune solution de supervision parce qu'ils considèrent que c'est impossible de virtualiser correctement les différentes architectures de manière fiable, et qu'ils conseillent plutôt des solutions moins parfaites en théorie, et moins pratiques, comme le chroot, ou la simple séparation des privilèges. Je ne dis pas que c'est forcément une bonne solution, je pense personnellement que la virtualisation est très utile, mais leur point de vue semble compréhensible aussi, et du coup leur objectif étant de rester simple, et OS à vocation pare-feu entre autres, sans doute que leur système d'init est suffisant pour leur objectif.

                • [^] # Re: Par rapport à quoi?

                  Posté par . Évalué à 3.

                  On a pas du parler de la même chose par supervision je pensais à des trucs comme Nagios, Shinken ou autre. Je pense que tu veux parler d'hyperviseur.

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

                  • [^] # Re: Par rapport à quoi?

                    Posté par (page perso) . Évalué à 1.

                    Oui, tu as raison, j'ai confondu les deux termes. Faut dire que hyper ~ super et vision ~ viseur ;) D'ailleurs c'est vrai que j'avais pas trop vu la logique de ta phrase du coup, je devais pas être très réveillé.

        • [^] # Re: Par rapport à quoi?

          Posté par . Évalué à 6.

          Proxmox est une distribution Linux qui se base sur deux choses : KVM (upstream certes, mais pas la même chose du tout que les jails) et OpenVZ (pas upstream).
          NanoBSD ce n'est pas une distribution Live. c'est un ensemble de scripts qui te permettent de générer ton propre système embarqué.

          • [^] # Re: Par rapport à quoi?

            Posté par (page perso) . Évalué à 5.

            Tu oublies de parler de crochet, un nouvel outil qui est apparu permettant de générer des images automatiquement pour des systèmes embarqués (Raspberry PI, Beagleboard…) sous FreeBSD :)

            CNRS & UNIX-Experience

            • [^] # Re: Par rapport à quoi?

              Posté par . Évalué à 2. Dernière modification le 22/01/14 à 12:08.

              Crochet est mentionné dans la dépêche il y a même un lien.
              Mais personnellement je ne l'ai jamais utilisé.

        • [^] # Re: Par rapport à quoi?

          Posté par (page perso) . Évalué à 2.

          Stable + rolling release : tu le dis toi-même, utilisation de Gentoo par exemple.
          Les ports : de même.

          Et avec des binaires au lieu de compiler à la main, tu as quoi ?

          Opera le fait depuis 10 ans.

          • [^] # Re: Par rapport à quoi?

            Posté par . Évalué à -5.

            Et avec des binaires au lieu de compiler à la main, tu as quoi ?

            Pleins dépendances inutiles (et donc de l'espace disque).

          • [^] # Re: Par rapport à quoi?

            Posté par (page perso) . Évalué à 1.

            Gentoo toujours, qui permet de télécharger les paquets précompilés si on veut.

            • [^] # Re: Par rapport à quoi?

              Posté par (page perso) . Évalué à 3.

              Y a pas de dépôts de binaires officiel, et il n'y en aura jamais (cf le wiki officiel de Gentoo).

              Opera le fait depuis 10 ans.

          • [^] # Re: Par rapport à quoi?

            Posté par . Évalué à 1.

            Debian avec du pinning ?

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

          • [^] # Re: Par rapport à quoi?

            Posté par . Évalué à 0. Dernière modification le 23/01/14 à 16:51.

            Ubuntu avec des PPAs/pinning, Manjaro ?

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Par rapport à quoi?

        Posté par . Évalué à 3.

        Les jails : pas présent dans Linux. La solution officielle est LXC et tout le monde la déconseille car pas mature

        En attendant, vserers et openVZ sont matures et très performants. Sous Solaris il y a les zones.

        Quant-à XEN, que tu mentionnes par ailleurs, c'est complètement différent. Comme KVM et virtualbox, il s'agit plus que d'un simple container.

        L'init basique : il ne reste que debian et ubuntu. je suis prêt à parier que dans 3 ans debian passera sur systemd (puisque la mode est de suivre redhat et conspuer Canonical, ils ne vont pas utiliser upstart).

        D'après le wiki Gentoo (première distrib prise au hasard) :

        systemd is a modern sysvinit & RC replacement for Linux systems. It is supported in Gentoo as an alternate init system.

        De ce que j'en comprends, systemd est optionnel. Ça doit être pareil pour d'autres distrib GNU/linux (je ne parles même pas de solaris ni de Debian GNU/kFreeBSD).

        Bref, j'ai surtout l'impression que c'est du FUD. Ou bien que tu connais très mal l'univers de GNU/Linux, ce qui te permet d'affirmer que l'herbe est plus verte ailleurs.

        Je ne reviens pas sur les autres points, l'ami zezihno a déjà répondu.

        • [^] # Re: Par rapport à quoi?

          Posté par . Évalué à 1.

          OpenVZ, performant ? sur du kernel 2.6 peut être… mais quand t'es obligé de monter sur du >= 3.8, ça commence à craindre…
          Vserver, n'est pas inclus dans debian, par exemple… Contrairement aux jails FreeBSD…
          L'alternative à XenServer, FreeBSD n'en a pas de viable pour le moment. Mais est-ce réellement un problème ?

        • [^] # Re: Par rapport à quoi?

          Posté par . Évalué à 4.

          vserver et openvz ne sont pas "upstream".
          Alors que les jail dans FreeBSD oui.
          Seul LXC est upstream sur Linux.

          Et Xen je ne le compte pas, pour moi c'est vraiment pas pareil.

      • [^] # Re: Par rapport à quoi?

        Posté par (page perso) . Évalué à 7.

        L'init basique : il ne reste que debian et ubuntu.

        As-tu déjà regardé le système d'init de slackware par exemple ? Il n'utilise que de simples scripts bash parfaitement lisibles et personnalisables à souhait. Il n'y a même pas d'outil d'init à proprement parler, que des scripts.

        • [^] # Re: Par rapport à quoi?

          Posté par . Évalué à -2. Dernière modification le 22/01/14 à 09:41.

          On a déjà dit que les scripts c'était nul pour l'init (langage bash difficile à maîtriser, au moins deux processus par service - 1 pour l'instance de bash, 1 pour le fork() -, pas de support pour l'évènementiel, beaucoup de code répété, …).

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Par rapport à quoi?

            Posté par (page perso) . Évalué à 2.

            On a déjà dit que les scripts c'était nul pour l'init (langage bash difficile à maîtriser,

            C'est sûr que si tu utilises bash pour faire un script RC sous FreeBSD tu dois t'attendre à des migraines et des nervous breakdown comme on dit de nos jours.

            les pixels au peuple !

            • [^] # Re: Par rapport à quoi?

              Posté par . Évalué à 0.

              Le commentaire auquel je répondais parlait de slackware (qui n'est pas un BSD) et de scripts bash pour l'init.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Par rapport à quoi?

            Posté par . Évalué à 5.

            Tu peux aimer systemd, c'est ton droit, mais de là à raconter n'importe quoi…

            Il n'y a qu'un seul processus :

                  fork + exec                  exec
            Init --------------> Shell script -------> daemon
            

            Eventuellement, le shell script peut effectuer des forks pour appeler des commandes externes, mais ce n'est pas forcément le cas, les scripts sont relativement simples.

            Beaucoup de code répetter, j'aimerais bein que tu m'explique ou. Tout le code commun se trouve dans rc et rc.subr. Si tu y vois du code répetté, tu es obligé d'admettre que la description des units est du code (déclaratif certes) répétté, car cela fonctionne exactement pareil.

            Pas de support de l'évenementiel, c'est vrai et c'est une raison historique. (à l'époque, c'était une raison de performances). Toutefoirs, ça dépend de ton usage encore une fois. Moi ça ne me dérange pas j'utilise un outil de supervision distinct pour faire ce genre de chose sur les daemons critiques. Bref ça dépend de ce dont tu as besoin.

            Je ne comprends pas cette volonté d'imposer une technologie en voulant absolument convaincre toute le monde que c'est la meilleure pour eux et pour n'importe qui, et de toute manière tant pis si les gens sont pas convaincu parce qu'on fera tout pour les forcer à l'utiliser quand même.

            • [^] # Re: Par rapport à quoi?

              Posté par . Évalué à 1. Dernière modification le 02/02/14 à 10:03.

              Il n'y a qu'un seul processus :
              fork + exec exec
              Init --------------> Shell script -------> daemon

              Dans tous les cas, utiliser les shell scripts pour contrôler les daemons ça donne ce résultat :

              1) init starts a service process.
              2) The service process starts some other sub process it needs.
              3) The service process gets terminated to restart
              4) The sub process stays running.
              5) service started falls over in a heap because sub process is still alive.

              ;-)

              Beaucoup de code répetter, j'aimerais bein que tu m'explique ou. Tout le code commun se trouve dans rc et rc.subr. Si tu y vois du code répetté, tu es obligé d'admettre que la description des units est du code (déclaratif certes) répétté, car cela fonctionne exactement pareil.

              Au lieu d'avoir un script d'init par distribution (qui font tous à peu près la même chose), il y a un fichier .service fourni par le projet concerné (exemple : Nginx) qui fonctionne partout sans modification.

              Et comme ce n'est pas du code, il y a beaucoup moins de risques d'erreurs.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Par rapport à quoi?

                Posté par . Évalué à 0.

                Au lieu d'avoir un script d'init par distribution (qui font tous à peu près la même chose), il y a un fichier .service fourni par le projet concerné (exemple : Nginx) qui fonctionne partout sans modification.

                Avant, il avait 7 systèmes d'init différents. Incompatibles entre eux.

                Maintenant, il y a 7 systèmes d'init différents. Incompatibles entre eux. La situation est bien meilleure.
                Encore une fois, Unix != Linux. Si tu veux un truc qui "tourne partout", comme Nginx, tu dois supporter beaucoup de choses. Nginx tourne sous BSD, qui utilisent deux version de de scripts RC différents (mais relativement compatibles en réalité). Nginx tourne sous gentoo/slackware etc. Nginx tourne sous Solaris, qui utilise SMF, et des fichiers XML (mais compatible avec sys-v inits il me semble, comme quoi c'est possible). Nginx tourne sous OS X, qui utilise launchd et des fichiers XML, mais différents.

                Mais je crois que tu as raison. Il suffit de fournir un .service et ça tourne partout.

      • [^] # Re: Par rapport à quoi?

        Posté par . Évalué à 4.

        (puisque la mode est de suivre redhat et conspuer Canonical, ils ne vont pas utiliser upstart).

        On n'est pourtant pas vendredi, si?

        • [^] # Re: Par rapport à quoi?

          Posté par . Évalué à 5.

          J'imagine mal debian s'isoler sur upstart alors que 99,9% des distributions vont utiliser (ou utilisent déjà) systemd.
          On ne sait pas quel est l'avenir de ubuntu quand on voit les mauvais choix stratégiques (smartphone, mir…).

      • [^] # Re: Par rapport à quoi?

        Posté par (page perso) . Évalué à 3.

        L'init basique : il ne reste que debian et ubuntu.

        Upstart c’est basique? D’après ce que j’ai compris, pas tant que ça.

        • Tasks and Services are started and stopped by events
        • Events are generated as tasks and services are started and stopped
        • Events may be received from any other process on the system
        • Services may be respawned if they die unexpectedly
        • Supervision and respawning of daemons which separate from their parent process
        • Communication with the init daemon over D-Bus
        • User services, which users can start and stop themselves

        Sans compter l’intégration avec Plymouth.

        Notons d’ailleurs que l’argument de nécessiter dbus sera bientôt obsolète (que ça soit pour Upstart ou systemd), car dbus sera intégré dans le noyau Linux (projet kdbus).

        je suis prêt à parier que dans 3 ans debian passera sur systemd (puisque la mode est de suivre redhat et conspuer Canonical, ils ne vont pas utiliser upstart).

        Nan mais c’est vrai que que souvent les développeurs de Debian prennent les décisions sur un coup de tête…

        D’ailleurs, un avis en faveur d’Upstart sur le wiki Debian.

        Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Par rapport à quoi?

        Posté par (page perso) . Évalué à 7.

        L'init basique : il ne reste que debian et ubuntu. je suis prêt à parier que dans 3 ans debian passera sur systemd (puisque la mode est de suivre redhat et conspuer Canonical, ils ne vont pas utiliser upstart).

        Cette manie d'oublier Slackware… Linux ce n'est pas que Debian/*buntu/RedHat.

        • [^] # Re: Par rapport à quoi?

          Posté par . Évalué à 5.

          Cette manie d'oublier Slackware… Linux ce n'est pas que Debian/*buntu/RedHat.

          Cette manie d’oublier gentoo… Linux ce n’est pas que Debian/*buntu/RedHat/Slackware ;-)

  • # Il me semblait que Capsicum était maintenant activé par défaut

    Posté par . Évalué à 7.

    Ce qui me paraissait un gros point au niveau sécurité, maintenant je ne l'ai pas vu dans les release note alors j'ignore si c'est le cas..

  • # Quelques autres changements

    Posté par . Évalué à 5.

    Principalement tirés de : https://wiki.freebsd.org/WhatsNew/FreeBSD10

    logiciels par défauts

    • le serveur DNS BIND est remplacé dans le système de bse par unbound et LDNS.

    plateforme

    • Freebsd tourne désormais sur EC2.

    Noyau

    • le support du pilote DRM/KMS radeon, tel que présent dans linux 3.8. une nouvelle console VT(9) aka newcons a vocation à remplacer l'ancien émulateur de console syscons. VT(9) fonctionne avec DRM, et il peut être utilisé quand KMS est activé, permettant d'avoir accés à une console après avoir démarer X avec un pilote KMS. newcons améliore aussi le support d'utf8.

    • les buffers d'entrée sorties, notament utilisés par la couche de systèmes de fichiers virtuel, peuvent désormais être utilisés sans être mappés dans un espace d'addressage. C'est à dire qu'au lieu d'accéder à la mémoire en utilisant des addresses virtuelles pointant vers un buffer contigu, on n'a pas besoin de faire correspondre des pages virtuelles aux pages mémoire physiques pour y accéder. Une liste des pages mémoire physique est conservée, et la lecture écriture utilise cette liste de page directement. Cela améliore grandement les performances. En effet, les buffers sont en général mappés dans l'espace mémoire virtuel du noyau, qui est mappé pour tout les processus. Donc, quand on crée un buffer, on a pas besoin de modifier la table des pages mémoires virtuelles, et donc à notifier tout les cpus que le cache des pages virtuelles est invalide. Ce qui est un gros gain.

    • le pilote netmap a été ajouté. Netmap est un framework qui permet d'utiliser directement les cartes réseau sans passer par la pile réseau et le mécanisme des sockets. La communication se fait par une zone mémoire mappée en espace utilisateur qui donne directement accés aux buffers de paquet, et à une copie des files TX et RX du pilote.

    • Une nouvelle pile SCSI entièrement en espace noyau

    • [^] # Re: Quelques autres changements

      Posté par . Évalué à 2.

      Pour BIND, c'est uniquement pour la partie récursive/cache.
      Ils ont pas poussé NSD ou Knot ?

      • [^] # Re: Quelques autres changements

        Posté par (page perso) . Évalué à 5.

        Ils ont pas poussé NSD ou Knot ?

        Non, il y a eu un consensus autour du fait qu'un serveur autoritaire n'avait pas sa place dans le système de base (pas plus qu'un serveur imap ou http …).

        • [^] # Re: Quelques autres changements

          Posté par . Évalué à 3.

          Non, il y a eu un consensus autour du fait qu'un serveur autoritaire n'avait pas sa place dans le système de base (pas plus qu'un serveur imap ou http …).

          Pourquoi ne pas faire la même chose pour Sendmail ? Parce que la suppression de Bind, c'est aussi pour des problèmes de sécurité régulier (je ne jette pas la pierre à Bind, c'est le succès dira t-on).
          Remplacer Sendmail par un Ssmtp (ou similaire) serait aussi judicieux dans ce cas.

          • [^] # Re: Quelques autres changements

            Posté par . Évalué à 2.

            Remplacer Sendmail par un Ssmtp (ou similaire) serait aussi judicieux dans ce cas.

            C'est le but de dma(8)

            Il accepte les mails locaux, et les délivre aux utilisateurs, il envoit des mails locaux ou distant, mais ce n'est pas un serveur smtp qui écoute sur le port 25 exterieur.

            • [^] # Re: Quelques autres changements

              Posté par . Évalué à 2.

              l envoit des mails locaux ou distant, mais ce n'est pas un serveur smtp qui écoute sur le port 25 exterieur.

              Pratique pour ne pas être emmerdé avec les bounces ;)

  • # image FreeBSD pour Raspberry Pi ?

    Posté par . Évalué à 2.

    Où trouver une image récente pour Raspberry Pi ?
    Est-il obligatoire d'utiliser Crochet pour ça ?

  • # Nombres aléatoires

    Posté par (page perso) . Évalué à 5.

    Après avoir lu la news sur le nouveau Linux 3.13 et en particulier cet article http://blog.cloudflare.com/ensuring-randomness-with-linuxs-random-number-generator je croyais que dans un générateur de nombres aléatoires, une mauvaise source ne pouvait pas diminuer la qualité, car de toute façon on fait un XOR. A la limite, ajouter une source parfaitement déterministe ne provoquerait simplement aucune amélioration de l'entropie.

    Pourquoi est-il donc plus sécurisé d'enlever certaines sources de basse qualité alors ? FreeBSD ne fait pas de XOR comme Linux ?

    • [^] # Re: Nombres aléatoires

      Posté par (page perso) . Évalué à 10. Dernière modification le 22/01/14 à 22:23.

      Houlala…tu prends des risques en lançant le sujet :-)

      Pour résumer les trois épisodes de la saga :

      1) FreeBSD annonce que, suite aux révélations de Snowden, ils vont réduire le rôle des générateurs d'entropie implémentés en hardware (HW RNGs) car ils n'ont plus confiance en Intel ou en Via.

      2) Un journaliste inconscient demande à Theo de Raadt (leader d'OpenBSD) si ils vont faire pareil que FreeBSD. Theo en profite pour passer le projet FreeBSD au lance-flammes en disant que ce sont des brèles qui ne connaissent rien à la sécurité. Que dans OpenBSD, et aussi dans Linux, cela fait des années (le commit sur le générateur Via date de 2003) qu'on n'accorde aucune confiance exclusive aux HW RNGs et qu'on se contente de les considérer comme une source d'entropie comme une autre qu'on mixe au sein de l'entropy pool.
      Theo se demande même pourquoi les gens de FreeBSD, pendant des années, n'ont pas suivi les bonnes pratiques cryptographiques. Il lance même une accusation vraiment grave : "They must have chosen a few years ago to do this wrong, intentionally. Perhaps that decision was made by their Californian developers, the ones who work fairly close to that NSA building."

      3) Marshall Kirk McKusick, un des grands manitous du monde UNIX et un des développeurs FreeBSD répond à Theo. En résumé il explique que ce choix avait été fait à l'époque pour des raisons de performances parce que les HW RNGs sont très rapides et consomment peu de CPU.
      Il confirme donc parfaitement les critiques de Theo avec cette phrase en forme d'aveu : "Specifically, FreeBSD 9.2 shipped using 'rdrand' support enabled by default. If you have an Intel CPU supporting this feature, Yarrow will not be used for /dev/random: all randomness comes straight from the CPU's built-in random number generator."

      Dans FreeBSD 9.2 on était donc complètement dépendant du générateur aléatoire rdrand d'Intel. A partir de FreeBSD 10.0 l'entropie générée par ce module sera envoyée dans Yarrow (le générateur cryptographique de nombres pseudo-aléatoires de FreeBSD).

      C'est donc certes un progrès pour FreeBSD mais ça arrive avec 10 ans de retard sur ses concurrents libres ;-)

      C'est pourquoi je me permets de rigoler un bon coup en lisant cette phrase dans l'article d'ITWire : "McKusick said FreeBSD remained committed to staying on the leading edge of cryptographic engineering."

      Leading edge ? Mouarf !

  • # ZFS dés l'installation.

    Posté par (page perso) . Évalué à 3.

    Voilà enfin ce que j'attendais, /racine natif en ZFS (bien qu'expérimental si j'en crois le menu d'installation), orné du nouvel algo de compression LZ4 … je sens que je vais me gaver.

    J'attends la fin de l'installation de ma VM de test pour voir si j'arrive à reproduire mon environnement existant (Ubuntu Server/ZFS/LxC), vers quelque chose du genre ZFS/Jails.

    Et à moi les joies de la sauvegarde système par snap ZFS, et la compression, les réplications block vers des machines distantes rhaaaa : )

    Niveau "virtualisation" c'est toujours autant le bazar en revanche y en a partout.

    Je suis un peu plus inquiet sur les fonctionnalités que propose les Jails par rapport aux LinuXConteneur, le niveau de virtualisation est-il "le même" ?

    J'entends par là Jails n'est il pas qu'un super chroot, qui ne virtualise pas du tout en fait, qui chroot façon stéorïde et qui autorise uniquement des "VM" BSD ?

    Les LxC bon c'est pas mal, mais ça sent quand même le produit pas trop mature je trouve, mais je commence à m'y faire, coupler à des slices ZFS ça envoie juste du petit pâté pour la sauvegarde ou la migration des conteneurs.

    OpenVZ bon ça c'est en fonction de la distribution, c'est très sympa (sur les distro Noyo 2.6 … ),Ubuntu server plébicite beaucoup plus LxC, je ne souhaite pas installer Debian 6.0 et mon test avec CentOS 6.3 m'a montré quelques bizarreries avec ZFS (niveau montage)

    KVM,Vserver,Xen et compagnie ne me présente pas d'intérêt (trop lourds).

    Sinon quelqu'un aurait un commentaire éclairé à faire par rapport à ça : FreeBSD Jails Security

    • [^] # Re: ZFS dés l'installation.

      Posté par . Évalué à 4. Dernière modification le 22/01/14 à 22:15.

      /racine natif en ZFS (bien qu'expérimental si j'en crois le menu d'installation)

      De fait, ça a toujours très bien marché sans utiliser l’installeur graphique, au moins en version 8.x et 9.x. Installeur qui est un tantinet inutile vu le peu de commandes nécessaires à l’installation.

      Pour le fameux blog de BSD FUD, tu pourras trouver quelques réponses en ligne.

    • [^] # Re: ZFS dés l'installation.

      Posté par (page perso) . Évalué à 7.

      Ton lien final c'est juste du n'importe quoi, lit un peu le reste des articles sur ce site et tu comprendras qu'il n'y a absoluement rien a tirer de ce site.

      (Par exemple selon se site j'ai volée le code d'apt, violé la license, et viré toutes les parties que je ne comprennais pas)

      • [^] # Re: ZFS dés l'installation.

        Posté par (page perso) . Évalué à 4.

        Par exemple selon se site j'ai volée le code d'apt, violé la license, et viré toutes les parties que je ne comprennais pas)

        Ce site m'a fait marrer, je ne vois pas comment on peut le prendre au sérieux plus de 5 secondes :)

        Mais bon, tu ne mérites pas ça :)

        les pixels au peuple !

        • [^] # Re: ZFS dés l'installation.

          Posté par (page perso) . Évalué à 5.

          Mais bon, tu ne mérites pas ça :)

          Au contraire ça veut dire que pkgng est pas mal si des gens pensent que j'ai piqué le code de apt :), ce site me fait rire aussi. A chaques fois, j'attends avec impatience la nouvelle news :)

    • [^] # Re: ZFS dés l'installation.

      Posté par (page perso) . Évalué à 5.

      J'entends par là Jails n'est il pas qu'un super chroot, qui ne virtualise pas du tout en fait, qui chroot façon stéorïde et qui autorise uniquement des "VM" BSD ?

      Oui les jails ce n'est pas de la virtualisation, c'est du "confinement". Un chroot mais qui va plus loin que le confinement au niveau disque (et n'a pas les soucis de chroot en terme de sécu), confinement de root, confinement des processus, et confinement réseau.

      C'est tout, l'avantage c'est que ça a très peu de coût en terme de performance.

      les pixels au peuple !

      • [^] # Re: ZFS dés l'installation.

        Posté par . Évalué à 2.

        Mis à part les problèmes du chroot, c'est fonctionnellement à peu près équivalents aux namespace linux, non ?

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

        • [^] # Re: ZFS dés l'installation.

          Posté par (page perso) . Évalué à 4.

          je ne connais pas trop linux, concernant les jails le papier d'origine de PHK est toujours d'actualité pour le principe http://phk.freebsd.dk/pubs/sane2000-jail.pdf

          Y'a eu des améliorations depuis (ipv6, jail sans IP, réseau virtualisé) mais c'est toujours ça.

          les pixels au peuple !

          • [^] # Re: ZFS dés l'installation.

            Posté par . Évalué à 3.

            Mis à part les problèmes du chroot, c'est fonctionnellement à peu près équivalents aux namespace linux, non ?

            Je ne connais pas non plus les namespace Linux, mais pour faire simple, c'est un chroot disque, un chroot réseau (partiel, une interface appartient toujours à son hôte), un chroot mémoire. Il y a encore quelques limites techniques mais elles sont rares (nfs ne fonctionne pas dans une jail).
            Si tu veux avoir un pile réseau complête, tu peux rajouter l'option VNET. Dans ce cas peut dire que la carte réseau n'appartient plus à l'hôte mais plutôt à la jail. Si tu veux partager la carte entre jail et l'hôte, faut faire du bridge (et utiliser netgraph, mais la ca dépasse mes compétences).
            Moi, je ne me sers que des jails sans VNET, ca suffit amplement.

            Le plus chiant, c'est les mises à jour des jails, c'est pas aussi pratique que l'OS hôte. Mais la encore, on trouve de très bon outils (en SH je crois), qui nous aident.

            Y'a eu des améliorations depuis (ipv6, jail sans IP, réseau virtualisé) mais c'est toujours ça.

            J'ai pas l'impression qu'il y ait eut des nouveautés en 10.0

      • [^] # Re: ZFS dés l'installation.

        Posté par . Évalué à 4.

        Tu peux aussi faire tourner du « Linux » en jail FreeBSD

  • # Je voulais tester et je suis tomber sur ce brûlot

    Posté par . Évalué à -1.

    Freebsd, un système d’exploitation obsolète et dangereux?

    Du coup, je reste perplexe… Je me doute bien que la réalité n'est pas si terrible, mais ça fait peur

    • [^] # Re: Je voulais tester et je suis tomber sur ce brûlot

      Posté par (page perso) . Évalué à 6.

      J'utilise FreeBSD en desktop tous les jours, sur mon laptop aussi, et pire je suis sur du CURRENT (aka la version de dev) sur le portable, et j'en suis très content :)

      • [^] # Re: Je voulais tester et je suis tomber sur ce brûlot

        Posté par (page perso) . Évalué à 4.

        J'utilise FreeBSD en desktop tous les jours, sur mon laptop aussi, et pire je suis sur du CURRENT (aka la version de dev) sur le portable, et j'en suis très content :)

        Oui mais là tu es un aventurier :) Ceci dit je l'utilise en desktop tous les jours chez moi et au boulot et j'en suis content aussi (même si je peste régulièrement sur les ports cassés)

        Au taf j'ai tenté une Ubuntu dans un moment de folie et j'en suis vite revenu. Je dois être trop vieux.

        les pixels au peuple !

    • [^] # Re: Je voulais tester et je suis tomber sur ce brûlot

      Posté par . Évalué à 5.

      Moi je voulais aller au état-unis, mais on m'a dit que la CIA et les sionistes avaient orchestré les attentats du 11 septembre. Du coup, je rete perplexe. Je me doute bien que la réalité n'est pas si terrible, mais ça fait peur.

    • [^] # Re: Je voulais tester et je suis tomber sur ce brûlot

      Posté par . Évalué à 5.

      Sinon, une réponse plus sur le fond :

      FreeBSD prétend être l’un des OS les plus sûr par sa conception et utilisation.

      Déjà, j'espère que FreeBSD ne prétend pas ça parce que ça serait un gros mensonge.

      • paquets/ports : 90% de ce qui est raconté n'est plus vraiment d'actualité avec FreeBSD 10. Une bonne partie est vraie, mais c'est présenté uniquement du point de vue négatif des choses.

      • Support matériel : il y a bien évidement moins de pilotes que sous linux. Après ça dépend des domaines, par exemple les controlleurs raids sont très bien supportés, les chipset bluetooth moins. Ça ressemble à ce qu'il se passait sous linux il y a pas si longtemps. ça dépend de ton materiel.

      • Je ne comprends pas du tout l'argument du "c'est plus monolithique que linux", je ne vois pas du tout sur quoi c'est fondé

      • Il me semble que chiffrement + TRIM, ça a changé récement aussi

      D'un point de vue général, les commentaires sont relativement fondés mais ça sent l'argumentaire un peu biaisé qui cherche à démontrer que "freebsd c'est nul et linux c'est mieux", ça n'insiste que sur les points négatifs dont parfois l'importance peut s'avérer relative quand tu utilises l'OS.

      • [^] # Re: Je voulais tester et je suis tomber sur ce brûlot

        Posté par . Évalué à 1.

        FreeBSD prétend être l’un des OS les plus sûr par sa conception et utilisation.

        Il confond pas avec OpenBSD ??.
        Pour moi FreeBSD, c'est plutot les perfs (a comparé avec NetBSD pour la portabilité et OpenBSD pour la sécu.)
        C'est comme pour les Linux, c'est juste une question d'utilisation.

        • [^] # Re: Je voulais tester et je suis tomber sur ce brûlot

          Posté par (page perso) . Évalué à 3.

          Je sais pas si on peut beaucoup parler de performances avec FreeBSD. En toute honnêteté, FreeBSD est légèrement moins réactif qu'un Linux pour ma part. Les compilations sont un poil plus longues et la réaction des environnement graphiques aussi.

          l'azerty est ce que subversion est aux SCMs

    • [^] # Re: Je voulais tester et je suis tomber sur ce brûlot

      Posté par . Évalué à 5.

      En gros le mec a eu une mauvaise expérience en desktop parce que son matériel n'était pas correctement supporté. Et il en profite pour chier sur tout le projet parce que quelqu'un (je me demande bien qui) lui a fait croire que c'était l'OS idéal, prêt à l'emploi du genre OS X.

    • [^] # Re: Je voulais tester et je suis tomber sur ce brûlot

      Posté par (page perso) . Évalué à 2.

      Il en a le problème le gars. Wifi, USB, carte graphique, carte son. En fait rien ne fonctionne sur son PC :-). Soit c'est un gros PEBKAC soit il a vraiment un matos désuet.

      Pour ma part, seul l'ACPI (mise en veille) me pose problème. Tout le reste fonctionne :-).

      l'azerty est ce que subversion est aux SCMs

Suivre le flux des commentaires

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