GhostBSD 4.0 : enfin un successeur léger à PC-BSD, qui redonne ses lettres de noblesse au bureau pour FreeBSD.

Ah, GhostBSD. Basé comme PC-BSD sur FreeBSD, c’est un OS qui veut proposer une alternative aux distributions GNU/Linux sur le bureau. Le travail de la nouvelle version – j’avais parlé pour la dernière fois de GhostBSD à l’époque de sa version 3.5 en novembre 2013 – a été très important et centré sur un seul environnement de bureau : Mate Desktop.

Je n’avais pas été super emballé par la version 3.5 de GhostBSD. Cependant ayant pu faire quelques tests des version intermédiaires, j’ai apprécié l’annonce de la sortie de la version 4.0, alias Karina. J’ai récupéré l’ISO et lancé le tout dans une machine VirtualBox.

[fred@fredo-arch ISO à tester]$ wget -c http://freefr.dl.sourceforge.net/project/ghostbsdproject/release/amd64/4.0/GhostBSD4.0-RELEASE-amd64.iso
–2014-10-03 09:49:16– http://freefr.dl.sourceforge.net/project/ghostbsdproject/release/amd64/4.0/GhostBSD4.0-RELEASE-amd64.iso
Résolution de freefr.dl.sourceforge.net (freefr.dl.sourceforge.net)… 2a01:e0d:1:8:58bf:fa88:0:1, 88.191.250.136
Connexion à freefr.dl.sourceforge.net (freefr.dl.sourceforge.net)|2a01:e0d:1:8:58bf:fa88:0:1|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1271048192 (1,2G) [application/octet-stream]
Sauvegarde en : « GhostBSD4.0-RELEASE-amd64.iso »

100%[====================================>] 1 271 048 192 1,86MB/s ds 12m 39s

2014-10-03 10:01:55 (1,60 MB/s) — « GhostBSD4.0-RELEASE-amd64.iso » sauvegardé [1271048192/1271048192]

Les notes de publications parlent d’un bug lié à xorg lors de la mise à jour de l’OS. J’indique un peu plus bas dans l’article comment contourner le dit bug. Au premier démarrage, on a le choix de l’interface à utiliser. Je suis resté avec l’option « classique »

L’installateur est très simple, mais il souffre d’un gros bug : le clavier reste en qwerty même si on demande un autre agencement. Il faut faire gaffe quand on saisit les divers mots de passe, sinon gare à la mauvaise surprise. Il faut espérer qu’il sera corrigé dans une future version. Bug rapporté par votre serviteur.

Les étapes sont classiques, des captures d’écran résumant bien les actions à faire. J’ai apprécié particulièrement le panneau des claviers et des fuseaux horaires. Lors de la création de l’utilisateur, on s’aperçoit que ce n’est pas bash qui est proposé comme shell par défaut, mais fish.

Pour cette étape, mieux ne vaut pas oublier d’installer le gestionnaire de démarrage, surtout sur une machine nue…

Après l’installation, on se retrouve devant GDM. Il faut bien entendu penser à passer l’ensemble avec des réglages français, aussi bien au niveau du clavier que de la localisation.

Dommage que si l’on désire utiliser GhostBSD dans une autre langue que l’anglais, il y a un autre bug, celui des répertoires utilisateurs non traduits, rapporté par votre serviteur.

Il y a trois étapes pour les mises à jour. La première est de se synchroniser avec le FreeBSD officiel, donc en ligne de commande :

sudo freebsd-update fetch
sudo freebsd-update install

Ensuite, on va contourner le bug lié à Xorg. Il faut verrouiller les paquets liés à Xorg :

sudo pkg lock xorg-drivers
sudo pkg lock xorg-server
sudo pkg lock xorg-minimal
sudo pkg lock xf86-video-vesa
sudo pkg lock xf86-input-keyboard
sudo pkg lock xf86-input-mouse

On passe ensuite à la mise à jour des paquets, qui a duré une bonne heure…

sudo pkg update
sudo pkg install pkg
sudo pkg update
sudo pkg upgrade

Dans la liste des mises à jour, il y a le passage de Mate Desktop 1.6 au 1.8. Au démarrage suivant, il faut penser à demander à gdm à rester avec la session Mate. Sinon, il ouvre par défaut une session… Gnome !

Passons maintenant à la traduction. Pour Libreoffice : sudo pkg install fr-libreoffice. Pour Mozilla Firefox : sudo pkg install firefox-i18n-fr

Pour le passage des répertoires utilisateurs de l’anglais vers le français, même si c’est ennuyeux et pas encore complètement au point.

On commence par installer le paquet xdg-user-dirs avec sudo pkg-install xdg-user-dirs. Ensuite, il faut supprimer le répertoire de configuration (qui supprimera certains réglages, dont la transparence du terminal, mais c’est facile à retrouver), avec un petit rm -rf .config.

Après un duo déconnexion et reconnexion, il faut ouvrir un terminal, et entrer xdg-user-dirs-update. Après, on peut enlever à la main les répertoires anglais : downloads, templates, music. Et on a un système un peu plus francisé. Même si c’est franchement crade… 🙁

Même s’il est un peu vert par endroit, GhostBSD prouve qu’on peut proposer une adaption de FreeBSD pour l’utilisateur de bureau sans tomber dans l’hippopotamesque PC-BSD. C’est le jour et la nuit pour la vitesse. Même s’il reste quelques angles à arrondir (comme le bug lié à la mise à jour de Xorg ou à la migration de certains outils vers Mate Desktop 1.8), l’ensemble est vraiment très utilisable. J’ai été agréablement surpris du résultat.

Il faut mettre un peu la main à la pâte, mais le jeu en vaut la chandelle, même si tout n’est pas parfait. Il faut rester conscient cependant qu’un BSD libre pour une utilisation bureautique est encore assez austère. Un peu comme les distributions GNU/Linux vers 2004/2005.

35 réflexions sur « GhostBSD 4.0 : enfin un successeur léger à PC-BSD, qui redonne ses lettres de noblesse au bureau pour FreeBSD. »

  1. Tu penses qu’un jour la gamme BSD arrivera à une facilité d’installation/d’utilisation des GNU/Linux d’aujourd’hui ?

    Merci pour la vidéo, et pour ton blog en général
    🙂

  2. C’est vrai qu’à la longue le vert du bureau Mate devient lassant, enfin c’est l’effet ressenti. merci de partager tes impressions et tes conseils pertinents.
    A pluche.

  4. Connaissant FreeBSD et essayant de l’apprivoiser comme poste de travail depuis quelques années, je peux vous dire que cette version de GhostBSD est une très bonne version. Comme le dit Fred, elle est rapide et fonctionnelle d’emblée. On est loin du paramétrage à la main d’un système FreeBSD. J’ose le dire, cela semble quasiment « user-friendly »… pour un BSD. Bon il est vrai que le système des packages est en ligne de commandes mais le logiciel « pkgng » est un apt-like encore jeune mais qui a de l’avenir ! Encore une fois je suis assez impressionné par le travail pour dégrossir FreeBSD pour aboutir à un tel résultat. Il faudrait que j’aille voir leur « /etc/rc.conf »…
    Sinon, je ne connaissais pas le shell fish : il a l’air pas mal. Je suis tellement emballé que je vais l’installer de ce pas sur une machine physique.

    1. Évidemment tout le monde l’aura compris, c’est GhostBSD qui va finir sur une machine physique avec le shell fish de toute façon 😉

  5. Voici un retour d’expérience de GhostBSD sur une machine physique (samedi 5 octobre vers 23 h 00) :

    (1) Je n’ai pas réussi (comme FreeBSD) à installer le système directement via le lecteur de DVD-ROM (version i386). J’ai donc extirpé le disque dur du portable, l’ai mis dans un boitier usb/ide (ai-je dis que c’était un vieux portable) et j’ai lancé l’installation via qemu (attention vers « /dev/sdb » !!!) depuis mon PC principal exploité par une Debian stable (amd64). Là vous suivez les explications de Frédéric. Pour ma part, je suis allé me coucher car l’installation via USB prend des plombes.

    (2) Ce matin au démarrage (sur la machine physique donc !), tout va bien… sauf à la fin car il y a un souci avec la carte graphique (radeon) et gdm. Comme avec FreeBSD (je commence à connaître le truc !), je change de console (CTRL-ALT-F2), me connecte en root, puis édite le fiochier « /etc/rc.conf » à l’aide de mon ami « vi ». Là, je mets à « NO » les flags suivants :
    – gdm_enable= »NO »
    – vboxguest_enable= »NO »
    – vboxservice_enable= »NO »
    J’édite le fichier « /etc/X11/sorg.conf ». Le driver est « vesa ». (Et oui Fred, avec FreeBSD, il est encore utile de savoir paramétrer le « xorg.?conf » si nécessaire… et là c’est nécessaire !) Je le laisse ainsi pour l’instant car je pourrai le modifier plus tard si besoin (driver radeon je crois !).

    (3) Je redémarre et je tombe sur le login en console.

    (4) J’ouvre ma session en tant que simple utilisateur. Je crée le fichier « .xinitrc » et écrit « exec mate_session ». Je sauve et lance « startx ». Au passage, le shell « fish » semble pas mal (ce pourrait être un bon remplaçant de « csh » un peu austère à l’installation) : la cloration syntaxique et la complétion sont déjà là fonctionnels.

    (5) À ma grande surprise, « /usr/local/bin/startx » est marqué comme un exécutable mais il ne peut être lancé sur cet OS !!!?

    Bon je verrai la suite cet après-midi… mais d’ores te déjà quitte à faire des « bidouilles » autant utiliser l’original. Je suis un peu refroidi là 🙁
    Mais je vais continuer car la fait qu’il ne veuille pas lancer « startx » titille ma curiosité (le vieux bidouileur qui sommeille en moi !) 🙂
    Je vous tindrai au courant.
    @+

  6. 2ème partie (petite précision avant de poursuivre : ce PC portable fonctionne à merveille avec FreeBSD donc il devrait en être de même avec GhostBSD !!!) :

    (6) La commande « startx » ne fonctionne pas avec le shell « fish ». Je me suis connecté en root puis j’ai lancé la commande « vipw » pour modifier changer le shell de mon simple utilisateur : changer la ligne « /usr/local/bin/fish » par « /bin/csh ». J’ai sauvé. Tant pis ! Le shell « csh » est moins beau à l’installation (mais on peut le paramétrer par la suite pour avoir de la coloration syntaxique par exemple) mais il est efficace et pour le coup il m’a permis de faire fonctionner la commande « startx » !
    (7) J’ai un beau « no screens found ». J’édite donc « /etc/X11/xorg.conf » puis modifie la ligne Driver « vesa » par Driver « radeon » puis la ligne BusID « PCI:0:2:0 » par BusID « PCI:2:0:0 » (très certainement lié à l’installation via qemu !)
    (8) Après un « startx », il me dit qu’il n’aime pas le driver « radeon » donc je remets le driver « vesa ». Puis RE-« startx » –> échec !
    (9) Il me dit qu’il n’aime pas le « exec » de mon « .xinitrc » donc je move mon « .xinitrc » en « xinitrc » ainsi il ne sera plus pris en compte ! Puis « startx » –> réussite !!! 🙂 Un son retentit, l’environnement Mate apparaît et mes tests en mode graphique se poursuivront cet après-midi.

    J’aime FreeBSD 🙂

    @+ tard

    NB : Ce qui m’intéressait dans GhostBSD c’était l’aspect clef en main ! Comment dire… cet aspect me paraît nettement moins évident ce matin. Par contre, je vais pouvoir voir comment l’équipe de GhostBSD a paramétré FreeBSD pour en faire un poste de travail convivial (enfin dans VirtualBox !!!). Cet OS me servira de modèle pour installer un FreeBSD from scratch en tant que poste de travail.

  7. Pour Fred, je n’ai effectue aucune mises a jour ! La, j’ai l’ingenieuse idee de remettre le service gdm par defaut dans le /etc/rc.conf. DU coup, je n’arrive plus a ouvrir ma session. Je le sais pourtant qu’il vaut lancer gdm au demarrage lorsque l’on est certain que tout fonctionne ! Bah pas grave, cet apres-midi je vais demarrer ghosbsd en single mode (le clavier sera alorsven qwerty) et je remettrai le flag NO a gdm_enable. La suite de mes aventures cet apres-midi ! 🙂

  8. Oui désolé pour la forme du message précédent, mais j’étais sur une tablette avec mon bébé dans les bras. Bah je suis multitâche comme un UNIX 🙂
    Sinon, je peux préciser davantage la raison pour laquelle je ne parviens plus à me connecter sur ma session graphique en tant que simple utilisateur : j’ai donc réactivé le service « gdm » au démarrage et j’ai remis le shell « fish » pour mon utilisateur. Bilan : Je ne peux plus me connecter en mode graphique… et comme d’hbitude dans ce genre de circonstance, je ne parviens plus non plus à me connecter sur une console. (Les CRT-ALT-* ne fonctionnent pas et je soupçonne le shell « fish » d’être responsable de ce désagrément !)
    @+

  9. Ça y est : j’ai booté en single mode. Voici la démarche (attention : désormais le clavier est en qwerty) :
    (1) Valider le choix du shell « /bin/sh »
    (2) Taper « mount -a » car la racine de l’OS est montée en lecture dans le mode single ! Cette commande permet (entre autre) de monter ce système de fichiers en écriture.
    (3) Éditer (en qwerty) le fichier « /etc/rc.conf » et changer « gdm_enable »YES » en « gdm_enable= »NO ».
    (4) Éditer (en qwerty) le fichier « passwd » via la commande « vipw » et remplacer le shel « /usr/local/bin/fish » par /bin/csh »
    (5) On reboote et cela re-fonctionne… enfin disons que je peux de nouveau avoir la main sur le système en tant que root dans le mode normal ! 🙂

  12. 3ème partie (reprise à 13 h 45 → fin à 16 h 09) :

    (10) J’ai réactivé le service « gdm » au démarrage et je n’arrive toujours pas à ouvrir une session. La souris fonctionne mais pas le clavier. (Donc, je ne peux pas écrire mon mot de passe !?) Je ne peux toujours pas passer sur une autre console via « CTRL-ALT-* ». J’en déduis donc que c’est « gdm » qui est la cause du problème et non le shell « fish ». Je reboote en mode single pour désactiver le service « gdm ».
    Bizarre ces deux problèmes liés à gdm ! (Habituellement j’utilise « slim » comme gestionnaire de connexion sur un système FreeBSD.)

    (11) Après avoir démarré, je suis de nouveau face à une session non graphique. Je me connecte en tant que simple utilisateur avec un shell « csh ».

    (12) Le réseau n’est pas encore fonctionnel (DHCP de qemu oblige!). J’ai donc édité le fichier « /etc/rc.conf ». (Vous l’aurez compris ce fichier de configuration est l’un des fichiers les plus importants d’un système FreeBSD.) C’était aussi le cas de ArchLinux il y a quelques années avant la migration vers system.d !

    Commande : sudo vi /etc/rc.conf

    Comme sur mon réseau les adresses IP sont statiques, je remplace la ligne

    ifconfig_bge0= « DHCP »

    par

    ifconfig_bge0= « inet 192.168.0.3 netmask 255.255.255.0 »

    Puis j’ajoute celle-ci :

    defaultrouter= « 192.168.0.254 » (C’est l’adresse de ma passerelle filtrante exploitée par OpenBSD)

    Au passage, j’ajoute aussi les lignes (Fred a eu ce « souci ») :

    dumpdev= « NO » (pour désactiver la création de fichiers « .core »)
    sendmail_enable= « NO »

    J’édite le fichier « /etc/resolv.conf » (qui est resté sur une config DHCP) pour commenter la ligne suivante avec un dièse :

    nameserver 10.0.2.3 (Installation via qemu oblige !)

    en

    #nameserver 10.0.2.3

    Puis dans ce même fichier, j’ajoute les lignes (serveurs d’OpenDNS) :

    nameserver 208.67.222.222
    nameserver 208.67.220.220

    Je sauve puis relance les services réseau :

    sudo /etc/netstart

    (13) Là je suis le billet de Fred :

    – Mise à jour du noyau FreeBSD et de la base du système :

    sudo freebsd-update fetch
    sudo freebsd-update install

    On rédemarre le système pour que le nouveau noyau et la nouvelle base soient pris en compte :

    sudo reboot

    La commande  « sudo uname -a » permet de vérifier que la version du noyau FreeBSD est une 10-RELEASE pour une architecture i386 (La machine est un vieux PC portable Evo N620c !)
    On peut aussi utiliser : sudo sysctl -a | grep release

    Je pense que ce noyau doit être le dernier en date et donc un 10-RELEASE-p9 mais je ne vois aucune info sur ce point ! Bizarre ?!

    – Puis pour xorg : (C’est donc pour cela que j’ai récemment cassé mon serveur xorg sur le système FreeBSD de ma machine principale !!!?)

    sudo pkg lock -y xorg-drivers (L’option « -y » évite de valider le yes à la main!)
    sudo pkg lock -y xorg-server
    sudo pkg lock -y xorg-minimal
    sudo pkg lock -y xf86-video-vesa
    sudo pkg lock -y xf86-input-keyboard
    sudo pkg lock -y xf86-input-mouse

    Je rentre pour mettre à jour les applications tierce : (Tous les logiciels binaires qui se trouvent dans le répertoire « /usr/local ». FreeBSD est un système carré et très propre !)

    sudo pkg update
    sudo pkg upgrade

    Là c’est le moment d’aller vaquer à d’autres occupations : installer windows 10 qui n’est pas neuf dans une machine virtuelle par exemple ou mieux OpenBSD ! 🙂

    L’environnement Mate est passé de sa version 1.6 à sa version 1.8.

    NB : Tous les logiciels téléchargés sont mis en cache dans « /var/db/pkg/ » ce qui est peut être utile pour installer plusieurs machines de même architecture sans tout télécharger pour chacune de ces machines.

    Une fois terminé, la commande

    sudo pkg audit -F

    permet de voir si des failles de sécurité connues ont été installées sur le système GhostBSD.

    Fichtre ! Le logiciel « dbus » possède une faille de sécurité (multiples vulnérabilité ?!). M’en fiche… je continue… je verrai cela plus tard ! Au pire

    À noter : Le parefeu de FreeBSD « pf » n’est pas activé par défaut sur GhostBSD.

    – Je sauve le fichier :

    sudo cp /etc/csh.cshrc /etc/csh.cshrc

    pour le modifier ainsi :

    sudo vi /etc/csh.cshrc

    en ajoutant les lignes :

    # Add color to CLI
    setenv  CLICOLOR        true
    # Disable system beep
    set nobeep

    – Pour avoir Mate en français :

    J’édite le fichier pour ajouter (après russian) un compte « french » :

    french|French Users Accounts:\
    :charset=UTF-8:\
    :lang=fr_FR.UTF-8:\
    :tc=default:

    puis je sauve et lance la commande :

    sudo cap_mkdb /etc/login.conf

    suivi de :

    sudo vipw

    et je modifie la ligne liée à mon simple utilisateur :

    jeff :$6$/XYZq2dWDlnSWnh4$uPmbpZcKQw/pPczfUgCjVM./Ji0lBuMy1S/Oazr.Pntmsb6ZrIFUbpaSbUMekNsEDKBFhUpKVkWWq6HLfJzJg0:1001:0::0:0:jeff:/home/jeff:/bin/csh

    en

    jeff:$6$/XYZq2dWDlnSWnh4$uPmbpZcKQw/pPczfUgCjVM./Ji0lBuMy1S/Oazr.Pntmsb6ZrIFUbpaSbUMekNsEDKBFhUpKVkWWq6HLfJzJg0:1001:0:french:0:0:jeff:/home/jeff:/bin/csh

    Je crée le fichier « 10-x11-input.fdi » dans « /usr/local/etc/hal/fdi/policy/ »

     
       
          fr
          latin9
          compose:rwin
       
     

    puis je modifie le fichier « /etc/X11/xorg.conf » en remplaçant la ligne

    Driver « vesa »

    par

    Driver « ati »

    pour avoir le bon driver graphique.

    Je ferme la session puis je l’ouvre. Un petit « startx » et la dernière version de Mate apparaît… et bien non c’est la version 1.6 ?!!! C’est quoi ce b**** de m**** 🙁

    Une conclusion intermédiaire : Ce n’est pas encore USER-FRIENDLY ! Loin de là. De plus, mon installation directe d’un système FreeBSD sur la même machine est plus « simple » (cela n’engage que moi) et plus rapide que le système GhostBSD que j’ai actuellement. Bizarre ?! Je vais continuer les tests.

    ps: Voici un URL intéressant pour FreeBSD : http://olivier.cochard.me/bidouillage/installation-et-configuration-de-freebsd-comme-poste-de-travail#TOC-Configuration-de-la-langue-du-clavier-avec-HAL

    @+

      1. Ok je vais lui envoyer un e-mail. Je lui donnerai le lien vers ce billet, car je n’ai pas vraiment envie de ré-expliquer toute ma démarche. Je suis un peu fatigué là. Je viens de boire un café et cela va mieux. Je commence à me faire vieux ! 🙂
        Avec un peu de recul, j’ai tout de même tendance à penser que le principe de l’installation et du paramétrage d’un système de base FreeBSD (sans couche graphique) avec l’installation ultérieure de logiciels tierce-partie à coup de « pkg » ou de compilations en mémoire vive (notamment avec le logiciel « portupgrade ») est quand même plus « simple » et efficace (avec de l’expérience) que le principe de l’installation d’une solution toute faite (PC-BSD ou GhostBSD) qui doit être ré-ajustée (utilisation de qemu à partir d’un autre système open source) à cause d’un souci matériel. En effet, dans mon cas, tout a commencé avec le lecteur de DVD-ROM « défaillant » avec l’installateur de GhostBSD (même « bug » avec celui de FreeBSD). Il est à noter que ce lecteur fonctionne très bien a priori ?!
        Enfin… je me suis bien amusé ces dernières heures. C’est déjà ça ! 🙂
        N’empêche que j’y étais presque à la version près de Mate. Bizarre ce problème ?!

    2. ericbsd de #ghostbsd recommande de faire ceci:
      portupgrade -c xorg-drivers xorg-server xorg-minimal xf86-video-vesa xf86-input-keyboard xf86-input-mouse
      parce que je cite :
      The software update is from FreeBSD repos and Xorg From FreeBSD repos is not using KMS and new Xorg this is why if you do pkg upgrade you will break your xorg

      I recommended to do portupgrade of xorg-drivers, xorg-server, xorg-minimal, xf86-video-vesa, f86-input-keyboard, xf86-input-mouse, and after update do pkg upgrade -n will give you an list of pkg that need to be update do not update any of xf86 with pkg upgrade, nether Xorg. those problem will be fix in a near future

      1. Sur mon système FreeBSD « pur », je passe par les dépôts de « FreeBSD_new_xorg », mais cela freeze lorsque je passe de Mate vers une autre console (via CTRL-ALT-F*). J’ai donc écrasé les packages binaires « xf86-input-keyboard » et « xf86-input-mouse » puis je les ai compilés à l’aide de portupgrade comme indiqué ci-dessus et dessous*. Par contre, le projet GhostBSD qui aimerait simplifier l’installation et le paramétrage de FreeBSD comme poste de travail (c’est un peu l’idée d’une Ubuntu à la FreeBSD mais en préservant la base du système d’origine !), je trouve qu’effectuer de telles manipulations est assez embêtant compte tenu du public visé. M’enfin, c’est certainement temporaire ! Avec l’arrivée de FreeBSD 11-RELEASE, je pense que les problèmes liés au serveur xorg devraient être réglés.
        *URL : http://imil.net/wp/2014/08/08/freebsd-10-kms-and-intel-4500mhd/

        2. Ok mais attention, car a la moindre mise a jour a l’aide des outils de pkgng, les binaires compiles par portupgrade seront ecrases sauf si tu les verrouilles (merci Fred pour cette info). Comme je n’ai jamais teste sur du moyen/long terme, donc je ne sais pas ce que cela peut donner l’option des packages verrouilles : a un moment donne, je suppose qu’il doit bien y avoir des problemes de compatibilite de dependances a regler au fil de mises a jour consecutives. Par contre, je peux te confimer qu’utiliser les deux methodes en duo (d’un cote portupgrade pour compiler des softs et et de l’autre cote pkgng pour installer des binaires compiles par l’equipe FreeBSD) engendre des conflits et rend moins triviale la globalite des mises a jour suivantes. Enfin, la je parle de mon experience… je n’ai pas encore eu/pris le temps de lire de la doc officielle pour garder une certaine coherence binaire lorsqu’on utilise les methodes. 🙂
          Tiens et comment, cela fontionne cette dualite sous Archlinux ?

          1. Maintenant Xorg est compilé par défaut avec la variable WITH_NEW_XORG. C’est un prérequis désormais pour KDE4 et GNOME3 (d’ailleurs en ce moment des tests sont réalisés pour la version 3.12). C’est également nécessaire pour xfdashboard (GNOME shell-like pour Xfce).

          2. Archlinux n’est pas trop mal lotie ici. Elle est assez souple pour permettre de mettre en parallèle les ports (AUR la plupart du temps), et les paquets officiels. Il m’arrive de recompiler des paquets officiels le temps qu’une mise à jour interviennent, comme je l’ai fait pour Gimp 2.8.14 récemment.

          3. Donc Gnome 3 va etre porte sur FreeBSD. C’est Fred qui va etre content ! Ce sera d’ailleurs une bonne occasion pour lui de tester dans quelque temps l’installation d’une FreeBSD 11-RELEASE avec un environnement Gnome 3 a l’aide de pkgng. Hein Fred ? 🙂

  13. Deux erreurs :

    – Le fichier 10-x11-input.fdi (voir le lien donné ci-dessus car il semble interprété contant des balises !).
    – Remplacer
    NB : Tous les logiciels téléchargés sont mis en cache dans « /var/DB/pkg/ » ce qui est peut être utile pour installer plusieurs machines de même architecture sans tout télécharger pour chacune de ces machines.
    par
    NB : Tous les logiciels téléchargés sont mis en cache dans « /var/CACHE/pkg/ » ce qui est peut être utile pour installer plusieurs machines de même architecture sans tout télécharger pour chacune de ces machines.
    J’espère avoir été clair ! 🙂

  14. @kuniyoshi, que de complication, pourquoi ne pas suivre le handbook, notamment la partie concernant Xorg. car éditer des fichiers à l’aveugle, c’est le seul moyen de perdre du temps, et de faire des erreurs.

    De plus je ne connais pas les options de compilation choisit par GhostBSD (sans doute les mêmes que FreeBSD), mais hal est obsolète, par conséquent le fichier situé dans /usr/local/etc/hal/fdi/policy n’est plus nécessaire.

    freebsd-update, ne met pas uniquement à jour le noyau, il apporte également les correctifs à tous les logiciels qui gravite dans le système de base. Le suffixe -p9 indique qu’il y a eut des correctifs qui ont affecté le noyau, dans ton cas la branche releng/10.0.

    Pour changer de shell, la commande chsh -s fonctionne très bien (même sous Linux), moins on touche au fichier /etc/passwd (il faut regénérer la db) mieux on se porte.

    Pour le soucis de Ctrl+Alt+F[1-9], il faut ajuster une variable dans le fichier /boot/loader.conf, https://lists.freebsd.org/pipermail/freebsd-ports/2014-October/095806.html

  15. Olivier… Cochard ? 🙂
    Désolé, mais a priori (mis à part le fichier « /etc/passwd » et « chsh -s », je te l’accorde), je ne pense pas éditer des fichiers à l’aveugle.
    Quant à hal, je ne sais pas si il est obsolète, mais la procédure apparaît explicitement dans le Handbook :
    https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11-understanding.html
    Sinon, merci pour le lien https://lists.freebsd.org/pipermail/freebsd-ports/2014-October/095806.html, cela pourrait expliquer le fait que je ne puisse plus switcher (depuis peu) de Mate vers une autre console sur le système FreeBSD de ma machine principale. 🙂
    Par contre, sur GhostBSD (installé sur une vieille machine), la cause du problème semble de nature différente car il se manifeste avant de lancer les mises à jour du système (notamment celles de xorg). De plus, le clavier ne fonctionne plus avec GDM (toujours avant les mises à jour).
    Pour ce qui est de freebsd-update et freebsd-upgrade, je l’ai aussi écrit juste au dessus, donc je suis nécessairement d’accord avec toi ! 🙂
    Par contre, pour quelle raison la patch 9 n’apparaît pas sur GhostBSD suite à la mise à jour du noyau et ddu système de base ? Sur mon système FreeBSD, après la même manipulation, cette indication est apparaît grâce à la commande « uname -a ».

      1. Bonsoir Olivier. Tu es donc un developpeur du projet FreeBSD. C’est cool ! 🙂
        Une question : tu as ecrit en dessous que hal etait obsolete. Que voulais-tu dire par la ? Que desormais, il est possible de s’en passer totalement sous un systeme FreeBSD muni d’un environnement graphique tout en gardant les memes fonctionnalites ?
        Une autre question qui n’a rien avoir avec ce post (si ce n’est FreeBSD !) : est-ce que tu connais le module « pam_mkhomdir » de pam sous FreeBSD ?

        1. Hal est toujours présent, car il est nécessaire pour GNOME2 (peut-être également pour Mate).

          Xfce ne l’utilise plus (si mes souvenirs sont bon, depuis la version 4.8). Il va être (ou il est déjà) supprimé dans KDE4 (en tout cas pour Plasma 5, c’est gudev only). De même pour GNOME3.

          Sous FreeBSD, nous avons un démon similaire à udev, qui s’appelle devd, il est notamment utilisé (en option, pas par défaut) dans la détection de nouveaux périphériques dans Xorg. C’est sur ma TODO list de faire une implémentation pour Xfce. En fait nous avons toutes les fonctions équivalentes à udev, il reste juste à l’intégrer avec GLib pour avoir un homologue à gudev.

          Pour ta seconde question, non je ne connais pas pam_mkhomedir, je sais qu’il est présent dans les ports. Sous FreeBSD, on utilise openPAM. Certains modules présents sous Linux, sont absents sous FreeBSD.

          1. Olivier, merci pour les informations. Sinon, je t’explique pour « pam_mkhomedir » de (open-)PAM. J’ai récemment essayé de reproduire sur FreeBSD (car je pense que cet OS a de l’avenir comme poste de travail) un comportement que j’ai réussi à faire fonctionner avec un système Debian GNU/Linux stable : intégrer un client FreeBSD dans un domaine contrôlé par un serveur Eole SCRIBE (via les services ldap et samba). Et pour l’instant, j’ai partiellement réussi. En effet, comme tu l’as écrit, openPAM n’est pas le PAM de Debian : il fonctionne donc différemment. D’un client FreeBSD 10-RELEASE, par exemple, j’arrive à me connecter à partir d’un compte existant dans la base du serveur ldap mais ma session s’ouvre sur la racine de l’OS et non dans un répertoire créé de toute pièce pour l’occasion par le module précité. Je n’ai toujours pas réussi à résoudre ce problème mais j’y travaille car je suis motivé ! 🙂
            @+ et encore merci pour tes infos

  17. Bah Mate oblige !? 🙂
    Sinon, c’est quoi l’environnement, Lumina ? Un nouvel environnement open source développé par l’équipe de PC-BSD ? J’avoue ne pas le connaître celui-là.
    @+

Les commentaires sont fermés.