PCInpact titre son article "Windows 8, échec et mat ?". Pour les gens non familiers avec l'univers de Microsoft vous obtenez le même niveau de troll en remplaçant "Windows 8" par "Gnome Shell". Les raisons du rejet sont les mêmes : changements radicaux par rapport à la version précédente et choix ergonomiques imposés à l'utilisateur (retrais volontaire de pas mal de fonctions).

L'article déclare que Windows 8 n'a pas su relancer le marché des PC. A mon sens le but de Windows 8 n'était pas de relancer le marché du PC, mais de jouer un double jeu PC / Tablettes. Avoir la même interface sur toutes les plateformes, et les mêmes applications si on passe par le market. En soit ce n'est pas idiot, mais retirer des éléments comme le menu démarrer était un choix risqué.

J'ai utilisé Windows 8 pendant trois mois au travail, car je souhaitais me faire ma propre idée sur l'efficacité des outils en entreprise. La disparition du menu démarrer ne m'a pas trop perturbé, je l'ai toujours trouvé trop bordélique. Sur 8 le lancement des applications se fait en appuyant sur la touche Windows puis en tapant les premières lettres du nom. Les habitués de Gnome-Do, Synapse, ALT-F2 sur KDE, Unity, Gnome-Shell retrouveront facilement leurs marques. Les applications présentes en "tuiles" (provenant du market) sont absolument inutiles, la plupart du temps on ne lance que le bureau ou des applications standard depuis le start screen.

La présence du market me semble inappropriée dans une version PRO de Windows. En effet l'utilisateur peut installer les applications même s'il n'est pas administrateur. De quoi casser les stratégies de sécurité du domaine et potentiellement semer la pagaille sur le réseau (que se passe-t-il si un utilisateur décide d'installer un client bittorrent et télécharger à fond ?).

Sous le capot les changements sont bien moindres par rapport à Windows 7. Les outils d'administration sont toujours là et les pilotes sont majoritairement compatibles. Par exemple notre serveur d'impression ne fournit que les pilotes XP & 7, mais j'ai pu m'y connecter sans problèmes. C'est la même chose pour les applications utilisées. Par contre, le client SCCM 2007 ne semble pas fonctionner.

Sur l'ordinateur que j'utilise (un Fujistu Lifebook e752) j'ai pu tester l'UEFI avec Secure Boot, par contre impossible de voir la puce TPM sur Windows et activer le chiffrement du disque. Cela me semble étrange, car si Secure Boot marche alors la puce TPM est bien là et reconnue. Mystère.

Ce qui m'a fait finalement downgrader en Windows 7 c'est une migration de domaine manquée et la volonté de repartir sur un environnement propre.

Mon expérience de Windows 8 n'est pas si mauvaise, après quelques heures d'utilisation on s'habitue et on peut retrouver la même productivité qu'avec Windows 7. A mon sens la marche à franchir est bien moins importante que Gnome 2 / Gnome 3. Si les ventes de PC chutent vraiment je pense qu'il faut chercher d'autres raisons.

Les jails permettent de créer des VPS sur un système FreeBSD. Les processus sont emprisonnés dans un niveau d'exécution et un environnement distinct. L'équivalent sur Linux est OpenVZ / VServer / LXC mais le système de jails sous FreeBSD est intégré au système et plutôt mature.

La documentation de FreeBSD décrit le processus manuel de création de jails. Je recommande la lecture et le suivi de l’exercice proposé afin d'acquérir les bases. Il est aussi mentionné la possibilité d'utiliser un "squelette" commun à toutes les jails, ces dernières n'ayant que les répertoires susceptibles d'être modifié. Cela évite d'avoir 10 fois la même arborescence alors que beaucoup d'éléments sont communs. ezjail est un outil permettant d'automatiser tout ceci, et nous allons voir que c'est plutôt bien foutu.

Installation de FreeBSD

Depuis la version 9, l'installeur a été simplifié au point qu'il n'est plus nécessaire de le détailler. Le choix des sets importe peu sur le résultat final, mais personnellement j'ajoute les sources car j'estime que cela fait partie de l'OS.

La suite de l'installation ne nécessite pas de paramétrage particulier.

Configuration

Vous pouvez commencer par mettre à jour le système :

# freebsd-update fetch
# freebsd-update install
# reboot

Nous allons maintenant installer ezjail. Il y a deux solutions : le compiler à partir des ports, ou le télécharger sous forme binaire avec pkg_add.

Méthode 1 : ports

Commencez par télécharger l'arbre des ports :

# portsnap fetch extract

Puis compilez et installez sysutils/ezjail :

# cd /usr/ports/sysutils/ezjail
# make install clean

Il faut ensuite autoriser ezjail à se lancer :

echo ezjail_enable="YES" >> /etc/rc.conf

Méthode 2 : pkg_add

Utilisez la commande suivante :

# pkg_add -r ezjail

Il faut ensuite autoriser ezjail à se lancer :

echo ezjail_enable="YES" >> /etc/rc.conf

Création de la jail de base

La commande suivante va préparer la jail de base :

# ezjail-admin install

Création d'une jail

Utilisez la commande suivante :

# ezjail-admin create dns 'em0|192.168.0.2'

Démarrer une jail

Voici la commande :

# ezjail-admin start dns

Arrêt d'une jail

ezjail-admin stop dns

Mise à jour des jails

La jail de base va être mise à jour, ce qui va répandre les modifications sur toutes les jails.

# ezjail-admin update -u

Suppression d'une jail

La commande est la suivante :

# ezjail-admin delete -wf dns

Modifier le "modèle" des jail

Cas concret : vous voulez activer SSH sur toutes les jails créées. C'est faisable ! La jail "modèle" est située ici : /usr/jails/newjail. Donc il faut éditer/créer le fichier /usr/jails/newjail/etc/rc.conf :

# echo sshd_enable="YES" >> /usr/jails/newjail/etc/rc.conf

Et voilà !

Documentation

D'autres usages sont possibles, certains seront intéressés par les possibilités offertes avec l'intégration ZFS.

• Site officiel ezjail : Très pauvre, mais les bases sont là.
• Utiliser la commande man ezjail-admin directement sur FreeBSD, c'est très complet.

Dans l'épisode 1 je signalais des freezes à répétition sur DragonflyBSD fonctionnant dans VMware. Le problème s'est reproduit sur une autre VM qui avait été épargnée jusqu'ici. J'ai donc migré de VMware à VirtualBox (il suffit de créer une VM en utilisant le disque .vmdk existant, puis de changer le contrôleur IDE en SAS) pour voir si les choses s'améliorent.

Les warning kernel qui s'affichaient semblent avoir disparu... en revanche j'ai toujours des avertissements relatifs à "sendmail/postfix" (quoi ? sendmail ? je me suis battu des heures pour qu'il se taise car j'utilise postfix !! ). L'autre point étrange c'est que je reçois par mail des rapports de fonctionnement (logwatch) qui me signalent l'existence de vulnérabilités dans les paquets tiers installés :

Fetching package vulnerabilities database:

Checking pkgsrc packages for vulnerabilities:
Package perl-5.14.2nb5 has a arbitrary-code-execution vulnerability, see http://secunia.com/advisories/51498/
Package perl-5.14.2nb5 has a denial-of-service vulnerability, see http://secunia.com/advisories/52472/
Package dovecot-2.1.9 has a denial-of-service vulnerability, see http://secunia.com/advisories/51455/
Package curl-7.27.0 has a remote-system-access vulnerability, see http://secunia.com/advisories/52103/
Package curl-7.27.0 has a remote-information-disclosure vulnerability, see http://secunia.com/advisories/53051/
Package scmgit-base-1.7.12nb1 has a man-in-the-middle-attack vulnerability, see http://secunia.com/advisories/52361/

C'est très bien mais... que puis-je faire ? Ces logiciels ont été installés à partir de pkgin et ils sont déjà à jour. A quoi bon me signaler l'existence de vulnérabilités puisque je ne peux rien faire à part attendre que ce soit corrigé dans les dépôts de pkgin ? Mieux : pourquoi y a-t-il autant de vulnérabilités sur les logiciels fournis par pkgin ???

Du côté de FreeBSD difficile de juger, puisque l'outil pkgng (équivalent de pkgin) n'est pas pleinement utilisable. En effet les dépôts publics sont fermés depuis plusieurs mois suite à des problèmes de sécurité ! Donc le seul moyen de tester pkgng c'est de créer vous-même votre dépôt... Ce que je n'ai pas vraiment envie de faire.

DragonflyBSD offre beaucoup de points intéressants, mais semble avoir des problèmes de comportement en environnement VMware et avec certains logiciels tiers. FreeBSD est encore en phase de transition vers pkgng mais se comporte plutôt bien dans les différents cas où je l'ai testé.

J'ai mis en place plusieurs machines virtuelles sous VMware qui ont les rôles suivants :

• Un serveur DNS sous FreeBSD 9.1 amd64
• Un serveur Jabber sous DragonflyBSD 3.2 x86_64
• Un serveur mail sous DragonflyBSD 3.2 x86_64
• Un serveur web sous CentOS 6.4 x86_64

FreeBSD et CentOS se comportent bien, en revanche DragonflyBSD ne semble pas aimer VMware. Parfois le boot n'aboutit pas, parfois le système se freeze. A l'heure où j'écris ce billet, le serveur Jabber ne répond pas, alors que le mail oui. Ce qui me laisse penser que la VM Jabber a planté.

La gestion des ports (tous systèmes *BSD confondus) est à mon sens problématique, surtout lors de l'installation d'un logiciel qui en remplace un autre dans le système de base (Postfix pour Sendmail par exemple). DragonflyBSD embarque pkgin qui facilite l'installation mais pas la configuration. Cas concret : j'ai installé Postfix sur DragonflyBSD pour remplacer Sendmail (car je ne le connais pas du tout). La configuration s'est bien passé, la réception des mails fonctionne. En revanche en installant fetchmail je me suis rendu compte que le système s'appuyait sur Sendmail. Or comme ce dernier n'est pas configuré, les messages ont été envoyés dans une dimension parallèle.

Une distribution Linux sous forme de paquets RPM ou DEB me semble donc bien plus propre que la séparation "world" et "port" que l'on trouve sous FreeBSD et les autres. Sous Debian l'installation de Postfix retire complètement Exim les risques de confusion sont donc réduits. Sous FreeBSD et dérivés, l'impossibilité de retirer Sendmail (sauf par recompilation du world avec le bon src.conf) peut au contraire poser des problèmes.

Je dois quand même dire que Pkgin est un excellent outil qui permet d'avoir une vraie gestion des paquets et de leur mises à jour. Étant implémenté dans NetBSD et DragonflyBSD il est amené à évoluer assez rapidement. Quelques exemples d'utilisation :

# pkgin update
# pkgin search postfix
# pkgin install postfix
# pkgin upgrade

Si on s'en tient au système de base, tout va beaucoup mieux. L'implémentation de Bind sous FreeBSD est très correct et chrootée par défaut. Les fichiers sont situés dans /var/named/etc/namedb mais vus par l'application comme /etc/namedb. La mise en place de mon fichier de zone s'est bien passé, ainsi que l'ajout d'un fichier named.conf.local appelé par un Include (oui je suis trop habitué à Debian et aux fichiers de configuration modulaires).

A bientôt pour de nouvelles aventures.

DragonflyBSD est un système d'exploitation visant à obtenir de meilleures performances que FreeBSD dont il est dérivé. C'est probablement l'un des plus discrets à côté de FreeBSD, NetBSD et OpenBSD et je n'y avais jamais touché avant que ce journal sur linuxfr ne m'en donne envie.

Les développeurs sont partis de FreeBSD 4 et ont opté pour des choix techniques différents dans la gestion des processeurs multiples (SMP). Ils ont aussi lancé un nouveau système de fichiers HAMMER offrant plus de souplesse et de performances qu'UFS.

Dans cet aperçu je me contenterai de l'aspect serveur, qui est pour moi le plus intéressant. J'ajouterai que ce n'est pas un retour d'expérience, je ne l'ai pas mis en production (ça viendra peut-être), mais juste un premier essai.

Installation

On peut difficilement faire plus simple puisqu'il s'agit d'une suite de menus permettant de partitionner son disque en choisissant le système de fichiers UFS ou bien HAMMER. Pas de choix dans les sets d'installation, tout va à l'essentiel. Il est tout de même possible de configurer son clavier, horloge, réseau, mot de passe root.

Sources du système et logiciels tiers

DragonflyBSD, tout comme les autres systèmes *BSD, est en fait un système d'exploitation avec plusieurs logiciels intégrés dans les branches de développement qui reçoivent du support et des correctifs (SSH, sendmail...). Si l'utilisateur souhaite installer un autre logiciel (par exemple Dovecot) il peut le récupérer par l’intermédiaire de pkgsrc. Un logiciel ne faisant pas partie du système ne reçoit pas de patchs de l'équipe de développement, il s'agit en fait de la version "normale" (vanilla) avec un jeu de scripts permettant le lancement sur le système.

Les sources du système servent pour les mises à jour et la compilation de pilotes ou de certains outils. Elles ne sont pas fournies sur CD mais on peut les télécharger en entrant tout simplement la commande suivante :

cd /usr
make src-create

Pour les logiciels additionnels, DragonflyBSD utilise pkgsrc, issu de NetBSD, contrairement à FreeBSD qui utilise les ports. Au final le principe reste tout de même plus ou moins indentique. Pour récupérer pkgsrc, la commande est la suivante :

cd /usr
make pkgsrc-create

J'aime bien ce principe qui est assez simple pour récupérer les sources ! Notez cependant que la documentation recommande de passer par les packages précompilés ou bien par pkgin (gestionnaire de paquets un peu plus abouti).

Les mises à jour du système se font par compilation, il faut tout d'abord récupérer les sources puis lancer un buildworld suivi des commandes suivantes qui vont bien, comme pour FreeBSD.

Administration

DragonflyBSD utilise un fichier rc.conf dans lequel on indique les paramètres du système (nom d'hôte, réseau...) ainsi que les services à démarrer. Rien de neuf de ce côté, mais c'est donc simple et efficace.

Pour gérer les services, il faut invoquer les scripts rc. Par exemple, pour lancer le daemon ssh :

# /etc/rc.d/sshd start

On peut automatiser le démarrage de sshd en ajoutant dans notre rc.conf la ligne suivante :

sshd_enabled="yes"

On garde un fonctionnement et une administration faciles à comprendre, à la portée de tous. Les habitués des systèmes *BSD ne seront pas dépaysés.

Difficultés

J'ai eu beaucoup de mal à récupérer pkgsrc, car pour une raison étrange le système arrivait à court de mémoire et de swap. J'avais pourtant respectivement 1GB et 2GB, ce qui me semble largement suffisant pour un système en mode texte.

Comme je faisais mes tests sous VMware je suis passé sous VirtualBox mais là encore le problème s'est reproduit.

Je suis allé faire un tour sur le salon IRC de dragonflybsd pour y exposer mon problème, et on m'a conseillé d'éditer /usr/Makefile pour y commenter les lignes contenant la commande :

git gc --aggressive

Et le problème est résolu.

Conclusion

Le système est globalement très proche de FreeBSD mais apporte une valeur ajoutée sur beaucoup de composants. Il est simple à utiliser et à administrer. Un excellent choix pour un serveur, j'espère avoir un jour l'occasion de travailler avec et d'en apprendre plus.

Cela va bientôt faire 3 mois que j'utilise pfSense, un système d'exploitation FreeBSD orienté routeur. En 2011 j'avais déjà rédigé un article dessus, mais depuis Juillet 2012 je l'ai mis en "production" avec fonctionnement 24h/24 et conditions réelles. Plusieurs points m'ont particulièrement plu dans pfSense, je vais les décrire ci-dessous.

Voici les fonctionnalités que j'exploite actuellement :

• NAT et PAT
• Firewall (DMZ)
• Serveur DHCP
• Client OpenVPN
• Routes statiques
• 3 VLAN taggés sur un unique port
• Casé sur une carte CF
• 4 postes utilisateurs sur le VLAN30, 4 serveurs sur le VLAN20 (dmz)

Notez qu'il y en a de nombreuses autres que je n'utilise pas : serveur NTP, DNS, relai DHCP, IPSec, la liste est longue...

Fiabilité

Pour l'instant, 79 jours d'uptime, ça peut paraître peu mais comme je l'ai dit précédemment cela ne fait que 3 mois. Les derniers redémarrages ont été volontaires pour des opérations de mise à jour ou des coupures en cas d'orage. Il faut aussi comparer cela à une merdebox domestique qui nécessite un reboot quasi journalier pour rétablir l'accès à internet. Bref, pfSense c'est fiable, ça tourne sans interruption.

Fonctionnalités

J'apprécie particulièrement que cette petite boite noire (Alix 1.d) soit capable de gérer à elle toute seule l'intégralité du réseau. J'ai ainsi pu y "greffer" mon VPN, mais aussi un serveur DHCP. Et les autres points appréciables concernent les outils de diagnostic. On peut faire des ping, visualiser les tables de routage, arp, traceroute, et il y a même un sniffeur de réseau réglable sur plusieurs niveaux de verbosité.

Simplicité

Tout est bien organisé, facile à trouver et à utiliser. Les changements sont pris en compte sans devoir redémarrer le routeur (là encore, comparaison aux box domestiques) ce qui est appréciable. Les tableaux récapitulatifs des règles de parefeu sont assez bien pensés. La configuration peut être exportée dans un fichier XML si vous désirez "formater" la machine (pour une mise à jour par exemple).

Conclusion

Je ne regrette pas le choix de pfSense comme solution pour gérer mon réseau :D toutes les qualités que l'on peut rechercher y sont, avec la souplesse, la simplicité et la fiabilité. C'est une appliance excellente qui n'est pas prête de me lâcher !

J'ai installé FreeBSD 9.1RC sur un ordinateur portable équipé d'un processeur Sandy Bridge (puce graphique intégrée dedans, Intel® HD Graphics 3000). Les pilotes graphiques Intel sont très bien réputés car ils sont libres, à jour, et développés par le constructeur ! Que demander de mieux ?

C'est donc avec une (très) grande surprise que j'ai découvert que les puces graphiques Intel ne sont pas supportées sur FreeBSD. Si j'en crois cet article de Phoronix, la raison est qu'Intel ne travaille qu'en KMS (Kernel Mode Setting), disponible uniquement sur Linux. Donc, pour FreeBSD, toute machine tournant sur un processeur graphique Intel fonctionne sur le pilote vesa en 1024x768... et je ne parle pas de l'accélération 2D et 3D. Heureusement(?), FreeBSD est en train de développer son Kernel Mode Setting afin de pouvoir faire tourner les pilotes graphiques qui ne sont compatibles qu'avec ça. On peut trouver sur les forums une procédure pour activer KMS sur le système et compiler le pilote Intel qui va bien. Malheureusement c'est très long et le résultat est un peu aléatoire (j'ai réussi mais je n'avais plus de souris).

Etant donné qu'AMD ne fourni pas de pilotes pour FreeBSD, il semble que le seul "bon" constructeur sous cet OS soit Nvidia. En effet, même pour les cartes haut de gamme (GTX600), on trouve des pilotes FreeBSD.

Est-il acceptable de faire des pilotes pour Xorg fonctionnant uniquement sur Linux ? Cette dépendance est une des reproches que l'on fait à systemd et à Lennart Poettring [combo troll] pour ses propos sur les systèmes *BSD. La notion de "bon" constructeur ne se résume donc pas à la licence.

La première partie est assez subjective et traite de ce que je préfère et pas de ce qui est le meilleur. La seconde partie va tenter d'être un peu plus objective.

Top distributions desktop

1/ Fedora

Elle propose des paquets récents, des nouvelles technos, elle est stable, elle est belle. Personnellement j'utilise le spin KDE que je trouve excellent. Un autre point positif est l'implémentation de KVM et son écosystème (libvirt, virt-manager) qui est vraiment à la pointe par rapport aux autres.

2/ Ubuntu

Depuis la 12.04, Ubuntu s'approche vraiment de ce qu'elle devrait être : récente et stable.

3/ Arch

Même si je râle sur le prosélytisme omniprésent envers cette distribution, c'est une des meilleurs au niveau desktop. Son gestionnaire de paquets est rapide, les versions sont récentes, la configuration est simple.

Top distributions serveur

1/ Ubuntu server

Tout simplement parce que c'est une Debian avec 5 ans de mises à jour, et des paquets plus récents.

2/ Debian

Je reviendrai dessus sur le point suivant.

3/ CentOS

Elle est grosse, elle est stable, incassable, les dernières technologies de virtualisation y sont. Ce qui la pénalise un peu est le nombre faible de paquets, par exemple il n'y a pas Prosody. Elle est plus stricte au niveau des architectures processeur, je ne peux par exemple pas l'installer sur mon Alix car le CPU ne supporte pas les instructions 686.

Si devait n'en rester qu'une

J'ai cité au dessus les distributions que je préfère, mais si on me demande laquelle est objectivement la meilleure, je pense que c'est Debian. Il y a un nombre incroyable de paquets mais également d'architectures. Ajoutez à cela la philosophie de liberté, d'ouverture, de travail de qualité, et cela explique pourquoi je choisirai celle-là si je devais n'en garder qu'une.

Voici une petite bidouille pour transférer un serveur OpenBSD physique vers une machine virtuelle (VMware dans mon cas, mais cela devrait fonctionner avec tous).

A moins de faire une mauvaise commande, il n'y a aucun risque pour le serveur car on ne modifie rien dessus.

Etape 1 : installation de la VM

Ici, rien de particulier. Récupérez une ISO d'OpenBSD et effectuez l'installation dans une machine virtuelle. Configurez le réseau afin d'avoir un accès SSH.

Etape 2 : lister l'essentiel sur le serveur physique

Si je liste ce que contient mon serveur, voilà ce que j'obtiens :

$ ls /
altroot boot    bsd.mp  dev     home    obsd    sbin    sys     usr
bin     bsd     bsd.rd  etc     mnt     root    stand   tmp     var

Mon serveur fait tourner OpenSMTPD dont la config se trouve dans /etc et les messages dans /home. Vient ensuite dovecot installé à partir des ports, ses fichiers se situent dans /usr (et la config dans /etc). Et pour finir, prosody qui vient lui aussi des ports et exploite une base de données située dans /var. La liste des répertoires à transférer est donc :

• /etc
• /home
• /usr
• /var

Etape 3 : sauvegarde des répertoires

On utilise un bon vieux tar (vous pouvez utiliser la compression en rajoutant l'argument z) :

# tar -pcvf etc.tar /etc/
# tar -pcvf home.tar /home/
# tar -pcvf usr.tar /usr/
# tar -pcvf var.tar /var/

Attention à ne pas travailler dans le répertoire /home lorsque vous faites la deuxième commande ! Sinon cela ne terminera jamais (il va archiver le fichier d'archive nouvellement créé, etc).

Etape 4 : transfert des archives sur la VM

Le plus simple est d'utiliser le protocole sftp (actif du moment que sshd est actif sur vos systèmes). Cela peut-être fait depuis Filezilla sur une tierce machine (avec les comptes root).

Etape 5 : Rétablissement des utilisateurs

Pour des raisons de sécurité, le fichier contenant les utilisateurs du système et leurs mots de passe est en lecture seule, même pour root (voir cette page). Vous devez utiliser l'outil vipw pour les importer.

Ouvrez vipw sur l'ordinateur hôte, copiez toutes les lignes situées après la ligne "nobody", et collez-là à la suite dans le vipw de la VM (vous pouvez faire cette opération depuis un ordinateur tiers et des connexions SSH).

Etape 6 : installation sur la VM

La procédure est classique, sauf qu'il faut penser à sauvegarder le fichier fstab car le partitionnement peut différer :

# tar -pxvf var.tar -C /
# tar -pxvf usr.tar -C /
# tar -pxvf home.tar -C /
# cp /etc/fstab /root/
# tar -pxvf etc.tar -C /
# cp /root/fstab /etc/
# reboot

Pensez à revoir la configuration du rc.conf, notamment le nom d'hôte et le réseau qui peuvent différer.

Vous n'avez probablement pas échappé aux nombreuses actualités concernant Windows 8. Avec cet OS Microsoft va imposer par la force de nombreux changements ergonomiques. Les mots ne sont pas exagérés, car comme d'habitude toutes les machines du commerce seront vendues sous cet OS, il n'y aura pas de possibilité de revenir en arrière. Et si vous n'aimez pas leur interface Metro, tant pis pour vous, Microsoft est en train de tout faire pour bloquer les petits malins qui veulent restaurer le menu démarrer.

Windows 8 sera un Vista 2, tout le monde prédit un front de résistance des utilisateurs qui prendra du temps à se briser (mais ce sera le cas grâce à la vente liée). Il y aura donc une ouverture pour faire entrer Ubuntu dans les ordinateurs du grand public,tout comme en 2007-2008. Je pense aussi que l'autre entreprise qui va se frotter les mains c'est Apple, ils ont parfaitement imposé leurs smartphones et tablettes, ce front anti-Windows leur permettra de boucler la boucle en vendant également des ordinateurs.

Il est certain que la plupart des utilisateurs vont préférer "downgrader" leur machine vers Windows 7 plutôt que se tourner vers Ubuntu, mais je prédis tout de même un afflux de nouveaux arrivants dans le monde Linux. Nous pourrons probablement le mesurer grâce aux install-party, aux journaux et à la blogosphère. Ubuntu 12.04 étant à mon sens plutôt réussie, surtout au niveau stabilité, il faut continuer dans ce sens pour pouvoir accueillir et satisfaire durablement ces futurs visiteurs.

J'étais parti pour porter mon serveur sur FreeBSD et remplacer la virtualisation par un système de jails. L'installation est simple, on a notamment tout une page sur la mise en place d'applications ainsi que des tutos permettant de combler les parties manquantes, comme la configuration du réseau.

Si tout cela se fait presque les doigts dans le nez, je me suis rapidement heurté à un problème de poids : l'impossibilité de faire fonctionner les jails avec un réseau virtuel. En gros toutes vos jails sont en bridge (en vrai c'est un alias) sur votre interface principale, ce qui peut causer des soucis dans plusieurs cas :

• Votre serveur a une IP publique (unique, impossible d'en faire un bridge/alias)
• Votre routeur est une Livebox qui refuse de rediriger en aveugler un port vers une IP (elle veut absolument un PC qu'elle connaît sur le réseau)

La fonctionnalité de réseau virtuel semble en développement mais nécessite des patchs sur l'OS ainsi qu'une configuration fastidieuse... sur les forums nous apprenons également qu'il y a des fuites de mémoire (on parle d'une fonctionnalité expérimentale, rappelons-le).

Etant donné que je dispose d'une Livebox comme routeur, il m'est impossible de rediriger les ports extérieurs vers les jail. Donc mon plan tombe à l'eau, il ne me reste plus qu'à me tourner vers une solution Linux+LXC qui semble bien plus permissive sur ce point.

Pour info, la compilation de FreeBSD au complet sur un AMD Geode (500Mhz) prend environ 20 heures.

Je dispose d'un ordinateur portable depuis début 2007, ce qui n'est pas si vieux, et quand on regarde sa config matérielle : Intel double coeur à 2GHz, 3GB de mémoire, on se conforte dans l'idée qu'il est loin d'être un ordinosaure.

Et pourtant depuis 2007 j'ai tourné sur beaucoup de distributions Linux, une des premières était debian etch, en version testing si je me rappelle bien. J'étais Pro-Gnome convaincu, et si on en était resté à la version 2 je le serais encore aujourd'hui. A l'époque je râlais quand le système, en 64 bits, consommait 700MB de mémoire, je trouvais que c'était beaucoup. Aujourd'hui je réalise à quel point les OS sont devenus lourds, puisque 700 correspond à ce qui est utilisé à froid au démarrage, et la charge peut gonfler l'utilisation jusqu'à 1,5GB.

Je me rends compte que mon ordinateur est quasiment obsolète au bout de 4 ans, alors que mon utilisation majoritairement bureautique et loisirs n'a pas changé. Pourquoi pouvais-je jouir d'un bureau fluide avec Gnome 2 et Compiz il y a longtemps, et pourquoi ça rame maintenant sur KDE sans même activer les effets ?

Le constat est le même sur mon shitop, nom que j'ai donné à mon netbook Poulsbo, puisqu'il est impossible d'y caser une distribution Linux qui ne rame pas, le seul OS adapté étant visiblement Windows 7 Starter. On a beaucoup critiqué cet OS pour ses limitations, mais en terme de performances sur du matériel faible, il est excellent.

Mon inquiétude se situe justement dans le fait qu'on peut dire que Windows est plus léger que "Linux", à moins de s'amuser à configurer du Openbox et des logiciels allégés ce qui n'est pas vraiment ma tasse de thé. J'aime, et je pense que c'est le cas de beaucoup d'utilisateurs, avoir un système prêt à l'emploi, sur lequel tout est correctement intégré. Si je dois renouveler mon matériel tous les 5 ans pour faire de la bureautique les choses vont commencer à coincer.

Comme tout le monde j'ai téléchargé la version preview de Windows 8, afin de voir à quoi cela ressemble. Ma première impression est que l'ISO est abusivement lourde, 3,3GB pour un système qui a la même tronche que Android, alors que ce dernier tient sur 100MB pour les versions les plus lourdes, on se demande ce que Microsoft met dedans. Windows 8, l'OS qui n'est pas garanti sans plomb.

L'interface Metro est un peu déroutante, ce n'est pas vraiment conçu pour les PC mais plutôt pour les interfaces tactiles, ou encore les media center. Ce qui choque à première vue est que les applications sont 100% Microsoft. Entendez par là que le client de messagerie instantanée ne se connecte bien entendu qu'à Windows Live, ne comptez pas utiliser un compte Facebook et encore moins Jabber; l'outil de lecture vidéo est un itunes-like avec un magasin de VOD; le lecteur de musique refuse de démarrer si on a pas appairé son OS avec un compte Microsoft.

Je me rends compte que si j'étais utilisateur de Windows 8, aucune application ne conviendrait à mes besoins, il y a donc beaucoup de choses qui prennent de la place pour rien. Heureusement il est possible de revenir à l'ancien bureau, quoi que le bouton "Démarrer" a disparu, c'est un espace vide dans lequel le fait de cliquer relance l'interface Metro. Avec un clic droit il est possible de retrouver le panneau de configuration, l'invite de commandes, la fonction "Exécuter".

Mon impression sur Windows 8 est que j'espère ne jamais avoir à travailler dessus sur un PC, il n'est simplement pas adapté. Windows 7 pour les PC, Windows 8 pour les tablettes. Je me rappelle aussi des procès pour abus de position dominante lancés par l'Europe contre Microsoft, à cause d'Internet Explorer et Media Player. Avec Windows 8 on replonge en plein dedans car toutes les applications proposées de base font appel aux services Microsoft et requièrent même un compte chez eux.

Si vous n'utilisez pas les services Microsoft en ligne, et si vous aimez le multitâches, restez sur Windows 7, il n'y a même pas à hésiter.

Après le buzz sur la montée en flèche de Linux Mint au détriment de Ubuntu, difficile d'ignorer la réputation désastreuse de Unity, la nouvelle interface développée par Canonical. Il y a plusieurs raisons pour ne pas aimer une interface selon moi, j'en ai retenu 4 :

• Ce n'est pas mature : ça plante, c'est lent, les applications ne sont pas intégrées... il faut donc revenir plus tard. C'était le cas avec les premières versions de KDE 4.
• Je ne suis pas d'accord avec les choix ergonomiques qui ont été faits : en gros ça ne convient pas à mon usage ou mes habitudes. C'est mon cas vis à vis de Gnome-Shell.
• Les gens sont stupides et trop bornés pour accepter de changer leurs habitudes : ah pardon, ce n'est pas une vraie raison mais une excuse employée par les développeurs et pas mal de blogueurs.
• Parce saymal : il y a 3 lignes de code proprio ou un des développeurs a dit un gros mot sur la mailing list, il faut donc boycotter. No comment.

Pour ma part mon expérience avec Unity c'était tout d'abord la première solution : elle ne fonctionnait pas sur mon ordinateur, je m'étais donc rabattu sur Kubuntu. Mais récemment j'ai récupéré une iso daily live de Ubuntu 12.04 (actuellement en alpha) pour retenter ma chance.

Et je ne comprends pas pourquoi on s'acharne autant sur Unity, certes c'est différent, mais bien loin d'être aussi déroutant que Gnome-Shell qui est par exemple incapable de se dépêtrer si on a plusieurs fenêtres de Gajim. Là sur Unity c'est possible, la liste des fenêtres actives est maintenant intégrée dans les lanceurs sur la gauche, à la manière du Dock d'OSX pour ceux qui aiment les gros mots. La barre de menu des applications apparait tout en haut de l'écran, là encore comme sur l'OS d'Apple.

Le lancement des applications peut aussi se faire en tapant le nom de ce qu'on veut, par exemple le fait d'entrer "pid" proposera Pidgin (il suffit de valider au clavier ou à la souris). C'est un comportement similaire à KDE (avec alt+f2) ou les autres environnements qui ont des systèmes similaires à Gnome-Do ou Synapse.

Unity 3D fonctionne plutôt bien sur mon ATI X1400, preuve que ça doit être pas trop mal codé. Par contre si vous prévoyez d'utiliser des applications comme Wine, qui ont besoin d'accélération graphique, privilégiez Unity 2D la différence sera flagrante (se règle sur l'écran de login).

Je conçois qu'on puisse ne pas aimer Unity, pour ses simplifications et son orientation "Apple", mais je ne comprends pas pourquoi on en fait tout un buzz et pourquoi Gnome-Shell récolte majoritairement des félicitations alors qu'il casse lui aussi toutes les habitudes des gens et simplifie (souvent trop) le bureau. La réponse selon moi est la 4e de ce que je listais en haut, Canonical saymal, alors que Gnome c'est artisanal, c'est libre, c'est communautaire et pas une vilaine entreprise capitaliste, donc c'est bien.

J'ai gardé pour le moment Unity sur mon ordinateur, car je n'ai pas de problème avec, et aussi car le mode 2D me permet d'avoir de meilleures performances sur Wine+KOTOR qu'avec KDE. Il y a bien entendu des choses que je n'aime pas, comme Empathy le logiciel qui ressemble à une version alpha depuis des années, ou des défauts de jeunesse comme le "panneau de configuration" qui n'a pas de bouton précédent lorsque l'on navigue dans les différentes options.

Au passage j'ai découvert la logithèque ubuntu, que je ne connaissais pas car j'utilise toujours apt-get pour gérer mes logiciels. Quelle surprise de constater que cela ressemble au market android, avec des applications notées par les utilisateurs à l'aide de petites étoiles, des classements par nouveauté, etc. Là encore on peut critiquer ce point, mais selon moi c'est une excellente idée lorsqu'on vise le grand public. La description est complète, il n'y a pas de nom bizarre de paquet, et il suffit d'un clic.

En conclusion je dirais que mon retour sur "ubuntu de base" s'est plutôt bien déroulé, je n'ai pas encore eu de surprise négative pour le moment, et je pense que les choix de Canonical sont les bons pour atteindre son objectif qui est simplifier l'expérience utilisateur, s'aligner sur ce qui se fait ailleurs.

OpenBSD 5.0 est sorti il y a peu de temps, apportant des nouveautés et mises à jour. Ce système relativement petit en comparaison d'autres et discret dans l'actualité est néanmoins l'un des plus importants car on lui doit notamment OpenSSH qui est aujourd'hui utilisé partout. OpenBSD est réputé pour son intransigeance sur la liberté des logiciels et leur sécurité avec notamment des audits de code.

Installation

La phase d'installation est très simple puisqu'on a affaire à un assistant qui pose des questions (en mode texte) auxquelles il faut répondre. Nom d'hôte, réseau, partitionnement... c'est vraiment très rapide et très simple. A la fin on indique aussi les "sets" à récupérer.

Découverte

Réseau

La configuration du réseau est effectuée par l'installeur néanmoins il est intéressant d'y jeter un coup d'œil. Contrairement à NetBSD, qui utilise le rc.conf, OpenBSD fonctionne sur un système de fichiers hostname.interface. Par exemple, pour l'interface re0 on aura /etc/hostname.re0. La passerelle par défaut doit être ajoutée dans /etc/mygate et les DNS dans /etc/resolv.conf.

Daemons

Le fichier /etc/rc.conf est utilisé pour contrôler les daemons. Il fonctionne avec un système de "flags". Par exemple, dhcpd_flags="" provoquera l'activation du daemon dhcpd au démarrage. Si on en veut pas, il faut spécifier dhcpd_flags=NO. Les scripts des différents daemons sont situés dans /etc/rc.d.

Taille

Le système de base, sans les librairies X11, frôle les 500 Mo d'espace disque ce qui peut sembler un peu beaucoup comparé aux 80 Mo de NetBSD. Mais les objectifs ne sont pas les mêmes.

# uname -a
OpenBSD vmbox.my.domain 5.0 GENERIC#53 amd64
# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/wd0a     1005M   41.4M    913M     4%    /
/dev/wd0k     13.7G   68.0K   13.1G     0%    /home
/dev/wd0d      2.1G    2.0K    2.0G     0%    /tmp
/dev/wd0f      2.0G    443M    1.4G    23%    /usr
/dev/wd0g     1005M    2.0K    955M     0%    /usr/X11R6
/dev/wd0h      4.4G    9.0M    4.2G     0%    /usr/local
/dev/wd0j      2.0G    2.0K    1.9G     0%    /usr/obj
/dev/wd0i      1.5G    2.0K    1.4G     0%    /usr/src
/dev/wd0e      3.3G    4.0M    3.1G     0%    /var
# free

Packages et ports

Tout comme FreeBSD et NetBSD, OpenBSD dispose de son système de ports permettant d'installer des logiciels tiers. Des packages sont également mis à disposition sur des miroirs HTTP et FTP pour installer sans devoir compiler. On utilise toujours la variable PKG_PATH et l'outil pkg_add. Pas de dépaysement de ce côté.

Pratique

Installer un système et 3 paquets est insuffisant pour en découvrir toutes les fonctionnalités, dans les prochains jours je vais tenter l'installation sur un serveur avec daemon SMTP et IMAP. Cela me permettra de me familiariser avec l'administration.