Desperate Switcher

No Line On The Horizon

noreply@blogger.com (Rominet.) — Thu, 05 Mar 2009 06:36:00 +0000

Christine Lagarde a déclaré que le gouvernement faisait "tout ce qui est nécessaire et possible pour maintenir la signature de la France, pour maintenir la notation triple A", qui constitue la meilleure note de solvabilité délivrée par les agences de notation.

Rappelez moi qui nous a mis dans la mouise, déjà ?

Lolggle

noreply@blogger.com (Rominet.) — Sat, 31 Jan 2009 14:47:00 +0000

WTF :

/o\ Oh my god, they killed THE INTERNET !

Leap Second

noreply@blogger.com (Rominet.) — Tue, 16 Dec 2008 08:09:00 +0000

Le 31 Décembre 2008 aura 86401 secondes. Enfin pour nous ce sera le 01/01/2009 à 01h00 : nous avons perdu à Waterloo et l'heure du méridien de Greenwich est devenu la base de l'UTC.

Vérifiez bien le 31 Décembre que vos serveurs NTP annoncent la leap second à venir (la sortie de la commande rv de ntpq doit montrer une valeur non nulle).

1176 at@khany:~> ntpq -n -c rv assID=0 status=4664 leap_add_sec, sync_ntp, 6 events, event_peer/strat_chg, version="ntpd 4.2.4p4@1.1520-o Fri Mar 7 20:24:07 UTC 2008 (1)", processor="i686", system="Linux/2.6.24-22-generic", leap=01, stratum=3, precision=-19, rootdelay=17.985, rootdispersion=107.325, peer=42101,

La très bonne page Wikipedia sur cet événement dont on avait perdu l'habitude, mais il semble que la terre recommence à ralentir :
http://en.wikipedia.org/wiki/Leap_second.

Le passage de la précédente Leap Second il y a 3 ans : http://www.at.usenet-fr.net/leap/ .

Alors ça c'est fait ...

noreply@blogger.com (Rominet.) — Mon, 14 Jul 2008 17:54:00 +0000

J'ai causé dans le poste en expliquant pourquoi l'Internet allait pas mourir demain :
http://www.france-info.com/spip.php?article160201

Debian/OpenSSL Debacle

noreply@blogger.com (Rominet.) — Thu, 15 May 2008 19:24:00 +0000

Parce qu'il vaut mieux en rire :

Velib \o/

noreply@blogger.com (Rominet.) — Wed, 29 Aug 2007 06:54:00 +0000

Bon mon quartier est envahi de nouveaux panneaux de pub, a tel point que ca en devient difficile à comprendre ...

On commence par une vue sur le carrefour Saussure/Pereire en venant de Pont Cardinet:

Un autre de l'autre coté qui masque aux voitures un panneau _assez_ important ...

Un gros plan sur l'espèce de monstre qui vient d'être installé ...

Une vision globale du carrefour ...

Etrange, Etrange, juste à coté il y a ça \o/

Mais ca ne marche pas /o\

On tourne la tête et encore deux autres ...

Tout cela aurait-il un rapport ?

Edit : GoogleMap:

View Larger Map

WTF !

noreply@blogger.com (Rominet.) — Tue, 27 Mar 2007 19:43:00 +0000

L0l le 21e siecle:

Ah les upgrades !

noreply@blogger.com (Rominet.) — Tue, 13 Feb 2007 17:34:00 +0000

Il y a quelques années, un upgrade d'Itunes qui faisait un rm -rf sans trop de précaution avait bien fait rire dans les chaumières, en particulier chez les vieux unixiens arrogants programmant en shell.

Ce qui vient de m'arriver lors d'un upgrade de iTerm est moins gênant mais tout aussi troublant :

Plein d'espoir et sûr de mes backups, j'ai cliqué Yes. Je n'ai pas vu d'effet spécial. Évidemment ce n'est arrivé que la première fois. Vous auriez fait quoi, vous ?

Batterie, crash et automount

noreply@blogger.com (Rominet.) — Thu, 25 Jan 2007 08:35:00 +0000

Bon, passons sur le fait que ma 2e batterie en 9 mois passe soudainement de 40 à 0% et que donc le système meurt sans prévenir ni même le temps de passer en veille.

Problème, lors du crash, j'avais une partition chiffrée montée, avec la commande suivante: hdiutil attach /home/at/crypto-container.dmg -stdinpass -mountroot /crypt (oui pour des raisons historiques de liens un peu partout dans mon $HOME, /Volumes j'en veux pas)

Passons sur le fait que depuis un passage 10.4.7->10.4.8 ca me monte en plus de la vraie partition chiffrée un ridicule /crypt/Boot OSX correspondant au secteur du IMG que je ne me rappelais pas avoir créé quand j'ai initialisé l'image.

Le problème dont je veux causer, c'est qu'il reste un /crypt/volumeamoi non vide (il y a un sale fichier .automounted sans doute créé par les bidules-on-sait-pas-ce-quils-font-mais-il-faut-pas-les-arreter) dedans, et que donc hdiutil monte très intelligement le disque sur /crypt/volumeamoi2 . Tres pratique quand le mail arrive et veut aller dans /crypt/volumeamoi/Mail/inbox .

Ethernet et veille

noreply@blogger.com (Rominet.) — Wed, 03 Jan 2007 07:48:00 +0000

Bonne année 2007 à tous les désespérés !

Environ une fois sur 50, quand le mac sort de veille, en0 reste inactif, obligeant à y retourner un petit instant ... (oué je sais j'ai qu'à faire du wifi, ethernet c'est pour les hasbeen).

Peut être est-ce que c'est ça qui le gêne avant de passer en veille, j'ai du enlever le cable trop tôt:

1011 root@khany:~> egrep -i '(Yukon|System Wake|System SafeSleep)' /var/log/system.log
Jan  3 08:26:38 khany kernel[0]: AppleYukon - en0 link is down
Jan  3 08:42:17 khany kernel[0]: System SafeSleep
Jan  3 08:42:17 khany kernel[0]: System Wake
Jan  3 08:45:08 khany kernel[0]: System SafeSleep
Jan  3 08:45:08 khany kernel[0]: System Wake
Jan  3 08:46:00 khany kernel[0]: AppleYukon - en0 link active, 10-Mbit, full duplex, flow control disabled

Retourner se coucher n'est peut être pas une mauvaise idée finalement.

X11

noreply@blogger.com (Rominet.) — Mon, 20 Nov 2006 13:22:00 +0000

Le serveur X11 se bloque régulièrement (mais évidemment pas de manière systématique) si on scrolle un peu vite vers le haut dans OpenOffice.Org , mais aussi dans rxvt ou d'autres applications. Je suis très étonné parce que je ne trouve pas de trace de de bug chez d'autres gens, mais c'est très très pénible de devoir faire Ctrl+S après chaque § écrit ...

Je suis sûr que ce n'est pas un bug OO.org:
- d'abord je l'ai déjà vu dans rxvt,
- ensuite le symptôme est que toutes les applications X11 sont bloquées, y compris les menus du haut, y compris la création d'une autre fenêtre...
- de toute manière un serveur graphique ne devrait pas se bloquer sur la réception d'une requête client ...

J'étais en train de radariser mais bugreport.apple.com m'a pété à la gueule..

Edit: comme je me méfie de ce serveur j'avais intelligement copié mon bug dans un terminal ... C'est donc le #4845847.

DNS

noreply@blogger.com (Rominet.) — Thu, 09 Nov 2006 08:07:00 +0000

Pourquoi tant de haine ? Pourquoi MacOS-X a t'il décidé que si je n'avais pas de route par défaut, je n'avais pas envie d'avoir un DNS ? Pourquoi cette merde de lookupd et DNSclient ne se met en marche que quand le système a une route par défaut ? Hein pourquoi ?

Le pire étant que le DNS que j'utilise est sur 127.0.0.1, bien entendu.

Update X11

noreply@blogger.com (Rominet.) — Mon, 06 Nov 2006 07:27:00 +0000

La récente mise à jour de X11 fait planter OpenOffice au démarrage. Je ne suis visiblement pas le seul.

Bien joué ! Je travaille comment moi maintenant ?

Edit: le problème est causé par 5 polices TTF (de la famille Vera) qui sont corrompues dans l'archive, et qu'il suffit de récupérer ailleurs. Bon. Mais le plus drôle, c'est ça.

Oui vous avez bien lu, un @&!=$# chez Apple a probablement transporté des fontes TTF binaires par FTP en mode ASCII.

Vieilleries

noreply@blogger.com (Rominet.) — Tue, 24 Oct 2006 18:48:00 +0000

Quelques vieilleries vues pendant ces quelques mois qui font tache dans un OS du XXIe siècle:

* Un vieil IKE de fin 2000 dans lequel AES s'appelle encore Rijndael ....

1016 at@khany:~> sudo racoon -vF
Foreground mode.
2006-10-24 20:39:54: INFO: main.c:176:main(): @(#)racoon 20001216 20001216 sakane@kame.net

* Des BPF dont les descripteurs de fichiers ne supportent pas select() : il n'y a pas de moyen simple d'appeler libpcap seulement quand on est sûr qu'il y a un paquet, ce qui ne facilite pas l'écriture d'applications d'écoute réseau un peu malignes (c'est dans FreeBSD depuis 4.3).

* Un SMBFS qui ne supporte pas le passage direct en SMB sur le port 445 et impose donc aux serveurs d'avoir NetBios sur TCP alors que c'est en voie d'abandon partout. Pas de signature de paquet non plus (alors que l'utilitaire smbclient livré supporte ces deux fonctions).

Mise en veille - 2

noreply@blogger.com (Rominet.) — Mon, 23 Oct 2006 16:31:00 +0000

Ce soir le mac s'est réveillé tout seul dans mon sac ... Du coup il était brûlant en le sortant. Peut être quelqu'un a branché une souris pendant que j'avais le dos tourné dans le train, qui sait ?

Accéder à /tmp

noreply@blogger.com (Rominet.) — Thu, 19 Oct 2006 14:10:00 +0000

MacOS a la désagréable manie d'essayer de cacher ses origines prolétariennes et son lourd passé Unix. Ainsi le Finder cache systématiquement les répertoires systèmes tels que /usr, /tmp et /var. On peut changer le comportement du Finder en tapant la douce ligne de commande defaults write com.apple.Finder AppleShowAllFiles true . Le problème c'est qu'apparaissent alors sur le bureau les fichiers Desktop DB et Desktop DF, qu'il faut donc planquer sous le tapis en les amenant dans un coin ou il ne gênent pas trop.

Bon ensuite naivement je pensais que j'allais avoir le même comportement dans le FileChooser, et que j'allais pouvoir ouvrir mes MP3 dans /tmp. Que nenni:

Après j'ai appris que je pouvais taper / et avoir accès à ça:

J'aurais pu m'en satisfaire, sauf que ça ne marche que dans les Applis COCOA (les trucs plus mieux bien) et pas dans les applis CARBON (un truc caca préhistorique qui doit mourir bouh).

Évidemment comme moi je suis préhistorique j'utilise beaucoup d'applications pas belles bouh, dont FireFox et Java. Comme je suis aussi très pervers j'ai donc créé un répertoire $HOME/slash dans lequel j'ai des liens vers /tmp et consorts. Haha.

Nawak à 200$

noreply@blogger.com (Rominet.) — Sun, 15 Oct 2006 17:32:00 +0000

Rien à voir avec le Mac, mais j'ai été atterré par cette maquette Apollo : 200$ pour un truc moche ou le LM est à l'envers ! (Sans parler de la taille relative de l'ombilical entre le CM et le SM).

Firewall

noreply@blogger.com (Rominet.) — Sun, 15 Oct 2006 11:10:00 +0000

MacOSX utilise le firewall ipfw de FreeBSD. Ce firewall est déjà largement moins bon que les deux autres qui étaient disponibles sur FreeBSD (pf et ipf), mais il est également très mal utilisé. Une interface graphique (pas très pas jolie ni intuitive) permet de le configurer, on trouve en particulier cette boite de dialogue "Advanced" :

Notez bien "Block UDP Traffic", puis allez voir avec ipfw show -a les règles générées, parmi les quelles:

20321 0 0 allow udp from any 67 to me in 20322 0 0 allow udp from any 5353 to me in 20340 0 0 allow udp from any to any dst-port 137 in 20350 0 0 allow udp from any to any dst-port 427 in 20360 0 0 allow udp from any to any dst-port 631 in 20370 0 0 allow udp from any to any dst-port 5353 in 22000 0 0 allow udp from any to any dst-port 3283 in 22010 0 0 allow udp from any to any dst-port 5900 in 22020 0 0 allow udp from any to any dst-port 123 in

Les deux premières sont très intéressantes : en prenant un port source égal à 67 (DHCP) ou 5353 (multicast DNS), vous pouvez accéder n'importe quel port UDP de la machine, ce qui est euhh ... contradictoire avec la première case à cocher. D'autre part, quand vous choisissez "Stealth Mode", vous avez la vague impression que votre système ne va pas envoyer plein d'infos quand on va le titiller sur le port Bonjour. IPFW possède pourant un moteur à états, capable de maintenir une pseudo-session UDP. Apple n'a visiblement pas jugé utile de l'utiliser, ce ne serait pourtant pas très compliqué de faire de meilleures règles un peu moins larges tout en sauvegardant le plug-and-play, ou alors de faire un bouton "Hellen Keller stealth mode" pour ceux qui branchent leur mac sur des réseaux pas très sûrs.

Evidemment rien ne vous empèche de réécrire vous même les règles manuellement et de profiter du moteur d'état, mais bon, il y a quand même tromperie sur le niveau de sécurité annoncé.

Please call the irony police !

noreply@blogger.com (Rominet.) — Fri, 13 Oct 2006 17:00:00 +0000

Reçu aujourd'hui :

From: Apple Research <macresearch@apple.com>
Date: Fri, 13 Oct 2006 09:54:02 UTC
Subject: Apple vous invite à participer à un important sondage

Cher/chère Alain, Apple prend en considération votre opinion et vous invite à participer à un sondage concernant votre expérience avec les ordinateurs Mac. Vos suggestions sont grandement appréciées et nous aideront à comprendre comment nous pouvons mieux répondre à vos besoins. Ce sondage est mené pour nous par LRW, une société indépendante de recherche en marketing.

Je pense que j'ai des lecteurs facétieux.

Verrouiller l'écran

noreply@blogger.com (Rominet.) — Thu, 12 Oct 2006 18:01:00 +0000

J'aime bien pouvoir verrouiller mon écran en une seule combinaison de touches . Je sais faire avec sous Unix avec X11 (grâce à xbindkeys par exemple ou d'autres programmes selon le Window manager utilisé). Je sais faire sur Windows qui a un raccourci en standard. Je me suis dit que MacOSX avait ça évidemment, c'est une fonction qui semble assez naturelle.

On peut assez facilement activer le screen-saver sur MacOS en utilisant des "hot-corners" (mettre la souris en haut à gauche par exemple), on peut aussi faire apparaître un petit menu avec un verrou so cute en utilisant "KeyChain Access" et en précisant "Show Status in Menu Bar". Ce petit menu a un choix "Lock Screen":

Après quelques jours, je me suis demandé pourquoi sélectionner ce menu ne verrouillait pas toujours mon écran. J'ai fini par comprendre un truc incroyable : vous sélectionnez le choix "Lock Screen", vous lachez la souris, et vous ne devez surtout pas la bouger avant que le screen-saver ne soit lancé (ce qui peut prendre quelques secondes si ça swappe, et MacOSX swappe beaucoup). Sinon le screen-saver croit qu'il y a eu de l'activité et que vous avez changé d'avis. Sisi.

Ensuite, pas découragé, j'ai cherché comment activer le "Cmd-L" (ou autre chose) pour déclencher le screen saver par clavier. Je suis allé dans System Preferences/Keyboard et là j'ai vu, oh miracle, qu'on pouvait créer des raccourcis globaux à toutes les applications. Génial !

Sauf que en fait ça ne marche pas. En cherchant pourquoi je suis tombé sur cette page ou quelqu'un sans doute de très bien explique "since this is a keyboard shortcut for a menubar icon, it only works when that area of the menubar is active (“has focus”). Et son contournement est délirant : il faut, pour activer le focus, faire auparavant Ctrl-F8. Pour simplifier les manipulations clavier il propose donc de mettre le raccourci Shift-Ctrl-F8. Et donc de locker l'écran avec la séquence Ctrl-F8 Shift-Ctrl-F8.

Bonk. Bonk.

Bizarreries Réseau (2)

noreply@blogger.com (Rominet.) — Thu, 12 Oct 2006 08:12:00 +0000

Bon en fait c'est plus qu'une bizarrerie, c'est un gros bug. Gros gros, qui montre que le passage de MacOS des processeurs PowerPC à Intel est pas si tranquille que ça.

Je développe un logiciel de détection d'anomalie de trafic réseau, un petit truc qui doit permettre de repérer les malins qui font du SSH dans HTTPS ou un tunnel IP dans DNS ... Pour cela, il est nécessaire d'écouter le réseau, mais également de reconstruire le trafic afin d'obtenir le flux de données tel qu'il est lu à l'autre bout. Cela nécessite donc de réassembler le trafic TCP, ce qui n'est pas très simple, et ce que fait (imparfaitement) par exemple libnids. J'ai parlé de ce truc en gestation à SSTIC06.

Quand j'ai commencé à porter ce petit travail sur mon Mac, libnids ne reconnaissait aucun trafic. J'ai commencé par penser que le portage de libnids était un peu moisi (ce qu'il est), puis j'ai examiné le trafic remontré par libpcap (dans tcpdump ou ethereal), et j'ai constaté que tous les checksums des paquets TCP envoyés par ma machine étaient faux.

10:39:29.784579 IP (tos 0x10, ttl 64, id 30135, offset 0, flags [DF], proto: TCP (6), length: 52) 192.70.106.104.61090 > 192.70.106.100.22: .,cksum 0x5580 (incorrect (-> 0x7e1c), 192:192(0) ack 2657 win 65312

Jusque là, ce n'est pas un bug en fait: les cartes Ethernet récentes savent calculer les checksums TCP en hardware, dans mon cas, les paquets émis au final sur le réseau étaient corrects (on peut juste regretter que libpcap n'aie pas accès au vrai paquet).

Je suis donc parti à la recherche d'une option permettant de désactiver la gestion hardware des checksums TCP, et après avoir pas mal cherché dans les forums de geeks MacOS qui font du réseau (c'est pas la majorité), je suis tombé sur deux sysctl \o/:

net.link.ether.inet.apple_hwcksum_tx: 1 net.link.ether.inet.apple_hwcksum_rx: 1

Il y avait donc plus qu'à les mettre à 0 pour que le système se mette à les générer (et à les vérifier) au lieu de laisser la carte le faire. Je fais donc:

1007 root@khany:~> sysctl -w net.link.ether.inet.apple_hwcksum_tx=0 net.link.ether.inet.apple_hwcksum_tx: 1 -> 0 1008 root@khany:~> sysctl -w net.link.ether.inet.apple_hwcksum_rx=0 net.link.ether.inet.apple_hwcksum_rx: 1 -> 0

Et la c'est le drame : plus moyen d'ouvrir un terminal, plus moyen de faire sudo, la résolution de nom marche plus, plus aucune appli ne se lance. C'est un symptôme assez connu sur MacOS qui indique que le réseau est mort : le système passe son temps à se causer sur lui même sur 127.0.0.1 pour interroger NetInfo (une vieille réminisence de NextStep de 1990 qui résiste, on se plaint pas, ca pourrait être du XML et du SOAP) . Quand le réseau est mort, le reste va suivre assez vite. Si vous avez de la chance vous avez encore votre shell root ouvert et vous remettez les deux valeurs à 1. Si vous avez pas de chance vous faites un ON/OFF brutal.

Vous réfléchissez, vous recommencez prêt à remettre la valeur à 1, vous regardez ce que donne tcpdump -lnvv -i lo0 et vous vous apercevez que les checksums TCP calculés par MacOS sur Intel sont faux. Ils sont faux sur Ethernet, mais la carte les recalcule quand même, ce qui fait que vous gardez votre connectivité avec les autres machines. Ils sont faux aussi sur le loopack et comme par le deuxième sysctl vous avez demandé à les vérifier, tous les paquets sont rejetés. Ils sont sans doute faux pour un bête problème d'Endianness et de raccourci dans les calculs, j'avoue que je n'ai pas cherché _ou_ ça merdait.

J'ai posté ce bug avec sa description sur bugreport.apple.com le 1er Mai, on m'a attribué le bug #4532260. 5 jours plus tard j'ai reçu un mail me disant que mon bug était un duplicate d'un autre (comment le savoir ?) et que "After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering." Depuis il y a eu 4 updates de systèmes, et le bug est toujours la dans MacOS 10.4.8.

Ce bug est grave parce qu'il montre qu'il y a des problèmes d'Endianness qui trainent dans le portage Intel. Il en est des plus faciles à contourner (j'en ai un autre sous le coude dont je vous parlerais), mais il y en a probablement qui ont des conséquences sur la sécurité. Il est grave aussi parce que en gros ça marche par miracle et que la qualité est pas là ... Ce que je n'ai pas encore compris, c'est pourquoi les checksums TCP sont corrects sur ppp ...

Pour finir, il n'est donc pas possible sur MacOS Intel de faire un système de détection d'intrusion réseau(NIDS) valide : il est en effet impossible de savoir si les paquets émis par la machine ont vraiment un checksum invalide ou pas, et il faut donc se résoudre à ça:

/* AT 20060501 Grrr if (my_tcp_check(this_tcphdr, iplen - 4 * this_iphdr->ip_hl, this_iphdr->ip_src.s_addr, this_iphdr->ip_dst.s_addr)) { nids_params.syslog(NIDS_WARN_TCP, NIDS_WARN_TCP_HDR, this_iphdr, this_tcphdr); return; } */

Autant dire que c'est dangereux, parce que quelqu'un de malin va balancer des paquets contenant des données vues comme normales, alors qu'elles ne seront pas acceptées par le système distant.

Bizarreries Réseau (1)

noreply@blogger.com (Rominet.) — Thu, 12 Oct 2006 07:13:00 +0000

Bon en lisant la suite vous allez dire que j'abuse. Mais non en fait.

Comme je l'ai dit, je fais des choses bizarres dans mon métier. Mais la couche réseau de MacOS, elle, elle est très bizarre. J'ai plein de petits exemples, alors on va commencer sur un que vous pourrez reproduire chez vous. Imaginons que la carte Ethernet ait l'adresse 192.168.230.5 et tapez les commandes suivantes:

1017 root@khany:~> route add 10.0.0.1 192.168.230.5 add host 10.0.0.1: gateway 192.168.230.5 1018 root@khany:~> telnet 10.0.0.1 Trying 10.0.0.1... telnet: connect to address 10.0.0.1: Cannot allocate memory telnet: Unable to connect to remote host

"Cannot allocate memory" ? WTF ! Évidemment dans le man de connect(2) cette erreur n'est pas prévue. Je ne comprends meme pas comment elle peut se produire d'ailleurs, j'imagine qu'il y a une boucle quelque part dans le noyau, ça fait un peu peur. D'ailleurs ce n'est pas propre à TCP, en icmp c'est pareil:

1022 root@khany:~> ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes ping: sendto: Cannot allocate memory

Je n'ai retrouvé ce comportement sur aucun autre système Unix (qui peuvent avoir des comportements divers selon la configuration du routage: soit ils répondent sur cette adresse, soit ils se mettent a renvoyer plein de ICMP Redirect, soit ca se perd).

[Edit: Radar #4782601]

iCal

noreply@blogger.com (Rominet.) — Wed, 11 Oct 2006 17:15:00 +0000

J'aime bien iCal. J'aime bien les gens qui l'ont écrit, ils montrent qu'il reste (ait?) de la place pour des équipes de développement en Europe, qu'il reste de la place pour faire de la qualité, des trucs jolis et pas trop lourdingues, et qui ne soient pas web-centric.

Sauf que je ne peux quasiment pas me servir d'iCal dans mon travail : mes collègues et mes clients (comme la plupart des gens dans le monde professionnel) ont pris la désagréable habitude de se référer aux numéros de semaine pour dater des évènements.

iCal sait saisir et afficher des tâches débutant en Arabe ancien et se terminant en Klingon, mais ne sais pas afficher un putain de numéro de semaine dans la colonne qui va bien.

"Alain, on peut faire un audit machin semaine 47 ?"
"Attends je finis de porter /usr/src/usr.bin/ncal sous MacOS et de voir à quoi ça correspond et je te réponds !"

Bon j'exagère, en pratique je me balade avec un QuoVadis Bleu pâle du meilleur effet, mais il est impossible que je sois le premier à demander ça. Et iCal a bientot 4 ans, et c'est la version 2.0.4.

Et non, il n'y a pas non plus de n° de semaine dans le widget Calendrier de Dashboard.

Ergonomie (1)

noreply@blogger.com (Rominet.) — Wed, 11 Oct 2006 15:48:00 +0000

MacOS est censé être très user-friendly, mais NextStep de 1990 sur lequel MacOSX est fondé avait selon moi de sérieux soucis d'ergonomie, et ces problèmes ressortent régulièrement, en particulier dans le Finder (que pour ma part j'ai renoncé un peu à utiliser: un shell, "cd" et "open" ça va à peu près), mais pas seulement.

Une des choses sur lesquelles je peste régulièrement, ce sont les "tabbed dialog" (enfin je crois que c'est cela le nom). Un des exemples les plus flagrants de leur dramatique destinée c'est ça:

"Je voudrais imprimer seulement cette page. Où est le numéro de la page ?" "Il est sous la boîte !" On peut la déplacer ? "Nan, il ne faut pas compliquer la vie de l'utilisateur avec des boîtes de dialogues qui se déplacent !". Bref.

De même dans Firefox, qui utilise les tabbed dialogs pour les alertes Javascript, ce qui m'empêche de faire de beaux screenshots pour montrer des attaques de Cross Site Scripting (on ne voit plus l'URL). Grr.

Trop compliqué pour moi.

noreply@blogger.com (Rominet.) — Wed, 11 Oct 2006 14:47:00 +0000

Quand le mac est livré il a un fond d'écran en dégradés. N'ayant pas forcément beaucoup de goût, je préfère un fond d'écran uni bleu foncé (pour vous dire comme je suis original, j'ai une voiture gris metallisé).

Bref j'ai voulu aller dans System Preferences/Desktop & Screen Saver, et mettre un fond bleu foncé. Chouette, un bidule marqué "Solid Colors", ça doit être ça ! Comment fait-on pour choisir une autre couleur, on doit cliquer quelque part je suppose...

Click Click Click Click ... Grmmmbbll Click Click Click ... RHAAA PUTAIN COMMENT ON FAIT !?

Après avoir demandé de l'aide à un ingénieur système MacOS reconnu: on fait pas. On prend ImageMagick compilé depuis Darwin Ports (y a pas de logiciel de dessin bitmap livré avec MacOS), on crée un fichier de 10x10 de la bonne couleur, on va le poser dans /Library/Desktop Pictures/Solid Colors et on le voit apparaître. Après on m'a dit que j'aurais pu faire un glisser/déposer. Ah.