FreeBSD 10.3

Posté par Loïc Blot (site web personnel) le 04 avril 2016 à 13:44. Édité par Nils Ratusznik, Bapt, Benoît Sibaud, palm123, tuiu pol et frederic. Modéré par Nils Ratusznik. Licence CC By‑SA.

Étiquettes :

avr.

2016

Après un cycle de bêta démarré le 5 février 2016, suivi d'un cycle de RC à partir du 5 mars 2016, FreeBSD 10.3 est disponible depuis le 29 mars. Il s'agit de la troisième mise à jour mineure de FreeBSD 10-STABLE.

Cette version n'apporte pas de changement majeur, mais corrige quelques problèmes de sécurité dans les logiciels inclus avec la distribution. Une sélection des nouveautés se trouve en deuxième partie de dépêche.

Améliorations

l'émulation de terminal a été ajoutée au chargeur de démarrage EFI ;
la variable sysctl kern.vt.enable_bell permet de changer l'état de la sonnerie du terminal vt ;
le script rc.d/netwait a été mis à jour afin d'attendre les interfaces réseau attachées plus tard dans le processus de démarrage, comme les interfaces réseau USB ;
l'installeur bsdinstall(8) sait désormais gérer le démarrage sur du ZFS pour les systèmes EFI ;
le code du cache l2arc de ZFS a été mis à jour afin de prendre en compte le paramètre ashift lors de la collecte des buffers à écrire sur le périphérique l2arc ;
l'outil ar dispose d'une nouvelle option -D permettant de prévenir la modification des temps de modification, uid, gid ou mode sur les fichiers, ce qui permet de créer des archives reproductibles ;
la commande cp dispose d'une nouvelle option -s créant un lien symbolique vers la source ;
mkimg sait gérer les systèmes de fichiers NTFS, que ce soit avec une table de partitions MBR ou GPT ;
un nouvel utilitaire nommé timeout(1) a été ajouté (compatible et inspiré de l'utilitaire du même nom fourni par les coreutils) ;
un nouveau mécanisme nommé "reroot" fait son apparition, et permet de redémarrer uniquement le userland (sans redémarrer la machine ni le kernel) ;
ifconfig peut désormais afficher via -v les données SFP/SFP+ ;
le chargeur de démarrage supporte désormais nativement les environnements de démarrage ZFS que ce soit en mode BIOS ou en UEFI (ce qui permet de choisir le snapshot ZFS sur lequel redémarrer le système) ;
l'utilitaire pkill permet désormais d'indiquer le nom d'une jail avec l'option -j, et non plus uniquement un ID de jail ;
la bibliothèque de résolution recharge le fichier /etc/resolv.conf si la date de modification du fichier a changé ;
la couche de compatibilité Linux peut désormais exécuter des binaires Linux 64 bits.

Correctifs

un kernel panic a été corrigé lors de l'utilisation rapide de ifconfig create/destroy sur des interfaces de type epair ;
un autre kernel panic a été corrigé sur les interfaces lagg ;
Packet Filter pouvait parfois journaliser des paquets non marqués comme tels, ce n'est plus le cas ;
ctladm ne retourne plus de valeur différente de zéro si tout s'est bien passé ;
un bug dans l'outil mkimg a été corrigé, permettant de faire fonctionner les images VHD avec qemu ;
netstat ne divise plus le nombre de paquets par 1024 mais par 1000 ;
l'appel système kqueue a été amélioré afin de pouvoir gérer des fichiers de plus de 2Gb.

Matériel

le pilote xen dispose désormais de la fonctionnalité blkif (segments d'entrées/sorties indirectes) ;
la partie haute disponibilité du pilote ctl, gérant notamment les cibles iSCSI ou les supports physiques SCSI a été réécrite ;
les anciens pilotes ata ont été supprimés en faveur de nouveaux pilotes ;
le pilote ctl sait maintenant gérer les CD-ROM ;
le pilote pms a été supprimé du noyau GENERIC ;
un nouvel outil nommé sesutil(8) fait son apparition, pour gérer les enclosures SCSI (ses(4)) permettant d'afficher la cartographie SES mais aussi passer des commandes (pour le moment juste la gestion de LED de localisation et/ou de fautes des disques).

Comment mettre à jour

Pour mettre à jour votre version de FreeBSD depuis les paquets binaires, effectuez la manipulation suivante:

freebsd-update -r 10.3-RELEASE upgrade
freebsd-update install
reboot
freebsd-update install
pkg-static upgrade

Quelques précautions malgré tout :

si vous utilisez les ports, remplacez la commande pkg upgrade par la commande portmaster -Raf ;
si vous utilisez poudriere, pensez à créer une nouvelle jail en FreeBSD 10.3, à reconstruire tous les ports et enfin à relier votre machine à ce nouveau dépôt.

Contributeurs

Cette nouvelle version a pu être peaufinée grâce au soutien de nombreux contributeurs mais également de quelques entités qu'il est important de citer, parmi lesquelles:

La fondation FreeBSD ;
ClusterHQ ;
Dell, Inc ;
Gandi.net ;
iXsystems ;
Limelight Networks ;
Intel Corporation ;
Multiplay ;
Netgate ;
ScaleEngine, Inc ;
Yandex LLC.

Aller plus loin

FreeBSD (516 clics)
Notes de version (173 clics)
Annonce de FreeBSD 10.3 sur la liste "FreeBSD-Announce" (145 clics)

# cp -s == ln -s

Posté par Anonyme le 04 avril 2016 à 15:41. Évalué à 1.

« la commande cp dispose d'une nouvelle option -s créant un lien symbolique vers la source »

Heu… c’est quoi l’objectif derrière cette nouvelle option ?
- [^] # Re: cp -s == ln -s
  
  Posté par Kerro le 04 avril 2016 à 16:10. Évalué à 3.
  
  La seule différence que je vois est que cp gère la récursivité.
  
  La page de manuelle n'est pas spécialement explicite, puisqu'elle indique juste que ça crée des liens symboliques. J'en conclu que c'est la seule spécificité : créer des liens symboliques, ce qui semble sain.
- [^] # Re: cp -s == ln -s
  
  Posté par David Marec (site web personnel) le 04 avril 2016 à 16:30. Évalué à 3.
  
  Sachant que cp -l faisait déjà le boulot de ln pour les liens physiques, il s'agit surtout, je pense, d'avoir son pendant pour les liens symboliques.
  - [^] # Re: cp -s == ln -s
    
    Posté par Anonyme le 04 avril 2016 à 21:39. Évalué à 4. Dernière modification le 04 avril 2016 à 21:39.
    
    Le cp GNU a déjà ces options. Souci de compat pitêtre.
    - [^] # Re: cp -s == ln -s
      
      Posté par David Marec (site web personnel) le 05 avril 2016 à 10:18. Évalué à 0.
      
      Le cp GNU a déjà ces options. Souci de compat pitêtre.
      
      Peut-être; ceci dit le port coreutils apporte déjà gcp, donc le cp GNU.
      - [^] # Re: cp -s == ln -s
        
        Posté par David Marec (site web personnel) le 05 avril 2016 à 11:39. Évalué à 5.
        
        D'ailleurs, c'est décrit dans le commit:
        
        Implement '-s' to copy as symlink, similar to the current -l link(2) handling.
        
        This is also implemented in at least GNU coreutils cp.
        
        Avec une petite amélioration au passage:
        
        While here also improve the '-l' handling to not open(2) the source file as
        it does not actually need the descriptor.
# Question naïve autour de la licence

Posté par Narann (site web personnel) le 05 avril 2016 à 15:38. Évalué à 1.

Hello!

Lors d'une discussion autour de la licence BSD de Redox (OS écrit en langage Rust) un argument m'a semble convaincant. Il disait que ce qui est dommage avec les licences permissive c'est qu'elles n'incitent en rien les gens qui l'utilisent (PS3/PS4 et autres) a contribuer en upstream. Ce qui explique pourquoi FreeBSD est un projet quasi vide cote driver, parce qu'aucun inde ne souhaite contribuer (car son travail peut être réutilisé permissivement) et qu'aucune boite n'est pousse a le faire (car rien ne l'y oblige).

Ducoup je me demandais ce qu'en pensais les gens de FreeBSD car les arguments (la page n'est plus dispo) de la page Redox sur le choix de licence ne m'ont pas vraiment convaincu (ou bien je ne comprends pas).

En gros, c'est quoi l’intérêt de FreeBSD pour le libre? :) C'est pas un troll, c'est une vraie question.
- [^] # Re: Question naïve autour de la licence
  
  Posté par David Marec (site web personnel) le 05 avril 2016 à 16:08. Évalué à -4.
  
  Ce qui explique pourquoi FreeBSD est un projet quasi vide cote driver
  
  Yep, nann ne ket.
  
  parce qu'aucun inde ne souhaite contribuer (car son travail peut être réutilisé permissivement)
  
  Oui, ça se voit tant que ça ?
  Et ils se permettent Une release mineure en attendant la version 11, prétendument majeure.
  On me dit aussi dans l'oreillette que OpenBSD 5.9 devrait débarquer aussi, surement pleine de vide elle aussi.
  Les fourbes, tout ça c'est un écran de fumée; en fait, il n'y a personne pour développer, donc rien à publier.
  
  et qu'aucune boite n'est pousse a le faire (car rien ne l'y oblige).
  
  Tout à fait, ils l'ont bien compris, chez NetFlix:
  https://openconnect.netflix.com/en/software/
  https://www.youtube.com/watch?v=KP_bKvXkoC4
  
  En gros, c'est quoi l’intérêt de FreeBSD pour le libre?
  
  Aucun, pas même un systemd; dormez en paix.
  - [^] # Re: Question naïve autour de la licence
    
    Posté par neriki (site web personnel) le 06 avril 2016 à 10:06. Évalué à 2.
    
    pas même un systemd
    
    Le voilà, l'intérêt de FreeBSD! \o/
    - [^] # Re: Question naïve autour de la licence
      
      Posté par ariasuni le 10 avril 2016 à 00:09. Évalué à 3.
      
      Tu dis ça parce que tu ne connais pas without-systemd.org!
      
      Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Question naïve autour de la licence
  
  Posté par David Demelier (site web personnel) le 05 avril 2016 à 17:18. Évalué à 8.
  
  Lors d'une discussion autour de la licence BSD de Redox (OS écrit en langage Rust) un argument m'a semble convaincant. Il disait que ce qui est dommage avec les licences permissive c'est qu'elles n'incitent en rien les gens qui l'utilisent (PS3/PS4 et autres) a contribuer en upstream. Ce qui explique pourquoi FreeBSD est un projet quasi vide cote driver, parce qu'aucun inde ne souhaite contribuer (car son travail peut être réutilisé permissivement) et qu'aucune boite n'est pousse a le faire (car rien ne l'y oblige).
  
  C'est une vision un poil extrémiste quand même.
  
  Nvidia a bien fait un driver non libre pour Linux et aussi pour FreeBSD, je vois pas en quoi cet argument de licence permissive va fait fuir les entreprises.
  
  De plus, rien ne t'empêche d'écrire un driver pour FreeBSD sous licence GPL. Personne ne t'interdira de faire cela.
  
  FreeBSD a déjà reçu des contributions extérieures. Si le projet évolue plus lentement c'est pour bien d'autres raisons. Déjà parce que le projet s'est largement focalisé sur les serveurs. C'est venu après Linux et le modèle de développement est largement plus stricte. De plus les *BSD ont fait moins de communication.
  
  Du coup je me demandais ce qu'en pensais les gens de FreeBSD car les arguments (la page n'est plus dispo) de la page Redox sur le choix de licence ne m'ont pas vraiment convaincu (ou bien je ne comprends pas).
  
  En gros, c'est quoi l’intérêt de FreeBSD pour le libre ? :) C'est pas un troll, c'est une vraie question.
  
  Si j'ai bien compris, pour toi c'est "use GPL or die" ? :)
  
  Chez FreeBSD (et autres BSD même) on aime la liberté. Utiliser la GPL et contraindre les gens pour moi c'est une vision de fanatiques qui détestent les entreprises et voient le mal partout.
  
  Je me souviens Theo de Raadt (OpenBSD) avoir dit quelque chose comme "Les gens font Linux parce qu'ils détestent Windows, nous faisons OpenBSD parce que nous aimons Unix".
  
  Personnellement je fais que du libre (license ISC) et si on contribue à mes projets tant mieux, sinon c'est pas grave.
  
  git is great because linus did it, mercurial is better because he didn't
  - [^] # Re: Question naïve autour de la licence
    
    Posté par Narann (site web personnel) le 05 avril 2016 à 18:12. Évalué à 7. Dernière modification le 05 avril 2016 à 18:14.
    
    Si j'ai bien compris, pour toi c'est "use GPL or die" ? :)
    
    Non, mais j'ai l'impression que les licences MIT/BSD sont principalement des licences soit de recherche (propagation) soit de business (conquete). Ducoup je me pose la question de la legitimite de voir des heures de travail prisent sans aucun retour (je ne parle pas d'argent mais d'investissement humain).
    
    Wine etait en licence MIT avant de subir l'abus d'une societe qui a forke et ferme le code, rendu payant le logiciel et fait pleins de correctifs (et le tout parfaitement legalement). Wine est finalement passe en GPL pour ces raisons (et aussi parce que beaucoup de contributeurs se rendaient compte qu'il travaillait presque directement pour l'autre entreprise qui cherry pickait tous les nouveaux fixes de Wine).
    
    Utiliser la GPL et contraindre les gens pour moi c'est une vision de fanatiques qui détestent les entreprises et voient le mal partout.
    
    En quoi la garantie de l'ouverture du code est une détestation des entreprises? Je bosse dans le milieu des VFX, les gros studios (Dreamworks/Pixar/etc.) font des libs en licences permissives pour permettre la propagation de leur standards (format de fichier Alembic, OpenEXR, OpenSubdiv, USD, etc.) en facilitant l’intégration dans les applications propriétaires (Maya, Nuke, Houdini, etc.). C'est une bonne chose pour l'industrie des VFX et pour mon travail au quotidien. Mais il y a un intérêt économique derrière: Les gros studios ne veulent pas avoir a intégrer leur lib dans tous les logiciels du marche (c'est pour ça que je parle de conquête). *BSD ne rentre pas dans ce schéma si?
    
    Les gens font Linux parce qu'ils détestent Windows, nous faisons OpenBSD parce que nous aimons Unix
    
    C'est propos ne sont pas plus extrémiste que les miens si?
    
    Ce n'est pas de l'incitation au troll, j’essaie de comprendre.
    
    Personnellement je fais que du libre (license ISC) et si on contribue à mes projets tant mieux, sinon c'est pas grave.
    
    Ducoup, que pense tu de ce qu'a vécu Wine? Auraient ils du rester en licence MIT et laisser la situation perdurer?
    - [^] # Re: Question naïve autour de la licence
      
      Posté par barmic le 06 avril 2016 à 09:56. Évalué à 5.
      Wine est un cas particulier d'une entreprise qui prend un modèle économique agressif envers un projet libre. Ça n'est pas la norme loin de là. Il y a un paquet de projets libres qui ne peuvent pas monter ce genre de modèle.
      
      Les licences sans copyleft fonctionnent très bien :
      
      quand le projet tiens la route de lui même par rapport aux éventuelles entreprises qui chercheraient à être agressif. Le projet linux pourrait (théoriquement) passer à une telle licence sans problème car il n'existe pas d'entreprise en mesure de faire un fork agressif et qui tiens la route.
      
      quand tu cherche à diffuser une techno, tu cherche alors à la propager autant que possible. C'est un point défendu par le projet GNU¹
      
      quand il n'y a tout simplement pas de modèle économique possible sur ton
      
      C'est propos ne sont pas plus extrémiste que les miens si ?
      
      Je pense qu'il veut juste montrer que l'on peut faire de l'opposé de ce que tu avance.
      
      https://www.gnu.org/licenses/license-recommendations.html : la vision est un peu minimaliste, ils parlent comme une guerre, alors qu'il y a des cas où tu n'es pas en concurrence. Par exemple si tu crée un système qui permet aux non-voyants de mieux interagir avec leur machine, ton objectif va probablement plus être de partager ton code plutôt que de le protéger. ↩
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Question naïve autour de la licence
        
        Posté par lasher le 06 avril 2016 à 17:29. Évalué à 6.
        
        Les licences sans copyleft fonctionnent très bien : […]
        
        J'irai même plus loin : Nessus a changé de licence pour passer de GPL à un truc propriétaire en grande partie parce que des entreprises qui font du « consulting sécurité », n'avaient aucun scrupule à virer les copyrights/crédits, modifier/corriger les bugs, et utiliser Nessus en disant qu'ils étaient à l'origine du produit. Et comme les « consultants » ne laissaient pas leur soft derrière eux (ils faisaient juste le scan des réseaux, etc.), il n'y a aucune preuve matérielle de la manipulation.
        
        Plus prosaïquement : même si les boites avaient été honnêtes et avaient dit qu'elles utilisaient Nessus, puisqu'elles ne distribuaient pas le soft aux clients, rien ne les obligeait à distribuer le code source modifié avec leurs patches.
        
        GPL ou BSD/MIT, dans ce cas, n'a rien changé.
      - [^] # Re: Question naïve autour de la licence
        
        Posté par Maclag le 08 avril 2016 à 22:36. Évalué à 5.
        
        quand le projet tiens la route de lui même par rapport aux éventuelles entreprises qui chercheraient à être agressif.
        
        Tu te rends compte que ça ne tient pas debout? Autant expliquer aux gens que s'ils ne sont jamais malades, ils n'ont pas besoin d'assurance-maladie, mais s'ils peuvent tomber malades, alors, oui, une assurance, c'est sans doute mieux.
        
        Le projet linux pourrait (théoriquement) passer à une telle licence sans problème car il n'existe pas d'entreprise en mesure de faire un fork agressif et qui tiens la route.
        
        Tu veux dire à part Google? Les fabricants de matériel? (cf certains routeurs), les constructeurs de tél chinois, etc. etc.
    - [^] # Re: Question naïve autour de la licence
      
      Posté par David Demelier (site web personnel) le 06 avril 2016 à 12:49. Évalué à 5. Dernière modification le 06 avril 2016 à 12:54.
      
      Wine etait en licence MIT avant de subir l'abus d'une societe qui a forke et ferme le code, rendu payant le logiciel et fait pleins de correctifs (et le tout parfaitement legalement). Wine est finalement passe en GPL pour ces raisons (et aussi parce que beaucoup de contributeurs se rendaient compte qu'il travaillait presque directement pour l'autre entreprise qui cherry pickait tous les nouveaux fixes de Wine).
      
      Effectivement pour le coup je pense que c'est bien pour Wine. Je n'ai rien contre la GPL lorsqu'il s'agit de frontends (exécutables finaux).
      
      Cela protège largement le logiciel et c'est très bien comme ça.
      
      C'est plutôt pour les bibliothèques, j'ai toujours pesté et fuis celles sous licence GPL. Je comprends pas l'intérêt de forcer un utilisateur de ta bibliothèque à faire du code open-source uniquement. C'est là que je trouve que la vision est vraiment orientée fanatique. Heureusement un bon nombre de personnes choisissent néanmoins la LGPL qui est bien mieux pour les bibliothèques.
      
      Tiled (mapeditor.org) est bien fait pour ça. Son exécutable est sous GPL ce qui contraint tous les changements à être libre aussi et sa bibliothèque est sous LGPL. Au moins, normalement tout le monde est content :)
      
      git is great because linus did it, mercurial is better because he didn't
  - [^] # Re: Question naïve autour de la licence
    
    Posté par Maclag le 08 avril 2016 à 22:33. Évalué à 6.
    
    Je me souviens Theo de Raadt (OpenBSD) avoir dit quelque chose comme "Les gens font Linux parce qu'ils détestent Windows, nous faisons OpenBSD parce que nous aimons Unix".
    
    Ouai, enfin, c'est ce même Theo qui se félicite de la liberté supplémentaire de la licence BSD tout en râlant continuellement sur le fait que beaucoup d'utilisateurs ne contribuent pas en amont.
    "Je veux pas les forcer, mais bordel, je veux qu'ils le fassent quand même!!" (pas de lui mais c'est l'idée). À un moment faut être cohérent!
- [^] # Re: Question naïve autour de la licence
  
  Posté par Olivier Cochard-Labbé (site web personnel) le 06 avril 2016 à 10:17. Évalué à 3.
  
  En gros, c'est quoi l’intérêt de FreeBSD pour le libre? :) C'est pas un troll, c'est une vraie question
  
  D'après le contexte, cette question devrait plutôt être reformulée comme ceci: Quel est l’intérêt de la license BSD pour le libre ?
  
  Voici une des réponses possible, sans évoquer le sujet de re-contribuer au codes de ses briques logiciels, mais rien que leurs usages:
  Aujourd'hui beaucoup d'entreprises développent leur logiciels maison spécifique à leur métier et veulent éviter de perdre trop d'argent. Donc pour éviter de ré-inventer la roue, leur logiciel maison intègrent le plus possible de briques logiciels libres. Et je parle de gros logiciels incluant des 50aines ou 100aines de briques.
  Sauf qu'il faut y ajouter la charge du «dé-risquage juridique» qui met en œuvres des compétences mixte juridique/développeur (donc coûte cher) pour analyser:
  - l'ensemble des licences libres utilisées;
  - le respect de leur usage;
  - leur incompatibilités entre-elles.
  Et cette analyse est très vite compliquée avec des briques logiciels sous licenses virales ou complexe.
  Donc du coup la règle est simple: Usage de logiciel sous license virales (GPL) fortement déconseillé et il faut privilégier les logiciels sous license copyleft (BSD, MIT, etc.).
  - [^] # Re: Question naïve autour de la licence
    
    Posté par ariasuni le 10 avril 2016 à 00:34. Évalué à 3.
    
    Tu confonds licences libres de type copyleft/restrictive/virale/redistribution à l’identique (qui obligent à redistribuer sous la même licence, comme la plupart des licences GNU, la MPL, la licence Art Libre ou la CC-BY-SA) et les licences copyfree/permissives (Apache — qui est assez complexe car couvrant beaucoup de choses malgré tout, MIT, BSD 2-clauses et BSD 3-clauses (juste «BSD» c’est ambigu), ou la CC-BY et CC-0).
    
    Écrit en Bépo selon l’orthographe de 1990
# upgrade depuis 10.1

Posté par b0b le 06 avril 2016 à 08:55. Évalué à 4.

Question un peu bête et je m'en excuse d'avance.

Je suppose qu'il serait toujours préférable de mettre à jour pas à pas (10.1 -> 10.2 -> 10.3), mais y a t-il des contre-indications à passer de 10.1 à 10.3 directement ?

Je pose cette question car n'ayant pas installé de paquet exotique, et au vu de la stabilité de FreeBSD mais également car il s'agit d'une mise à jour mineure, cela me paraissait plausible, et renforcerait l'image que j'ai de FreeBSD.

Merci de vos réponses/conseils :)
- [^] # Re: upgrade depuis 10.1
  
  Posté par David Marec (site web personnel) le 06 avril 2016 à 11:47. Évalué à 4.
  
  y a t-il des contre-indications à passer de 10.1 à 10.3 directement ?
  
  A priori et sans l'avoir essayé, non; je ne vois rien de dangereux sur la 10.2 et la 10.3.
  
  Sauf: une mise à jour de ZFS, qui, si vous mettez à jour un zpool qui contient root, ne démarrera plus sans mise à jour de l'amorce GPT:
  
  https://linuxfr.org/news/freebsd-10-2#comment-1619104
  
  Ceci dit, la mise à jour du poolne se fera pas sans l'ordre explicite:
  zpool upgrade
# Boot Loader Changes

Posté par David Marec (site web personnel) le 06 avril 2016 à 11:36. Évalué à 4.

Je n'ai pas compris ce qu'apportait celle-là:

l'émulation de terminal a été ajoutée au chargeur de démarrage EFI ;

et comment en profiter, au besoin ?

De même pour les deux autres changement du lanceur (ou démarreur):

le chargeur de démarrage supporte désormais nativement les environnements de démarrage ZFS

qu'il s'agisse de celle-ci
ou celle-là.

Plus besoin de charger les modules ZFS et openSolaris au boot ?

Je ne l'ai pas vu dans la dépêche, mais on a retrouvé Beastie en UEFI, en lieu et place du "Hello-Kitty" officiel.
- [^] # Re: Boot Loader Changes
  
  Posté par Bapt (site web personnel) le 06 avril 2016 à 23:16. Évalué à 5.
```
Pour l'émulation de terminal, ça veut juste dire que le loader peut maintenant afficher le menu de boot, ce qui n'était pas le cas avant. (Donc le beastie apparait)
```Pour le boot environement il s'agit de beadm.
  Aka avoir la possibilité depuis le menu de boot de choisir sur quel environement ZFS booter les système.
```
- [^] # Re: Boot Loader Changes
  
  Posté par David Marec (site web personnel) le 07 avril 2016 à 21:06. Évalué à 3.
  
  Merci bapt, mais le concept d’ «environnement ZFS» qui m'échappe encore.
  
  Sous le nouveau menu apparait maintenant, outre le root ZFS d'origine, des clones de snapshots du serveur lui même mais aussi d'autres machines, rapatriés à coup zfs send | ssh recv.
  
  Cela signifie que l'on pourrait, lors d'une mise à jour comme celle-ci, faire un snapshot avant la mise à jour et l'utiliser en cas de problème; sans avoir à faire de rollback ?
  Pour pouvoir réparer une petite erreur de merge lors de l'installation par exemple ? - vécu :) -
  
  Le menu est d'ailleurs lui-même divisé en deux section chez moi,
  deux entrées (un environnement à amorcer+le root d'origine) d'abord, la liste des clones ensuite.
  
  J'ai essayé d'amorcer sur les clones, sans succès: cela échoue à la fin de l'initialisation à la recherche de dev au mieux. Il devrait y avoir un petit manuel qui explique l'utilisation de ce menu.
  - Je n'ai qu'un zpool et les clones ne sont pas /promus/. -
  
  je suis sur la lecture de http://docs.oracle.com/cd/E23824_01/html/821-1462/beadm-1m.html, mais y aurait-il un manuel ou un tutoriel plus complet pour l'expliquer ?
# FreeBSD-RELEASE + semi-rolling release

Posté par kuniyoshi le 12 avril 2016 à 10:10. Évalué à 3.

Pour information, peux-tu considérer le système FreeBSD-RELEASE comme un système de type "rolling-release" ?

Ma définition d'un système "rolling-release" :

(1) Mises à jour de sécurité sur le couple base/noyau (pas de nouvelles fonctionnalités donc, de ce point de vue ce mode de fonctionnement est à rapprocher du mode de fonctionnement d'un système Debian GNU/Linux stable) via "freebsd-update" (pour une version générique de cet ensemble).
(2) Mises à jour en flux continue sur les logiciels tierce-partie (côté "rolling-release" comparable au mode de fonctionnement du système ArchLinux) via les commandes "pkg update" et "pkg upgrade" (dans ce contexte "pkg-ng" gère uniquement les paquets binaires des dépôts officiels du projet FreeBSD… ou pas --> construction d'un dépôt local via le triplet jail/ZFS/poudriere).

À mon sens cette approche est d'autant plus justifiée que, de par sa conception, le système de base de FreeBSD-RELEASE et le reste (logiciels tierce-partie) sont bel et bien (proprement) séparés.

Quel est votre avis ?
- [^] # Re: FreeBSD-RELEASE + semi-rolling release
  
  Posté par David Marec (site web personnel) le 13 avril 2016 à 21:36. Évalué à 2.
  
  (1) Mises à jour de sécurité sur le couple base/noyau
  
  C'est le rôle de freebsd-update;
  de base, il suit les mises à jour d'une même branche, mais à l'aide de la commande données en entête, il permet de se 'brancher' sur une autre release.
  
  Pas de nouvelles fonctionnalités
  
  En fait, si. Certaines nouveautés testées sur une branche plus récente peuvent être embarquées dans une release mineure,voire un patch.J'ai un exemple récent: il semblerait que le module EFI pour bhyve, normalement prévu uniquement sur la 11, soit disponible en 10.3.
  
  (2) Mises à jour en flux continue sur les logiciels tierce-partie
  
  C'est le rôle de pkgng:
  
  Comme vous l'avez noté, nombre d'utilisateur fabriquent leur propres paquets dans une poudriere.
  
  Pour répondre à la question, depuis l'arrivée de ces deux fonctions, je dirais oui.
  ( il existait des fonctions un peu équivalentes avant, mais beaucoup moins pratiques)
  
  Par exemple, dans ma situation:
  Sur un serveur, les ports sont à jour et je suis actuellement la branche 10 de RELEASE en RELEASE.
  
  Sur la présente machine, les mises à jours sans réinstallation datent de la branche 7 ou 8 (et encore, pour changer de FS sur root).
  
  De plus, comme on peut diriger pkg sur un dépôt local ou celui d'un copain, on peut aussi choisir un le dépôt officiel qui se met à jour plus ou moins rapidement (QUARTELY ou LATEST).
  
  Par contre, n'ayant jamais installé que du Debian, je ne peux comparer avec les autres distributions comme Arch.
  - [^] # Re: FreeBSD-RELEASE + semi-rolling release
    
    Posté par kuniyoshi le 13 avril 2016 à 23:51. Évalué à 0.
    
    Merci pour votre réponse. Pour ce qui est du système GNU/Linux ArchLinux, je l'ai déjà utilisé mais je ne prétends pas le maîtriser. Les mises à jour se font de façon continue (base, noyau linux et logiciels tierce-partie). Mais en fait, je ne crois pas que cela soit bien judicieux de faire une distinction entre ces trois éléments dans ce contexte. (La séparation entre tous ces éléments n'étant pas aussi scricte et "carrée" que sur un système FreeBSD.) De mon expérience avec ArchLinux, l'ensemble de l'OS bouge au fur et à mesure en fonction des nouveautés logicielles (après quelques tests de stabilité… je suppose). De fait, il n'y a pas de version pour ArchLinux. Si un utilisateur d'ArchLinux plus expert passe par ici, il pourrait peut-être confirmer ?! Par contre une chose est certaine : avant l'arrivée du système d'initialisation systemd, le système ArchLinux centralisait la configuration de ses services dans le fichier "/etc/rc.conf" comme le système FreeBSD. Ce n'est plus le cas désormais.
- [^] # Re: FreeBSD-RELEASE + semi-rolling release
  
  Posté par barmic le 14 avril 2016 à 10:45. Évalué à 4.
  
  Il me semble que c'est un fonctionnement assez naturel chez les BSD qui ont un découpage base système/arbre des ports.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: FreeBSD-RELEASE + semi-rolling release
    
    Posté par kuniyoshi le 14 avril 2016 à 16:10. Évalué à 0. Dernière modification le 14 avril 2016 à 16:13.
    
    Effectivement. Pour avoir aussi utilisé NetBSD (très brièvement) et OpenBSD (plutôt pour la création de passerelles filtrantes), cela semble être une caractéristique des systèmes *BSD. Par contre, il me semble que les développeurs du système OpenBSD (contrairement à leurs homologues de NetBSD) ne recommandent pas d'installer des logiciels tierce-partie via pkg_add ou en les compilant depuis les ports (sauf besoins spécifiques). Ils recommandent l'utilisation générique du couple base/noyau d'OpenBSD. Néanmoins, c'est tout à fait faisable mais dans ce cas l'utilisateur s'éloigne de "l'esprit" du projet.
    
    Sinon, dans l'organisation générale du sytème et dans l'esprit (exemple : système des ports*), je trouve qu'un système FreeBSD est plus proche d'un système NetBSD. Sur ces deux aspects, OpenBSD est plus en retrait. Mais, il s'agit juste de mon avis ! (Il y a tout de même quelques "passerelles" entre tous ces projets : pf, openssh,… Rien n'est figé.)
    
    NB : *A priori, le système des ports de FreeBSD est inspiré de celui de NetBSD ("pkgsrc" de mémoire).
# kern.vt.enable_bell

Posté par kuniyoshi le 12 avril 2016 à 10:22. Évalué à 4.

Tout est dans le titre ! Lorsque la commande "sysctl -a | grep bell" est lancée, elle donne les informations suivantes sur mon système FreeBSD 10.3-RELEASE :

kern.vt.enable_bell: 0
hw.syscons.bell: 0

Contrairement à ce qui est mentionné au début de la dépêche :

la variable sysctl kern.vt.bell_enable permet de changer l'état de la sonnerie du terminal vt ;

Est-ce une coquille ?
- [^] # Re: kern.vt.enable_bell
  
  Posté par David Marec (site web personnel) le 13 avril 2016 à 18:27. Évalué à 2.
  
  Ça m'a tout l'air d'être une coquille, mais dans les Release Notes.
  Pas de trace de bell dans
  man vt(4)
  - [^] # Re: kern.vt.enable_bell
    
    Posté par David Marec (site web personnel) le 13 avril 2016 à 18:35. Évalué à 3.
    
    L'erreur initiale est dans le descriptif du commit.
    Le sysctl se trouve dans sysctl kern.vt.enable_bell
    
    https://svnweb.freebsd.org/base/stable/10/sys/dev/vt/vt_core.c?r1=287782&r2=287781&pathrev=287782
    
    VT_SYSCTL_INT(enable_bell, 1, "Enable bell");
- [^] # Re: kern.vt.enable_bell
  
  Posté par David Marec (site web personnel) le 13 avril 2016 à 22:06. Évalué à 3.
  
  Est-ce une coquille ?
  
  Oui, bien vu:
  
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208785
  - [^] # Re: kern.vt.enable_bell
    
    Posté par kuniyoshi le 13 avril 2016 à 23:53. Évalué à 0.
    
    Êtes-vous un développeur officiel du projet FreeBSD… un contributeur ?
    - [^] # Re: kern.vt.enable_bell
      
      Posté par David Marec (site web personnel) le 14 avril 2016 à 00:33. Évalué à 2.
      
      Êtes-vous un développeur officiel du projet FreeBSD…
      
      Non.
      
      un contributeur ?
      
      Pas plus que vous, maintenant: https://forums.freebsd.org/threads/55848/
      
      J'ai juste "go ahead" comme demandé :)
      - [^] # Re: kern.vt.enable_bell
        
        Posté par kuniyoshi le 14 avril 2016 à 10:33. Évalué à 1.
        
        Ok. Merci.
        
        Je suis en train d'apprendre à utiliser FreeBSD (dans sa version RELEASE). Cela fait environ cinq ans que je "tourne" autour de ce système comme je l'ai fait il y a quelques années avec le système Debian GNU/Linux stable (que j'ai finalement adopté en simple boot sur toutes mes postes de travail). En effet, j'essaie actuellement de le "modeler" pour que :
        
        d'une part, il exploite au mieux mon ultra-portable LENOVO ThinkPad X200s ;
        
        d'autre part, il exploite cette machine en tant que poste de travail (notamment dans le cadre de ma mission de professeur de mathématiques).
        
        Pour ce faire, je me base sur ce que je connais bien. J'essaie donc de reproduire les fonctionnalités de mes systèmes Debian GNU/Linux. FreeBSD n'est clairement pas aussi "user-friendly" (cela me rappelle mes débuts sur les systèmes GNU/Linux !) mais j'apprécie de plus en plus son côté "carré" (voire "obscur" ;-)). Donc, je persévére !
        
        Pour ceux ou celles qui seraient intéressés par mes tentatives multiples et répétées pour atteindre l'objectif ci-dessus, voici un lien :
        
        http://cyrille-borne.com/forum/showthread.php?tid=656
        
        Pour l'instant j'apprends… notamment sur le mode de fonctionnement de la communauté qui se "cache" derrière FreeBSD… d'où, ma question précédente ! :-)
        
        NB :
        Exemple : Récemment, j'ai découvert ce site. (Je ne sais pas si ce site est représentatif de l'état d'esprit de la communauté des *BSD mais a priori, je ne pense pas.)
        
        http://www.gcu-squad.org/
        
        et notamment
        
        http://www.gcu-squad.org/rule --> J'utilise l'UTF-8 !
        
        puis
        
        http://www.gcu-squad.org/rules
        
        C'est spécial mais drôle je trouve ! :-)
  - [^] # Re: kern.vt.enable_bell
    
    Posté par kuniyoshi le 13 avril 2016 à 23:58. Évalué à 2.
    
    Bah je me suis juste rendu compte que la commande "sysrc -f /etc/sysctl.conf kern.vt.bell_enable" ne fonctionnait pas sur mon système. Or cette commande m'intéressait, car j'avais des "bip" désagréables dans mes consoles "Xterm" sur mon environnement Xfce. Et je voulais à tout prix régler ce souci désagréable. Et bien, c'est désormais chose faite ! ;-)
- [^] # Re: kern.vt.enable_bell
  
  Posté par Benoît Sibaud (site web personnel) le 14 avril 2016 à 00:07. Évalué à 3.
  
  Corrigé, merci.

Suivre le flux des commentaires

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