Linuxman - octobre 1999

Linuxman - octobre 1999

INDEX

29 10 1999
30 10 1999

29 10 1999

Mots Clés : Youpla.

Et oui youpla, en ce 29 octobre 1999, voilà que le temps passe encore, à croire que c'est à nous de nous organiser pour gérer de temps qui passe, dingue... :) J'ai un sérieux doute quant au nombre de personnes qui va lire cet article après mon long silence (quoique j'en avais aussi avant dans mes précédent articles sans long silence) mais qu'importe, finalement j'écris aussi pour moi et l'égoïsme est finalement un peu ce qui nous fait avancer.

Donc un bon mois de silence pendant lequel le monde n'a sûrement pas arrêté de tourner, RedHat, Mandrake et autres sont toujours dans une course effreinée, tout comme Intel, AMD et compagnie. /. tourne toujours à plein pot dans les bookmarks et Dust Puppy affronte les Nazguls de Redmond aidé de son « true ping »... La fin du monde n'est plus qu'à deux gros mois et le prix de la RAM redescend tout doucement... Linux continue son chemin, Microsoft fait toujours des bénéfices records. Finalement rien ne change et les cycles restent les mêmes... Toujours une Halloween de plus en plus commerciale, des pubs toujours plus nombreuses, des conflits à droite à gauche, du beau et du mauvais temps, bref, un mois d'octobre somme toute très banal...

Mais l'originalité n'a jamais été ailleurs que dans nos tête, alors arrêtons un peu de faire la fine bouche et continuons allègrement sur notre lancée, après tout à quoi bon réfléchir, ce serait peut-être perdre un temps précieux...

Pourtant ce sont les personnes qui aujourd'hui savent ce qui viendra demain qui seront prêtes, et ceux qui suivent aujourd'hui suivront demain (des fois quand je me relis je me dis que je ne suis vraiment, mais vraiment, qu'un blaireau...). Il n'est pas évident, même à très court terme, quelques mois, de se positionner sur l'état du marché, de Linux, des technologies, des tendances...

Petit break culturel, ou pause, plus politiquement correct. lsof est une commande permettant de lister l'ensemble des fichiers ouverts et le processus responsable ; cela peut s'avérer pratique. cd - permet de revenir au dernier répertoire visité, très pratique quand on tape sur entrée un peu trop vite et que l'on se retrouve sous son $HOME sweet $HOME. Contrairement à une croyance bien connu, le software RAID serait plus rapide que le hard, c'est tout de même surprenant (pour ceux ne connaissant pas très bien le principe du RAID, en deux mots, RAID signifie Redundant Array of Inexpensive Disks, l'idée est de prendre un certain nombre de disques et de les coller ensembles pour faire des disques plus gros. Le disque logique ainsi créé est de plus entrelacé (strippé) sur tous les disques, permettant de multiplier la vitesse de lecture/écriture étant donné que tous les disques crachent en même temps, dans la limite du controleur, bien sûr (d'ou l'intérêt d'un bus à 80 Mo plutôt que 40 ou 20 quand on met dessus 5 ou 6 disques a 12 ou 13 Mo/s en débit soutenu). Existent de plus des notions de redondance de l'information sous forme de bits de parité, d'où des recontructions dynamiques de disque en cas de panne (si qu'un seul disque pète, s'il y en a deux, dommage, enfin cela doit dépendre des techno aussi, mais je suis pas sûr qu'il existe du RAID capable de supporter deux disques qui lachent), etc, etc, il existe de bons HOWTOs et autre documentation sur ce sujet que je ne connais que très vaguement. Cela dit si vous avez la chance d'avoir plusieurs disques accessibles simultanément, tester le software RAID de Linux ne peut être qu'une bonne et enrichissante expérience (tester en général est assez synonyme d'expérience nouvelle, même carrément, mais on ne va pas se fâcher pour des détails linguistiques, ce serait quand même dommage si près de la fin du monde :)).

Tiens et bien ma parenthèse précédente est finalement assez balèze... Enfin longue je veux dire, parce qu'elle n'est pas si balèze que ça du côté technique, même plutôt légère.

Je me suis longtemps demandé s'il valait mieux écrire le nom de mes répertoires chronologiques (je suis très chronologique comme gars, je trouve, à tort ou à raison (cela ajoute toujours une certaine tenue que de mettre des expressions toutes faites sans aucun intérêt :), que de classer les choses par chronologie c'est pas débile comme idée, alors je classe tout, enfin presque, par chronologie, mails, fichiers... Cela permet d'une part de considérablement faciliter les phases de sauvegarde/nettoyage, ainsi que de limiter les erreurs de classement au niveau mensuel, et de plus la taille des répertoires et fichiers reste toujours correcte, assez pratique pour les mails... Cela peut cependant avoir le désavantage de complexifier un chouillat la recherche d'une info passée, mais locate et grep sont mes amis il faut les aimer aussi.

Mais cela soulève LA question, à savoir faut il écrire 101999 ou 199910. Ha Ha, complexe. Ecrire 101999 facilite la lecture visuelle (enfin une lecture pas visuelle c'est assez dur, mais c'est dans le sens du temps qu'il faut à mon chtit cerveau pour poser un brin de sens dessus ces quelques caractères, et les picosecondes, de nos jours, c'est important), cela doit aussi rendre un peu plus évident le parsing de tout cela et a l'énorme avantage, vue la notation en little endian, de ne pas provoquer de décalage lors de l'augmentation du nombre de digit de l'année. Avantages très théorique, certes, parce que ce n'est pas demain la veille que l'on passe en l'an 10 000, mais ils disaient ça aussi en 70 en parlant de l'an 2000, et resultat on nous a bien pris la tête avec cette histoire, alors restons prudents, le temps passe vite :). Cependant, la notation 199910 a l'avantage lors d'un listing classé alphanumériquement, soit un listing standard, de se classer chronologiquement, ce qui est loin d'être négligeable. Cela reste cependant tributaire de ne pas augmenter les digits de l'année, mais on est quand même tranquille pour 8000 ans, et d'ici là les listing seront suffisamment intelligent pour intuiter correctement les désirs de l'opérateur, et plus si affinités. D'autre part, et c'est un peu le contre argument vis-à-vis du nombre de digits de l'année, cela permet de préciser la date sans décalage. Je peux rajouter, heure, minutes, secondes et ticks d'horloges à volonté sans me stresser. Apréciable, vous en conviendrez :).

La nuit s'avance alors je reprendrai demain ce monologue fort plaisant...

30 10 1999

Mots Clés : Boom.

Le but de ce petit article commencé hier était d'une part pour montrer que j'étais toujours en vie, si tant est que cela puisse intéresser quiquonque, et aussi de faire une petite synthèse de l'état du monde, de linux, et apparenté... Hormis mon certainement passionnant bavardage sur le choix de l'écriture des dates, je n'ai en fait pas dit grand chose... Tiens je me rappelle avoir parlé il y a de cela bien longtemps désormais du langage java et de sa relative importance. Si java reste à mes yeux un excellent langage objet très appréciable pour le prototypage, je serais aujourd'hui un peu plus frileux quant à sa future pénétration, hum... Non je vais changer de tournure là, parce que cela porte à confusion, disons que java everywhere j'ai quelques doute. Ce n'est pas tant java en lui même aujourd'hui qui me fait douter, c'est plutôt SUN (S! tanford University Netwok à la base, on en apprend tous les jours) dont la politique commerciale très agressive me semble en décalage avec l'arrivée de Linux. Arrivée de Linux qui, si elle permet à SUN de diminuer le pouvoir de Microsoft et d'augmenter l'audience UNIX, n'en reste pas moins à un peu plus long terme une concurrence. La concurrence n'est pas mauvaise, au contraire, c'est juste le manque de fair play qui peut faire un peu peur... En fait je pense vraiment que si un langage doit se généraliser à l'avenir, ce ne sera pas java, parce qu'il est trop sous le contrôle de SUN, ce sera plutôt un langage venant de la communauté, sous GPL ou simili. Je ne sais pas trop quand cela arrivera, mais cela devrait arriver... Tiens cela me donne des idées... C'est peut être le bon plan de faire un langage... Quoique cela ne doit pas être super évident... Le plus embetant c'est qu'il faut se taper un ! compilateur... Quoique cela doit & circ;tre assez marrant comme truc... Je vais un peu réfléchir à cela...

Revenons dans le vif du sujet, hum, ya pas de sujet... hum, bon, et bien alors parlons de choses, et d'autres... La concurrence n'est pas pour autant un gage de qualité. Prenons l'exemple des boulangers. Personnelement, grand amateur de pain, je suis profondemment déçu d'avoir un mal fou pour trouver un boulanger capable de faire du bon pain, et pourtant ce n'est pas le nombre de boulangers qui manque, mais leur pain n'est pas bon. En fait les boulangers utilise le critère de proximité pour se permettre de ne pas faire du bon pain puisque les gens considère plus important d'avoir du pain _vite_ que d'avoir du pain _bon_, Ce qui est dommage.

Cette parenthèse refermée, je m'apercois une fois de plus que je dis tout ce qui me passe par la tête et que la structuration du document est une fois de plus totalement bancale et desorganisée... Mais ce n'est pas très évident de définir une structure dès le départ et de s'y tenir par la suite. C'est d'ailleurs une cause majeure je pense de la non fonctionnalité de logiciel. Une structure est définie au début, puis s'aglutine la dessus des générations de programmeurs qui ont tous une idée un peu différente de cette structure ou veulent y ajouter un touche innovante et alors c'est un chef d'oeuvre de désorganisation qui voit le jour. Cela me rappelle une citation de je ne sais trop qui et qui ressemble à : ce qui réduit la productivité d'une entreprise, ce sont les éclairs de génie des incompétents qui stipule en gr! os que les personnes qui n'ont qu' une vision partielle de la chose et qui trouve une méthode beaucoup plus efficace pour faire leur travail ont en fait une repercussion telle à plus grande échelle que c'est tout le processus qui perd sa cohérence...

Mais c'est un problème difficile à corriger, si la situation idéale de tout réécrire from scratch à chaque fois parait séduisante elle n'en reste pas moins inapliccable pour les gros projets. Et, comme le démontre la créativité du modèle open source, c'est un facteur de rapidité et de plus grande productivité que de réutiliser du code déjà existant. Mais un jour, inévitablement, apparait le probleme d'une structure plus adaptée, ou dépassée. C'est pour cela que je pense que s'il est très profitable d'utiliser un code jusqu'à épuisement, il ne faut pas hésiter par moment à tout remettre a plat et repartir de zéro avec peut être un langage plus adapté ou plus puissant. Le concept de programmation objet peut sembler permettre dans un premier temps d'éviter cette remise à! plat et de tout recommencer en pe rmettant une modification itérative et régulière de chaque objet séparemment. Mais en fin de compte, et pour ceux qui ont fait un petit peu de programmation objet, cette modularité est toute relative et très limitée dans le temps, parce que basée aussi sur une structure, une normalisation partielle des interfaces qui sont vouées à évoluer elles-mêmes et par conséquent rendent caduques l'intérêt de la programmation objet. L'intérêt en tant que style de programmation évolutif : je ne reviens pas sur la plus grande simplicité et rigueur de la programmation objet.

Tout cela pour dire qu'à un moment ou à un autre il faudra revenir sur la structuration du noyau et, soit faire la même chose d'une façon plus intelligente, soit repartir sur des bases et style d'architecture logicielle différente si le matériel et la théorie de la programmation le permettent. Cependant ceci est encore un peu loin dans le futur je pense. Si Linux continue sont évolution à un rythme voisin de celui d'aujourd'hui, il devrait pouvoir tourner correctement sur 64 processeurs d'ici à un an, 512 dans 2 ou 3 ans mais après, je pense que commenceront à se poser des questions sur sa viabilité au dela de 1024 proc, et il y aura surement des divergences notables de lignées de noyaux mettant en oeuvre des approches différentes du SMP à grande échelle. Bon après tout cela c'est au feeling et c'est juste pour me réchauffer un peu les doigts pa! r ce samedi 30 octobre, hein, ne s oyons pas prétentieux, la stratégie c'est une copine à moi mais je la vois qu'une fois ou deux tous les dix ans alors bon...

Discuter du futur c'est sympa parce qu'on peut raconter à peu près n'importe quoi et c'est pas très grave, mais c'est un peu non productif aussi de perdre du temps à parler de choses qu'on ne connait pas, alors sur ce je m'en retourne à des choses plus terre à terre... J'ai un langage à créer moi :)

Mois suivant