Un petit billet pour annoncer que je suis passé de FreeBSD à ArchLinux sur mon serveur@home. Pourquoi ? Pourquoi pas. J’avais envie de quelque chose de plus simple et aussi un peu de changer. Merci le disque dur externe de 1 To pour faire les sauvegardes nécessaires :)

Comme j’utilise déjà ArchLinux depuis quelques années sur mon netbook et mon autre machine, la transition s’est évidemment faite sans aucun accroc. Tout marche comme il faut, le seul point un peu délicat concernant l’installation : impossible d’installer grub1 sur des disques GPT, malgré ce que dit le wiki. Utiliser LVM et mdadm pour faire du raid5 et du raid1 a aussi été nouveau. Au revoir ZFS, et à bientôt j’espère… Ou btrfs, qui sait ?

Ayant acquis une certaine expérience dans ces deux OS, je me suis dit, pourquoi ne pas faire un petit comparatif des points noirs qui m’ennuient et des fonctionnalités que j’aime utiliser au quotidien ?

FreeBSD

• (+) Les jails : c’est tout simplement très pratique, cela permet d’isoler les différents services sur une machine pour des raisons de sécurité et de stabilité (si un composant ne fonctionne plus à cause d’une mauvaise manip ou d’une mise à jour foireuse, uniquement ce système là est affecté et pas les autres)
• (+) Excellente documentation, le handbook est la référence et les manpages sont aussi très détaillées ; par exemple security(7). Il faut également lire /etc/UPDATING avant de mettre à jour pour se renseigner les changements éventuels à faire manuellement.
• (+) On peut se faire un système 100% ZFS avec GPT, et c’est vraiment très bon.
• (+/-) Distinction entre le système de base (noyau, userland) et les logiciels tiers, autant dans l’organisation que dans le processus de mise à jour. Cela permet un contrôle plus fin des mises à jour mais est également plus complexe pour les néophytes.
• (++/-) Les ports : c’est pratique et il y a beaucoup de logiciels tiers disponibles facilement, mais malheureusement la compilation prend du temps s’il n’y a pas de paquets. Quand on souhaite installer un logiciel qui ne s’y trouve pas, c’est souvent bien plus difficile (à cause du fait que FreeBSD utilise comme préfixe /usr/local pour tous les logiciels tiers) à compiler.
• (-) Les mises à jour sont horriblement lentes, surtout avec CVS.
• (-) Lenteur de portupgrade(1). C’est un outil tiers facultatif mais qui facilite l’installation, la mise à jour et la gestion des ports.
• (-) Beaucoup de ports ne sont plus à jour depuis belle lurette. Par exemple games/stepmania-devel date de 2007.

ArchLinux

• (+) Beaucoup plus simple que FreeBSD à utiliser et à administrer.
• (+) Pacman est très rapide et fait bien son travail. De manière générale, le système de paquets est bien fait (groupes, providers, …). Les mises à jour sont très simples à effectuer.
• (+) Rolling release. C’est un très gros bonus. Au lieu d’avoir tout un tas de mises à jour d’un coup (une date définie arbitrairement), elles arrivent en même temps que leur publication en upstream. On a par exemple le nouveau noyau Linux dès qu’il est distribué. Cela permet de distiller les gros problèmes de mise à jour, c’est psychologiquement moins déprimant.
• (++) Système d’init basé sur BSD et non sur sysvinit. Ça rend la gestion des daemons et la création de tels scripts de démarrage beaucoup plus simple. Et quand on se casse pas la tête grâce à un système plus simple qui fournit les fonctionnalités dont j’ai besoin (qui honnêtement utilise les runlevels ?), c’est très bon.
• (++/-) L’AUR, permet la création de paquets tiers par la communauté, très pratique mais aucune garantie concernant leur sécurité ou leur pérennité. La plupart sont néanmoins bien maintenus ; on peut lire le PKGBUILD avant l’installation pour vérifier que rien de malveillant n’est fait.
• (+) Wiki correct.
• (-) Pas de jails, donc il faut faire très attention à la sécurité et à l’organisation de la machine.

Partager/enregistrer ce post

Seulement voila : le port stepmania date de 2007 et a de grandes chances de ne plus jamais être mis a jour. Il faut donc compiler à la main. C’est pas difficile du tout, sauf que là je suis apparemment le seul blaireau a avoir essayé, je n’ai rien touvé à ce sujet sur la toile. Comme j’ai réussi a avoir un jeu 100% utilisable, voici les étapes à suivre :

1. Étape préliminaire : assurez-vous de ne pas avoir pulseaudio d’installé. Si vous l’avez, StepMania va se connecter dessus au lieu d’utiliser le driver OSS, et croyez-moi, c’est injouable tellement il y a des artefacts audio et de la latence.

2. svn co https://svn.stepmania.com/svn/trunk/stepmania
   cd stepmania

3. Ajoutez « -liconv » à la ligne commencant par « LIBS = @LIBS@ -lpthread -lrt » dans src/Makefile.am
4. Appliquez le patch suivant pour compiler avec la version  1.4 de la libpng (et d’autres trucs pour que ça marche) :

   Index: src/RageSurface_Load_PNG.cpp
   ===================================================================
   --- src/RageSurface_Load_PNG.cpp	(revision 28355)
   +++ src/RageSurface_Load_PNG.cpp	(working copy)
   @@ -140,7 +140,7 @@
   
    	/* Expand grayscale images to the full 8 bits from 1, 2, or 4 bits/pixel */
    	if( color_type == PNG_COLOR_TYPE_GRAY && bit_depth < 8 )
   -		png_set_gray_1_2_4_to_8( png );
   +		png_set_expand_gray_1_2_4_to_8( png );
   
    	/* These are set for type == PALETTE. */
    	RageSurfaceColor colors[256];
   Index: src/arch/ArchHooks/ArchHooks_Unix.cpp
   ===================================================================
   --- src/arch/ArchHooks/ArchHooks_Unix.cpp	(revision 28355)
   +++ src/arch/ArchHooks/ArchHooks_Unix.cpp	(working copy)
   @@ -12,7 +12,9 @@
    #include "archutils/Unix/AssertionHandler.h"
    #include <unistd.h>
    #include <sys/time.h>
   +#include <sys/wait.h>
   
    #if defined(CRASH_HANDLER)
    #include "archutils/Unix/CrashHandler.h"
    #endif
   Index: src/RageSurface_Save_PNG.cpp
   ===================================================================
   --- src/RageSurface_Save_PNG.cpp	(revision 28355)
   +++ src/RageSurface_Save_PNG.cpp	(working copy)
   @@ -103,7 +103,7 @@
   
    	if( setjmp(pPng->jmpbuf) )
    	{
   -		png_destroy_read_struct( &pPng, &pInfo, png_infopp_NULL );
   +		png_destroy_read_struct( &pPng, &pInfo, NULL );
    		return false;
    	}

5. CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure --without-ffmpeg
   

   Et oui, comme d’habitude, les Linuxiens sont crades et rangent tout dans /usr, et ils n’ont même pas la délicatesse d’aller voir dans /usr/local. Scandaleux.

6. Installez textproc/gsed et changez dans src/Makefile chaque occurence de sed par gsed. Oui, c’est crade, c’est encore une histoire de syntaxe qui change.

7. make

8. ./src/stepmania

Et admirez le résultat. Aucun problème de latence (merci a l’autosync quand même).

Partager/enregistrer ce post

Le problème viendrait de :

1. Une carte de mauvaise qualité (Marvell 88E8053)
2. Un driver msk(4) peu testé et donc rempli de bugs potentiels

La seule façon de rétablir la connexion est de redémarrer la machine. Ce qui pose problème quand on a accès à la machine en question uniquement par SSH la majorité du temps…  J’ai donc réalisé un petit script (vraiment fait à la vite), faisant office de solution de secours, qui fait automatiquement redémarrer la machine si un watchdog timeout a été détécté. Cela permet de ne pas complètement bloquer l’accès via SSH.

Il suffit donc de lancer ce script en cronjob (effectué par root, bien sûr) :

#!/bin/sh

LOGFILE="/var/log/check_msk0"
DATE=`date`

CLEAN=`echo | grep zero`
LOGDATE=`date "+%b %d"`
TIMEOUTS=`cat /var/log/messages | grep "msk0: watchdog timeout" | tail | grep "$LOGDATE"`

if [ "$TIMEOUTS" = "$CLEAN" ]
then
 echo "$DATE OK, no timeouts." >> $LOGFILE
 echo OK.
else
 echo "$DATE WATCHDOG TIMEOUT, initiating reboot..." >> $LOGFILE
 echo Rebooting in 15 seconds. Press ^C to abort.
 sleep 15
 cp /var/log/messages /var/log/messages.timeout
 echo > /var/log/messages
 /sbin/reboot
fi

Inutile de préciser que j’ai commandé une nouvelle carte réseau, plus adaptée pour un serveur, et que cette solution est vraiment temporaire…

Partager/enregistrer ce post

Désolé pour la petite indisponibilité d’environ une semaine, la faute à un bloc d’alim qui a rendu l’âme…

Bon, j’en ai en attendant profité pour mettre à jour le système, avec :

• Une nouvelle alim, et un onduleur, pour ne pas avoir des soucis de FS corrompu
• Quatre disques de 1.5 TB en RAID10, grâce à ZFS. Ce système de fichiers est réellement génial.
• FreeBSD 8.0 avec Apache qui tourne dans une jail :-)

Partager/enregistrer ce post

Cependant, il n’a pas été porté sous FreeBSD, bien qu’il fonctionne bien sous Linux. Heureusement, grâce à quelques hacks simples, il est possible d’utiliser GoatTracker sous FreeBSD.

Avant tout, vérifiez que vous avez les ports/packages SDL d’installés, ainsi que GNU Make (“gmake”) différent du BSD Make par défaut (“make”). Il y a quelques différences dans la structure des Makefiles donc il faut utiliser l’un ou l’autre en fonction de ce qu’on compile.

Ensuite, procurez vous GoatTracker à cette adresse : http://covertbitops.c64.org/ (rubrique “Tools”).

Unzippez les sources dans un répertoire spécial crée à cette occasion, et placez vous dedans.

Avant de compiler GoatTracker, il faut compiler 2 outils qui seront nécessaires : datafile et dat2inc.

Placez vous donc dans le répertoire src/bme. Avant de lancer gmake, il faut modifier le Makefile car il est adapté à une machine Linux. Or, les machines Linux n’utilisent quasiment pas le préfixe /usr/local pour les includes. Le Makefile va donc chercher SDL_types.h dans /usr/include, alors qu’il est situé dans /usr/local/include. Pour corriger cela, il suffit d’ajouter ceci aux CFLAGS : -I/usr/local/include. Le makefile étant ici extrêmement simple, rajoutez cela aux deux appels à gcc.

Vous pouvez ensuite lancer la compilation avec gmake. Une fois que c’est terminé, vous devez copier ces deux exécutables produits dans votre $PATH, donc en gros vous devez copier les fichiers datafile et dat2inc dans /usr/local/bin.

Ensuite, placez vous dans le répertoire src. Cette fois, le Makefile est un peu plus complexe, vous devez rajouter -I/usr/local/include à la fin de la ligne CFLAGS= dans le fichier makefile.common. La compilation se passe ensuite sans problèmes.

Vous pouvez enfin jouer avec GoatTracker, l’exécutable étant situé dans le sous dossier linux/ et commencant par gt2. Enfin, voici une preuve que ça fonctionne :

Partager/enregistrer ce post

J’ai testé Fedora 10 pendant à peu près un mois, histoire de voir comment ça a évolué depuis ma dernière expérience Linux, et également pour voir à quel point FreeBSD déchire tout. Pourquoi ? Vous allez très vite comprendre.

On passe tout de suite au premier point qui fâche : PulseAudio. Je suis pas intrinsèquement “contre” ce dernier, mais son intégration est tellement bâclée et son développement est tellement actif encore qu’il serait préférable de ne pas l’utiliser par défaut, ou encore de nous laisser le choix à l’installation. PulseAudio est l’avenir de l’audio sous tous les sytèmes, peut-être. Mais dans le futur.

Déjà la doc est relativement pauvre. En dehors du PerfectSetup, on est un peu seul dans la nature. Donc quand ça merde, on l’est aussi. Le problème de PulseAudio c’est que plein de trucs ne fonctionnent pas encore avec. Certes, il a un mode d’émulation de pérphiériques io OSS via l’utilitaire padsp, ça marche de temps en temps mais il y a également des cas ou ça ne marche pas. Par exemple avec Wine, c’est une vraie plaie pour faire marcher l’audio. Quand à l’émulation alsa, n’en parlons pas, je n’ai jamais comrpis comment m’en servir et je n’ai jamais réussi à obtenir quelque chose de concluant avec ça.

Cependant, mes problèmes ne se sont pas arrêté là, car une fois que tout marchait “à peu près”, je me suis rendu compte que mon microphone n’étais pas reconnu. Et là, c’est le comble ! J’ai demandé de l’aide sur IRC, sur les forums, rien. Pourtant mon chipset est très très commun en ce moment (hda_intel).

Ensuite, un gros dernier problème en ce qui concerne la latence audio. Elle est bonne, mais cependant le son était très mauvais, avec beaucoup d’artefacts audio, ce qui est quand même dérangeant quand on est adepte de MAO.

Néanmoins, PulseAudio possède quelques fonctions qui auraient pu être sympas. Comme par exemple la diffusion RTP sur le réseau, qui permet par exemple de lire la musique de sa bibliothèque du PC du bureau avec MPD, et entrendre le son sortir par son ordinateur portable situé dans une autre pièce. Seulement, je n’ai jamais réussi à la faire fonctionner et ça n’était pas à cause du firewall ni des débits réseau (les deux PC étaient câblés directement via un hub).

Ce qui est dérangeant, c’est quand on pense qu’avec FreeBSD, tout ça fonctionne au poil, du premier coup et sans toucher à rien : un simple kldload snd_hda et paf, ça fait des chocapics. Basse latence dans MilkyTracker, et ce même si plusieurs applications utilisent actuellement le périphérique, microphone reconnu et volume bien confortable, pas de “device busy” au moindre pet de mouche, la zénitude totale quoi.

Passons maintenant à autre chose : le gestionnaire de paquets. Mon arbre de ports favori m’a réellement manqué, pas parce que PackageKit et yum sont mauvais mais qu’on arrive vite aux limites. Déjà, quand on veut compiler quelque chose, on doit installer une tonne de paquets de développement (en gros ce sont des fichiers .h) sinon ça ne compile pas. Jamais eu besoin de faire ça avec FreeBSD, étant donné que les ports utilisent les sources au lieu de paquets précompilés (bien que ça soit possible d’en installer aussi sous FreeBSD).

Ce qui était embêtant, c’était les base de données de rpm qui avaient tendance à se corrompre toutes seules, et à bloquer tous les threads jusqu’a ce qu’on supprime de fichiers bien particuliers, c’est relativement agaçant à force.

Sinon, à part ça, Fedora a quand même des trucs vraiment cool comme par exemple la possibilité d’installer les paquets i386 ou amd64 si on est en amd64, afin de lancer des programmes binaires compilés pour une architecture i386. Y’a aussi le démarrage graphique relativement rapide, un thème GNOME par défaut bien réussi et bien intégré. Enfin les goûts et les couleurs, …

Partager/enregistrer ce post