Blogounage

Seb, à un collègue :

Toi, t'es un HighGlandeur !

Une citation immortelle. Très bon ! .

UPDATE : En train d'écrire ce billet, un collègue nouvellement arrivé regarde mon écran et me demande : Tiens !? batmat.net, tu connais ?. Moi : Ben, euuu, comment ça ? Tu rigoles ? (comprenant et rougissant) oui, euu, c'est mon blog... Et là, comme dit Seb, érection molle .

Je pars aujourd'hui en vacances jusqu'à après mi-août. Je serai donc un rien moins présent :-). Je laisse les commentaires ouverts, je suis un fou. J'y jetterai peut-être un œil de temps en temps depuis un cyber-café.

À bientôt.

Nous utilisons encore Struts 1 actuellement. Ce n'est normalement qu'une question de temps avant de passer à autre chose. Nous sommes sûrs de ne plus l'utiliser à terme. Nous connaissons donc notre source, mais pas encore la cible. Voici les nombreuses solutions qui s'offrent à nous :

• Struts 2
• GWT
• .Net
• Flex
• ...

Toutefois, je ne suis pas très chaud pour .Net ou Flex ou toute technologie qui nous contraigne forcément à passer par les WS pour accéder à nos services (développés en Java). Je suis réticent à devoir obligatoirement passer par une couche WS alors que nous pourrions garder du java de bout en bout, et ainsi économiser le marshalling/unmarshalling incessant qui va avec les WS, sans parler du problème de l'identification du graphe d'objets à sérialiser pour le renvoyer. Quoi qu'on en dise, utiliser systématiquement des WS n'est pas neutre et amène de nombreuses questions qu'on ne se pose jamais sinon (hein Séb...).

Donc, pour revenir au sujet, nous ne sommes pas encore fixés sur notre future couche présentation (ou plutôt nos futures couches de présentation). Pour le moment, nous avons donc décidé de continuer à fonctionner tant bien que mal Struts 1.x avec la version 2 du socle technique que nous sortons.

Or, la différence fondamentale entre notre version 1 et notre version 2 est que nous avons supprimé une "transformation" systématique entre deux couches. Auparavant, en effet, nos entités persistantes de couche DAO étaient systématiquement transformés en objet de couche service. Entre les deux couches, nous avions systématisé un bidouillage destiné à régler le problème que nous avons dans la couche Web dans la gestion des multiplicités 0..1.

La gestion du null de Struts 1.x

Avec Struts 1, si vous demandez par exemple le prénom d'un client null, vous n'aurez pas quelque chose de null, mais une exception. La question a été discutée il y a déjà un moment sur la liste de Struts et posée sur le tracker de Struts en février 2001 (quand je vous disais que ça faisait un moment), et Craig Mc Clanahan d'expliquer que le principe était que si vous vouliez afficher le prénom d'un client, eh bien il fallait protéger le code pour n'afficher le prénom que si le client est non null :

<logic:present name="beanname" property="client">

  <bean:write property="client.prenom"/>

</logic:present>

Si dans l'exemple ci-dessus, on met un champ de saisie à la place du <bean:write />, on est dans une impasse : certes, il n'y aura pas de plantage, mais il devient alors impossible de saisir le prénom du client puisque le textfield n'apparaîtra même pas...

Si votre objectif est de créer le client seulement si l'utilisateur a saisi des données (exemple : le formbean en cours gère un objet Facture qui a une multiplicité 0..1 vers un objet client), vous êtes obligé de créer dans votre FormBean un objet destiné à recevoir ces données. Le problème qui survient alors, c'est que si vous voulez conserver des objets "propres"^[1], vous devez ensuite vérifier l'instance de Client pour la remettre à null ou l'associer manuellement (si pas encore fait) à la Facture avant de transmettre la Facture à la couche service pour mettre à jour. Ouf...

La longueur de l'explication ci-dessus par rapport à la complexité de ce qu'il faut gérer me paraît parler d'elle-même. Et le code qu'il faut écrire pour gérer ce cas est toujours le même... :

1. avant affichage de la JSP : instancier les propriétés null pour pouvoir les afficher. Eh oui, rappel comme je l'ai dit plus haut : la demande de la propriété "a.b" déclenche une exception si a est null, il faut donc s'assurer que a est non null et l'instancier le cas échéant.
2. après soumission du formulaire de la JSP et avant de passer les données à la couche application : supprimer les objets 0..1 non modifiés dans la JSP.

Struts 2

Dans Struts 2, le premier point est géré différemment : la demande de "a.b" si a est null renvoie simplement null. Par contre, le deuxième point est toujours à gérer manuellement et plantera si on cherche à valoriser a.b.

Une étape a déjà été franchie, pourquoi ne pas aller plus loin ?

Une solution

Pourquoi ne pas instancier automatiquement a s'il est null lorsqu'on cherche à valoriser a.b ? La question se pose d'autant que nous ne sommes pas les seuls à nous être posés la question : ce patch apportait déjà les modifications nécessaires aux commons-beanutils (utilisé par Struts, c'est cette bibliothèque qui impose le comportement de lever une exception si une propriété imbriquée est demandée à l'intérieur d'un objet null)...

Une autre solution (sans patch, cette fois) intermédiaire a été proposée pour la partie "get" : mettre en place un handler externe pour gérer le cas des propriétés imbriquées (nested properties) dans un conteneur null. Cette solution est un intermédiaire intéressant parce qu'elle est très courte à implémenter et permet de faciler renvoyer null ou de lancer une autre exception dans le cas en question.

Cette deuxième solution ne gère toutefois que le cas get. Peut-être le même principe serait-il utilisable pour le "set". Cela permettrait de même de positionner une sorte de NestedSetterHandler qui pourrait s'occuper d'instancier les propriétés intermédiaires si besoin. Avec un fonctionnement de ce type, on pourrait même envisager de définir un handler qui serait observable afin de gérer à la fois l'instanciation "dynamique" et de pouvoir suivre les instanciations effectuées. C'est à creuser.

Ce mode de fonctionnement aurait toutefois quelques inconvénients : lorsqu'on instancie manuellement a, on sait qu'on risque de devoir l'enlever s'il n'est pas vraiment saisi avant de l'envoyer à la couche service. Et que faire si on décide de faire gérer ça en standard par le service ? Imaginons par exemple qu'une adresse ait été automatiquement instanciée pour un Client. À quel composant, à quelle couche, incombe le rôle de supprimer l'adresse créée dynamiquement si le fonctionnel indique qu'elle n'est pas correcte ?

Conclusion

Dommage que l'équipe de commons-beanutils soit peu réactive sur cette question à mon avis primordiale de gestion des propriétés. C'est aussi très dommage que l'idée d'avoir derrière la classe statique BeanUtils une instance de BeanUtilsBean ne soit pas poussée à son terme : en l'état, il est en effet impossible d'utiliser de façon transparente une sous-classe BeanUtilsBean qu'on aurait adaptée à ses besoins.

Je nous vois bien maintenir en interne une version patchée de commons-beanutils afin de résoudre le problème tant que nous utiliserons Struts 1, en espérant bien sûr que le patch en question soit finalement appliqué.

En même temps, il reste la question de la gestion de la suppression des propriétés instanciées dynamiquement. Mais je ne suis pas sûr que ce soit un véritable problème, c'est un code qu'il faut de toute façon écrire. Au final, il y a actuellement les deux points suivants à gérer :

1. instanciation manuelle pour gérer l'affichage ;
2. vérification des données et suppression des créations incorrectes si les données n'ont par exemple pas été saisies.

C'est à mon sens un point qu'il serait intéressant de creuser. Avec Struts 2 par exemple, écrire un Interceptor chargé de l'instanciation dynamique ferait l'affaire pour enlever le point 1 ci-dessus.

Le tout serait ensuite de définir un emplacement de choix pour faire la validation, puis la suppression des propriétés fonctionnellement "inacceptables". À part ce point, je ne vois aucun frein à cette évolution. Cette question se posant pour n'importe quel formulaire de saisie, le monde de l'informatique aurait à mon sens beaucoup à gagner à trouver un véritable pattern pour gérer ce cas...

Martin Fowler a pondu ce soir un long billet sur la politique de Microsoft envers Ruby. Il parle ensuite de sa sensation selon laquelle une certaine désaffection pour la plate-forme .Net serait en cours, et que les AlphaGeeks (tiens, il faudrait un questionnaire, êtes-vous un AlphaGeek ? :-)) seraient en train de quitter l'environnement de développement MS.

Quelques morceaux choisis :

A few years ago my (limited) contacts in Redmond told me that they were seeing a real drift of technical leaders away from the Windows platform. More recently these signs seem to be increasing.

The tools, with their rigid role-separations, actively discourage the blurry boundaries that agilists prefer.

Pour ceux qui ont récemment joué avec WPF, Blend et consorts, on voit très bien ce qu'il entend par là.

The attitude to open-source is a large part of this problem. When Java appeared there were yawning gaps in its portfolio [...] Those gaps and bad ideas were fixed by the open-source community. [...] .NET has also got its gaps, and again the open source community has stepped up to fill them. Yet Microsoft refuses to collaborate with these efforts, [...] Microsoft ended not just bringing out a competitive library, but deliberately making it incompatible. That's not the kind of reaction that encourages people to invest their time in the platform.

Je connais peu .Net, mais est-ce que MS travaille à l'intégration ou en tout cas encourage un projet comme NHibernate ?

Quelques liens (déjà donnés ci-dessus)

• L'article en question : RubyMicrosoft chez Martin Fowler.
• Qu'est-ce qu'un AlphaGeek.
• Is Microsoft losing the Alpha Geeks?.

MAJ : ajout de liens :

• L'avis de Sam Gentile, un expert MS consulté par Martin Fowler pour l'écriture de son article. Martin Fowler a ajouté en fin de son billet des liens vers des réactions, dont celle de Sam.

C'est un peu dommage. Mme Royal a cassé les pattes arrières de Nicolas Sarkozy sur le sujet des handicapés, mais a fait durer un peu trop le sujet. Elle a laissé M. Sarkozy reprendre du poil de la bête et faire le choqué, le blessé après la longue attaque, semble-t-il justifiée. Elle ressort de ce moment du débat avec moins de points que ce qu'elle aurait pu.

Pour résumer, Sarkozy propose de fournir un droit opposable pour tout (crèches, enfants handicapés scolarisés dans des écoles classiques...). Ségolène Royal lui répond, à juste titre il me semble, qu'on ne peut pas tout résoudre avec des lois et des passages en justice. Elle répond avec énergie à la partie sur les enfants handicapés, où elle explique qu'elle avait déjà mis en place des auxilliaires (7000 postes, je crois) spécialisés pour aider les enfants handicapés dans les écoles lorsqu'elle était ministre de l'éducation. C'est justement le gouvernement dans lequel travaillait Sarkozy qui aurait fait sauter ces postes. Le problème, c'est que ça a duré trop longtemps à mon goût. Elle aurait dû s'interrompre après la réponse qu'elle lui a faite, histoire de voir sa réaction. Il a eu le temps de préparer une réponse pendant qu'il faisait le pauvre petit gars qu'on attaque sans raison. Toutefois, sur le fond, je trouve qu'elle a très bien réagi.

De sensibilité plutôt encline à vouloir aider les plus démunis qu'à protéger l'ISF, j'ai une forte inclination à gauche. Toutefois, je m'intéresse aux arguments des candidats pour ne pas partir dans le mur aveuglément.

L'UMP me donne des raisons supplémentaires de ne pas voter pour elle. Je dirais même plus, le PS me donne des raisons de voter pour lui. Chose importante, vu le nombre de fois que l'on on a entendu notamment la gauche de la gauche "voter pour faire perdre la droite" et non simplement voter pour la gauche.

Merci à Thomas d'avoir rédigé un billet récapitulatif de l'initiative Candidats.fr, qui a consisté à poser des questions à chacun des candidats concernant différents sujets afférant à Internet, à la protection des droits d'auteurs, aux Mesures Techniques de Protection, ces fameuses DRM, les brevets logiciels.

À mon sens, la gauche est loin devant quant au traitement de la problématique des droits des citoyens sur Internet, la protection des consommateurs (vente liée, interopérabilité des lecteurs de musique numérique, ...).

La synthèse de Thomas.

Aujourd'hui, prise par nous dans la banlieue toulousaine... Tout est flouté, à part moi, pour éviter les éventuels problèmes (le sujet de la photo, âgé d'une dizaine d'années, ne s'est aperçu de rien, tout concentré dans sa lecture qu'il était). Je déflouterai peut-être les gens qui sont à gauche s'ils sont d'accord :-).

Des fois, je vais sur YouTube et je me fais une série de Régis. Aujourd'hui, je suis tombé sur un qui m'a peu fait rire tellement il est orienté sur des vautres qui ont dû faire mal. Je me demande même si certains morceaux de cette séquence n'ont pas provoqué la mort d'un ou plusieurs des intervenants... J'ai plus souvent fait ouch ! que je me suis marré. À votre tour de juger :

Avec un peu de retard, je prends enfin le temps de faire un billet sur mon deuxième jour aux Tech Days. Cette journée a été très chargée, mais j'ai appris pleins de nouvelles choses. Évidemment, ce sont des choses à approfondir, mais je vais essayer de vous donner aussi envie de le faire. En cherchant un logiciel pour faire des vidéos de démo comme on en voit partout fleurir sur le net, je suis tombé sur Wink. C'est simplissime d'utilisation : avec ça, plus aucune excuse pour ne pas faire de vidéo explicative de l'installation ou d'une démo d'un logiciel (et on peut générer du flash ou un .exe pur windows).

Sun Technical Keynote

Cette introduction a été l'occasion de nous montrer le langage F3 : Form follows function, censé simplifier le développement d'interfaces graphiques. C'est vrai que la partie de la démo montrant comment mettre un fond en dégradé de rouge vers bleu vers jaune (ou d'autres couleurs) a montré que c'était effectivement très simple.

Speach VMWare

En tant que sponsor Platinium, VMWare a eu droit à un speach devant tout le monde. On nous a présenté ce qu'était VMWare, pour ceux qui l'ignoraient encore. Ça a été l'occasion de parler de Lab Manager, une sorte de dépôt central dans lequel on peut stocker des machines virtuelles et les lancer depuis des postes clients. Ça a l'air intéressant dans le cas des recettes par des équipes de tests. En effet, le syndrôme du Chez moi ça marche est effectivement connu de tout informaticien. Avec ce système qui simplifie le partage d'une configuration complète (du logiciel jusqu'à l'OS et sa configuration précise), il devient possible de débugguer un problème dans les conditions qui garantissent la reproductibilité, ce qui est la première difficulté pour un développeur : trouver les conditions permettant de reproduire le problème (essayez de corriger un problème que vous n'avez pas, pour voir !).

Java Jacket Give away

20 minutes pour un mini-show de 4 d'entre nous. Je n'ai pas osé y aller. J'ai eu une idée un peu tard, mais j'aurais dû la préparer la veille. Peut-être pour l'année prochaine :-).

Le gagnant a chanté une petite chanson sur Java et a donc gagné la veste en cuir avec le logo Java :-).

Java scripting: One VM, Many Languages

Cette session a été très intéressante. La démo de Guillaume Laforge m'a notamment donné envie de me mettre au Groovy, pour les apports en rapidité d'écriture par rapport au Java, l'ajout des fermetures, mais aussi pour sa proximité syntaxique et son intégration avec le Java. Ça peut en effet fonctionner directement avec la JVM, être mis dans un jar..., puisqu'on peut générer du pur bytecode Java. L'idée n'est pas de remplacer le Java, mais d'apporter une alternative plus puissante aux scripts shell et une syntaxe plus habituelle pour le développeur Java qui veut déployer un script de batch sur le serveur, par exemple.

Cette présentation a été l'occasion de découvrir la JSR223, la spécification qui permet d'intégrer n'importe quel langage de script à la plate-forme Java. Javascript l'est déjà (cf. la présentation flash plus bas), JRuby, Groovy, etc. En gros, l'architecture mise en place permet à n'importe qui d'intégrer n'importe quel langage de script en implémentant simplement les interfaces de la spéc (pensez à JDBC si vous ne voyez pas ce que je veux dire).

Code Quality issues: Prevention and Detection

C'est certainement l'une des sessions dans lesquelles je me suis senti le plus à l'aise, parce que j'avais déjà mis en place un grand nombre des outils cités. Ça a toutefois été l'occasion de découvrir de nouveaux outils (Selenium, notamment).

La présentation a commencé en citant Dijkstra : Testing can only show you bug presence, not their absence. Et c'est vrai que c'est bien de rappelant l'intérêt essentiel des outils de qualité de code... Ce n'est pas magique.

Pour résumer :

• Test unitaire : Junit, TestNg
• Couverture de code : Emma (+ pleins d'autres), ce type d'outil permet de savoir quelles parties de votre code ont été testées par les tests unitaires. En gros, vous lancez tous les tests de votre projet et l'outil monitore par où ça passe. Ensuite, vous pouvez généralement savoir quelles parties ont été testées, voire même lesquelles l'ont été plusieurs fois et d'autres une seule. La plupart de ces outils possèdent des plugins pour les principaux IDE qui permettent de voir graphiquement la couverture. Bien sûr, il existe aussi des plugins pour des outils comme Maven, permettant de sortir des statistiques.
• Montée en charge : JMeter, LoadRunner (j'ajouterais OpenSTA)
• Mock objects : EasyMock, JMock
• Qualité du code : PMD, Checstyle
• Test fonctionnel d'une webapp : Selenium
• P6Spy pour voir la valeur des "?" dans les requêtes SQL paramétrées.

TP : Les nouveautés de Java 6

Comme j'en ai parlé plus haut, il est possible d'interfacer la JVM avec d'autres langages. Avec Java 6, vous disposez de jrunscript, un interpréteur Ecmascript (javascript normalisé).

En voici une petite démo :(cliquez sur l'image pour voir la démo flash) :

JMX, Performance et concurrence

JMX

J'ai appris au cours de cette session que l'équipe de développement de JMX était située à Grenoble.

L'objet de cette session a été principalement de développer un MBean et de l'exposer via le MBeanServer. Ceux qui, comme moi, ont déjà développé un MBean et joué avec JConsole juste pour voir n'auront pas été surpris.

Par contre, j'en ai appris sur les différentes espaces mémoires de la JVM :

• Eden : c'est l'espace mémoire où les objets à courte durée durée de vie sont stockés (la plupart en général) ;
• Survivor : pour les objets qui ont une durée de vie un peu plus grande ;
• Tenured : ben euu, encore plus :-).

Autre chose que les conférenciers ont dit, je n'ai pas vérifié, mais à propos des options -client et -server :

• -client est toujours utilisé sous Windows, quelle que soit la machine
• -server est utilisé automatiquement sous Linux ou sous Solaris si la machine possède plus de 2Go de mémoire vive.

Truc génial : la possibilité de repérer des deadlocks avec un simple bouton ! (je crois que c'est un ajout dans le JConsole embarqué dans Mustang, parce que je ne me souviens pas de l'avoir dans Tiger).

JSR 262

La façon dont on accède à JMX, JMX Remote, n'est pas liée fortement à JMX. En effet, l'implémentation par défaut dans Java 5 est effectivement en RMI, mais il reste très faisable de permettre l'accès aux fonctionnalités d'un serveur JMX par n'importe quelle autre implémentation.

C'est justement l'objet de la JSR 262 : implémenter une couche WebServices d'accès à JMX. Comme il existe une norme appelée WS-Man qui n'est pas liée au Java. Cette implémentation permettra donc l'accès au management de la JVM d'une façon normalisée. WiseMan est ainsi l'implémentation Java de WS-Man.

Lors de la séance de Q/R, j'ai posé la seule question de ces deux jours à Paris : pourquoi n'y a-t-il pas pour les MBeans, de la même façon qu'il y a l'annotation @WebService pour les Webservices, une annotation @MBean qui indiquerait automatiquement aux MBeanServer quels sont les MBeans à exposer ? Éamonn McMannus a répondu que c'était une question qu'on leur posait souvent, et que c'était justement prévu.

Performance

Bon, ils ont parlé du classique StringBuffer à la place de concaténer des String. Attention : depuis la version 5 de Java, la classe StringBuilder est à privilégier : de la même manière qu'il est recommandé d'utiliser HashMap à la place de Hashtable, il faut utiliser StringBuilder dans un contexte qui ne nécessite pas de synchronisation. En effet, la synchro n'est pas gratuite, donc l'utiliser de façon systématique est une grave erreur.

Concurrence

Ils ont présenté la nouvelle API de gestion de la concurrence ajoutée au JDK5, encore peu connue.

Java Puzzle

Pour finir, on a eu droit à un Java Puzzle (en anglais, puzzled correspond à surpris, étonné), c'est un bout de code qui surprend ou pour lequel on n'a généralement pas une réponse évidente pour tout le monde :

public class PingPong {

    public static synchronized void main(String[] a) {

        Thread t = new Thread() {

            public void run() { pong(); }

        };

        t.run();

        System.out.print("Ping");

    }



    static synchronized void pong() {

        System.out.print("Pong");

    }

}

Qu'affiche ce bout de code ?

1. PingPong
2. PongPing
3. Ça varie

J'avoue sans honte que j'ai répondu correctement à cette question :-). Je mettrai la réponse dans les commentaires un peu plus tard (si personne d'autre ne le fait avant, d'ailleurs).

Je reprends le titre du billet de NiKo de PuC.

Au cas où vous auriez raté ça dans l'actualité, Dell envisage de livrer des configurations avec des Linux préinstallés. Allez donc remplir leur sondage afin de leur montrer que les utilisateurs de Linux existent bel et bien.

En distribution, j'ai mis Ubuntu, puisque c'est à mon sens la seule réponse sérieuse aujourd'hui.

Plus sérieusement et sans pousser gratuitement au troll comme dans ma phrase précédente, pour la petite histoire : j'ai commencé à utiliser Linux au début de mon DUT, Informatique c'était en 2000. Je ne connaissais comme OS que Windows. J'avais pas mal bidouillé Windows 95 et 98, mais pas trop les précédentes versions puisque je n'ai vraiment commencé à m'intéresser à l'informatique que lorsque j'étais en seconde.

Slackware, un Linux pour les unixiens...

La première distribution que j'ai installée fut donc une Slackware (à prononcer avec l'accent Ukrainien, Kostia, si tu m'entends ;o)). Je peux vous garantir que j'ai lutté. Il m'a déjà fallu plusieurs jours avant d'abandonner et de rapporter enfin le CD que Kostia m'avait passé pour m'entendre dire : Aaaaah, mais ce sont les sources !... Pour vous dire à quel point j'étais une tanche. Je ne me souviens pas s'il est excusé de s'être trompé de CD. Toujours est-il que je suis donc reparti avec un CD et un espoir flambant neufs. Au bout d'une bonne dizaine de tentatives (je suis arrivé plusieurs fois à la fin de l'install, mais comme j'avais peur de merder quelque part, lorsqu'il manquait quelque chose d'important je recommencais tout à zéro. Une habitude issue de windows, sûrement :-D).

En résumé, la slackware, pas simple. Faut aimer ./configure&&make&&make install en tout cas...

Bref, c'était pas le top. Il fallait passer à autre chose.

Mandrake, the solution pour les newbies... Mouai...

C'est un peu comme ça qu'on me l'a vendue en fait. Je crois qu'à cette époque, j'étais aide-administrateur à temps partiel, en plus du DUT, des machines du département informatique, avec Peter. J'ai découvert ce à quoi pouvait ressembler de l'administration système. Je vous avoue que j'en ai un souvenir mitigé : à la fois intéressant, parce que j'ai indéniablement appris des trucs, surtout sur Linux grâce à Peter, mais aussi incroyablement chiant ces tâches répétitives d'install de x postes à l'identiques, même en passant par des images...

Tout ça pour dire, donc, que l'école utilisait des Mandrake 8. Je crois plus précisément que la Mandrake 8.0 était sortie récemment et que nous l'avions installée sur tous les postes. Si je ne me trompe toujours pas, je me souviens que c'est à la même époque qu'est sortie la RedHat 7, qu'André arborait fièrement. De mémoire, toujours, je crois qu'André a installé la RH7 et nous a sorti : cette fois, je passe à Linux, c'est pour de bon. Je pense qu'André a prononcé ensuite plusieurs fois cette phrase dans les 2 années qui ont suivi, Dédé si tu m'entends :-).

J'ai donc installé sur ma machine une Mdk8... Énorme, qu'on m'avait dit. L'outil rpm déchire, tu verras, et tout et tout... Mon cul, oui ! À l'époque, pour installer un rpm alors que tu n'étais qu'un newbie, fallait bien s'accrocher au lecteur de cd pour pas vomir. Aucune gestion des dépendances, donc yavait intérêt à avoir tout sur place. Je me souviens encore de la commande, tiens : ''rpm -Uivh' leRpm.rpm' (j'ai un doute sur la casse des options). Bref, toujours pas génial tout ça.

Debian, et la lumière fut

En fait, je me rends que je vous raconte ça dans un léger désordre et une certaine inexactitude, mais c'est pas très grave. J'ai dû récupérer la Mdk8 avant d'être admin sys, puisqu'il me semble justement que c'est le fait d'avoir été admin sys qui m'a permis de mieux connaître Peter. Comme c'est Peter qui m'a convaincu d'installer Debian, doit y avoir un truc comme ça. C'est pas grave, je suis pas loin de la réalité, l'essentiel c'est que j'en arrive à vous parler de Debian, ou plutôt de Debian et moi :-).

Peter m'a donc poussé à installer la Debian. Heureusement, parce que c'est vrai qu'à l'époque, vu mon niveau, je ne sais pas si j'aurais franchi le pas si tôt. La Debian était en effet réputée pour être complexe à installer, limite imbitable. Les légendes urbaines, tout ça.

Bon, je me disais qu'après la Slackware, ça pourrait pas être pire. Donc, je me suis lancé. Effectivement, pour un windowsien habitué au suivant-suivant, c'était un peu surprenant cette interface mode texte. Mais finalement, une fois l'étape du partitionnement franchie, le reste n'était en gros qu'une suite d'appui sur la touche entrée. Le plus long consistait à choisir les packages qu'on souhaitait installer. Si on décidait de dire oui ou non à chaque paquet, fallait vraiment être à bloc, parce qu'on en voyait pas le bout. Bon, après tout, pas long pour rien le bazar.

Une fois l'installation de base franchie, on commencait à saisir toute l'ampleur de la magnificence de la Debian : apt-get. The killer-app comme on dit en bon françois. Gestion des dépendances : tu demandes gnome, il t'installe gnome et tout ce dont gnome a besoin. En gros, tu tapes apt-get install gnome, tu attends que tout soit téléchargé, installé et configuré, ça te rend la main et tu peux lancer gnome !

Depuis cette époque, je suis resté sur Debian. En fait, sur des dérivées. J'ai essayé Knoppix, suis passé par Kanotix, deux fois, distrib sur laquelle je tourne encore aujourd'hui sur pumte, ma dernière machine, un Dell Inspiron 8600 justement, que j'ai depuis environ 2 ans.

Donc, Debian, c'est clair, ya pas mieux. Apt-get est tout simplement géniale. rpm à côté, à l'époque où je l'ai laissé, c'était de la merde en boîte. Alors, pourquoi j'irais réessayer des distrib qui ne se sont pas rendues à l'évidence qu'un système comme apt qui existait depuis si longtemps et fonctionnait si bien était forcément la direction à suivre. Franchement, je ne comprends pas pourquoi Mandrake, Opensuse et les autres continuent à jouer avec leurs petits outils à côté d'apt-get, the Legend :-).

Allez, bonne nuit et faites passer le message :-).