FreeBSD 8.2 et 7.4 : deux sorties pour le prix d'une

Posté par (page perso) . Modéré par patrick_g. Licence CC by-sa
64
27
fév.
2011
FreeBSD

Cette semaine, deux nouvelles versions du système d'exploitation au démon rouge sont sorties : 7.4 et 8.2. La version 7.4 sera la dernière version de la branche 7, et à ce titre, a droit à un support allongé, dont la fin est prévue dans 2 ans. Les utilisateurs des versions 7.x sont encouragés à mettre à jour leurs systèmes. En revanche, la version 8.2 contient des changements plus intrusifs, mais bénéficiera d'un support plus court.

La version 7.4 est essentiellement une série de corrections par rapport à la version 7.3 : quelques correctifs de sécurité, beaucoup de mises à jour et de nouvelles fonctionnalités dans les pilotes de cartes réseau, et des améliorations un peu partout ; je vous laisse lire les notes de mises à jour.

Dans la version 8.2, une nouvelle version de ZFS a été importée depuis Solaris, avec un nouveau format sur disque, ainsi que des promesses de performances accrues. Un message sur les forums indique d'énormes gains pour ZFS entre 8.1 et 8.2 ; à prendre avec un grain de sel tout de même. Le support de Xen (en tant que domU) a été amélioré, pour les architectures i386 et amd64. Dans le système de base, BIND et OpenSSL ont été mis à jour. Un nouveau pilote, aesni(4), a été ajouté pour tirer parti des possibilités d'accélération matérielle du chiffrement AES, disponibles sur certains processeurs Intel.

Bien sûr, on retrouve toujours les forces de FreeBSD dans ces nouvelles versions :

  • un système d'exploitation cohérent, avec une base développée par une équipe qui a une vision d'ensemble, augmentée par les ports, qui sont indépendants ;
  • un vrai système Unix, solide, performant, et avec un très bon historique de sécurité ;
  • les jails, une solution de virtualisation légère, comparable à LXC qui fait le bonheur de certaines moules ;
  • ZFS, le système de fichiers du futur, mais qui est là aujourd'hui, contrairement au FS en beurre ;
  • Packet Filter, le pare-feu d'OpenBSD, mais sans devoir installer les backdoors du FBI ;
  • une documentation et des pages de manuel de grande qualité, avec notamment le magnifique manuel de FreeBSD ;
  • un environnement qui récompense la compétence technique, ce qui vous permet de vous distinguer du premier Kévin venu capable d'installer Fedorubuntu ;
  • etc..

J'ai mentionné plus haut le système de base : FreeBSD, comme les autres *BSD, est un système d'exploitation complet, qui abrite dans le même arbre SVN le noyau, les outils utilisateurs (le shell, l'équivalent de GNU coreutils, une version de nvi(1), etc.), les fichiers de configuration (tout ce qui va dans /etc), ainsi qu'un certain nombre de logiciels externes : BIND, OpenSSL, déjà cités, GNU GCC, sendmail, etc.. L'avantage, assez évident, est d'avoir l'ensemble des outils développés de façon cohérente, mis à jour ensembles.

Pour utiliser les milliers d'applications qui ne sont pas dans le système de base, on utilise les ports. Le port est le grand-père de l'extraordinaire pkgsrc de NetBSD. Un port est un ensemble de Makefile qui décrivent comment télécharger, configurer, compiler et installer chaque application et ses dépendances. Ainsi, pour l'utilisateur final, l'installation de son éditeur de texte préféré se fera avec cd /usr/ports/editors/emacs && make install. Les gens qui ne souhaitent pas compiler peuvent bien sûr utiliser les paquets binaires qui sont régulièrement construits pour vérifier l'« installabilité » de chaque port.

  • # frist prost

    Posté par . Évalué à 1.

    J'aime bien les petits clins d'oeil humoristiques (le fr en beurre, les backdoors du FBI...) mais je sens déjà venir ceux qui vont crier au troll !

    • [^] # Re: frist prost

      Posté par . Évalué à -8.

      Et il n'auront pas tort… Il est questions de savoir si les utilisateurs de de logiciels libres sont une communauté ou un ensemble de corporations.

      Entretenir guéguerre *BSD vs Linux, ou Kévin vs Power User, c'est tirer sur des ambulances. 90% des ordinateurs ont des OS proprio merdique, 5% de plus ont des OS propriétaire moins merdique mais tout aussi liberticide.

      Bref, oui : TROLL

      Please do not feed the trolls

      • [^] # Re: frist prost

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

        Bienvenu sur trollfr !

        « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

    • [^] # Re: frist prost

      Posté par . Évalué à 2.

      De toute façon, la preuve que Linux est mieux que FreeBSD, c'est qu'il n'y a pas de http://freebsdfr.org.

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

      • [^] # Re: frist prost

        Posté par . Évalué à 3.

        putain j'ai un DNS menteur dessus... :/

        Sedullus dux et princeps Lemovicum occiditur

  • # Merci le LTS

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

    C'est marrant, mais la seule annonce d'un réel intérêt "industriel" que je vois là est le passage de la 7.x en LTS.

    Le LTS est un des points critiques pour l'industrialisation d'un système d'exploitation en entreprise hors du cadre des geeks. C'est, avec l'appui de Canonical, une des raisons pour lesquelles de plus en plus d'hébergeurs infogestionnaires remplace Debian par Ubuntu. Espérons que cela permette également à FreeBSD de décoller chez les décideurs pressés.

    • [^] # Re: Merci le LTS

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

      Une version sur deux (a peu pres) a un support étendu sous FreeBSD. Voir http://www.freebsd.org/security/security.html#sup .

      De plus la compatibilité binaire est complète entre les versions de chaque branche (si tu passe de 7.3 a 7.4 tu n'as pas besoin de recompiler tes ports). Lorsque tu choisi une version majeure (aujourd'hui la 8 par exemple), tu es tranquille pour au moins 5 ou 6 ans.

      Enfin il existe des modules de compatibilité binaire pour chaque version non maintenue. Ainsi un binaire compilé sous FreeBSD 4 pourra fonctionner sous FreeBSD 8 (sous reserve d'installer la compat 4x).

    • [^] # Re: Merci le LTS

      Posté par . Évalué à 10.

      Toutes les Debian sont LTS par défaut vu le cycle de release, ça n'est même pas la peine de le préciser...

      • [^] # Re: Merci le LTS

        Posté par . Évalué à 6.

        On ne doit pas avoir la même notion de LTS : avec une nouvelle version tous les deux ans, plus un an de support, cela ne fait que trois ans au total, ce qui est vraiment faible...

        • [^] # Re: Merci le LTS

          Posté par . Évalué à 4.

          Lors de la minidebconf à Paris en Octobre dernier, je me souviens d'une conférence faite par un employé d'EDF qui disait avoir choisi Debian justement car le cycle de développement était suffisamment long et indiqué que les choix étaient limité pour le support long terme (Red Hat, Open Suse, Debian et Ubuntu).

          Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

          • [^] # Re: Merci le LTS

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

            Euh... Il y a encore moins de choix.

            • Open Suse??? Sûrement pas, le cycle est de moins de 2 ans. Complètement insuffisant. SLES (Suse Linux Entreprise Server) sans doute plus : entre 7 et 10 ans
            • J'ai du mal à voir Debian dans le lot "cycle de développement était suffisamment long", il est court malgré sa réputation surfaite, et surtout son support est ridiculement court pour un serveur, 3 ans max.

            Bref, oui on est très limité dès qu'on regarde la pérennité d'une solution : RHEL et SLES sont les seuls choix long terme (7-10 ans), pour les pauvres il y a Ubuntu Server (5 ans, moins cher mais moins long et surtout moins de logiciels "pro" certifié), et pour les radins CentOS. En dehors de ça, peu de salut (Debian sur un serveur d'entreprise, ça me fait quand même bizarre, il faut vachement suivre le cycle de release, ça marche pour des petites entreprises avec un admin geek passionné mais pour des grosses entreprises?)

            • [^] # Re: Merci le LTS

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

              Debian sur un serveur d'entreprise, ça me fait quand même bizarre

              Ben faut lire les slides de Josselin Mouette. Il explique pourquoi à EDF ils ont choisi Debian.
              Le lien : http://malsain.org/static/debian/201010-Paris/ScientificComputing.pdf

              C'est déployé sur des stations de travail et sur les clusters de calcul. Sur la slide intitulé "Why we keep Debian" il y a "Appropriate release cycle: 2 years is fine, 3 years would be better".

            • [^] # Re: Merci le LTS

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

              Debian sur un serveur d'entreprise, ça me fait quand même bizarre

              1 - lire les notes de révision
              2 - apt-get update; apt-get upgrade
              En gros c'est la même chose qu'avec le chapeau rouge.
              Il y a de temps en temps UN truc qu'il faut changer. Whaaaa, terrible.

              • [^] # Re: Merci le LTS

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

                En gros c'est la même chose qu'avec le chapeau rouge.

                Oui, mais moins souvent. Et on évite de toucher à des machines qui marchent, le plus possible.

                Il y a de temps en temps UN truc qu'il faut changer. Whaaaa, terrible.

                Belle démonstration d’incompétence. Viré. Faut pas déconner, jouer avec des machines de cette manières, ça mérite la porte direct, on ne joue pas comme ça avec des machines utiles, seulement avec une machine chez soit pour faire geek qui se la pête.

                Désolé, mais upgrader la machine n'est pas la seule chose à faire : faire sur une machine de test avec le même environnement, tester la compatibilité des logiciels non dans les dépôts, tester TOUS les services utilisé dans TOUS les cas de figure, prévoir l'indisponibilité lors de la migration, vérifier après la migration. Pareil pour le desktop que pour le serveur. Et la personne qui fait tout ça ainsi que la disponibilité de la machine de test n'est pas gratuite.

                Dans la vraie vie, changer un truc qui marche parce que l'OS est en fin de support, ça a un coût, et pas faible.

                • [^] # Re: Merci le LTS

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

                  Belle démonstration d’incompétence.

                  Toujours en finesse. C'est être incompétent que d'avoir des choses à changer au bout de 3 ans ? Si c'est le cas pour toi, vas faire un tour dans la vraie vie, ça t'évitera de raconter n'importe quoi. A moins que ton serveur, tu n'y touches jamais pendant 7 ans parce qu'il ne délivre qu'un service basique. Par exemple serveur de fichiers. Dans ce cas, pas besoin non plus de Red Hat. Mais dans tous les autres cas, tu vas être obligé d'ajouter tel service, de modifier tel paramétrage. Alors une mise à jour de temps en temps, franchement, c'est une paire d'heure en comptant le temps de sauvegarde intégrale.

                  • [^] # Re: Merci le LTS

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

                    . C'est être incompétent que d'avoir des choses à changer au bout de 3 ans ?

                    C'est de l’incompétence de faire, je cite :

                    1 - lire les notes de révision
                    2 - apt-get update; apt-get upgrade
                    

                    Oui, je continue de l'affirmer, une personne qui fait ça est incompétente et ne peut pas être admin, il met en danger l'entreprise. Y compris "serveur de fichier" (si le serveur existe, c'est qu'il est utile. Donc on teste avant de foutre la merde, on ne sait jamais ce qui peut arriver).

                    c'est une paire d'heure en comptant le temps de sauvegarde intégrale.

                    C'est toujours la paire d'heure à payer + les autres heures si ça ne marche pas bien comme il faut, et encore une fois il faut trouver une autre machine aussi pour tester et il faut prévoir la coupure (étudier à quel moment on peut faire l'upgrade sans impacter les utilisateurs par exemple). Un upgrade, ce n'est pas 2 lignes de check-list, Ca monte vite.

                    D'ailleurs, au passage je note que tu parles de "sauvegarde intégrale", tient ça commence déjà a rajouter des lignes dans la liste des choses à faire...

                    • [^] # Re: Merci le LTS

                      Posté par . Évalué à 8.

                      Faudrait voir à se détendre entre 7~10 ans et et quelques minutes il y a un univers. Si on en ai à vouloir multiplier les 9 du taux de disponibilité, il y a plusieurs choses à prendre en compte :

                      • On a pas un serveur à maintenir mais un cluster, une grille bref un ensemble de miroir. On peu faire une mise à jour sans indisponibilité en effectuant la mise à jour serveur par serveur et en configurant le DNS ou le serveur de répartition de charge.
                      • monter 3 ou 4 machines de teste (pour pouvoir tester les interactions entre eux) ne doit coûter que le prix du matériel, parce que sinon ça veut dire que ta solution de sauvegarde restauration n'est pas à la hauteur de tes ambitions de disponibilité. Pour le matériel pour limiter le coût tu peut utiliser du matériel qui est gardé pour pouvoir monter un serveur en cas de panne.

                      Alors oui ça prends du temps, ça s'appelle du travail. Il y a pleins de métiers où il y a du travail.

                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                    • [^] # Re: Merci le LTS

                      Posté par . Évalué à 4.

                      C'est de l’incompétence de faire, je cite :

                      1 - lire les notes de révision
                      2 - apt-get update; apt-get upgrade

                      Oui, je continue de l'affirmer, une personne qui fait ça est incompétente et ne peut pas être admin, il met en danger l'entreprise. Y compris "serveur de fichier" (si le serveur existe, c'est qu'il est utile. Donc on teste avant de foutre la merde, on ne sait jamais ce qui peut arriver).

                      Il n'a jamais dit qu'il faisait ça sur de la prod non plus. Il est évident que ça doit d'abord être validé sur un environnement dédié, puis être appliqué en prod.

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

                • [^] # Re: Merci le LTS

                  Posté par . Évalué à 8.

                  faire sur une machine de test avec le même environnement

                  jail sait faire.

                  tester la compatibilité des logiciels non dans les dépôts

                  pkg_add sait faire

                  tester TOUS les services utilisé dans TOUS les cas de figure

                  /etc/ sait faire

                  prévoir l'indisponibilité lors de la migration

                  FreeBSD-UPDATE sait faire

                  vérifier après la migration

                  Linuxfr .

                  Sedullus dux et princeps Lemovicum occiditur

            • [^] # Re: Merci le LTS

              Posté par . Évalué à 5.

              il faut vachement suivre le cycle de release, ça marche pour des petites entreprises avec un admin geek passionné mais pour des grosses entreprises?

              Tu veux dire que les admins employés par les grosses entreprises ne devraient surtout pas faire ce qu'ils sont payés pour faire (à savoir de l'administration système) ?

              Ensuite, s'il faut être un "geek passionné" pour "suivre le cycle de release" d'un truc qui est mis à jour tous les deux ans...

        • [^] # Re: Merci le LTS

          Posté par . Évalué à 4.

          Une durée longue de release est à double tranchant. D'un côté ça limite le nombre d'upgrade mais d'un autre côté ça les rends plus difficiles, avec d'avantages de changements d'un seul coup. Inversement des releases fréquentes limitent le nombre de changements pour chacune et les rends plus simples, parfois insignifiantes. Je me souviens encore de la migration où on est passé d'exim3 à 4 apache 1 à 2 et iso8859 à utf8 ! une horreur ! En revanche de la lenny à la squeeze pour moi ça a été insignifiant.

    • [^] # Re: Merci le LTS

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

      C'est marrant, mais la seule annonce d'un réel intérêt "industriel" que je vois là est le passage de la 7.x en LTS.

      Gni??? C'est où que tu vois un support à long terme? Perso, je n'en vois aucun dans la dépêche. Il y a un truc "2 ans", c'est sympa mais ça ne fait pas une "LTS" si L veut dire long. Ubuntu est déjà un peu léger sur le desktop avec 3 ans, heureusement il y a la version "Serveur" de 5 ans, c'est la limite. Redhat, c'est plus long, on attaque 7 (voir 10) ans. Microsoft aussi, leur durée de support est vraiment est de 7 à 12 ans, très très loin d'un "2 ans" Alors dire que 2 ans c'est du LTS comme tu sembles le sous-entendre, c'est assez rigolo : c'est à peine le temps de tester, valider, prévoir le déploiement, faire valider le budget (non, déployer, ce n'est pas gratuit), faire des recettes et passer en production sur un site puis un déploiement plus grand. Surtout pour un serveur (les BSD sur du desktop, euh...)

    • [^] # Re: Merci le LTS

      Posté par . Évalué à 3.

      Si je peux me permettre une remarque, qui je l'espère ne sera pas mal prise : il y a il me semble une erreur d'appréciation sur le modèle FreeBSD. Modèle économique et cible clients. Le Desktop FreeBSD restera un "truc de geek" (ou de professionnels) et ne sortira certainement pas de là (en tout cas je ne vois ni besoin ni volonté). Et FreeBSD n'a pas vocation à vouloir "vendre" du FreeBSD à "tire larigot".

      Par contre FreeBSD est soutenue par un sacré gros paquet d'entreprises, et même si on peux considérer que certaines n'échangent pas assez (etc...), il n'en reste pas moins que pour le business, une entreprise s'adresse à une autre entreprise. Le fournisseur de services (matériels & appliances, supports, développement, purs services) n'a pas de lien économique directe avec FreeBSD.

      Et puis c'est quant même historiquement un coeur de cible "réseaux", comme NetBSD. Cela non plus ne tends vers "un décollage vers les décideurs pressés".

      Voili voilà. Un exemple ? le plus "célèbre" : http://www.ixsystems.com Mais bien d'autres existent. Ainsi que des ISV d'ailleurs.

      /ma vie/ me faut vraiment bouger mon cul pour installer cette version ...

    • [^] # Re: Merci le LTS

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

      C'est marrant, mais la seule annonce d'un réel intérêt "industriel" que je vois là est le passage de la 7.x en LTS.
      

      La dernière version d'une branche est toujours supportée deux ans. (dernière dans le sens où il n'y aura pas d'autre release dans la branche 7.x)

      les pixels au peuple !

  • # Une autre nouvelle importante

    Posté par . Évalué à 2.

    FreeBSD KMS GEM et DRI_pour_Intel_Graphics
    Dri et dri2 sont déjà exploités pour AMD . :)
    Sinon, pour donner mon grain de sel au niveau du support ' longtemps ', la nouveauté, c'est certainement l'annonce à priori d'un support long, puisqu'avant la 7.1 , il me semble, il y avait juste un tableau donnant les versions encore supportées au niveau des update de sécurité. :)
    Mais j'ai certainement raté quelque chose.
    Sinon, au niveau de la " gueguerre " , je trouve rigolo que quelqu'un se satisfasse de s'affilier à Debian comme d'autres s'affilient au PSG.
    Pour le graphique, j'attends avec impatience les solutions _sans_Xorg que ce soit sous FreeBSD ou sous Linux.
    Ah oui, autre chose: FreeBSD est un très bon OS desktop. de tous les BSD, c'est sans doute celui qui offre le plus de possibilités en usage desktop. ( bien plus que Debian en fait puisqu'on peut faire fonctionner une Debian dans FreeBSD en utilisant le linuxulator , y compris avec les drivers NVidia pour Linux ).
    Pour les fanas d'Ubuntu, passez votre chemin, les questions d'ergonomie qui cachent le fonctionnement ne sont pas les questions auxquelles FreeBSD répond.

    Sedullus dux et princeps Lemovicum occiditur

    • [^] # Re: Une autre nouvelle importante

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

      bien plus que Debian en fait puisqu'on peut faire fonctionner une Debian dans FreeBSD en utilisant le linuxulator , y compris avec les drivers NVidia pour Linux

      Ce n'est pas vrai, puisqu'on peut faire tourner un noyau FreeBSD dans Debian. Maintenant, est-ce qu'il est possible de faire tourner linuxulator sur Debian/kFreeBSD pour pour faire tourner une Debian/Linux je ne sais pas.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Une autre nouvelle importante

        Posté par . Évalué à 2.

        Oui mais tu ne peux pas faire fonctionner tout le système d'exploitation FreeBSD dans Debian, alors que l'inverse ( faire fonctionner toute une distribution Debian dans FreeBSD ) est possible. lien

        En fait, la question est plutôt : Est-il possible de faire fonctionner le linuxulator dans une Debian Gnu-kFreeBSD dans FreeBSD lui même en virtualisation dans une Debian gnu-Linux? :)

        Sedullus dux et princeps Lemovicum occiditur

        • [^] # Re: Une autre nouvelle importante

          Posté par . Évalué à 3.

          Oui, avec KVM.

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

    • [^] # Re: Une autre nouvelle importante

      Posté par . Évalué à 2.

      Ha ben c'est sûr que lancer une nouvelle instance shell ne charge pas un module noyau ipv6 :-)

    • [^] # Re: Une autre nouvelle importante

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

      Comment peut-on opposer BSD à Debian ? http://www.debian.org/ports/kfreebsd-gnu/

      Thrystan.

      • [^] # Re: Une autre nouvelle importante

        Posté par . Évalué à 4.

        Meuh, le taf de portage de la Glibc sur le noyau freebsd a démarré en 2004 ou 2005 il me semble. On est loin de la nouveauté. Dans le troll, on pourrait dire que la GNUification de freebsd avance bien moins vite que la BSDification de linux (llvm, apache, android, etc etc...)

        • [^] # Re: Une autre nouvelle importante

          Posté par . Évalué à 4.

          Dans le troll, on pourrait dire que la GNUification de freebsd avance bien moins vite que la BSDification de linux

          Donc on peut dire que le monde Linux est plus ouvert puisqu'il accueille plus vite les technos BSD…

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

          • [^] # Re: Une autre nouvelle importante

            Posté par . Évalué à 4.

            Ou alors, l’univers Linux est plus en retard, et adopte avidement les technos BSD qui lui manquent.

            Depending on the time of day, the French go either way.

            • [^] # Re: Une autre nouvelle importante

              Posté par . Évalué à 0.

              Oui, Linux est tellement en retard qu'XFCE n'est pleinement fonctionnel que sur ce noyau…

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

  • # Gestionnaire de paquets

    Posté par . Évalué à 2.

    Je n'ai jamais utilisé un BSD bien que je me dise à chaque fois qu'il faut que j’essaie. Le système de ports doit pas mal ressembler au Portage de Gentoo vu que l'idée vient de ces derniers. Et que comme Gentoo, il existe des paquets binaires pour quand on à la flemme de compiler.

    Mais pourquoi ne pas fournir une gestion des paquets plus avancée que cd /chemin/paquet && make install ? Est-ce l'esprit BSD ? Il y a pkgsrc qui apporte un premier niveau d'abstraction je dirai, pourquoi n'est-il pas plus utilisé ? Et enfin, pourquoi pas un outils plus haut niveau comme emerge ?

    En fait, je pense que les développeurs sont capables de construire des outils pour la gestion des paquets sources de façon évoluée ou même fournir des paquets binaires directement gérés par un gestionnaire de paquets comme la plupart des distributions Linux. Mais j'aimerais comprendre pourquoi ce n'est pas le cas ?

    • [^] # Re: Gestionnaire de paquets

      Posté par . Évalué à 8.

      Non, c'est parce que, comme tu le dis, tu n'as jamais essayé FreeBSD.

      Essai portmaster pour gérer les ports.

    • [^] # Re: Gestionnaire de paquets

      Posté par (page perso) . Évalué à 3. Dernière modification le 28/02/11 à 08:18.

      Le système de ports doit pas mal ressembler au Portage de Gentoo vu que l'idée vient de ces derniers.

      Euh, ta phrase est à l'envers. Il aurait fallu écrire un truc du genre :
      « Le système de ports doit pas mal ressembler au Portage de Gentoo vu que ce dernier est basé dessus. »
      C'est pas vraiment mieux, mais comme « ce(s) dernier(s) » est lexicalement « portage, » ça évite les contre-sens (puisque portage est basé sur les ports, et non l'inverse).

      • [^] # Re: Gestionnaire de paquets

        Posté par . Évalué à 2.

        J'avais un peu cogité sur comment bien écrire cette phrase mais celle-ci est restée avec cette tournure mal foutue...

    • [^] # Re: Gestionnaire de paquets

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

      cd /chemin/paquet && make install [...] Il y a pkgsrc qui apporte un premier niveau d'abstraction.

      Heuh. J'ai toujours utilisé make avec pkgsrc (jamais pkg_add).

      pourquoi n'est-il pas plus utilisé ?

      Oui, pourquoi ?

      pourquoi pas un outils plus haut niveau comme emerge ? En fait, je pense que les développeurs sont capables de construire des outils pour la gestion des paquets sources de façon évoluée ou même fournir des paquets binaires directement gérés par un gestionnaire de paquets comme la plupart des distributions Linux. Mais j'aimerais comprendre pourquoi ce n'est pas le cas ?

      C'est le cas : un outil plus haut niveau comme pkgin ! Et pkgin est quand même très utilisé vu qu'il est le gestionnaire de paquet par défaut de dragonflyBSD, est fort utilisé sous netBSD (normal, c'est pour lui qu'il a été développé à l'origine puisque pkgsrc est avant tout netBSD). En plus, il marche bien sous linux (au moins debian) et sous Mac OS X.

      • [^] # Re: Gestionnaire de paquets

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

        pkgin a l'air un outil intéressant, mais dans les plateformes supportées FreeBSD n'y est pas.

        C'est étonnant pcq même Debian, MINIX, MacOS X et Solaris sont supportés !

        « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

        • [^] # Re: Gestionnaire de paquets

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

          Ce qui est supporté par pkgin c'est pkgsrc. Sur FreeBSD il n'y a pas pkgsrc, mais pkgin build très bien et fonctionne très bien quand même sur FreeBSD si tu utilises pkgsrc en lieu et place des ports.

          J'ai fait le support de pkgin pour qu'il supporte les packages FreeBSD générés depuis les ports, ça marchait mais ça n'ira pas plus loin car c'est trop bancale (selon moi), les ports et pkgsrc sont assez proches en terme de packages générés, mais les petites différences rendent le résultat "trop fragile" pour que ça soit viable imho, il est donc plus intéressant de laisser pkgin se concentrer sur son vrai boulot, les packages binaire issus de pkgsrc, ce qu'il fait très bien.

    • [^] # Re: Gestionnaire de paquets

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

      Mais pourquoi ne pas fournir une gestion des paquets plus avancée que cd /chemin/paquet && make install ?

      En fait ça dépend de ce que tu veux faire. pkg_add, le gestionnaire de paquet binaires et un peu léger pour être un apt like.

      Je dirais que pour une machine configuré aux petits oignons, les ports sont excellent et te permettent dans la plus part des cas d’exprimer ce que tu souhaite faire. Pour un parc la solution la plus propre est de générer des packages à partir des ports (make package-recursive) puis de les déployer avec pkg_add. Cela te permet de gérer tes mises à jour finement sans trop se prendre la tête. Par contre pour quelqu'un qui veut quelque chose plug and play a la apt, il y a clairement un manque.

      C'est comme beaucoup de choses sous FreeBSD (et dans le libre), tant que personne n'y trouvera un intérêt suffisant ce ne sera pas fait (pour les packages, je crois que bapt http://blog.etoilebsd.net/ est plus ou moins sur le coup). Un autre exemple est le vénérable installateur (sysinstall) visiblement, il va enfin être réécrit. Tout le monde dit qu'il manque ci ou ça, ceci dit si je prends mon exemple personnel, je ne l'utilise que très peu et pour faire pas grand chose. Je pense que c'est le cas de beaucoup. La bonne façon d'aborder les problèmes sous FreeBSD avant de dire que saynul y pas aptitude, c'est d'essayer de comprendre comment font les gens. Si l'outil n'est pas là, c'est souvent qu'il existe une autre façon de faire et en général elle est maline et pratique.

      • [^] # Re: Gestionnaire de paquets

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

        C'est comme beaucoup de choses sous FreeBSD (et dans le libre), tant que personne n'y trouvera un intérêt suffisant ce ne sera pas fait (pour les packages, je crois que bapt http://blog.etoilebsd.net/ est plus ou moins sur le coup)

        Balance !!! c'est secret comme projet et pas encore fini du tout et rien d'officiel du tout pour le moment :)

        • [^] # Re: Gestionnaire de paquets

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

          Balance !!! c'est secret comme projet et pas encore fini du tout et rien d'officiel du tout pour le moment :)

          Remarque que j'aurais pu mettre un lien direct vers le repo :)

  • # Netbook

    Posté par . Évalué à 7.

    FreeBSD, pour beaucoup (dont moi), c'est un peu le GNU/Linux des utilisateurs Windows : on se dis que ça à l'aire cool, qu'on devrait essayer, mais on y a jamais trop touché et on se trouve toujours une excuse pour reporter notre installation.

    Bref ce que je voulais demander c'est est ce que l'ensemble des paquets sont accessible en binaire ? Si je l'installe c'est sur un netbook et je n'ai pas trop envie de passer mon temps à compiler mes logiciels (pas un problème de compétence mais de temps passé pour le faire).

    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Netbook

      Posté par . Évalué à 8.

      est ce que l'ensemble des paquets sont accessible en binaire

      non, et souvent les paquets binaires sont obsolètes par rapport à la version des ports. Et un vrai gestionnaire de paquets, ça ne ferait pas de mal à un système qui se veut un "système d'exploitation cohérent".

      Pour le reste, c'est plus que du troll, ça s'apparente presque à du FUD : "une base développée par une équipe qui a une vision d'ensemble", "FreeBSD, comme les autres *BSD, est un système d'exploitation complet,/.../L'avantage, assez évident, est d'avoir l'ensemble des outils développés de façon cohérente, mis à jour ensembles.", genre on n'a pas ça dans Linux.

      Ça me rappelle un peu quand Ubuntu se présentait comme un OS fait par un seul homme visionnaire. "Des outils développés de façon cohérente", ce qu'on entend toujours lorsqu'on parle des BSD, c'est un peu du pipeau, GCC, Sendmail, etc, ce n'est pas développé par l'équipe de FreeBSD, openssh non plus (OpenBSD), et quand on rajoute le serveur graphique, ben c'est xorg en surcouche d'un unix, bref, comme Linux. Patcher des outils extérieurs, les intégrer dans l'OS, les sortir dans des mises à jour régulières, ben on a ça aussi dans Debian, dans OpenSuse, dans Fedora, dans Ubuntu aussi non ? Les BSDistes ils font quoi de plus réellement ?

      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: Netbook

        Posté par . Évalué à 3.

        Dans ce que j'ai lu/entendu ce qui m’intéresse c'est la différenciation entre le base system et le reste du système, même si la limite est encore floue pour moi je trouve l'idée intéressante et un peu plus pratique que pour ma Debian où je mélange testing et sid la plupart du temps. zfs est aussi intéressant en attendant Btrfs.

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: Netbook

          Posté par . Évalué à 1.

          Je pense que si on le veut vraiment il doit être possible d'arriver à peu près au même résultat en utilisant APT Pinning sur Debian. aptitude safe-upgrade devrait ensuite réussir à trouver la bonne combinaison.

          Par exemple, on repère les paquets du système de base et on les force à suivre le dépôt stable, puis on laisse le dépôt testing/sid mettre à jour le reste. A voir par la suite si on ne se retrouve pas avec un paquet qui force la mise à jour d'un paquet système en testing/sid.

          • [^] # Re: Netbook

            Posté par . Évalué à 2.

            C'est ce que je fait, mais il y a des problèmes comme la libc qui bloque un grand nombre de paquets. De ce que j'imagine, FreeBSD gère ça grâce à la compilation des paquets, mais sur les petites config c'est pas le top.

            Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: Netbook

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

        est ce que l'ensemble des paquets sont accessible en binaire

        non, et souvent les paquets binaires sont obsolètes par rapport à la version des ports. Et un vrai gestionnaire de paquets, ça ne ferait pas de mal à un système qui se veut un "système d'exploitation cohérent".

        C'est sûr que les paquets binaires fournis sur les DVD lors de la sortie d'une nouvelle version deviennent vite obsolètes, mais la ferme de compilation produit des binaires pour la quasi totalité des 22.000 ports en ~2 jours sur amd64, et 3 ou 4 jours pour i386 : ça me semble tout de même assez rapide ! Quant aux gestionnaires de paquets, on a le choix entre portupgrade (classique, un peu lent) et portmaster (plus récent, surtout pour la gestion des paquets binaires, mais qui se défend bien).

        • [^] # Re: Netbook

          Posté par . Évalué à 3.

          pour les binaires, c'était peut-être il y a longtemps ou bien j'avais fait une boulette, faudra que je teste de nouveau.
          Et je testerai portmaster aussi, merci.

          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: Netbook

        Posté par . Évalué à 2.

        en 2 mots, hein :)

        non, et souvent les paquets binaires sont obsolètes par rapport à la version des ports. Et un vrai gestionnaire de paquets, ça ne ferait pas de mal à un système qui se veut un "système d'exploitation cohérent".

        Je ne crois pas que les utilisateurs de FreeBSD se plaignent de l'absence ou de l'obsolescence de leur App Store . Pas vu beaucoup de questions sans réponses sur le forum de FreeBSD, personnellement.

        Sedullus dux et princeps Lemovicum occiditur

    • [^] # Re: Netbook

      Posté par . Évalué à 3.

      Un des intérêts est justement d'apprendre à manier les options pour la compilation. (un peu comme http://wiki.debian.org/Hardening mais en plus simple et plus rapide. Tout comme Gentoo, je ne vois pas l'intérêt (à part se la raconter (...)) d'utiliser une gentoo si c'est pour installer un stage 5 et des binaires tout prêts. LE truc c'est justement d'avoir une solution intermédiaire facilitant la gestion de la compilation des sources.

      Bref, les ports (ou les overlays), faut les faire mais pas les utiliser ;-) oula ça va taper je sens :-)

      En plus, en général (et je suppose que c'est ton cas également) on sait ce qu'on veux et se dont on a besoin. On l'installe, et basta. Pour faire quelques tests de quelques softs (certainement bien moins souvent que la moyenne des gens utilisant windows), la compilation convient très bien. Non ?

      Enfin, ça me semble pas être ni le même but ni la même manière d'utiliser son système.

      • [^] # Re: Netbook

        Posté par . Évalué à 2.

        Mon problème c'est pas forcément à l'installation, mais à la mise à jour. Il peut s'écouler plusieurs mois sans que je fasse de mise à jour, j'ai pas envi de laisser ma machine compiler 3 jours, juste pour une mise à jour

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: Netbook

          Posté par (page perso) . Évalué à 4. Dernière modification le 28/02/11 à 08:21.

          Tu fais un jail à côté qui sert à compiler tes ports chaque nuit.
          Tu checkes le UPDATING régulièrement pour corriger éventuellement quelques trucs au cas où (car des updates peuvent avoir des répercussions assez conséquentes), et le jour où tu veux mettre à jour, tu regardes tes logs de compilation, et si tout est bien, alors tu installes les binaires qui se sont compilés l'autre jour.

          Et si t'as envie de zéro compilation, ben, tu utilises autre chose.

          J'ai FreeBSD en desktop depuis 7 ans, mais mon netbook actuel tourne sous Debian GNU/Linux.
          L'entretien n'est clairement pas le même, mais c'est pas la mort non plus (et j'ai de moins en moins de temps à consacrer à la gestion de mon OS, c'est pour ça que je le configure comme indiqué ci-dessus pour que ça simplifie les upgrades tardives.)

          • [^] # Re: Netbook

            Posté par . Évalué à 1.

            Et si t'as envie de zéro compilation, ben, tu utilises autre chose.

            Ok, ça réponds à ma question. :)

            Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: Netbook

        Posté par . Évalué à 2.

        tiens la dernière fois que j'ai voulu me remettre à gentoo, je commence et me dis "bon on va la refaire à la warrior, comme il y a 4 ans, en stage 1"
        bon ben loupé, on peut plus la faire en stage 1, c'est forcément stage 3...

        Bon que cela ne tienne. Je commence a faire le truc tranquillement, puis a compiler deux trois paquets.

        Puis aller hop, de tête je veux installer open ldap et kerberos, avec ipv6. Et paf dépendance cyclique et veux pas se compiler. (X demande ldap pour etre compilé avec ldap. mais ldap demande que x soit présent pour être compilé).

        Bon j'ai regardé quelque peu comment résoudre ça, puis ça m'a quand même souler, et j'ai supprimé mon chroot sur lequel je testait gentoo.

        • [^] # Re: Netbook

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

          ldap demande que x soit présent pour être compilé

          Je n'ai jamais utilisé Gentoo, ni compilé X ou OpenLDAP. Mais là, comme ça, je suis assez surpris de savoir qu'il faut que X soit présent pour qu'il soit possible de compiler LDAP... Qu'apporte X de nécessaire à la compilation ?

          • [^] # Re: Netbook

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

            Mais là, comme ça, je suis assez surpris de savoir qu'il faut que X soit présent pour qu'il soit possible de compiler LDAP...

            C'est parce qu'il l'a demandé pour pouvoir utiliser X avec LDAP. C'est ce qu'on appelle les USE FLAGS chez Gentoo

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Netbook

            Posté par . Évalué à 5.

            ah zut j'avais oublié que x était aussi un logiciel.

            Il fallait le lire comme une variable muette (donc tu peux remplacer x par y. Merde loupé c'est aussi un serveur d'affichage. Bon par t ça devrais passer. (par contre par r ça marche toujours pas ;))

    • [^] # Re: Netbook

      Posté par . Évalué à 5.

      j'utilise pas les binaires ( honte à moi :) )
      mais bon

      To use packages instead of ports for installation, provide -P flag. With this option portupgrade searches the local directories listed in PKG_PATH, or fetches packages from remote site if it is not found locally. If packages can not be found locally or fetched remotely, portupgrade will use ports. To avoid using ports, specify -PP.

      # portupgrade -PP gnome2  
      

      C'est là
      D'ailleurs la plupart des questions trouvent leurs réponses dans la bible le handbook.

      Sedullus dux et princeps Lemovicum occiditur

Suivre le flux des commentaires

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