gouttegd a écrit 1805 commentaires

De Microsoft, il y a Services For Unix (SFU), qui a l’air de fournir un environnement compatible POSIX assez complet (sans bash, mais avec ksh, csh et « plus de 350 commandes et utilitaires Unix usuels », dixit Microsoft).

Disclaimer : je ne l’ai jamais utilisé, je ne sais pas ce que ça vaut.

Personne n'a tilté sur l'affiche présentant l’évènement?

Si, moi : pourquoi une majuscule à « Linux » et pas à « gnu » ?

bon, sauf erreur ils ont aussi mis ce qu'il faut pour démarrer les softs qui s'installeraient avec des scripts dans les rcX.d

En effet, dans le paquet a/sysvinit-functions. Mais rien n’oblige à l’installer, aucun paquet Slackware officiel ne l’utilise. Ce paquet existe uniquement pour, je cite, « commercial (or other) software that expects to find "Red Hat-isms" ».

j'ai toujours pas pigé à quoi servent les bloats type consolekit

Tu ne dois pas être le seul, l’auteur de la doc de ConsoleKit ne semble pas le savoir non plus :

1. Introduction

Defining the problem

To be written.

ConsoleKit sert donc à résoudre un problème que l’on ne savait manifestement pas résoudre avant sans lui, mais on ne sait pas exactement lequel.

C’est du quoted-printable. Un outil pour le décoder est disponible ici : qprint.

Dispositif similaire chez moi, à quelques détails près. Notamment :

On me vole un des PCs, on peut récupérer mes données

Pour ça, tous mes disques sont chiffrés, aussi bien celui du portable que la matrice RAID du serveur.

Oh si, j’ai lu la lettre. Mais quelqu’un qui pose en postulat de base que « les logiciels propriétaires sont habituellement meilleurs », qui assimile le fait de refuser d’utiliser des logiciels propriétaires au fait d’« abandonner la modernité », je ne suis pas sûr que ce soit un meilleur défenseur du logiciel libre que Richard Stallman.

Que l’on reconnaisse que tel logiciel libre n’est pas à la hauteur de son équivalent propriétaire lorsque c’est le cas, c’est une très bonne chose, c’est ainsi qu’on peut le faire avancer (refuser de le reconnaître ne mènerait nul part). Mais il n’est pas nécessaire de tomber dans l’auto-flagellation généralisée, ça ne mène nul part non plus.

Pourquoi l'illustre inconnu veut des logiciels libres s'il s'en fout qu'ils soient libres? Je ne comprendrai jamais ça.

Peut-être parce que l’inconnu veut surtout, en réalité, des logiciels gratuits, auquel cas le résumé serait plutôt

« Vos idées sur le libre ne m’intéressent pas et me font peur, arrêtez de parler et codez-moi plutôt des logiciels aussi bien qu’Office et Photoshop sans me faire payer le prix d’Office et Photoshop — et qui fonctionnent aussi sous Windows, bien entendu. »

Dans le même ordre d'idée, ça serait peut-être bien d'avoir quelque chose comme un répertoire "/home/utilisateur_untel/etc".

Ça existe déjà, c’est le répertoire /home/utilisateur/.config, proposé par la XDG Base Directory Specification. Mais l’utilisation de ce répertoire n’est pas encore très répandue, même si j’ai l’impression que ça augmente peu à peu.

Relativement à l'histoire de TeX, ça ne fait pas si longtemps qu'on peut mettre de l'UTF-8 dans les codes sources au lieu d'écrire \moncaracterespecial, qui reste la solution la plus portable (mais la moins pratique, j'en conviens).

Portable ? C’est totalement spécifique à TeX. UTF-8 a pour lui d’être utilisable en toutes circonstances (comme sur ce site web, par exemple).

En quoi est-ce gênant ? Et bien pour mon fichier de bibliographie, par exemple. Je ne l’utilise pas qu’avec LaTeX, je m’en sers aussi pour gérer (consulter, chercher, etc.) ma bibliographie même lorsque je n’ai pas de document à écrire. Si le fichier était encodé en ASCII avec des séquences d’échappement à-la-TeX, mon gestionnaire de bibliographie devrait soit interpréter lesdites séquences d’échappement soit m’afficher « Mac\r{u}rek » (ce que je n’aimerais pas du tout voir). Heureusement, mon fichier est encodé en UTF-8, ce qu’aussi bien TeX que mon gestionnaire de bibliographie savent gérer aujourd’hui, du coup tout le monde est content.

TeX vise à produire des documents imprimés de qualité, c'est tout autre chose que le texte brut qui ne sera jamais optimal (n'es-tu pas sensible aux ligatures, aux indentations, et à la justification des paragraphes ? )

Je ne suis pas insensible aux autres subtilités de l’orthotypographie, mais pouvoir représenter toutes sortes de caractères et composer un texte sont deux choses différentes. UTF-8 rend la première chose possible indépendamment de la seconde. Encore une fois, comme sur ce site par exemple, où nous n‘avons pas besoin d’un système de composition pour afficher les caractères que nous avons — c’est-à-dire, que j’ai ;) — envie d’afficher.

Ai-je jamais soutenu autre chose ? ai-je même contesté que tu puisses arbitrer qu'écrire le Tchèque en texte brut est une raison suffisante pour passer à l'UTF-8 ? c'est vous qui depuis le départ contestez que Latin9 est un choix aussi rationnel et valable qu'UTF-8...

Tu dois me confondre avec Zenitram. Comme je l’ai dit à deux reprises déjà, je n’ai aucun problème avec le fait que tu choisisses d’utiliser un encodage régional — tant que ton client mail est configuré pour me dire quel est l’encodage en question, si jamais tu dois m’envoyer un message.

Je réagissais simplement pour dire qu’il y avait d’autres raisons justifiant pour certains le choix d’UTF-8 que le seul plaisir de la complexité ou la volonté machiavélique de pourrir la vie des programmeurs et des utilisateurs de vieilles machines.

For the record, je suis entièrement d’accord avec la conclusion d’un de tes précédents messages :

c'est une question d'équilibre entre besoins et désagréments

Là où je ne suis absolument pas d’accord avec toi, c’est quand tu sembles dire que des contraintes techniques (ici, l’encodage des caractères) doivent dicter les comportements de l’utilisateur (ici, la façon d’écrire). Moi, je veux que ma machine s’adapte à mes lubies et non l’inverse, d’où mon choix de l’UTF-8 et de ses désagréments.

Tu n'auras pas le choix, tu te poseras toujours la question de l'encodage.

Bah ça fait pourtant des années que je ne me la suis pas posée. Tant que je reste chez moi, la question ne ne pose pas parce que tout est en UTF-8. Je n’ai pas besoin de me demander, au moment de sauver un fichier, « quels caractères contient-il et quel encodage devrais-je utiliser ? »

Lorsque le fichier sort de chez moi, pareil : je l’envoie sans me soucier de son encodage. Mon client mail ajoute automatiquement un en-tête Content-Type: text/plain; charset=UTF-8. Comment mon client mail sait-il que le fichier est en UTF-8 ? Je n’ai pas regardé, mais je suppose sur un système dont la locale est en_US.UTF-8, il considère que les pièces jointes sont en UTF-8 par défaut, ce qui est exactement ce que je veux (si je me mettais à utiliser un autre encodage, là je serais sans doute obligé de le spécifier manuellement — c’est exactement ce que je ne veux pas).

Lorsque le fichier vient de l’extérieur (reçu par e-mail, téléchargé depuis la toile, etc.), la question de l’encodage ne se posera que si « l’émetteur » du fichier n’a pas précisé l’encodage (serveur web mal configuré, balise « META » absente, client mail n’envoyant pas d’en-tête MIME…). Ça arrive encore quelque fois, mais je constate que ça devient très rare. Des collègues ou amis qui ne savent probablement même pas ce qu’est un « encodage de caractères » parviennent à m’envoyer des fichiers que mon éditeur n’a aucune peine à afficher correctement. Ou bien je les sous-estime et ils savent en réalité tout de cette problématique, ou bien leurs systèmes et leurs logiciels arrivent très bien à gérer cette épineuse question de façon transparente (ce qui, je le répète, est pour moi la moindre des choses).

Biographie que tu publies en texte brut ? non, tu le feras en PDF ou en HTML, langages dans lesquels tu n'auras aucun soucis et qui n'impliquent aucune locale spécifique.

Encore une fois, non, je ne vais pas systématiquement utiliser LaTeX pour le moindre petit bout de document que je peux avoir besoin d’écrire. LaTeX (ou tout autre système de traitement de texte) répond à un besoin bien précis, pas à tous.

Je ne comprends pas. Tu te plains de l’augmentation de complexité induite par UTF-8, mais tu pousses à l’utilisation d’usines à gaz à la place ?

De plus, combien de gens vont connaître la différence de prononciation entre Macůrek et Macurek ?

Je ne la connais pas, personnellement. Est-ce une raison pour écorcher le nom ?

Certes, la francisation des noms est tout-à-fait acceptable quand on ne peux pas faire autrement (Angström voire Angstrœm au lieu de Ångström, Ceausescu au lieu de Ceauşescu, Sarkozy au lieu de Sarközy…). Mais justement, avec UTF-8 il est possible de faire autrement, et ce en toutes circonstances (et non pas uniquement quand on prépare un document destiné à la publication avec LaTeX). Pourquoi faudrait-il s’en priver ? Parce que des informaticiens à l’esprit étroit ne voyant pas plus loin que le bout de leurs frontières ont décidé que 256 caractères suffiraient bien pour tout le monde (sont-ce les mêmes informaticiens que ceux qui ont dit que personne n’aurait jamais besoin de plus de 640 ko de mémoire ?), et que pour les « exotiques » (comprendre, les non-occidentaux), bah tant pis mais ça ne va pas être possible ?

Granted, si j’écris « Macurek et al. (2008) » au lieu de « Macůrek et al. (2008) », je ne connais personne qui m’en tiendra rigueur (surtout pas mon chef, pourtant d’originaire d’Europe orientale, qui n’en aura rien à cirer). Mais moi, ça me dérangera. Mon troisième prénom est Jean-Noël, et en bon vieux con briseur de noix qui se respecte, je n’aimerais pas le voir écrit Jean-Noel par un étranger au motif fallacieux que son encodage régional ne contient pas de « ë ».

Enfin, n'oublie pas également que des générations d'écrivains ont employé des machines à écrire à disposition azerty, puis des traitements de texte avec des encodages limités (pas de cadratin &cie.).

Et des générations de typographes ont utilisé tout l’éventail des caractères disponibles, n’hésitant pas à en inventer quand il le fallait. Et des générations d’écrivains ont écrit à la main sans jamais être freiné par la moindre limitation technique. Le caron (le diacritique ˇ) utilisé pour transcrire certains phonèmes des langues slaves a été inventé au quinzième siècle, et a longtemps été utilisé sans problèmes par ceux qui en avaient besoin. Il n’y avait pas d’informaticiens ou de constructeur de machines à écrire en ce temps-là pour dire « arrêtez d’avoir des idées, on n’a pas de place pour les encoder. »

Ce n’est pas parce qu’on a connu au vingtième siècle une période où les limitations techniques étaient fortes qu’il faudrait considérer lesdites limites comme allant de soi sans jamais chercher à les dépasser.

Avec un raisonnement comme le tien, Donald Knuth se serait contenté du rendu médiocre de son livre The Art of Computer Programming que lui proposaient les logiciels de composition des années 70, et il n’aurait jamais écrit TeX…

Le double-guillemet droit en lieu et place du chevron fait sûrement s'étrangler les vieilles barbes de l'Académie Française, il n'empêche pas le français d'être du français.

Pour autant que je sache, l’Académie française (pas de majuscule à « française » ici) ne se préoccupe pas des questions de typographie. Mais il y a d’autres vieux cons (et des moins vieux, merci) que le guillemet droit fait s’étrangler.

Encore une fois, tu es parfaitement libre de continuer à utiliser un encodage européen occidental si tes besoins ne vont pas au-delà. Mais dans la vie réelle (© 2011 dr_home), tes besoins et tes attentes ne sont pas ceux de tout le monde.

Sauf que dans la vie réelle, ma glibc me permet de décoder/encoder les fichiers comme je veux (fais un iconv -l, pour t'en convaincre) et donc de partager avec n'importe qui.

Sauf que dans la vie réelle, j'en n'aurai même pas besoin parce que vim me permet d'éditer avec l'encodage de mon choix.

Personnellement, je préfère accepter de perdre un chouia de performances pour ne pas avoir à me poser la question de l’encodage. L’ordinateur n’est-il pas là pour me simplifier la vie ? Quand j’écris avec un stylo sur du papier, je n’ai pas à me demander quel encodage je dois utiliser pour tracer tel caractère…

Gérer de façon transparente ce genre de détails est quand même, selon moi, la moindre des choses que l’on est en droit de demander à une puce qui renferme dans quelques millimètres carrés plus de puissance de calcul qu’il n’en a fallu pour concevoir la bombe atomique ou envoyer un homme sur la lune (et je ne parle pas forcément d’un octo-cœur à 4 GHz, hein).

Sauf que dans la vie réelle, la seule langue que je baragouine à part le Français c'est l'Anglais, donc afficher le Cyrillique, les Kanjis ou l'Arabe, ça ne m'avance pas beaucoup par rapport à une pâtée 8bits.

Je ne parle pas un mot de serbe, de suédois ou de polonais, ce qui n’empêche pas ma bibliographie de comporter des travaux de dénommés Radosavljević, Čuboňová, Meşe, Kågedal, Macůrek ou Chełstowska. Autant de noms que je peux avoir avois besoin de citer dans un document bien franco-français destinés à des seuls francophones de France. Quel encodage 8 bits me permet d’écrire en français sans écorcher les noms du reste du monde ? C’est un problème insurmontable par définition avec les encodages régionaux.

Sauf que dans la vie réelle, j'ai passé des années en Latin9 sans en souffrir plus que ça.

Tant mieux pour toi. Tu es libre de rester en Latin-9 si ça te convient. Mais ne t’étonne pas si le reste du monde pousse vers l’UTF-8 (enfin, j’espère).

Oui, le problème de grep est connu depuis longtemps, mais doit être lié à la manière dont la commande est codée, de telle sorte qu'il n'est pas simple de le résoudre.

Apparemment, il est résolu. Je viens de compiler grep 2.7 et de refaire les tests, j’obtiens peu ou prou la même chose qu’avec sed : le temps d’exécution est plus long avec LANG=en_US.UTF-8 mais reste dans le même ordre de grandeur qu’avec LANG=C (et non trois ordres de grandeur au-dessus comme avec grep 2.5.4).

En fait, ma position ici vient du fait que je suis passé de Latin9 à UTF-8 et que, rétrospectivement, je trouve que ça m'a apporté (relativement) plus de complications que d'avantages concrets.

Après être passé de latin-1 à UTF-8, je pense exactement le contraire. :)

J’admets volontiers que la période de transition, quand on a des trucs déjà en UTF-8 d’un côté et d’autres trucs encore en latin-1 de l’autre, est délicate, surtout quand le support d’UTF-8 par les logiciels est encore fragmentaire (de mémoire, c’est LaTeX et surtout BibTeX qui m’avait posé le plus de problèmes). Mais après, quand tout est en UTF-8, depuis les noms de fichiers jusqu’aux contenus des documents en passant par les tags des fichiers Vorbis, et qu’on n’a plus à se poser la question de l’encodage… je ne le regrette pas.

Tous les utilitaires sont plus ou moins ralentis.

Autant le faible écart pour sed et awk ne me choque pas (d’autant moins que je ne le reproduis pas fidèlement ici), autant l’écart avec grep, parfaitement reproductible, est énorme.

Une telle différence n’est pas normale, à mon avis ça traduit plus un bug de grep qu’un problème général posé par UTF-8.

En « texte brut », oui, mais en général les ouvrages ne peuvent se permettre d'être écrits en "texte brut". Ils ont besoin de mises en forme beaucoup plus élaborées qui supposent des outils auxquels les caractères "spéciaux" (disons "précis") ne posent aucun problème.

Et lorsqu’on n’a pas de gros besoins de mise en forme, mais qu’on veut quand même écrire correctement, il faudrait obligatoirement utiliser ces « outils » dédiés sensiblement complexes ? J’aime beaucoup LaTeX, mais de là à le sortir pour le moindre bout de document…

La disponibilité d’UTF-8 me permet de me contenter d’un banal fichier en « texte brut » sans pour autant devoir faire l’impasse sur les « caractères spéciaux » (qui n’on en fait rien de spéciaux) lorsqu’ils sont nécessaires. Surtout quand on ajoute la facilité avec laquelle on peut saisir toutes sortes de caractères sous X.11.

Je trouve de plus qu'en ISO-8859-15 (fr_FR@euro), on arrive quand même à écrire très correctement le français.

Mouais, on peut parler d’argent en euros et écrire une recette de cuisine à base d’œufs. Mais on n’a toujours pas de tiret cadratin — donc pas d’incise —, pas de véritable apostrophe (la courbe), pas de trois points… Et absolument aucune possibilité d’insérer ponctuellement un caractère non-français (ce qui peut être nécessaire même en écrivant exclusivement en français, par exemple lorsque je veux parler d’intégrine α5β1), à moins d’utiliser un traitement de texte et de changer de police (adieu le texte brut).

Et il y a toujours le risque, lorsque le texte est destiné à être transmis (par e-mail par exemple), que l’encodage ne soit pas compris à l’autre bout du fil (en UTF-8 aussi, certes, mais je pense que le risque est plus élevé avec la multitude des encodages 8-bits régionaux qu’avec l’UTF-8 qui a vocation à être utilisé partout).

Auquel cas il s'agirait d'un avantage concurrentiel tout à fait déloyal en faveur de la langue anglaise et de son alphabet sans accent :-(

L’ASCII, un avantage en faveur de la langue anglaise ? Alors que l’ASCII n’a jamais permis d’écrire correctement en anglais (pas plus que que l’ISO-8859-1 n’a permis d’écrire correctement en français) ?

Je prends n’importe quel ouvrage en anglais sur mes étagères, n’importe quelle page et n’importe quel paragraphe, je tombe instantanément sur plusieurs caractères ne figurant pas dans une table ASCII. Les plus fréquents étant notamment les « guillemets anglais », simples ou doubles (U2018, U2019, U201C, U201D), et le tiret cadratin (U2014).

Sans compter l’utilisation pas si rare de mots étrangers (dont beaucoup de français), que l’usage commande d’écrire avec leurs diacritiques d’origine.

WMFS c'est en premier lieu très léger : 7886 SLOC

Le nombre de lignes de code est-il une métrique à laquelle les développeurs de WMFS attachent de l’importance, à la manière des développeurs de suckless.org (wmii) qui mettent un point d’honneur à ne pas dépasser 10 000 lignes ? Il ne semble pas en être fait mention sur le site.

Je me méfie un peu de ceux qui cherchent à tout prix à réduire la taille de leur code. Small is beautiful, certes, mais à condition que ne ce soit pas au détriment de la lisibilité du code, sinon on gagne quoi ?

Connais-tu des alternatives ?

Citadel ?

Avec Mono/.Net, c'est comme en Java, tu compile une fois tu execute partout

Non, tu exécutes là où un environnement d’exécution est disponible, ce qui est très différent de « partout ».

Je n’ai rien contre Java (enfin, si, mais c’est pas le jour), mais le slogan mensonger « write once, run everywhere » me fait voir rouge depuis que je n’ai pas réussi à trouver une JVM qui fonctionne sur un GNU/Linux sur Mac PPC.

Le problème n’est pas l’utilisation d’une technologie particulière, mais l’exclusion délibérée de certains navigateurs.

IE supporte peut-être mal le HTML5, mais dans ce cas la meilleure chose à faire est de le laisser se dépatouiller avec. Lui fermer la porte au nez n’est pas une solution. S’il gère si mal que ça le HTML5, il s’exclura tout seul.

Un support IE9 est en cours de codage.

Oui mais non. S’il faut explicitement supporter chaque navigateur et même chaque version de navigateur, on tombe précisément dans le travers dénoncé par Tim Berners-Lee. Un des intérêts du web, c’est que je pond une page et une seule pour tout le monde, et tous les navigateurs doivent l’afficher correctement (y compris des navigateurs dont je ne connaissais même pas l’existence quand j’ai écris la page).

On fait des choix technologiques disruptifs, c'est notre choix.

Pousser à l’utilisation d’un seul couple de navigateurs (Chrome/Firefox), c’est très disruptif en effet.

plus sérieusement on a explicitement blacklisté les IE. & navigateurs moasis (sic)

Malgré tout le mal que je pense de IE, un tel comportement de la part d’un site web m’est insupportable.

« Quiconque appose sur une page web un logo du type : “Cette page est optimisée pour le navigateur X” est quelqu’un qui semble souhaiter revenir à l’époque préhistorique d’avant le web, lorsque l’on avait très peu de chances de pouvoir lire un document écrit sur un autre ordinateur, sur un autre traitement de texte, ou un autre réseau. » — Tim Berners-Lee, juillet 1996

Permet moi de faire mon pbpg

Ton quoi ? Je connais rien à Apple, moi, je te rappelle.

Corrige moi si je me trompe, mais un serveur smtp en rade, Mail te le signale.

Eh bien non, justement. Je ne saurai te ressortir le message d’erreur exact (cette anecdote doit remonter à deux ans), mais il ne laissait rien transparaître de l’origine du problème, c’était un message inutile du genre « impossible d’envoyer le message ». Pourquoi crois-tu que j’ai essayé de chercher les logs ?

Je dit pas qu'une erreur arrivera jamais, mais qu'une erreur de ce style DOIT etre notifiee a l'utilisateur. Si elle ne l'est pas, c'est un blocker et tu shippes pas tant que c'est pas resolu.

Et bien tu devrais vérifier ce qu’il en est avec ta version de Mail, parce que si c’est encore comme il y a deux ans, il faudrait dire à Apple qu’ils « shippé » une application avec un « blocker ».

Si t'es capable de la logger, t'es capable de la presenter. Logger ne sert a rien

Si, logger est utile dans le cas où il n’est pas possible (pour quelques raisons que ce soit) de reproduire l’erreur.

Logger en production le moindre appel de method pour une appli qui tourne 24/7 avec potentiellement une forte activite, je suis pas convaincu que ca soit une super idee.

Logger le moindre appel de méthode, c’est même stupide. Mais une ligne de log par mail envoyé et reçu, c’est beaucoup plus raisonnable et ça apporte déjà des informations utiles.

Il est hors de question que je me fade les logs d'une appli, c'est precisement pour eviter ce genre d'emmerdements que j'utilise des produits apple. Mail est utilise quotidiennement par des dizaines de millions d'utilisateurs, tu crois que ca se saurais pas si yavait de gros problemes qui necessite de se tapper des logs?

Mais qui t’a dit que le problème venait de l’application Mail elle-même ?

Dans l’anecdote que je mentionne, il s’est avéré que le problème ne venait ni de Mail ni même du Mac, mais du serveur SMTP qui était tombé en rade.

Ne rien logger du tout parce qu’on est persuadé que le système et les logiciels sont suffisament bien conçus, c’est complètement idiot parce que c’est oublier que tout ne dépend pas du système ou des logiciels. Mail est certainement bien conçu, mais même lui ne peut pas se connecter à un serveur qui fait le mort.

Une banal ligne dans les logs du genre « cannot reach SMTP serveur: connection timed out », c’est tout ce que je cherchais dans les logs.

Et sans même aller voir les logs, un simple message affiché directement dans l’interface du logiciel, du genre « votre message n’a pas pu être envoyé parce que le serveur d’envoi est injoignable », aurait amplement suffi à mon collègue pour comprendre que le problème venait du serveur et non de sa machine, il n’aurait même pas eu besoin de me déranger. Mais apparemment chez Apple on pense que les messages d’erreur trop explicites font peur à l’utilisateur…

D'un autre cote, se fader les logs d'une appli, c'est pas vraiment ce que j'appelerais une operation de base. Le simple fait de devoir se les taper c'est signe d'un echec flagrant de l'appli.

Absolument. Dans le cas présent, échec flagrant à signaler à l’utilisateur une condition d’erreur indépendante du logiciel.

P. S. : Merci quand même d’avoir répondu à ma question, j’en prends note au cas où.

activer les logs pour Mail (pas fait par defaut). T'as une palanquee de cles de logs que tu peux activer en fonction du niveau de log desire. Cf nain ternet pour les cles dispo

C’est tellement évident et intuitif que je me demande comment je n’y ai pas pensé ⸮

Et sinon, l’utilisateur lambda qui n’est pas un « power user », qui n’a pas vraiment envie de le devenir, mais qui a quand même envie de comprendre pourquoi il n’arrive pas à envoyer un mail, il fait comment ? Il demande au geek du coin ?

Il faudra qu’il demande à quelqu’un d’autre que moi alors, parce que tout ça confirme bien ce que je disais dans mon premier message : je connais très mal Mac OS X, je ne vois pas pourquoi ce serait à moi de me décarcasser pour aider un mac user à utiliser le système qu’il a choisi (et dont il vante fréquemment les mérites).