Pour faire un benchmark L4D2 sur PC ou Mac, il faut procéder à plusieurs manipulations que je ne vais pas détailler. Sachez juste qu'il faut activer la console développeur dans les préférences du jeu. Grace à cette console, vous allez pouvoir enregistrer une "demo", c'est à dire le script d'une partie. Ensuite il faut rejouer ce script avec différents réglages vidéo, et enregistrer le nombre d'images par seconde que votre machine génère pendant le rendu vidéo de cette "demo". C'est long et fastidieux, et il est impossible (et stupide) de tester tous les réglages vidéo. Si j'avais voulu faire une mesure pour chaque combinaison de réglages, sans changer la résolution, il aurait fallu que je fasse 2700 rendus de ma partie enregistrée.

J'ai donc pris le parti de lancer 5 fois la partie enregistrée, toujours dans la même résolution (1920x1200), et toujours avec les paramètres "effects" et "model" au maximum.

Voici le résultat sous la forme d'un graphique :

En rouge, est représenté le pourcentage d'images qui sont calculées à la vitesse de 60 images par seconde ou plus. Donc plus la proportion de rouge est grande, plus la carte video calcule vite le rendu de la partie. Et plus la proportion de vert et de bleu est faible, moins vous avez de ralentissements perceptibles dans le rafraîchissement de l'image. Ici le bleu (moins de 20 fps) est totalement absent.
Le jeu est capable d'afficher des chiffres de FPS ("frame per second") supérieurs à 60, mais le système intégré qui enregistre la répartition des FPS considère qu'à partir de 60 images par seconde il n'est plus utile de donner la répartition des FPS.
Ce n'est pas gênant, car in fine, les écrans actuels sont assez limités en terme de rafraîchissement, et que 60 images par seconde, c'est suffisant pour un affichage stéréoscopique à 30 images par seconde pour chaque œil. Donc à partir de 60 FPS, même un joueur exigeant pourrait jouer avec des lunettes 3D confortablement.

On voit sur ce graphique qu'un réglage a énormément d'impact sur le nombre de FPS : la synchronisation verticale. Si la synchronisation verticale est activée, le jeu ne peut pas dépasser 60 images par secondes, et le nombre global de FPS est sensiblement réduit. Mais ce réglage garanti une certaine cohérence de l'affichage et prévient l'apparition d'artefacts graphiques qui peuvent dénaturer l'expérience du joueur. Si votre machine le permet, laissez la synchronisation verticale activée. Les réglages 3 et 4 montrent l'impact de la désactivation de cette synchronisation sur la répartition des FPS.

Je ne vais pas plus loin dans l'analyse, il est aisé de comparer chaque jeu de réglages en utilisant le graphique. Si vous souhaitez faire le même benchmark que moi exactement, il vous faut le script de la partie que j'ai enregistré (ZIP 3,6Mo). La partie dure environ 10 minutes. L'archive contient un fichier parish000.dem qui est le script de la partie, et un fichier parish000.vdm qui est un fichier texte contenant les commandes qui lancent l'enregistrement des FPS au début du rendu, et qui arrêtent l'enregistrement à la fin du rendu. Il faut placer ces deux fichiers dans /left 4 dead 2/left4dead2 (je ne donne pas le chemin complet il est différent sur Mac OS X et Windows).
Après avoir joué la partie sur votre machine, vous obtiendrez un fichier prof_c5m4_quarter.csv situé dans /left 4 dead 2/update/. Attention, ce fichier est écrasé à chaque lancement de la "demo".
Je vous renvoie vers les forums et les aides en ligne pour tous les détails techniques (comment lancer une "demo", etc.).

Addendum

À titre de comparaison, voici le même benchmark effectué sur un MacBook Pro (un portable donc), doté d'un Core Duo 2,8 GHz, de 8 Go de RAM DDR3, et d'une carte vidéo GeForce 9600M GT. La résolution est native : 1440x900. J'ai tenté de faire le test avec les réglages vidéo "recommandés" par le jeu, l'écriture du fichier de log des FPS a échoué, mais les résultats étaient de toute manière catastrophiques.

À gauche, un jeu de réglages "tout medium" avec antialiasing et filtering au minimum. Au centre, les mêmes réglages mais avec la synchronisation verticale désactivée. Enfin à droite le jeu de réglages "recommandés" par L4D2, mais avec la synchronisation verticale désactivée. Le résultat reste injouable, avec presque 75% des frames générées à moins de 20 fps.

Dans mon PowerMac G5, j'ai deux disques durs de 640 Go. Un pour travailler, et un pour les sauvegardes. Dans mon Mac Pro, j'ai un disque dur de 1 To, et trois emplacements libres.

J'ai décidé de :

• réinstaller un système personnalisé sur le Mac Pro (donc de reformater le disque fourni)
• monter les deux disques du G5 dans le Mac Pro, pour en récupérer les données
• poursuivre les sauvegardes Time Machine sur le Mac Pro, sans perdre l'historique du G5 (c'est le point le plus délicat)

Au cours de ce processus, l'ancien disque système du G5 va devenir le nouveau disque Time Machine du Mac Pro, et l'ancien disque Time Machine du G5 va devenir un disque de stockage de l'ancien système, le temps de terminer la migration.
Attention, si comme moi vous possédez une licence Adobe (genre CS3/4/5) n'oubliez pas au préalable de la désactiver sur votre ancienne machine, avant de démarrer votre migration.

Voici comment j'ai procédé :

1. Démontage des disques du G5, et remontage dans le Mac Pro
2. Démarrage du Mac Pro sur le DVD d'installation, formatage du disque système, installation personnalisée du système
3. Récupération des données de mon compte utilisateur (et uniquement celles là) via l'assistant de migration. Ici, il est très important de savoir que les dossiers que vous aviez exclus de la sauvegarde Time Machine ne sont pas récupérés par l'assistant de migration, alors même qu'on les récupère à partir de l'ancien disque système, et pas de l'ancien disque Time Machine !
4. À ce stade, vous pouvez lancer les mises à jour de votre système, et désactiver Spotlight pour les deux disques provenant du G5
5. Création d'une image disque compressée de mon ancien disque système (prévoir plus d'une heure), montage de l'image disque pour vérifier qu'elle est utilisable (la première que j'ai faite n'était pas fonctionnelle)
6. Formatage de ce disque avec une table de partition GUID
7. Restauration de l'ancien disque Time Machine, vers le disque fraîchement formaté (compter aussi plus d'une heure) en utilisant l'utilitaire de disque
8. Formatage de l'ancien disque Time Machine avec une table de partition GUID
9. Comme l'adresse MAC de la machine a changé, il faut bricoler un peu la sauvegarde Time Machine pour pouvoir continuer à utiliser l'ancien historique. Cela nécessite d'utiliser une commande UNIX qui était fournie avec Mac OS X 10.5, mais qui n'est plus fournie avec Mac OS X 10.6. Cela tombe bien, car nous avons toujours l'ancien disque système (sous forme d'image disque)
10. Montage de l'image de l'ancien disque système
11. Lancement de l'utilitaire Terminal, et application de la méthode suivante ; Attention, fsaclctl n'existe pas en 10.6, il faut indiquer le chemin dans votre image disque (par exemple /Volumes/image_ancien_os/usr/sbin/fsaclctl )
12. Restauration de l'image disque de l'ancien système vers l'ancien disque Time Machine
13. À ce stade, j'ai un disque système à jour dans mon Mac Pro, un disque Time Machine opérationnel, formaté en GUID, et contenant l'historique du G5 et dans la continuité, l'historique du Mac Pro. J'ai un troisième disque dur, contenant mon ancien système, pour récupérer des documents et applications manuellement en cas de besoin
14. Édition des options de Time Machine, pour ne pas sauvegarder n'importe quoi
15. Réinstallation des applications tierces

Si vous suivez cette méthode, il vous appartient ensuite de faire le ménage dans votre ancien système pour gagner un peu de place, d'y récupérer ce que vous souhaitez et qui n'aurait pas été restauré, etc. Gardez à l'esprit que ce n'est pas une méthode universelle. C'est plus un canevas sur le quel vous pouvez broder votre propre migration, en retenant ce qui vous intéresse, en écartant ce qui ne vous convient pas, et en découvrant des choses aux quelles vous n'aviez pas pensé !

Notez que les manipulations interactives ne sont pas longues, mais des volumes importants de données peuvent amener l'ensemble de l'opération à durer une bonne demi-journée.
La méthode de récupération de l'ancienne sauvegarde Time Machine pour ne pas perdre l'historique peut sembler absconse, mais en réalité elle est logique et simple.

Pornography
It's simple: You can hold something that weighs 1.5 pounds in one hand.
-- Gizmodo

Trouvez l'alexandrin, clickez donc sur ce lien

Alors, combien d'heures dans 20175 minutes ? (iCal 3.0.8, Mac OS X 10.5.8)

Background

There is something quite messy in the Service Access Control Lists (SACLs) on Mac OS X 10.5: you just can't display the full users & groups list of a SACL in command line.
Basically, you can do this:

$ dscl . -read /Groups/com.apple.access_ssh
AppleMetaNodeLocation: /Local/Default
GeneratedUID: A7E16606-3C52-42B9-852E-D197C7598EA8
NestedGroups: 955F946A-7C9D-4D3E-B286-E16003380282 ABCDEFAB-CDEF-ABCD-EFAB-CD...
PrimaryGroupID: 101
RealName:
 Remote Login Group
RecordName: com.apple.access_ssh
RecordType: dsRecTypeStandard:Groups

As you can see, this SACL group com.apple.access_ssh has no direct members, only nested groups (NestedGroups key). So, in order to list users, you have to read the content of each nested group. But groups are only available by their name. So the first step is to find out group's names.
At this stage, you have no way to know if the target group is local or if it sits on a remote open directory server, so you must use the /Search path:

$ dscl /Search -search /Groups GeneratedUID 955F946A-7C9D-4D3E-B286-E16003380282
myadmins		GeneratedUID = (
    "955F946A-7C9D-4D3E-B286-E16003380282"
)

The second step is to list users of the group:

$ dscl /Search -read /Groups/myadmins GroupMembership
GroupMembership: admin01 admin02 user01 user02 ldapuser01

But guess what: this group might have more than just users, may be its NestedGroups key is not empty! So at this point, you must also check the NestedGroups value, and recursively follow each group GUID, until you find only users.
Think "huge groups", think "handfulls of nested groups", and watch your fingers as you're going thru dscl torments. You've figured it out: Mac OS X lacks a good command line tool for following a SACL tree of users and groups.

Here come's getsacls.sh

I won't promise you a killer command line tool with foolproof error and recursion handling, but I still believe I've designed a usable piece of shell script. Even if it looks like it's the worst code I've ever wrote (wich is not true, I've made things way uglier).
The source code is too long and messy to be just copy-pasted here, just follow this link to download the getsacls.sh script.

How to get getsacls.sh:
Just download the latest version from here.

How to install getsacls.sh:
Simply copy to your Mac OS X 10.5 server (or managed client). Somewhere in your $PATH should be fine. Then chmod +x the script, so that it can be executed.

How to configure getsacls.sh:
Defaults values should be ok, but if you really want to change something, open the script in your favorite editor, and find the "FEW USER TUNABLE MISCS" section. Edit at your own risks.

How to use getsacls.sh:
It's simple, you just have to launch it. It will then proceed with the parsing of every SACL on your local system.
DO NOT use the sh command to launch this script. getsacls.sh uses special escape sequences and command options that sh will not recognize. Just run:

$ getsacls.sh

If you want to parse only some SACLs, you can provide each SACL name at the command line:

$ getsacls.sh com.apple.access_ssh com.apple.access_loginwindow

Still, you should only use SACL names that exist on your local system.

The default output is "fancy", it uses bold, indentation, and a beach-ball cursor. If you want the "no fancy" mode, you can either edit the corresponding "tunable misc variable" or define FANCY=NO at launch time:

$ FANCY=NO getsacls.sh com.apple.access_ssh

This "no fancy" mode allows for later parsing.

Caveats/bug:
The script will not handle circular references. If your SACL uses nested groups in a circular way (group 1 -> group 2 -> group 1), the script will not stop.
When finding two or more similar users or groups (for example the local admin group and the open directory admin group), it will use only one of them, and that should be the local one.
The script uses SQLite3 as a backend, because bash is not good with arrays, and because I'm not good with PERL/Python/Ruby.

Sample "fancy" output:

com.apple.access_ssh
--------------------------------
   myadmins	/LDAPv3/192.168.128.34	955F946A-7C9D-4D3E-B286-...
     admin01	/Local/Default	9A7917D1-D8E7-49D6-8211-...
     admin02	/Local/Default	40D516A2-4D02-4C92-9505-...
     ldapuser01	/LDAPv3/ldap.example.com	ldapuser01_OUT_OF_OD
     ldapuser02	/LDAPv3/ldap.example.com	ldapuser02_OUT_OF_OD
     ldapuser03	/LDAPv3/ldap.example.com	ldapuser03_OUT_OF_OD
     user01	/LDAPv3/192.168.128.34	49EF9C64-D98B-11D8-BCFA-...
   admin	/Local/Default	ABCDEFAB-CDEF-ABCD-EFAB-...
     root	/Local/Default	FFFFEEEE-DDDD-CCCC-BBBB-...
     admin01	/Local/Default	9A7917D1-D8E7-49D6-8211-...
     admin02	/Local/Default	40D516A2-4D02-4C92-9505-...
     user01	/LDAPv3/192.168.128.34	49EF9C64-D98B-11D8-BCFA-...
================================

Sample "no fancy" output:

com.apple.access_ssh
--------------------------------
g 1 myadmins /LDAPv3/192.168.128.34 955F946A-7C9D-4D3E-B286-...
u 2 admin01 /Local/Default 9A7917D1-D8E7-49D6-8211-...
u 2 admin02 /Local/Default 40D516A2-4D02-4C92-9505-...
u 2 ldapuser01 /LDAPv3/ldap.example.com ldapuser01_OUT_OF_OD
u 2 ldapuser02 /LDAPv3/ldap.example.com ldapuser02_OUT_OF_OD
u 2 ldapuser03 /LDAPv3/ldap.example.com ldapuser03_OUT_OF_OD
u 2 user01 /LDAPv3/192.168.128.34 49EF9C64-D98B-11D8-BCFA-...
g 1 admin /Local/Default ABCDEFAB-CDEF-ABCD-EFAB-...
u 2 root /Local/Default FFFFEEEE-DDDD-CCCC-BBBB-...
u 2 admin01 /Local/Default 9A7917D1-D8E7-49D6-8211-...
u 2 admin02 /Local/Default 40D516A2-4D02-4C92-9505-...
u 2 user01 /LDAPv3/192.168.128.34 49EF9C64-D98B-11D8-BCFA-...
================================

Current version:
As of now, current version of getsacls.sh is 407 ($Id: getsacls.sh 407 2009-07-09 09:36:26Z patpro $). Next revisions will be listed here.

Update: $Id: getsacls.sh 409 2009-07-09 14:30:01Z patpro $
I've added some error handling for a rare case: when a user account lives on a LDAP server distinct from the Open Directory server, the GroupMembership field is not updated on the OD if the user account is destroyed on the LDAP. So according to the GroupMembership the user is still here, but according to the LDAP the user is nowhere to be found.

Update: $Id: getsacls.sh 412 2009-07-23 20:24:54Z patpro $
I'm forcing LC_NUMERIC in the beachball function, so that sleep 0.05 runs as expected even for people not using the dot as a decimal separator. Some cleanup.

Update: $Id: getsacls.sh 414 2009-08-03 10:33:30Z patpro $
Some cleanup and english corrections. Added some delay to the beatchball rotation so it's more enjoyable.

Feel free to comment, and to correct my english ;)

daily_output=root
weekly_output=root
monthly_output=root

La formule fonctionne parfaitement pour FreeBSD ou Mac OS X 10.4, mais pas pour Mac OS X Server 10.5.4. Launchd semble présenter un bug qui l'empêche de gérer la création du mail post-periodic. On lit alors cette erreur dans /var/log/system.log :

Jul 29 03:17:42 myserver com.apple.launchd[1] (com.apple.periodic-daily[...]):
  Stray process with PGID equal to this dead job: PID ... PPID 1 sendmail

C'est fâcheux, mais ne nous laissons pas abattre, car il existe une solution. Contrairement à ce qu'on peut lire à droite et à gauche, il ne faut pas modifier la configuration de Postfix, et laisser les références à Cyrus tranquilles. La solution est plutôt du côté de launchd. Certains ont mis en évidence que le mail sera bien généré si au lieu d'exécuter simplement le periodic, on exécute en plus et juste après une petite pause.
Après quelques tests, j'ai trouvé que c'est une solution assez satisfaisante. Sur le plan fonctionnel elle est parfaite, mais elle n'est pas idéale, car elle impose de modifier des fichiers fournis par Apple. Donc cette correction est susceptible d'être perdue au détour d'une mise à jour du système.

J'ai choisi de modifier les plist de launchd correspondant aux lancements de periodic :

[edit] : En réalité, la modification des plists com.apple.periodic* n'a pas donné le résultat escompté sur le terrain. Sur mon serveur de test, les mails de periodic étaient bien envoyés, mais sur mes serveurs de production, 3 machines sur 4 n'ont pas réussi à envoyer les mails pour le daily. Par ailleurs, le nombre d'erreurs dans les log système a sensiblement augmenté.

J'ai donc décidé de restaurer les fichiers com.apple.periodic* dans leur état d'origine et de modifier à la place la commande periodic. J'ai renommé /usr/sbin/periodic en /usr/sbin/periodic_orig, puis j'ai créé un script shell nommé /usr/sbin/periodic :

#!/bin/bash
/usr/sbin/periodic_orig $@
sleep 1

Ainsi, le lancement par launchd de la commande `periodic daily` va en réalité lancer `/usr/sbin/periodic_orig daily` (donc le script periodic original), puis va lancer `sleep 1`, ce qui suffit à launchd pour pouvoir générer le mail de résultat de periodic.

J'ai comme l'impression qu'avec launchd, on n'a pas fini d'en baver...

• MacBook Pro 15"
• Intel Core 2 Duo 2.4 GHz
• 2 Go de RAM
• 256 Mo de Vram
• disque de 200 Go, 5400 rpm
• numéro de série : W8810EZSYJX
• adresse MAC (ethernet) : 00:1e:c2:1c:e2:42

Faites passer le message !

J'ai bien sûr contacté macbook-fr.com pour que la machine soit inscrite dans la liste de machines volées. Et je vais contacter Apple d'ici lundi.

Ayant la chance d'avoir deux macs en 10.4 à porté de mains, j'ai choisi d'en migrer un vers Leopard. C'est le G5 qui s'y colle. Celui-là même dont je prends un soin quasi maniac et dont l'alimentation avait brûlé en mai dernier. Maintronic l'a réparé pour une petite fortune, tout en rayant profondément la carrosserie en plusieurs endroits et en me rendant la machine plus sale qu'avant. Bref.

Migrer un G5 qui a des années d'utilisation n'est pas forcément une chose immédiate. Ma stratégie habituelle est l'installation avec archivage et restauration des utilisateurs. Cela consiste à archiver l'ancien système au complet sur le disque, puis à installer un système tout neuf, et ensuite à restaurer les comptes utilisateurs, leurs documents et préférences, et à réinjecter les paramètres de l'ancien système dans le nouveau. Tout est géré automatiquement par le logiciel d'installation. C'est une méthode aussi efficace qu'élégante, et je l'utilise depuis qu'elle est disponible (10.1 je crois). Néanmoins, il y a un défaut essentiel : il faut disposer sur le disque d'un espace libre au moins égal à l'espace occupé avant l'installation. Avec l'augmentation galopante de la taille des fichiers, du stockage musical, et à cause de ma nouvelle fringale de photo numérique, nous voici en présence d'un disque dur de 160 Go dont seuls 45 Go sont libres. L'ajout d'un disque semble donc inéluctable.
Par ailleurs, j'ai constaté dans mes utilisations post-photographiques de Photoshop CS3 que les besoins de mémoire vive suivent de prêt ceux des périphériques de stockages. Ainsi, mes 1,5 Go de RAM ne sont plus suffisants.

Bilan des courses, la migration vers Leopard ne s'improvise pas, et coûte sensiblement plus cher que le logiciel lui-même. La facture monte à 216 euros : 115 euros pour Mac OS X 10.5 tarif "edu web", et 101 euros pour un disque SATA 160 Go et 2x512 Mo de mémoire DDR.

Une fois le nouveau disque installé et l'installation "vierge" de Leopard effectuée, le premier redémarrage déclenche le lancement de l'assistant de migration. Cet outil permet de sélectionner un périphérique (un autre disque, une machine branchée en firewire...) comme source de données à restaurer. Le G5 ayant deux emplacements de disque, j'ai bien sur laissé l'ancien disque dans la machine aux côtés du nouveau. Je choisi alors comme source cet ancien disque pour restaurer mes comptes utilisateurs avec leurs documents, les applications que j'avais installées, mes paramètres réseau, et d'autres babioles. Le logiciel se charge de copier les quelques 100 Go de données aux endroits ad hoc, avec les bonnes permissions unix. Un reboot final, et me voilà sous Mac OS X 10.5 avec un système configuré et des utilisateurs intacts.

L'avantage énorme de cette méthode coûteuse, c'est que mon installation de Tiger est intacte, et reste utilisable à 100% en cas de besoin. Quand ma migration sera vraiment terminée et que je pourrais faire une croix sur le contenu de mon ancien disque, ce dernier deviendra le receptacle tout désigné pour les sauvegardes de Time Machine.
Acheter un second disque pour migrer en douceur trouve donc une utilité bien au delà de la conservation immédiate de ses données. Cela permet aussi d'embrasser Leopard complètement, en adoptant d'emblée une de ses plus belles (et probablement plus utiles) nouveautés : Time Machine.