fplanque: blog geek

Je crois qu'on peut désormais affirmer sans trop de risques, qu'aux côtés de Jonathan Ive, Apple a définitivement réuni la meilleure team de design industriel de ce début de siècle! :yes:

Eh bien ils ont encore frappé: voici Mighty Mouse! En réponse à ceux qui réclament une souris à 2 boutons pour le Mac, Apple présente une souris sans boutons qui agit comme si elle en avait 4! Plus molette de défilement multi-directionnelle!

On peut cliquer à gauche, à droite, au mileu, sur les côtés et surtout: on peut faire défiler la petite boule grise que l'on voit sur le dessus, et ce dans n'importe quel sens, pas seulement vers le haut et le bas comme avec la plupart des souris "évolués" que nous connaiss(i)ons!

Apple avait besoin du clic droit pour convaincre les utilisateurs Windows de migrer vers le Mac. ("je sais de quoi je parle": j'ai essayé d'utiliser DreamWeaver sur le Mac de ma copine avec un seul bouton... c'est in-sup-por-ta-ble! Et même iTunes sans clic droit c'est pénible pour mettre à jour les infos!).

Mais là où c'est très fort, c'est qu'en plus du clic-droit, en plus du scroll multi-directionnel, en plus du design épuré... Apple propose aux utilisateurs Windows d'utiliser ce petit bout du "Apple Concept" dès à présent sur leur machine Windows! Apparemment les drivers sont fournis!

Je suis vraiment impressionné par la stratégie marketing: Apple nous vend des périphériques géniaux (le premier étant l'iPod) comptabiles PC jusqu'à ce qu'il ne reste plus que l'unité centrale... à remplacer par un Mac mini à 529€ pas cher seulement!

Je suis sûr que ça va marcher. Personnellement j'ai de plus en plus de mal à résister! :)

C'est quoi le prochain périphérique blanc compatible Windows? Un clavier évolué avec un design moins grotesque que ces horreurs de chez Logitech ou Microsoft? Des enceintes 5.1 sans fil? Un casque pour Skype?

Crypter les fichiers sur le disque dur, ça a pour unique but que si on vous vole la machine on ne puisse pas lire vos données (mots de passe ou autre) en analysant le disque dur. Windows XP intègre un système pour celà: propriétés du fichier > attributs > avancé... > cochez la case "crypter". C'est gratuit et ça marche. Pensez-y avant de partir en vacances! :P (Pensez aussi à faire un backup! ;D)

Le problème c'est que ça ralentit aussi l'accès aux fichiers puisque Windows doit en permamence crypter/décrypter à la volée. Un peu le même problème qu'avec les antivirus qui scannent tout en permanence...

Alors pourquoi faire ça sur un serveur plutôt que de mettre le serveur sous clef... et pui surtout déjà: pourquoi avoir un serveur sous Windows XP!? :!::?:

C'est simple: ici (au bureau) on a des serveurs web (Apache/PHP/MySQL) sur les machines de développement, et on s'en sert pour tester les modifications en temps réel. Mais évidemment, ces machines de développement sont plus exposées au vol que les serveurs. (Et je vous parle pas des portables...)

Et on ne voudrait pas donner nos codes sources à n'importe qui, n'est-ce pas? :roll:

A partir de là, crypter les bases de données et les fichiers PHP pose deux problèmes...

Tout d'abord, une fois les fichiers cryptés, les services Apache et MySQL ne peuvent plus y accéder! Solution: changer la configuration des services en question pour les faire tourner sous le nom de l'utilisateur qui à crypté les fichiers. Moi, ou vous, en l'occurrence! :P [ Service > Propriétés > Connexion ].

Ensuite, il y a un problème de performances assez ahurissant. Crypter le fichier InnoDB de MySQL semble avoir un impact limité. En revanche, crypter l'ensemble des fichiers PHP peut (par le jeu des include) multiplier le temps de génération des pages web par 6 ! :(

La seule solution que j'ai trouvée à ce problème pour l'instant, c'est de ne crypter que des fichiers choisis. Les fichiers de config en particulier (ceux qui contiennent des mots de passe en premier lieu) ainsi que d'autres fichiers stratégiquement choisis pour qu'on ne puisse pas faire grand chose sans eux.

Une solution qui serait peut être plus intéressante serait d'avoir un script qui crypte l'ensemble des codes sources le soir en partant et les redécrypte le matin en arrivant... en partant du principe que les PCs ont moins de risques de vol aux heures de bureau qu'en dehors. Je me demande s'il existe des solutions élégantes pour ça... :?:

Pour finir, une petite astuce pour avoir l'option Crypter/Décrypter directement dans le menu contextuel du fichier: avec RegEdit, il faut aller dans HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion \Explorer\ Advanced puis créer une Valeur DWORD nommée EncryptionContextMenu et lui assigner la valeur 1.

J'ai passé presque deux ans à développer b2evolution sur un écran plat de 15" en 1024*768. Et j'ai passé presque deux ans à croire que j'étais bien équipé! (Juste parce que je n'avais plus à subir la fatigue visuelle des tubes cathodiques du XXème siècle!) Arf' :roll:

Je me suis retrouvé comme un con ce week-end à essayer de débugguer ledit b2evolution depuis chez moi avec ledit petit écran que je croyais grand! Il faut dire qu'entre temps j'étais passé au double écran 18/19" 2 fois 1280*1024 au bureau. C'est à dire un bureau de 2560 * 1024 pixels, c'est à dire 2,6 millions de pixels, c'est à dire 3,32 fois plus que chez moi. Et ça fait une vraie différence!

Vous vous demandez pourquoi je parle en pixels et pas en pouces ou en centimètres? Parce que seuls les pixels déterminent la quantité d'informations que vous pouvez afficher simultanément!

Vous vous demandez pourquoi mon 19" ne fait que 1208*1024 et pas 1600*1200 ? Parce que j'aime bien que lesdits pixels soient d'une taille respectable. Trop de pixels sur une trop petite surface et vous pouvez effectivement afficher beaucoup d'informations, mais tout est écrit tellement petit, que ça fait mal aux yeux!

Concernant le deuxième écran, au début je ne l'ai branché que par curiosité, pour m'amuser un peu, pour essayer les possibilités de la carte graphique de mon PC, et surtout parce que personne ne se servait de cet écran ce jour là...

Aujourd'hui je serais prêt à mordre quiconque voudrait me le reprendre! :P

Bien sûr on travaille difficilement avec un oeil sur chaque écran! Je pense qu'on finit irrémédiablement avec un écran principal en face de soi et un écran annexe à côté. Mais cet écran annexe est incroyablement utile! Et pas seulement pour y laisser trainer une horloge et un player mp3!

Personnellement j'utilise cet écran avec 2 fenêtres principales: la console Javascript de Firefox et les résultats de recherche de PhpED. Lorsque l'on fait du développement Web, il est tout simplement indispensable de garder un oeil sur la console Javascript, faute de quoi on se retrouve avec des sites ou des applis pourris de bugs "qu'on avait pas vus"... et justement... J'hallucine en voyant le nombre d'erreurs qui viennent se logguer dans cette fenêtre en visitant des sites grand public... même développés par des SSII a priori respectables. (pas de noms, c'est pas le sujet! :P)

De même, les résultats de recherche dans une fenêtre sur le côté, ça permet de garder l'écran principal pour scroller dans le code, et l'écran annexe pour scroller dans la recherche. Avec des gros codes source, c'est pas superflu!

Idem avec Photoshop ou Dreamweaver: à chaque fois, le simple fait de pouvoir déplacer certaines palettes d'outils ou de résultats sur l'écran d'à côté, ça permet de libérer de place extrêment utile pour voir le document principal.

Pour finir, j'ambitionne également de garder un oeil sur la santé de mes serveurs avec quelques petites fenêtes de monitoring sur le deuxième écran... mais je n'ai pas encore trouvé l'appli adaptée...

Le côté obscur de tout ça: quand on ouvre un grand nombre de fenêtres simultanément, on est vite perdu dans la multitude de boutons dans la barre de tâches en bas de l'écran... idem avec Alt+Tab! Va aussi falloir se pencher sur ce problème là...

Most useful Fedora rundown I came accross this week B)

[NDA: Article écrit en Juin 1996, publié dans ST Magazine n° ? en ?]

STUT ONE est un logiciel vous permettant de réaliser un serveur Minitel avec un simple ATARI STF connecté à un Minitel. Nous vous avons parlé de ce logiciel à plusieurs reprises dans ST Magazine, et en particulier dans les numéros 72 et 105 où nous vous avions fourni, respectivement, les versions 2.6 et 3.0 du logiciel. Nous arrivons aujourd'hui au terme de cette longue aventure en levant le voile sur le code source de la version 3. Vous le trouverez sur la disquette accompagnant le magazine.

DEBALLAGE

En décompactant le fichier STUT_SRC.ZIP se trouvant sur la disquette [attaché à cette page web] vous obtiendrez une collection de modules C (*.C) avec leurs headers (*.H) ainsi que quelques fichiers ressource (.RSC) et le fichier liant tout ceci en un seul et même projet: STUT_3.PRJ.

Tout ceci totalise 1,5 Mega-octets de code source! C'est un chiffre relativement important, surtout si on le compare aux 500 Kilo-octets de code source de la version 2.6... Toujours est-il: prévoyez quelques 5 ou 6 Mega-octets de place libre sur votre disque dur si vous voulez pouvoir décompacter puis recompiler le logiciel...

RESSOURCES NECESSAIRES

Alors justement: de quoi avez vous besoin pour recompiler le logiciel? D'un disque dur avec de la place libre, bien sûr, mais aussi d'un compilateur C. Sachez que STUT ONE 3 a été développé avec Pure C version 1.1 (du 20 Mars 1993). L'utilisation de ce même compilateur pour recompiler le logiciel sera bien évidemment préférable à toute autre solution.

Ceci dit, si vous avez un minimum d'expérience avec le portage d'applications en langage C d'une plate-forme à une autre, ou encore d'un compilateur C à un autre, vous pourrez vous en sortir avec tout compilateur C/ATARI digne de ce nom, moyennant quelques retouches mineures du code source, de manière à l'adapter aux bibliothèques (*.LIB) fournies avec votre compilateur.

STUT ONE 3 étant une application d'assez grande taille (comparativement aux applications ATARI courantes), une machine équipée de 4 Mo de RAM est préférable pour le développement et la compilation. L'exploitation peut se faire sur une machine de 1 Mo de RAM si l'on s'en tient à un serveur Minitel d'envergure limitée.

Concernant la taille de l'écran, le minimum confortable est le monochrome 640 * 400 pixels. STUT ONE 3 peut néanmoins supporter une utilisation en mode "moyenne résolution ST", c'est à dire 640 * 200 pixels. Vous découvrirez que des fichiers de ressources spécifiques à ce mode sont inclus dans la distribution de code source. En tout état de cause, si vous avez la possibilité de faire fonctionner le logiciel en mode VGA (640*400, 16 couleurs), ne vous privez surtout pas!

Au niveau disque dur, si quelques Mega-octets sont indispensables à la compilation, il est envisageable de faire tourner un petit serveur sur une machine équipée uniquement de lecteurs de disquettes.

Finalement, STUT ONE 3 est un logiciel serveur Minitel, son utilisation nécessite donc l'emploi d'un ou de plusieurs Minitels. Vous avez besoin d'un Minitel pour vérifier votre travail et pour vous connecter à distance. Mais vous avez également besoin d'un ou de plusieurs Minitels (selon le nombre d'appels simultanés que votre serveur aura à traiter) pour recevoir les appels entrants. Le nombre de Minitels que vous pouvez brancher dépend du nombre de ports série dont dispose votre ordinateur. Néanmoins, maintenant que vous disposez du code source, vous pouvez envisager d'interfacer STUT ONE avec le port MIDI ou encore une carte multi-séries. L'utilisation de modems à la place des Minitels est également envisageable.

COMPILATION

La compilation du logiciel sous Pure C exige que vous chargiez le fichier projet (STUT_3.PRJ) d'une part, et que vous fixiez précisément certaines options de compilation d'autre part.

Mais avant même de parler des options de compilation, parlons d'un petit détail qui a son importance: les tabulations. En effet, comme tout programme écrit dans les règles de l'art les plus évidentes, le code source de STUT ONE fait un fort usage d'indentations et d'alignements dans les tableaux ou les listes d'arguments. Ceux-ci sont souvent obtenus au moyens de tabulations. Ce que vous devez savoir c'est que la taille de ces tabulations est censée être de 3 caractères. Si vous ne visualisez pas le source en ayant fixé la taille des tabulations à 3, vous risquez de vous retrouver avec un code source ressemblant plus à une salade de mots-clef qu'à un programme structuré. Dans Pure C, la taille des tabulations se règle dans le menu Options/Shell:tabsize.

Au niveau de la compilation (menu Options/Compiler) maintenant, deux options doivent absolument être cochées: "Default char is unsigned" (-K) et "Use absolute calls" (-P).

Au niveau de l'édition des liens (menu Options/Linker), il n'y a pas d'indications particulières, si ce n'est de réserver au moins 4096 octets à la pile (Stack).

Une fois ces quelques options correctement paramétrées, vous pouvez tout simplement lancer un "make" pour compiler et linker tous les modules. Ce processus peut être assez long. A titre d'exemple, sur mon Mega STE à 16 Mhz avec 4 Mo de RAM, il a fallu 9 minutes 30 pour tout compiler. C'est en partie pour cette raison que le logiciel est découpé en de multiples modules de petite taille. En effet, par la suite, si vous modifiez un module, un "make" ne recompilera que le module en question et le "linkera" avec les autres modules déjà compilés (sous forme de fichier *.O) auparavant.

La fichier compilé aura une taille approximative de 170 Ko... si vous n'avez pas inclus d'informations de debug ni de table des symboles, etc. L'inclusion de toutes ces options vous sera néanmoins fort utile si vous décidez de modifier le code source et que vous avez besoin de le debugguer au moyen d'un debugger (tel que Pure Debug par exemple).

UN MOT SUR LA LICENCE

Tout comme la version 2, STUT ONE 3 est soumis aux termes de la GNU General Public License (GPL version 2). Cela implique que vous êtes libre d'utiliser le logiciel, de le modifier et même de le revendre, tout ceci à la condition expresse que vous diffusiez également le code source intégral correspondant à toute version compilée que vous diffuseriez par quelque moyen que ce soit.

Contrairement aux licences d'utilisation classiques des logiciels, la GPL est une licence destinée à protéger les utilisateurs, plutôt que les vendeurs de logiciels. Le texte complet de la licence est fourni dans le fichier LICENCE.TXT.

LE CODE SOURCE

Comme nous l'avons déjà évoqué plus haut, le code source est décomposé en une multitude de modules plus ou moins importants. Chacun de ces modules remplit (en théorie) un ensemble de fonctions corrélées. Les modules les plus soignés ressemblent même à des objets et sont plus ou moins inspirés de la terminologie objet du C++. Prenons un exemple...

Au hasard: SERIAL.C. Si vous ouvrez ce fichier, vous devriez comprendre très vite qu'il s'agit d'une sorte de "classe" permettant de gérer les ports série de l'ordinateur (c'est écrit dans les commentaires au début du fichier :-).

Ce fichier contient par exemple la définition de la "méthode" (une fonction C) Serial_WaitTXEmpty( n_device ), dont la fonction est d'attendre que le buffer de transmission (TX par opposition à réception/RX) du port n_device soit vide. Cette méthode pourra par exemple être appelée depuis un autre module qui désirerait s'assurer que toutes les informations ont bien été envoyées avant de faire autre chose.

Cette méthode est publique, c'est à dire, qu'elle peut être appelée depuis un autre module. Néanmoins, afin que l'autre module puisse appeler la méthode, il faut lui déclarer. C'est à cet effet que l'interface publique du module SERIAL.C a été regroupée dans le fichier SRIAL_PU.H. Tout module désirant faire appel à une méthode publique du module SERIAL.C peut dès lors le faire en ayant simplement inclus le fichier de déclarations de la manière suivante:

#include "SRIAL_PU.H"

SERIAL.C contient également des méthodes privées, à usage exclusivement interne. C'est le cas par exemple de get_iorec() qui permet à des fonctions de gestion des ports séries d'accomplir leur tâche en obtenant des informations du système d'exploitation. Cette "fonction privée" est déclarée "static" de manière à ne pouvoir être référencée qu'à l'intérieur du module SERIAL.C et sa déclaration ne figure bien sûr pas dans l'interface publique (SRIAL_PU.H).

Voilà pour le principe d'organisation générale. La liste complète des modules se trouve dans STUT_3.PRJ avec une brève description. Vous pouvez obtenir plus d'informations en ouvrant chacun des modules séparément. Vous constaterez en effet que ceux-ci sont en général abondamment commentés.

L'AVENIR ?

Voilà, vous avez entre les mains le fruit de plusieurs années de travail et de recherche en matière de télématique conviviale (vous trouvez que j'exagère? :-) et vous avez le champ libre quant aux possibilités d'évolution: gestion de modems, transformation en serveur BBS, en serveur vocal ou même en logiciel de création multimédia! (Si on y réfléchit, le moteur d'arborescence à la base du logiciel peut être appliqué à un grand nombre de tâches diverses...)

Quant à moi, je vais aller m'occuper d'une autre vision de la télématique que l'on nomme l'Internet...

Juin 1996

NDA: Le code source de STUT ONE 3 fait appel aux routines de débogage des mallocs expliquées dans un autre article.