| Accueil | Archives francophones de TidBITS | Sommaire des quatre derniers TidBITS traduits | L'Equipe francophone de TidBITS | Consignes pour traduire TidBITS | LexBITS | Tronchoscope des traducteurs |
TidBITS#714/26-Jan-04
A l'occasion du 20è anniversaire du Macintosh, Adam s'entretient avec Bruce Horn, l'auteur du Finder, sur son travail chez Apple, ce qu'il a fait depuis et sur quels projets Macintosh il travaille maintenant. De son coté Brady Johnson analyse la législation anti pourriel U.S. CAN-SPAM Act et s'interroge sur son efficacité à diminiuer le flot de messages non sollicités dans nos boites à lettres. Du coté des nouveautés, Dantz sort Retrospect 6 et OrangeWare propose des pilotes Mac OS X pour des cartes sans fil utilisant la puce Atheros chipsets, et notamment les cartes 802.11a.
Topics:
Copyright 2004 TidBITS Electronic Publishing. Droits d'utilisation soumis à la licence Creative Commons
<http://www.tidbits.com/terms/>
Information : <info@tidbits.com> Commentaires sur l'édition française: <gregoire@pobox.com>
Ce numéro a été traduit de l'américain par les traducteurs bénévoles, de TidBITS-FR : Dominique -- Fabrice Jaffré -- Frederic Denonne -- Harold J. Benjamin -- Jacques Ravaux -- Jean Philippe Muthelet -- Jean-Marc Gargantiel -- John Howland -- Luc Saint-Elie -- Patrick Mpondo Dicka -- Sylvie Koullen -- Thierry Lesnik -- Jean-Louis Delaunney -- Grégoire Seither
NOUS CHERCHONS des TRADUCTEURS !!!!! Ca ne vous prendra que 30 minutes par semaine, vous permettra d'améliorer votre anglais et d'augmenter votre karma Macintoshien ! Venez rejoindre une bande de joyeux drilles amateurs de bonnes bouffes, bons vins et discussions éclairées ! Jetez un coup d'oeil aux consignes de traduction et contactez le coordinateur de la traduction : Grégoire Seither (gregoire@pobox.com).
<http://www.tidbits.com/tb-issues/lang/fr/consignes.html>
Cette édition de TidBITS est rendue en partie possible grâce au soutien financier de :
DES LECTEURS COMME VOUS ! 
Vous pouvez aider à pérenniser TidBITS en participant à notre programme de donation volontaire. Cette semaine nous remercions tout particulièrement Peter Morgan, et la ApplesBC Computer Society pour leur généreux soutien financier !
<http://www..tidbits.com/about/support/contributors.html>
Tiens ! Il n'y a plus les publicités ? Ben non, vu qu'elles ne concernent que le lectorat états-unien, on s'est dit qu'on pourrait aussi bien ne pas les mettre... en attendant de trouver des annonceurs francophones éventuels.
Si vraiment cela vous dérange, faites le nous savoir.
Le Mac enfin compatible avec la 802.11a -- Quand Steve Jobs a présenté son système sans fil Apple AirPort Extreme (IEEE 802.11g) en Janvier 2003, il a annoncé qu'il ne serait pas compatible avec l'ancienne norme, connue sous l'appelation 802.11a, étant donné que de toute façon cette dernière était quasiment morte. Utilisant des fréquences différentes que la norme d'AirPort (802.11b) et d'AirPort Extreme standards, la 802.11a connaît une résurrection depuis un an, avec de nouvelles fréquences ajoutées à san bande passante et une vaste gamme de cartes sans fil non Apple qui savent gérer tant la 802.11a, que la variante b et g. Malgré son enterrement un peu hâtif par Apple, la 802.11a a l'avantage d'être moins affecté par les interférences que la norme b et g. Mais étant donné la position d'Apple, les utilisateurs de Mac n'y avaient pas accès jusqu'à présent.
OrangeWare vient de sortir un ensemble de pilotes logiciels, développés à l'origine pour les puces Atheros de 3Com, un concurrent de Broadcom qui fournit la moteur des applications sans fil d'Apple. Bien qu'au départ les pilotes OrangeWare sont censés uniquement concerner l'utilisation sous Mac OS X des cartes sans fil Atheros, de nombreux utilisateurs Mac indiquent avoir été capables d'utiliser des cartes 802.11g de chez Linksys, Buffalo, Belkin et autres fabricants utilisant les puces Broadcom - les mêmes que celles contenues dans la gamme AirPort Extreme et compatibles avec le logiciel AirPort 3.1. Le pilote OrangeWare (vendu 15 US$ avec une période d'essai gratuite), vous pouvez utiliser des cartes 802.11a ou des cartes a/g PC ainsi que PCI de fabricants tel que NetGear, Fujitsu, D-Link etc. Vous trouverez sur le site de OrangeWare une liste de cartes testées comme étant compatibles, mais elle n'est pas exhaustive. [GF]
<http://www.orangeware.com/endusers/wirelessformac.htm>
par Glenn Fleishman <glenn@tidbits.com>
Le vénérable logiciel de sauvegards Retrospect de Dantz Development est finalement 100% compatible Mac OS X 10.3. Bien que Retrospect 5.1 tournait sous Panther tout comme Retrospect Client, Dantz avait néanmoins identifié toute une série de bogues et avait publié une longue liste de situations à éviter si on voulait ne pas avoir de problèmes, notamment après des plantages et des redémarrages intempestifs. (c'est la raison pour laquelle la majorité d'entre nous utilise encore Jaguar sur les serveurs de sauvegarde.)
<http://www.dantz.com/>
<http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=28093>
Les esprits chagrins diront que Retrospect 6.0 est une mise à jour de maintenance affublée d'un prix élevé... et c'est vrai sauf si vous avez l'un des quatre besoins suivants ; créer des archives ("sets") de sauvegarde qui dépassent le Terabit de données ; si vous faites des sauvegardes sur un RAID Xserve; si vous utilisez des enregistreurs à bande via une connectique SCSI ou Fibre optique; ou si votre archive Retrospect est étalé sur plusieurs disques dur, cette dernière situation est le cas d'Adam qui utilise des disques durs pour ses sauvegardes. Dantz annonce également de nettes améliorations des performances du logiciel.
<http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=28121>
<http://db.tidbits.com/getbits.acgi?tbart=07295>
Le logiciel est atuellement disponible en téléchargement; la version sur CD viendra mi-février. Le barème de prix est toujours aussi compliquée, mais on a l'habitude avec Dantz et sa multitude de versions selon que vous l'utilisez sur un petit, moyen ou grands réseau.
Retrospect Desktop peut sauvegarder un Mac en local et deux postes Windows, Mac OS, ou Red Hat Linux en réseau local à l'aide du logiciel Retrospect Client. Par contre il ne peut pas sauvegarder des ordinateurs tournant sous Mac OS X Server (localement ou avec Retrospect Client), et ne gère pas les enregistreurs à bande haute-capacité, les RAID Xserve ou bien les archives dépassant le Terabit. Prix public 130 US$ ou 60 US$ pour la mise à jour depuis une ancienne version.
Retrospect Workgroup et Retrospect Server peuvent gérer entre 20 et 100 machines, respectivement et offrent toutes les options décrites ci-dessus. Cependant, seul Retrospect Server sait gérer des systèmes Mac OS X Server. Retrospect Workgroup est vendu 500 US$ ou 200 US$ pour la mise à jour ; Le serveur est vendu 800 US$ ou 350 US$ pour la mise à jour ..
Toutes les versions incluent Retrospect 5.1 pour ceux qui utilisent un système sous OS 9 pour leur sauvegardes. Retrospect 6.0 peut sauvegarder des Mac tournant sur de anciennes versions d'OS, à l'aide de Retrospect Client. La version fournie sur CD (pas celle en téléchargement) est livrée avec un CD Rom d'urgence permettant de redémarrer une machine plantée.
par Adam C. Engst <ace@tidbits.com>
Vingt ans de Macintosh. Au Macworld Expo de cette année, Steve Jobs a diffusé une version de la fameuse pub spo "1984" qui lançait le Mac, et Alan Oppenheimer, qui a été responsable pour une large part d'AppleTalk, a fait une causerie fabuleuse à propos de l'histoire de la mise en réseau sur le Mac. Ce que j'ai trouvé le plus intéressant, était que, bien que vingt ans soient passés, beaucoup des gens qui étaient là à l'origine sont non seulement toujours présents, mais continuent à fournir un fabuleux travail. L'histoire du Macintosh n'est pas seulement en train de s'écrire mais certains des fondateurs sont encore tiennent encore la plume.
<http://www.opendoor.com/ nethistor y/>
Laissez-moi vous présenter un autre membre de l'équipe Macintosh des origines, Bruce Horn, qui était responsable de nombre des aspects-clés du Mac et qui a continué à écrire du code innovant. Chez Apple, Bruce (c'est qui ce type) était responsable de la conception et de l'implémentation du Finder (ah bon, en effet, c'est pas n'importe qui !), dy systéme d'identification des fichiers par des métadonnées TYPE/CREATEUR, ainsi que du gestionnaire de ressources (qui gérait la lecture et l'écriture de la plage de ressources [ressource fork] dans les fichiers ; une note de la documentation technique d'Apple, à un moment donné précisait d'ailleurs avec emphase : "Le Gestionnaire de Ressources n'est pas une base de données !"). Le gestionnaire de Dialogues et le fait que le Presse-papiers puisse accueillir des données de tout genre est également le fruit de l'ingéniosité de Bruce.
Alors, pour commémorer ce vingtième anniversaire du Macintosh, j'ai voulu parler avec Bruce non seulement de ce qu'il a fait chez Apple, mais aussi de ce qu'il est devenu depuis lors, étant donné que, sous de nombreux aspects, son travail actuel est à la fois un retour aux sources et un aperçu de ce qui pourrait être possible avec le Macintosh dans le futur.
Adam : Bruce, par bien des aspects, le Mac sur lequel tu as travaillé au départ posait le problème de l’accès à des données structurées. Le Finder était une porte d’accès au système des fichiers ; le Gestionnaire de Ressources, malgré cette remarque figurant dans la documentation, ressemblait quelque peu à une base de données non-relationnelle. Et les indicateurs de type et de créateur ne demandaient qu’à être exploités dans une base de données. Est-ce que ceci était prévu au départ, ou bien ces solutions se sont-elles imposées au fur et à mesure que ton travail avançait ?
Bruce : J’en suis venu à adopter ces solutions en cherchant à remplir des objectifs distincts. Ayant acquis une bonne partie de mon expérience de programmeur dans l’environnement Smalltalk de chez Xerox, où il était possible de modifier ce qu’on voulait pendant l’exécution même du programme, j’ai cherché une manière dynamique de manipuler les objets au sein du système de manière à ce que les données comme les chaînes de caractères à localiser, les menus, les images, etc., puissent être modifiées par des non-programmeurs sans avoir à recompiler le code source. Je me suis aussi rendu compte que le type de données que je voulais gérer à l’aide du Finder (les icônes des applications et des documents, et les liens avec ces icônes) relevaient du même genre de manipulation, et j’ai voulu une solution homogène à ces problèmes . Et c’est ainsi que le travail sur la base de données du bureau a été le moteur de ce que le Gestionnaire de Ressources allait devenir en fin de compte.
De plus, ce sont les exigences du Finder qui sont à l’origine des méta-données de fichier. Très vite, j’ai compris que pour proposer un mécanisme de double-clic à l’ouverture pour les documents, je devais aussi prévoir un moyen simple de relier ce document à l’application par défaut qui était censée l’ouvrir. De même, puisque qu’il existait des applications diverses capables d’ouvrir des types de fichiers divers, je ne pouvais pas me contenter d’une correspondance unique entre un type de fichier et une application censée gérer tous les fichiers de ce type. C’est la raison pour laquelle il existe un code de TYPE de fichier (le véritable format du fichier) qui est distinct du code CREATEUR (l’application par défaut, facile à modifier). L’existence de codes distincts pour le type et le créateur coexistant dans le système de fichiers nous a aussi permis d’éviter d’encombrer le nom de fichier avec les informations sur le type de fichier ; il me semblait que c’était là une supériorité non négligeable de notre approche par rapport aux autres.
La base de données du bureau consistait en une mémoire tampon listant les liens entre les types, les créateurs et les icônes qui les représentent, sous forme de ressources. Étant donné que les liens d’applications – c’est-à-dire des ensembles de ressources liées contenant des informations sur l’icône et le type de document – étaient enregistrées dans la plage de ressources des applications, il suffisait, pour installer une application, de copier les ressources appropriées de cette application vers le bureau. Les informations redondantes, c’est-à-dire les informations de type et de créateur du répertoire, ainsi que les informations de liens se trouvant dans les plages de ressources des applications, permettaient de reconstituer la base de données à tout moment sans perdre la moindre information. Il s’avère que ceci a été important dans les premiers temps.
Naturellement, on a procédé à un usage intensif des ressources pour gérer les données qui n’étaient pas propres aux applications comme les menus et les chaînes de caractères, qui pouvaient être localisées en plusieurs langues. Grâce à ResEdit, les traducteurs pouvaient rapidement produire des versions localisées des applications sans avoir besoin de toucher au code source.
Quand j'ai réussi à convaincre Andy Hertzfeld de l’utilité du Gestionnaire de Ressources, il a accepté de réécrire la plus grande partie du code de la bibliothèque ToolBox afin de l’exploiter, ce qui a permis de gagner pas mal de place en mémoire morte, tout en nous facilitant la tâche de localisation des applications.
Adam: Si je comprends bien, le système adopté par Mac OS X qui reprend le système Unix des extensions dans les noms de fichiers pour faire correspondre des documents à des applications est un peu un pas en arrière, non ?
Bruce: Oui et non. La justification originelle derrière cela était que Mac OS X devait être compatible avec les conventions de nommage de fichiers de Windows, et pour ce faire nous devions forcer l'utilisation des extensions dans les noms de fichiers. En raison du nombre élevé de situations amenant un fichier à quitter le paradis Mac pour le monde cruel où les extensions sont exigées, on considérait comme impossible de traduire les noms de la convention Mac (avec types et créateurs) vers la convention du monde d'en face. Pour ce qui est de la compatibilité, ça a marché.
Mais avec le temps c'est devenu évident qu'il est difficile de réaliser ceci correctement, et le mécanisme originel avec la redondance d'informations sur le type, permettant à l'utilisateur de nommer les fichiers comme il veut, était plus flexible et moins sujet à erreur. Il s'est avéré que Mac OS X avait encore besoin de la notion de créateur, par laquelle des documents donnés peuvent être ouverts par des applications spécifiques, donc cette information est enregistrée dans la plage de ressources du fichier (ce qui est en soi une énormité, puisque Apple décourage officiellement l'utilisation de la plage de ressources), plutôt que simplement dans le code créateur.
Au final l'approche de nommage de fichiers avec extensions a fonctionné, mais avec un peu moins d'élégance que l'approche originelle.
Bruce: C'eut été bien. J'avais bien quelques idées en tête, mais quand il fallu les caser dans la ROM 64K, il ne restait plus que de la place pour le gestionnaire de ressources. C'était un réel effort de la part de tout le monde pour réaliser le code le plus compact possible. Le gestionnaire de ressources faisait 3 K, et le Finder 46 K - assez incroyable comparé à la taille des applications actuelles !
Bruce: J'ai quitté Apple au printemps 1984 après avoir terminé une version "finale" du Finder. Je suppose que je cherchais seulement à faire autre chose. Il me fallait une pause après toutes ses années intenses à travailler sur le Mac. Avoir travaillé dans l'équipe du Mac avec tous ces gens fantastiques est l'une de mes expériences les plus enrichissantes et je garde toujours d'excellents souvenirs de cette époque.
Bruce: Après Apple, j'ai suis entré chez Adobe où j'ai travaillé sur pas mal de petits projets, comme par exemple un spooler pour la LaserWriter. J'y ai aussi rencontré quelques diplômés de Carnegie Mellon et, pour faire court, ils m'ont convaincu de m'y inscrire (Chuck Geschke, l'un des fondateurs d'Adobe, détient un doctorat de l'Université Carnegie Mellon). Les études universitaires ont été une expérience fantastique. Pendant mes études, j'ai aussi été assistant à l'université d'Oslo, en Norvège, j'ai fait du consulting chez Apple et j'ai participé à quelques start-up hors du commun. Pour ma thèse de doctorat, j'ai décrit un langage de programmation basé sur la contrainte et orienté objet appelé Siri. Si j'en ai un jour le temps, j'aimerais vraiment le réimplémenter.
Mon diplôme en poche, je suis retourné chez Apple en tant que consultant pour le groupe de technologies avancées et j'y ai travaillé sur un projet appelé LiveDoc avec notamment Tom Bonura et Jim Miller. Avec LiveDoc, nous avons essayé de structurer automatiquement les documents, de telle sorte que des agents différents puissent déterminer que par exemple, 555-1212 est un numéro de téléphone et 124 rue Gambetta est une adresse et proposer des actions en fonction de ce qu'ils ont reconnu. C'était très gai et j'aurais bien aimé disposer de LiveDoc pour Mac OS X aujourd'hui. L'SBook de Simson Garfinkel propose certaines options similaires dans une application PIM.
<http://www.sbook5.com/>
Mais aucun de ces projets n'était vraiment une réponse au problème que je me posais, à savoir : comment concevoir un explorateur qui gérerait tous types de données, des messages e-mail aux documents en passant par les fichiers de musique, tout en proposant un mécanisme unifié pour l'organisation, la recherche et l'affichage de ces informations ?
J'ai commencé le projet iFile en 1997 dans ce but, et j'ai travaillé dessus pendant deux ans, avant de le mettre en veille pour me consacrer au lancement de mon autre société, Marketocracy, qui m'occupe depuis le milieu de l'année 1999.
Marketocracy est une société de fonds communs de placement que j'ai créée avec mon associé Ken Kam. Notre équipe a conçu un site Web - à l'aide de Macintosh - qui fait tourner WebObjects et une base de données FrontBase pour permettre à plus de 50.000 personnes dans le monde entier d'acheter et de vendre des actions en temps réel (mais avec de la monnaie virtuelle) et de se constituer un modèle de portefeuille d'actions. Nous fournissons une grande variété d'outils pour aider nos utilisateurs à devenir de meilleurs gestionnaires de portefeuille ; en observant leurs performances dans le temps et en les classant, nous sommes en mesure de trouver les personnes les plus douées dans le monde pour gérer nos fonds d'investissement. Notre fonds Masters 100, basé sur le top 100 de notre communauté, existe maintenant depuis plus de deux ans et nous a surpris nous mêmes par ses performances impressionnantes et son faible risque. Il a eu un rendement de plus de 39 % depuis son lancement, dans un marché particulièrement plat, avec un beta (mesure relative de la sensibilité de la performance d'un investissement par rapport à une évolution de la performance de son indice de référence, NdT) de 0,47 - moitié moins risqué que le marché !
<http://www.marketocracy.com/>
Bruce: Je viens de me remettre à iFile (c'est juste un nom de code), là où je l'avais laissé en 1999. iFile est un navigateur d'informations sur le bureau, comme le Finder, mais avec une architecture sérieusement améliorée. Il s'appuie sur une base de données orientée objet que j'ai développée moi-même et qui permet de lier entre eux et d'organiser des objets de tous types. A la base du système d'organisation se trouve ce que j'appelle une "collection," qui se différencie d'un dossier par le fait qu'un objet peut exister dans plusieurs collections, mais dans un seul dossier. Les collections sont un peu comme les albums photo de iPhoto, ou les listes musicales de iTunes, mais elles peuvent contenir n'importe quoi: des fichiers texte, des images, des messages email, des fichiers musicaux, des contacts, des notes, des rendez-vous, etc. Ça fait penser à un amalgame de BFS (BeOS Filing System) et BeOs Tracker, mais c'est en fait beaucoup plus général, et on peut l'utiliser dans n'importe quel système de fichiers avec les pilotes adéquats.
La première application évidente de la technologie iFile est l'organisation de photos, un domaine que iPhoto gère déjà très bien. Mais iFile offre des fonctionnalités supplémentaires d'organisation par métadonnées (il peut pour l'instant gérer jusqu'à 46 éléments de métadonnées par image), et il devrait fonctionner beaucoup plus souplement qu'iPhoto sur les grosses collections. Mais iFile n'est pas qu'un simple catalogue photo: c'est un navigateur d'informations généraliste qui peut être utilisé de plusieurs façons et il peut facilement intégrer des sources d'infos différentes comme un PIM, le courriel et la musique, par exemple. Je crois que la version que je diffuserai aura beaucoup plus de fonctionnalités dans ces domaines.
C'est possible. Je crois qu'il est plus complexe que je ne l'avais imaginé au début. Si je peux le ramener à un niveau où un nouvel utilisateur peut l'assimiler facilement, il pourrait s'avérer un bon remplacement pour le Finder.
Bruce: En 99, je l'ai montré d'abord à l'équipe du Finder, puis à Avie Tevanian, et enfin à Steve Jobs. Je crois qu'Apple se concentrait sur la résolution des derniers problèmes liés à la sortie prochaine d'OS X, et que ce n'était pas le moment pour eux d'envisager de changer le Finder. Je crois qu'ils ont été intéressés mais qu'ils avaient déjà pris une autre direction et qu'il était trop tard pour profiter de la technologie d'iFile. En voyant l'historique d'OS X, je crois qu'ils ont bien fait.
Bruce: Dans la version actuelle d'iFile, l'utilisateur doit préciser à iFile quels sont les fichiers à suivre, en les faisant glisser dans l'espace de travail d'iFile. Ceci fait, iFile recense tout changement affectant le contenu des dossiers et met automatiquement à jour la base de données. Par exemple, l'utilisateur peut mettre le dossier Images dans l'espace de travail afin de pouvoir afficher n'importe laquelle d'entre elles, constituer des collections, etc, sans avoir bien sûr à copier ou déplacer la moindre donnée. iFile respecte la structure de vos répertoires et ne modifie jamais rien directement, au contraire d'iPhoto qui lui copie les images dans son propre répertoire.
La version d'iFile qui est sortie n'exige pas de l'utilisateur qu'il précise quels dossiers doivent être scannés. A la place, iFile va fournir une vue du répertoire de l'utilisateur, et automatiquement, scannera en arrière-plan fichiers et dossiers.
Adam: Bien ! Moins les utilisateurs doivent en faire, mieux c'est. En fait, quelque soit le système de fichiers, un des gros problèmes est que seules quelques personnes font l'effort de catégoriser et gérer leurs données pour pouvoir les retrouver plus tard de manière fiable. iFile peut-il classer automatiquement les fichiers par catégorie selon leurs contenu et métadonnées.
Bruce: Oui, il est capable de le faire. Les collections sont une façon de classer automatiquement les fichiers selon leurs propriétés. Parce qu'iFile maintient un fichier métadonnées dans la base de données objets, il peut rechercher et trier les métadonnées très vite pour sélectionner les fichiers appropriés. Les collections sont aussi "live" : en particulier, si des fichiers sur le disque correspondent avec les spécifications d'une collection, ils sont automatiquement ajoutés à cette collection, sans se préoccuper de savoir si la collection est en train d'être regardée. On peut imaginer toutes sortes de scripts AppleScript qui pourraient être déclenchés par des événements de ce type.
Les collections rassemblent aussi des fichiers d'après leur contenu. Plutôt que de chercher des mots seuls comme Google le fait, les collections cherchent des phrases-clé : un mot ou une phrase. Les fichiers qui contiennent n'importe quelle phrase-clé spécifiée sont automatiquement ajoutés à la collection.
Et donc, ce que font les collections, c'est de proposer une autre façon de segmenter l'info que vous possédez déjà sans qu'il soit nécessaire d'importer vos données ou de les réorganiser complétement.
Adam: Que penses tu d’une fonctionnalité du genre outil de classement bayésien qui évaluerait de manière statistique le contenu d’un fichier, un peu à la manière de certains filtres anti-spam ou du logiciel de classement de courriers électronique POPfile ? Cela simplifierait probablement encore davantage le travail de l’utilisateur.
Bruce: C’est une excellente idée qui fait l’objet de discussions depuis un bon bout de temps. En fait, Apple a travaillé sur un projet qui était basé là-dessus. Son nom était Apple Piles et consistait en des regroupements automatiques de fichiers, basés sur leur contenu.
<http://www.th
eregister.co.uk/content/archive/30360.html>
L’un des défis est de déterminer une fonction de similitude appropriée: comment décider a priori ce que seront les collections, pour éviter de se retrouver avec des centaines de collections contenant un seul fichier, ou très peu de collections avec des milliers de fichiers ? Cela demandera encore pas mal de travail.
Bruce: Absolument. Une collection est principalement un dossier intelligent, basé sur un critère de recherche. Par exemple, il est très simple de créer une collection qui regrouperait toutes les images prises par un appareil photo particulier en spécifiant "<Modèle> est '2500' et <Marque> est 'Nikon'", vu que ces données sont disponibles dans les métadonnées EXIF de l’image. De même, les métadonnées telles que les marqueurs ID3 pour la musique, les informations relatives aux images comme la résolution, la largeur et la hauteur, les données liées aux fichiers tels que les noms de fichiers, les dates de création et de modification, la taille, etc. sont toutes stockées dans la base de données pour le classement et pour pouvoir être récupérées ensuite.
Ainsi, on peut dire que les collections ont en fait trois mécanismes de regroupement : manuellement par glisser-déposer ; automatiquement par le biais de critères de recherche faisant appel aux métadonnées ; et automatiquement par recoupement avec une expression clé.
Adam: L'architecture d'iFile semble vraiment intéressante, mais je suspecte que tout n'est pas rose, aussi bien dans les détails qu'au niveau de l'interface. Est-ce que iFile s'en tient à l'actuelle métaphore fichier/dossier (en dépit du changement de dénomination pour "collections") ou bien cela impliquera-t'il que nous devrons changer notre façon d'interragir avec nos données?
Bruce: Tu as raison de penser que le diable se cache dans les détails d'un projet. Je suis justement en train de travailler sur la meilleure façon de présenter toutes ces informations d'une façon intuitive et appropriée, et je pense que je m'en approche, mais il y a certainement encore beaucoup de pain sur la planche.
iFile commence avec des aspects familiers: des fichiers avec des icônes et une organisation sous forme de containers (ceux-ci pouvant être aussi bien des dossiers que des collections), mais cela va bien plus loin avec des tas de possibilités de présentation et d'affichages. Beaucoup d'affichages proposent des prévisualisations des contenus des fichiers et, dans le cas de fichiers textes, iFile crée automatiquement des hyperliens vers des collections en relation, depuis l'intérieur même du texte. C'est difficile à expliquer, mais une fois que vous utiliserez iFile vous verrez que certaines vues vous donneront réellement l'opportunité de manipuler vos fichiers sous diverses perspectives.
Plus vous donnerez de l'information à iFile concernant la façon dont vous voudrez visualiser vos données, en définissant des collections, plus il pourra vous aider en faisant des index croisés et en mettant en relief les inter-relations, là où elles n'étaient pas si claires auparavant.
Adam: Y a t'il, au sein d'iFile, des choses sur lesquelles vous travaillez qui seraient totalement au-delà de ce que la plupart des utilisateurs seraient capables de comprendre? Beaucoup de gens veulent juste qu'on leur dise ce qu'ils doivent faire et quelque chose dans la flexibilité sous-tendue par iFile risque de leur passer largement au-dessus de la tête, à moins qu'iFile soit capable d'observer leurs actions et de les transformer automatiquement en collections.
Bruce: Je suis d'accord qu'iFile peut être très intimidant, surtout pour les nouveaux utilisateurs: il y a beaucoup de choses très différentes qu'iFile peut faire et ces choses ont besoin d'être immédiatement gratifiantes quand vous les utilisez. Créer des collections automatiquement est une bonne approche, et en créant des collections utiles, non seulement à base d'images mais aussi de documents et de courriels, je pense que la puissance de cette technologie deviendra encore plus apparente. J'ai pour plan d'implémenter la plupart de tout ça dans les mois à venir, alors, restez à l'écoute! Pour quiconque serait intéressé par cette nouvelle technologie et qui désirerait être contacté lorsqu'une version publique sera disponible, enregistrez-vous sur le site ci-dessous et je vous tiendrais informés. Je serai très heureux d'entrer encore plus dans les détails des prochaines versions disponibles dans un numéro futur de TidBITS.
<http:// www.ingenuitysoftware.com/>
Adam: Bruce, merci d'avoir pris le temps de discuter avec moi, nous sommes tous impatients de voir ce que tu vas nous apporter avec iFile. Qui sait, maintenant qu'Apple a stabilisé OSX, ils trouveront peut-être le temps de se pencher à nouveau sur ton bébé.
par Brady Johnson <brj@fremontlaw.com>
J'ai une forte impression de déjà vu... Je me souviens avoir, de par le passé, écrit des articles pour TidBITS et traitant du pollupostage, augmentant, à chaque article les statistiques malheureuses sur le volume de pourriels (spam) circulant sur le réseau. Je commence toujours par jeter un coup d'oeil au site de Brightmail et autres qui traquent le pourriel (spam) pour voir dans quelle mesure les efforts récents ont eu un impact. Malheureusement, les nouvelles ne sont jamais bonnes. Même le Congrès américain le reconnaît piteusement dans son introduction au projet de loi CAN-SPAM : " on estime que les messages électroniques commerciaux non-sollicités comptent pour plus de la moitié du traffic en courrier électronique, ce qui représente une hausse de 7 % en 2001, et le volume continue d'augmenter."
<http://db.tidbits.com/g
etbits.acgi?tbser=1169>
En réalité, selon Brightmail, le volume de spam grimpe encore plus vite que le mercure dans un thermomètre un jour de canicule. En 2002, le pollupostage représentait pour 40 % de tout le courrier électronique, ce qui veut dire que, si le chiffre du Congrès de 7 % est correct, il y a eu une augmentation de presque 600 % entre 2001 et 2002. A la fin de 2003 le chiffre est monté jusqu'à 58 %. Si cette tendance continue, 65 % de nos courriers électroniques seront des pourriels non-sollicités d'ici la fin 2004.
<http://www.brightmail.com/sp
amstats.html>
Pour lutter contre cette marée noire, le Congrès américain a promulgué la loi "Controlling the Assault of Non-Solicited Pornography and Marketing Act," ou CAN-SPAM. Le Président Bush a signé le projet de loi le 16 décembre 2003 et il est en vigueur depuis le premier janvier 2004.
<http://www.spamlaws.com/
federal/108s877.html>
CAN-SPAM a suscité beaucoup de discussions et de débats ; une grande partie de la communauté en ligne pense que cette loi est l'équivalent d'un pacte avec le diable alors que la communauté marchande l'accueille comme un pas en avant important dans la lutte contre le pollupostage.
En lisant les divers commentaires sur CAN-SPAM, on voit très vite qu'un désaccord de base tourne autour de la définition du "spam." Pour un bon nombre de gens qui utilisent Internet fréquemment, un pourriel est tout message non-sollicité distribué massivement, quelle que soit la source. Pour ces derniers, CAN-SPAM lance une offensive contre une toute petite partie de la totalité de ces envois tout en légitimisant le reste. La communauté marchande et d'autres trouvent plutôt que l'envoi massif de messages électroniques qui ne sont ni trompeurs ni frauduleux ne représente que le libre exercice commercial de leurs droits de s'exprimer en public, et que ce n'est pas plus répréhensible que les courriers commerciaux envoyés par voie normale. Ils prétendent donc que leurs envois par voie électronique ne devraient pas figurer dans la définition du "pollupostage." Pour ces utilisateurs, CAN-SPAM représente un grand pas en avant.
Qu’est ce que le “Spam” de toute façon ? Je suis obligé de vous indiquer que le terme anglais “spam” désigne en fait un produit rosé dérivé de la viande fabriqué par la société Hormel. Hormel a tardivement réagi à l’utilisation du nom de son produit pour désigner du courriel nuisible et essaie actuellement d’empêcher le dépôt de marques déposées qui incluent le terme “spam” comme par exemple SpamArrest.
<http://abcnews.go.com/sections/scitech/Business/techtv_spam030801.html
>
Mais pour la plupart du monde, le terme “spam” fait simplement référence à un courriel provenant d’un étranger essayant de vous vendre un produit, vanter une position, publiciser un site Web commercial, ou influencer l’opinion du lecteur d’une quelconque façon. Depuis que des lois anti-pollupostage ont été promulguées dans plusieurs états américains , la définition a changé et s’est précisée comme étant un “courriel commercial non sollicité” ou “UCE (unwanted commercial email)” en exemptant les courriels non-commerciaux tels les courriels provenant des organisations politiques et charitables. CAN-SPAM afine encore plus la définition de ce qu'est un pourriel.
CAN-SPAM utilise le terme “spam” seulement dans l’acronyme du titre et dans un des commentaires initiaux. (Dans une loi, les commentaires ne sont pas liées à une obligation légale et sont seulement des énoncés de droit pour aider les tribunaux à interpréter ladite loi). CAN-SPAM définit le “courriel électronique commercial” comme étant un courriel “dont le but principal est l’annonce ou la promotion d’un produit ou service commercial”. Les sollicitations provenant d’organisations politiques ou charitables sont encore exclues de cette définition, ainsi que “les messages transactionnels et relationnels” qu’on peut définir comme des courriels provenant d’une source avec laquelle vous avez un lien existant quelconque.
CAN-SPAM donne à la FTC (Federal Trade Commission - Bureau fédéral du Commerce) le pouvoir de changer la définition des “messages transactionnels et relationnels” à condition “qu’une telle modification soit nécessaire pour s’adapter aux changements dans la technologie ou les usages du courrier électronique et que cette modification accomplisse les buts de ladite loi”. Par contre, la FTC n’a pas le pouvoir de changer la définition du “courrier électronique commercial”.
Les principales dispositions de la CAN-SPAM -- Les restrictions les plus sévères de la CAN-SPAM portent sur certains types de courriels frauduleux et malhonnêtes. Ceux-ci peuvent apporter au polluposteur des peines criminelles substantielles de trois ans pour un premier délit, et cinq ans pour une infraction ultérieure, ou pour un courriel commercial frauduleux qui serait envoyé à la suite d'une autre tromperie. Cela inclut, par exemple, les nombreux messages sensés provenir de leaders politiques exilés cherchant de l'aide pour blanchir le magot d'une fortune dissimulée, si seulement le récepteur peut d'abord leur fournir un numéro de compte en banque valide. Ces messages - qui sont déjà sujet à poursuites sous les lois criminelles existantes - font l'objet d'une plus grande criminalisation avec la CAN-SPAM .
D'autres actes criminels consistent à utiliser un ordinateur, un serveur, ou un domaine pour envoyer ou relayer un courriel commercial sans la permission légale de son propriétaire, et d'utiliser de faux en-têtes ou des sujets trompeurs. Ces activités font aussi l'objet d'actions civiles et d'amendes, à ajouter aux poursuites criminelles .
Un élément très critiqué de la loi est la disposition qui lui fait avoir le dessus sur les lois de chaque état, concernant le pollupostage, à quelques rares exceptions près. Les seules lois des états qui survivent à cette éviscération sont celles qui interdisent la falsification et la tromperie dans les courriels commerciaux, comme les lois de l'état de Washington, ou la majeure partie de celles de l'état de Californie, ainsi que celles qui n'affectent qu'accidentellement le courrier électronique. Par exempl, pour ces dernières, il y a les lois générales sur la propriété informatique, sur la protection du consommateur, et d'autres, dont l'application peut parfois inclure le courriel. Cela signifie que beaucoup de lois étatiques existantes ont été abandonnées et que la loi californienne récemment adoptée, qui devait prendre effet cette année, a été pratiquement rendu caduque dans la plupart de ses aspects matériels.
Pour ce qui est de l’application de la loi, CAN-SPAM ne permet pas aux particuliers victimes des spammeurs d’agir en justice et de porter plainte pour violation de la réglementation. Les personnes habilitées à agir sont le FTC (NdT : Federal Trade Commission, Commission fédérale du commerce, correspondant à la Direction Générale de Concurrence, de la Consommation et de la Répression des Fraudes en France) et d’autres agences fédérales gouvernementales, les procureurs généraux des états et les Fournisseurs d’accès Internet. Il faut noter que les Fournisseurs d’accès Internet ont souvent leur propre réglementation sur la bonne utilisation de l’e-mail et sur le spam. La nouvelle loi fédérale ne se mêle pas de ces réglementations privées, ce qui signifie qu’un FAI garde son autorité pour ce qui est de ses conditions d’utilisation relatives à la radiation ou suspension d’un utilisateur, voire pour lui réclamer des dommages-intérêts pour non-respect des règles. Le fait de conserver l’autorité du FAI en la matière garantit une possibilité de recours indépendante contre les spammeurs, même si elle est rarement utilisée.
Est-ce que CAN-SPAM va fonctionner ? A vrai dire, je ne le crois pas. CAN-SPAM est un bon début, mais à mon avis il a trop de défauts pour qu’il puisse arrêter voire seulement réduire le spam.
Mais il y a quand même des points positifs : CAN-SPAM est une loi fédérale et par conséquent elle s’applique sur l’ensemble du territoire des Etats-Unis d’Amérique. Cela permet d’éviter les incohérences dues aux différentes législations qui existaient dans les états qui ont promulgué des réglementations anti-spam. Cela permet également de résoudre les problèmes de compétence juridictionnels sur la question de savoir si un état donné était compétent pour contrôler une entreprise située en dehors de ses frontières. Ces litiges juridictionnels étaient assez courants sous le régime étatique (NdT : par opposition à fédéral) de la législation anti-spam.
Une autre avancée est de voir nommées et définies d’un point de vue juridique les différentes "violations aggravées", en ce sens que cela simplifiera le travail des demandeurs en justice.
Par ailleurs, tout ce qui va dans le sens d’augmenter la responsabilité des spammeurs peut avoir un impact sur l’équilibre économique du spam. Si le fait d’envoyer du spam pouvait aboutir à une peine de prison, les spammeurs commenceraient probablement à se demander si les bénéfices qu’ils en tirent valent le risque potentiel qu’ils prennent. Et bien qu’une responsabilité accrue n’aura probablement pas un impact sérieux sur les incorrigibles qui ignorent toute interdiction ou prescription légale jusqu’à ce qu’ils soient arrêtés, on peut penser que l’augmentation du risque d’une peine de prison ou encore des amendes significatives vont faire réfléchir à deux fois des entreprises qui ont pu envisager de contourner la loi auparavant.
Mais malgré ces bons points, les inconvénients du CAN SPAM abondent. Examinons-les.
Problèmes internationaux -- Malheureusement, CAN-SPAM ne s'applique qu'aux Etats-Unis. C'est vrai, la loi US et les traités internationaux confèrent une juridiction aux courts US pour traiter des problèmes naissant au niveau international s'ils touchent les Etats-Unis. Mais alors que ça a l'air bien sur le papier, il souffre de deux problèmes majeurs.
Premièrement, il y a le problème de la mise en application réelle. Les spammers opérant hors des Etats-Unis sont souvent non soumis aux cours US, et même quand ils le sont, tout jugement ou ordre de la cour ne sert à rien s'il ne peut être mis en application. Ce fait signifie que la seule manière qu'une agence de mise en application peut contraindre un spammer étranger avec la loi est via la pression diplomatique des Etats-Unis. Spectacle de mains : combien de personnes pensent que renforcer la loi US sur le spam est susceptible de devenir une haute priorité pour les efforts diplomatiques pour bientôt ? Maintenant, si nous pouvions montrer que les spammers étaient en fait les premiers rangs pour des organisations terroristes...
Deuxièmement, l'approche du retrait du CAN SPAM est directemement à l'opposé avec l'approche prise par beaucoup - peut-être la plupart du reste de - le premier monde. L'Union Européenne a adopté une directive (un document de politique) qui établit une approche participative. Chaque nation membre individuel doit ensuite voter des lois spécifiques mettant en oeuvre la directive (Le premier URL ci-dessous va à la version en anglais de la directive ; le second URL conduit aux versions dans d'autres langages.)
<http://europa.eu.int/eur-lex/pri/en/oj/dat/2002/l_201/l_2012002 0731en00370047.pdf>
<http://europa.eu.int/info rmation_society/topics/ecomm/useful_information/library/legislation/text_en. htm#dir_2002_58_ec>
L'Australie a aussi adopté une loi de participation interdisant largement les mels commerciaux envoyés aux australiens. En bref, comme il semble vraisemblable que la plupart des spams vient des Etats-Unis ou revend des produits et services de firmes basées aux Etats-Unis, la mise en particpation apparaît être le modèle de choix dans la plupart du monde technologiquement développé, les Etats-Unis se trouvant hors du reste de la communauté globale.
Ces approches conflictuelles sont susceptibles de causer des problèmes similaires à, peut-être pire que, ceux qui existaient aux Etats-Unis avant que la loi fédérale ne soit passée, et quand il y avait divers statuts d'état avec des mandats et des normes différents. Aux Etats-Unis, au moins tous ces états étaient soumis aux mêmes règles du gouvernement fédéral et générales d'analyse et d'interprétation légale. Sur la scène internationale, les problèmes provoqués par ces modèles anti-spam largement en conflit sont suceptibles d'être pire. Comme la loi US est moins restrictive, il m'apparaît que les nations de l'U.E. et l'Australie peuvent être submergés de spam qui est légal aux Etats-Unis, mais illégal dans leur pays.
Les problèmes de l’Opt-Out -- Le modèle opt-out est un choix peu judicieux qui requiert que les destinataires contactent l’expéditeur pour décliner la réception des messages futurs. Si cela peut fonctionner avec les services marketing légitimes qui généralement incluent un lien de desinscription qui fonctionne (par email ou depuis un serveur Web), la majorité du spam n’est pas légitime, et utilise ce type de lien de désinscription comme un moyen de valider l’adresse du destinataire ou de récupérer d’autres adresses. En encourageant les gens à utiliser ces liens d’opt-out, CAN-SPAM risque en réalité d’augmenter la quantité de spam illégal. Il augmente également le risque d’usurpation d’identité et autres exactions visant l’utilisateur d’Internet inexpérimenté.
Les problèmes du contrôle renforcé -- CAN-SPAM fait reposer la totalité de la responsabilité du respect des règles sur les épaules déjà bien chargées des services de police fédéraux et de chaque état, ce qui n’est pas le signe d’un empressement marqué à contrecarrer le spam. Il est probable que les FAI vont prendre les choses à leur charge mais la plupart des FAI manquent des ressources financières nécessaires pour poursuivre les spammeurs dans d’autres pays ou pour faire face aux coût de poursuites de nature à les mettre à terre.
Pour être honnête, avant que la question du CAN-SPAM ne se pose, la répression du spam devra se faire au niveau individuel, fréquemment dans des états sans politiques anti-spam solides. La plupart des individus ne peuvent pas à titre personnel faire face aux dépenses d’une véritable enquête anti-spam, ils sont dans la même situation que les FAI. Mais CAN-SPAM ne permet pas aux victimes individuelles d’engager des poursuites pour violation des engagements pris. Il semble contreproductif de ne pas autoriser les poursuites à titre individuel car cela pourrait aider le combat global contre le spam et pourrait également conduire à des résolutions intéressantes pour les victimes (les utilisateurs finaux) dans les cas ou le spammeur pourrait être retrouvé et s’avérerait solvable.
Enfin, même lorsque les spammeurs seront traînés devant les tribunaux, CAN-SPAM aura des manques. Pour l’instant, si l’on s’en tient à "l’objet premier" de la définition du spam qui indique que les spammeurs peuvent inclure des notes personnelles dans leurs messages qui incidemment offrent quelque chose à vendre, ils pourront arguer que la sollicitation n’était pas "l’objet premier" de l’email. Je suspecte que la plupart des gens qui lisent ce texte ont reçu des spam comportant des phrases comme : "Salut ! Comment allez-vous ? Moi je passe du bon temps. À propos, je suis tombé sur ce produit <insérez le produit ici> et j’ai pensé que vous pourriez être intéressé." Bien qu’on puisse penser qu’une cour de justice ne s’arrêtera probablement pas à cette ambiguïté, c’est le genre de chose qui devra presque certainement être validé dans une cour avant d‘avoir un impact réel, délayant de fait tout bénéfice potentiel du dispositif jusqu’à ce qu’une des forces de justices autorisées décide de poser la question à un juge. C’est une autre des raisons pour lesquelles l’action individuelle aurait pu être une bonne chose – Il semble vraisemblable qu’un individu ou un groupe de consommateurs aurait clarifié ce point bien plus vite que ce à quoi je m’attends des représentants officiels de la loi.
Synthèse -- Dans mes articles précédents, je suis arrivé à la conclusion que si le spam était mis hors la loi, seuls les hors la loi vont utiliser le spam. Un nombre croissant de spams violent déjà les lois actuelles de notre état et pourtant n’ont été ni éliminés ni même réduits en dépit de cette violation. Les entreprises légitimes vont essayer de se plier aux règles, mais les autres, moins que légitimes vont continuer à violer la loi jusqu’à ce qu’elles soient physiquement arrêtées.
Au final, CAN-SPAM est un bon début, mais il est beaucoup trop faible pour constituer un outil anti-spam efficace. Comme c’est le cas avec les lois des états, il va inciter les entreprises légitimes à ne pas utiliser le spam (quoique peu d’entre elles l’utilisent), ; mais il n’aura aucun impact sur les spammers en dehors des juridictions américaines, et donc qui ne sont pas assujettis aux lois américaines, pas plus sur les spammeurs peu scrupuleux qui vont ignorer les lois jusqu’à ce qu’on les arrête. Le manque de cohérence avec les lois anti-spam adoptées dans les autres parties du monde risque de contrecarrer les stratégies que ces nations déploient contre le spam en incitant au développement d’un spam depuis les Etats-unis pour contourner leurs lois locales.
Pour finir, CAN-SPAM consiste à dire aux spammeurs qu’ils peuvent spammer tant qu’ils sont suffisamment adroits pour conduire leurs pleins camions de spam au travers des trous énormes que prévoit le statut. Ce qui est sans doute le point le plus décevant c’est que nous avons dû attendre pendant des années pour une loi fédérale anti-spam, et celle dont nous héritons est loin d’être aussi bonne qu’elle aurait pu l’être, voire moins bonne que certaines lois locales déjà existantes. C’est une honte, et sans aucun doute une honte de celles avec lesquelles nous devrons vivre un bon moment.
[Brady Johnson est un avocat de Seattle qui déteste vraiment le spam.]
par la rédaction de TidBITS <editors@tidbits.com>
Versions localisées d'AppleWorks -- Dans l'annonce par Apple de la dernière mise à jour d'AppleWorks il n'a pas été clairement expliqué que des versions localisées étaient publiées simultanément. A noter que la version française n'est pas encore mise à jour. (2 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2145>
Baptème du feu pour Habeas -- Habeas fait face à son premier défi dans la guerre contre le pollupostage ("spam") . Ont ils les moyens de poursuivre en justice les nuisibles qui ont falsifié leurs entêtes contenant des poêmes haiku et protégés par droit d'auteur ? C'est l'avenir de la société Habeas qui est en jeu. (5 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2144>
Apple proposera-t'elle une gamme complète de logiciels audio ? -- Quelles seront les réactions des professionnels de l'industrie audio face aux dernières annonces d'Apple - sorties de nouveaux logiciels et annonces d'autres programe ? (2 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2143>
iPhoto 4 premières impressions -- Avant toute autre considération, tous les participants sont d'accord pour dire que les performances accrues de iPhoto sont parmi les meilleurs bon points de la suite iLife '04. (2 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2142>
Les publications et les sites web sans but lucratif peuvent réimprimer ou créer des liens vers nos articles en référençant leur origine. Pour les autres, contactez-nous, SVP. Nous ne garantissons pas l'exactitude de nos articles. Caveat lector. Les noms de publication, de produit et de société peuvent être des marques déposées. TidBITS ISSN 1090-7017.
| Accueil | Archives francophones de TidBITS | Sommaire des quatre derniers TidBITS traduits | L'Equipe francophone de TidBITS | Consignes pour traduire TidBITS | LexBITS | Tronchoscope des traducteurs |