En 2011 je postais un article pour rendre hommage à Opera, que je trouvais injustement délaissé alors qu'il était novateur dans plusieurs domaines. En 2014, mon avis a changé.

Opera a lâché son propre moteur de rendu presto pour adopter webkit, comme 99% des navigateurs existants, et en a profité pour revoir son interface, abandonner des fonctionnalités comme le client mail, et accessoirement le support Linux (qui reste cantonné à la version 12). Le résultat ? Un navigateur banal selon moi, avec une interface plutôt chargée et une navigation beaucoup moins fluide qu'avant.

C'est triste à dire, mais Opera devient un énième navigateur basé sur Webkit, en retard sur la concurrence, et seul dans son coin puisque contrairement à Firefox et Chrome, il n'est pas libre et n'est pas distribué sur Linux. Les commentaires de cet article sur nextinpact semblent indiquer que je ne suis pas le seul à déplorer cette suite de mauvais choix chez Opera.

Devant le poids de Firefox et surtout Chrome qui prolifère sur les ordinateurs en usant de moyens peu éthiques, il est peu probable qu'Opera existe encore longtemps, car incapable de retenir ses adeptes et de séduire de nouveaux utilisateurs.

Bientôt Chrome deviendra le nouvel Internet Explorer 6, c'est à dire le navigateur dominant à plus de 90% les ordinateurs de la planète, suivi par Firefox et Safari. Opera et les autres auront disparu, ou seront anecdotiques, et nous subirons à nouveau les joies d'un monopole qui sera probablement ponctué par l'obligation d'utiliser le réseau Google+. L'avenir n'est pas radieux...

Pkgng est un gestionnaire de paquets moderne pour FreeBSD censé mieux gérer l'installation, l'upgrade et la désinstallation des paquets tiers. Ma réaction, comme beaucoup fut "un apt-get like sur FreeBSD, enfin !". Oui, mais il faut différentier l'outil de gestion des paquets, et les dépôts binaires eux-même.

En effet, FreeBSD est un système d'exploitation composé d'un ensemble de logiciels. Mais quand on veut un autre logiciel, par exemple dovecot, historiquement on doit utiliser les ports. Les ports, c'est une arborescence contenant des scripts qui vont télécharger les sources et compiler les logiciels et leurs dépendances. Au moment de compiler, une interface en ncurses va proposer à l'utilisateur de sélectionner les options dont il a besoin ou non. Par exemple, pour dovecot, on peut activer ou non le support de MySQL.

FreeBSD fourni également des dépôts dans lesquels ces logiciels tiers sont déjà compilés, on gagne ainsi pas mal de temps. Mais ces versions binaires ne permettent pas de choisir les options. Par exemple, dovecot n'a pas le support de MySQL. Que peut-on faire si on en a besoin ? Eh bien on en revient aux ports, et on compile.

Debian et apt-get ont résolu ce problème en découpant en plusieurs modules un paquet. Par exemple, pour dovecot, il y a plusieurs paquets, comme on le voit ici. Le paquet dovecot va installer la version basique. Si on veut le support mysql, on installe en plus le paquet dovecot-mysql.

Pkgng et les dépôts de logiciels binaires se contentent de fournir des versions compilées des ports. Il n'y a aucune gestion des options, probablement parce que ces systèmes sont conçus pour pouvoir utiliser l'un et l'autre en même temps. Mais en pratique c'est problématique. Il y a le même problème avec PHP, si on veut php-fpm, c'est une option à activer lors de la compilation de php55. La version de php55 qui vient des dépôts binaires ne supporte pas php-fpm.

Il ne faut donc pas se faire d'illusions, pkgng ne rend pas FreeBSD aussi simple que Debian quand il s'agit de gérer des paquets. Dans la pratique, on utilise encore beaucoup les ports.

Pour alimenter un peu mon blog, voici un petit retour d'expérience sur la mise en place d'un serveur Minecraft chez moi. Bon tout d'abord il y a des pré requis techniques, il faut un bon CPU et 2GB de RAM ou plus, car java le jeu est très gourmand. Chez moi j'utilise des jails sur mon serveur FreeBSD afin de tout séparer proprement, et j'utilise les ports car les packages binaires sur les dépôts officiels ne me conviennent pas.

Création de la jail

Je créé à l'aide de ezjail-admin une jail nommée minecraft avec l'IP 192.168.0.7 :

(hôte)# ezjail-admin create minecraft 're0|192.168.0.7'

Je démarre cette jail, je me connecte dessus afin de paramétrer le mot de passe root, puis je ferme tout :

(hôte) # ezjail-admin start minecraft
(hôte) # ezjail-admin console minecraft
(minecraft) # passwd
(minecraft) # exit
(hôte) exit

Je me connecte en SSH sur ma jail (si vous voulez vous connecter en root il faut mettre le PermitRootLogin à yes dans /etc/ssh/sshd_config de la jail au préalable) :

$ ssh root@192.168.0.7

J'installe pkg et portmaster, deux outils pour gérer mes ports plus facilement :

(minecraft) # cd /usr/ports/ports-mgmt/pkg
(minecraft) # make install clean
(minecraft) # pkg2ng
(minecraft) # cd /usr/ports/ports-mgmt/portmaster
(minecraft) # make install clean

Je paramètre mon make.conf :

(minecraft) # vi /etc/make.conf
WRKDIRPREFIX=           /var/ports
DISTDIR=                /var/ports/distfiles
PACKAGES=               /var/ports/packages
INDEXDIR=               /var/ports
WITHOUT_X11=            yes
OPTIONS_UNSET=X11
WITH_PKGNG=             yes

Notez qu'il est possible de modifier le template des jails, afin que les nouvelles jails aient automatiquement certains paramètres. Exemple depuis l'hôte : /usr/jails/newjail/etc/ssh/sshd_config.

Installation de Java

J'utilise OpenJDK7, car la version 8 est encore déconseillée aux utilisateurs finaux, et la compilation sera plus longue (car il va compiler aussi la 7). Le paquet Java officiel est également disponible dans les ports mais il fait appel à la couche de compatibilité Linux. C'est donc plus simple d'utiliser OpenJDK7 qui est natif.

(minecraft) # cd /usr/ports/java/openjdk7/
(minecraft) # make install clean

La compilation va être plutôt longue. Je laisse les options par défaut.

Récupération et lancement du serveur Minecraft

Je télécharge le serveur Minecraft depuis le site officiel :

(minecraft) # cd /root
(minecraft) # fetch https://s3.amazonaws.com/Minecraft.Download/versions/1.7.9/minecraft_server.1.7.9.jar

Note : Pour un maximum de sécurité il est recommandé de créer un utilisateur minecraft, avec son propre dossier /home afin d'exécuter le jeu. Dans ce tutoriel, pour faire simple, et puisque nous sommes dans une jail dédiée, je passe cette étape et fais tout en root.

(minecraft) # java -Xmx1024M -Xms1024M -jar minecraft_server.1.7.9.jar nogui

Après quelques secondes la carte est générée, et il est possible de se connecter à ce serveur depuis un autre poste qui exécute Minecraft. Pour leses connexions de l'extérieur il faut penser à rediriger le port 25565 depuis le routeur.

Performances

La compilation de Java a pris plus de 4h sur mon serveur à base d'Atom 32 bits à 1,6GHz, un temps non négligeable ! Pour l'exécution du .jar, il est possible de diminuer les paramètres mémoire, car mon serveur n'a que 1GB de RAM, je ne peux donc pas allouer 1GB au jeu sous peine de le faire tomber. J'ai utilisé java -Xmx512M -Xms512M -jar minecraft_server.1.7.9.jar nogui. A l’exécution, la commande top m'a montré que le système est très sollicité, le CPU est en moyenne a 50% de charge, avec des pointes à 100%.

Lorsque je joue sur ce serveur, j'observe d'importantes latences, avec des blocs qui ne disparaissent que 1 seconde après avoir été cassés, en résumé ce n'est pas vraiment jouable. Un Atom 32 bits + 1GB de ram n'est donc pas suffisant pour supporter un serveur Minecraft.

Conclusion

Il est très facile de faire un serveur Minecraft sur FreeBSD, même dans une jail, par contre les pré requis techniques sont plutôt importants. Un CPU 64 bits double cœur pas trop vieux et 2GB de RAM ou plus sont recommandés, surtout si vous prévoyez d'accueillir une dizaine de joueurs.

Xubuntu, pourquoi pas. Je n'ai jamais été fan de Xfce vanilla, mais l'intégration dans Xubuntu est plutôt intéressante. Plus léger que KDE (surtout au lancement) et proche de l'esprit Gnome 2.

De plus la version 32 bits est assez légère et peut tenir sur des machines avec 1GB de ram, pratique pour redonner un coup de jeune aux vieilles bécanes (après la fin du support de Windows XP par exemple).

Xubuntu c'est bon, mangez-en.

Suite au rachat de SFR par Numéricable la grande question porte sur la stratégie de déploiement de la fibre qui sera utilisée. En effet Numéricable pose de la fibre dans les quartiers mais ne va pas jusqu'aux logements. La fibre s'arrête à un boitier, et les raccordements aux abonnés sont faits en utilisant le câble coaxial déjà en place (qui historiquement servait uniquement pour la diffusion de la télévision). C'est ce qu'on appelle le FTTLa, Fiber To The Last amplifier. Numéricable est le seul à faire du FTTLa parce qu'il dispose d'un réseau coaxial historique déjà en place. Les autres - Orange, SFR, Free - font parvenir la fibre optique jusqu'au logement de l'abonné, c'est ce qu'on appelle le FTTH, Fiber To The Home. L'opérateur Bouygues se contente jusqu'à présent de louer le réseau Numéricable, donc FTTLa.

Dans cette analyse on remarque que SFR déploie du FTTH alors que Numéricable préfère le FTTLa. La question est donc de savoir quelle technologie va être retenue ou privilégiée. D'un côté j'imagine mal Numéricable abandonner son réseau coaxial, sachant qu'il compte 1 million d'abonnés, plus 363 000 locataires Bouygues. De plus, pourquoi priver les personnes desservies par le coaxial d'un raccordement au FTTLa afin de booster leurs débits ? D'un autre côté, il ne semble pas envisageable de miser éternellement sur cette technologie. On imagine mal en 2014 une entreprise miser sur un réseau de cuivre, dont on connaît les limitations (atténuation avec la distance, usure...), et on imagine encore moins demander aux propriétaires de faire poser du câble coaxial dans leur logement neuf en plus de la fibre sous peine de ne pas être éligible. La force du FTTLa c'est avant tout le réseau coaxial historique.

Je ne parle pas des débits dans mon analyse. En effet à l'heure actuelle la FTTH est plus intéressante (1Gbps descendant, 500Mbps montants) que la FTTLa (200Mbps descendant, 10Mbps montants) mais il est probable que d'ici 2 ans cet écart soit réduit voir nul. En effet Numéricable prépare l'arrivée de débits plus importants, allant jusqu'à 1Gbps, et même de diffusion de tv en 4K (qui en plus n'empiète pas sur le débit internet). La question des débits est donc académique, le débat porte sur la technologie et la mutualisation.

J'espère donc que le FTTLa ne sera qu'un réseau de transition, tout comme le VDSL qui redonne de la vigueur à la paire de cuivre historique, en attendant le déploiement du FTTH, véritable réseau fibre ayant un avenir.