La question d'un convertisseur ext2->reiserfs revient souvent... C'est euh.... pas impossible... mais TRES TRES TRES CHIANT à faire, et personne n'a envie de bosser là-dessus à court ou moyen terme.
Voici comme prévu le second épisode de notre fabuleuse saga...
*** REISERFS AUJOURD'HUI ***
Les performances des versions actuelles de ReiserFS dépendent énormément de
ce que l'on en fait. Pour les accès en lecture, c'est en général beaucoup
plus rapide qu'Ext2, surtout si l'on s'amuse à faire des déplacement un peu
partout dans les fichiers. En écriture... ça dépend. C'est souvent comparable
à Ext2, mais la journalisation ajoute quelques limitations. Tout d'abord,
les appels à fsync() ou fsyncdata() sont lents. Car actuellement, appeler
ces fonctions conduit à une synchronisation complete du journal. Toutes les
transactions sont réalisées, y compris celles concernant d'autres fichiers
que celui sur lequel on appelle fsync(). Pour cette raison, des logiciels
comme les serveurs de mail et les bases de donées sont plus lents en mise à
jour avec ReiserFS que Ext2. Solution radicale pour accélérer tout ça :
enlever la journalisation.
ReiserFS est aussi très rapide pour accéder à des répertoires contenant des
millions de fichiers. En effet, tous les noms sont indexés dans une table de
hash pour les repérer rapidement (c'est ça, le R5 hash, TEA hash, etc...) .
C'est très intéressant, car pour une application genre 'forum' par exemple,
il n'y a aucune honte à coller tous les messages dans un répertoire, un
fichier par message. Ca ne pose aucun problème, c'est simple à coder et
c'est très rapide. L'Ext2 tire très vite la langue dans des conditions
similaires.
Et pour encore plus de performances dans une telle situation, on peut
désormais accéder aux fichiers directement à partir de leur numéro d'inode.
Aucune recherche n'est donc effectuée, l'accès est immédiat. Ce sont des
travaux qui ont été réalisés pour l'optimisation de Squid, mais d'autres
applications peuvent en tirer partie.
ReiserFS a un autre intéret : il peut vous faire gagner de l'espace disque
(voir l'épisode 1 - plusieurs choses dans un même bloc) . Ce sont les
'tails'. Prenez une partition ext2, convertissez-là en ReiserFS et ... oh
miracle, vous avez environ 5% de place en plus qu'avant. Tout dépend de la
taille des fichiers, mais tous les petits fichiers de config y gagnent.
D'un autre coté, l'écriture (et surtout le fait d'y ajouter des données)
dans ces fichiers 'compactés' est plus lente qu'en temps normal. Vous pouvez
accélérer les choses en montant vos filesystems ReiserFS avec l'option
'-notail'.
Sinon, puisque quelqu'un parlait d'un problème avec Lilo... Le problème
venait justement de l'histoire des tails. Lilo a du mal à charger des données
qui débutent en plein milieu d'un secteur. Un appel système a donc été rajouté
sur les versions récentes de ReiserFS pour 'décompacter' un fichier. Cet
appel est utilisé sur les versions récentes de Lilo. Votre partition /boot
(ou /) peut donc utiliser les tails sans problème, pensez juste à mettre à
jour votre Lilo.
Quid des autres filesystems....
Ext3 : malgré son numéro de version faiblard, il est assez stable. Mais très
lent. Trop lent même. Intéret : on peut migrer de ext3 vers ext2 et
inversement facilement.
Tux2 : instable, encore beaucoup de travail à y apporter, mais le concept
est intéressant et l'auteur bosse bien dessus.
XFS et JFS : quelqu'un qui a testé longuement les derniers snapshots peut
nous en parler ?
Quoi qu'il en soit, le meilleur filesystem "traditionnel" (organisation
linéaire pour les applications, pas de plug-ins) est à mon avis celui de
Netapp. Il a d'ailleurs été programmé par l'équipe qui avait pondu le XFS à
l'époque. Mais je doute qu'il soit un jour porté sur nos linuxettes.
Bon alors on va essayer de résumer un peu la situation...
*** POURQUOI A ETE CREE REISERFS ? ***
Lorsque Monsieur Reiser, Hans de son prénom, étudiait à Berkeley, il a eu
comme tous ses petits camarades, une thèse de fin d'étude à rendre. Et en
guise de sujet, il a choisi les filesystems. Après avoir étudié un peu tout
ce qui avait été fait dans le domaine, il s'est appercu qu'ils reposaient
tous sur les memes concepts archaiques :
- Les données sont organisées dans des fichiers, situés dans une
arborescence de répertoires. Ces données se présentent sous la forme d'un
triste ensemble linéaire.
- On peut ajouter des données à la fin d'un fichier, écrire par dessus
celles qui sont déjà présentes ou tronquer la fin d'un fichier. C'est tout,
aucune autre opération.
A cause de ces deux points, programmer des applications est souvent un
casse-tête. Les applications manipulent des données. Des données
structurées. Des données qui ont des liens entre elles. Des données que l'on
peut trafiquer dans tous les sens en mémoire. Mais dès l'instant où il faut
les sauvegarder, les charger, les indexer sur disque, bref... les placer
dans un système de fichiers, c'est la galère. Il faut trouver un moyen de
linéariser toutes ces structures, définir une nouvelle représentation qui
n'a aucun rapport avec celle en mémoire et qui est à des années lumière
d'une idéale représentation théorique. Prenons un exemple simple : une liste
chaînée. En mémoire, c'est simple, hop, hop, hop, chaque élément est composé
d'un champs qui pointe vers un autre élément. Maintenant effectuons la même
chose dans un fichier... oh-oh... ça engendre déjà quelques complications,
surtout si toutes ces données sont dynamiques... Il va falloir commencer à
se creuser la tête pour imaginer un "format de données", cette chose qui
représente la principale source d'incompatibilités et de soucis entre les
logiciels...
Pour limiter la casse, on peut passer par des moteurs de bases de données,
qui nous présentent une interface un peu moins limitée que
open/fseek/read/write/ftruncate ... Ces moteurs vont trafiquer des données
présentées sous une certaine forme pour finalement les recoder autrement sur
disque dur, au prix d'une charge processeur et disque incroyables pour lire
quelques malheureux octets. Il existe aussi maintenant des langages tels que
XML qui prouvent bien le manque qui existe pour la représentation de données
structurées sur un disque dur.
Plutot que d'employer des artifices ou de demander aux programmeurs
d'adapter leurs applications aux limitations d'un filesystem... pourquoi ne
pas voir les choses autrement ?
Par exemple, au lieu d'accéder à des données à l'aide d'un chemin, pourquoi
n'y accederait-on pas par mots-clefs ? Si notre application représente
facilement des arbres en mémoire, pourquoi ne serait-il pas possible d'avoir
un système de fichiers adapté à la structure que l'on utilise ?
L'idée serait par exemple d'avoir un système de plug-ins, pour que le
filesystem s'adapte aux applications. La programmation devient beaucoup plus
simple, et les performances sont optimales. Cela permet au passage de mettre
les traditionnelles bases de données à la poubelle dans bien des cas.
Hans Reiser a continué sa reflexion sur l'organisation des fichiers dans les
principaux filesystems. Bizarre... une division en 'blocs', un index et une
liste de blocs libres, tout ça localisé dans un coin (tout au début du
disque pour la plupart, en plein milieu pour HPFS) ... les données
elles-memes réparties un peu n'importe comment sur le disque, là où il y a
de la place...)
C'est bizarre... Pourquoi ne pas mettre les méta-données à coté des données
concernées ? Ce serait plus simple et plus rapide. Pourquoi cette notion de
blocs ? Ne pourrait-on pas placer données et métadonnées dans un seul bloc,
voir plusieurs petits fichiers dans un meme bloc ? On gagnerait du coup de
l'espace disque et des performances (un seul secteur à lire pour plusieurs
fichiers, méta-données et contenu) . Apparemment, tous les filesystems
traditionnels ont négligé les petits fichiers.
Un disque dur est principalement mécanique. Sa pauvre petite tete n'a pas
une vitesse infinie. Pourquoi n'essayerait-on pas de placer les données au
mieux pour en limiter les déplacements ? Quitte à déplacer et à réorganiser
ces données sur le disque pour que, dès qu'un meilleur emplacement pour des
données soit disponible, il soit utilisé ?
Autre reflexion... Se balader dans de gros fichiers prend du temps. Car un
gros fichier n'est que très rarement linéaire sur le disque... il est en
plusieurs morceaux... Mais... Pourquoi ne pas organiser les données (et pas
seulement les indexes) sous forme d'un B-tree ? Il serait alors toujours
aussi rapide d'accéder à n'importe quel point d'un fichier. Ah oui il faut
rééquilibrer l'arbre régulierement pour que ça reste un b-tree... C'est pas
si évident que ça à coder...
En fait toutes ces idées sont excellentes. Repartir sur de nouvelles bases
(après tout très logiques) pour un filesystem est une aventure passionnante.
Mais c'est un travail énorme. Le pauvre petit Hans ne pouvait pas faire ça
tout seul. Alors, une fois son diplôme en poche, il a fondé Namesys Venture,
convaincu quelques investisseurs de lui donner du pognon pour commencer...
Et embaucher des programmeurs pour travailler sur le projet.
Le moteur de recherche Ecila a été assez rapidement intéressé pour
sponsoriser le projet, en particulier pour une indexation par mots-clefs. La
société Namesys est née. Elle a ensuite changé de nom pour passer à ReiserFS
à cause de quelques escrocs qui ont quitté la barque en cours de route.
Bon, dans le prochain épisode, je tenterai de répondre aux questions
suivantes : quel intéret aujourd'hui, face à Ext2, Ext3, Tux2, XFS et JFS.
Et dans le dernier épisode : le futur.
Non, malgré un nom qui "sonne" allemand, Hans Reiser est en Oakland, avec sa maman qui gère aussi les sous. Mais il est très souvent à Saint Petersburg, ne serait-ce-que parce que sa petite femme Nina s'y trouve.
Mais Monsieur Reiser et son filesystem n'ont aucun rapport avec le sujet de la news, alors on va s'arreter là pour aujourd'hui.
Je ne travaille plus sur ReiserFS, du moins comme employé pour Hans Reiser. Non pas par manque d'intéret pour le projet, loin de là (surtout pour ce qui est en préparation en ce moment), mais parce que lorsque l'on réside en France, mais que l'on travaille pour une société américaine, c'est l'enfer (problèmes administratifs, fiscaux, les banques qui mettent 4 mois pour faire les virements, ...) .
Mon bouquin est fini depuis longtemps, et continue d'etre actualisé sans cesse (http://www.weka.fr(...) et après c'est dans les nouveautés) . Cela dit, je pense que d'etre abonné à toutes les mailing-lists de développeurs et d'utilisateurs en rapport avec les logiciels qu'on utilise régulierement vaut très largement le meilleur des bouquins sur Linux. Ce qui est raconté dans le bouquin est principalement un condensé des discussions qui ont pu se tenir sur les listes lkml, reiserfs, qmail, etc...
Dan Bernstein n'est pas seulement l'auteur de Qmail, mais de tout un tas d'autres logiciels très utiles. Il a tendance à réinventer Unix (tinydns au lieu de bind, ucspi-tcp au lieu de inetd et netcat, cdb au lieu de db -pour les données statiques-, qmail au lieu de sendmail...) .
Et pourtant... quand on a mis le pied dans le djb-ware, on a du mal à installer des systèmes sans ses logiciels. Malgré leur interface très déroutante et les documentations succintes, ils sont rapides, peu gourmands en ressources, ne plantent jamais et sont sécurisés jusqu'à la moelle.
Ce ne sont jamais des usines à gaz, mais tout un tas de petites briques qui s'assemblent les unes dans les autres, laissant facilement place à d'autres briques pour la personnalisation.
Je vous recommande en particulier les daemontools : ils permettent de lancer et de superviser ses démons avec 'supervise', 'svc', 'svscan' et 'fghack', des outils très, très, très pratiques qui simplifient bien l'administration système et aident à fiabiliser les services.
Tinydns est aussi un excellent choix comme serveur DNS, meme si au premier abord, la configuration peut paraitre vraiment... originale !
Concernant Qmail, vous pouvez trouver quelques outils et patches non référencés sur qmail.org à l'adresse suivante : http://www.jedi.claranet.fr(...) ... En particulier un patch qui permet de compresser/décompresser les messages email de façon transparente. Pratique pour les commerciaux qui envoient des powerpoint et du word à tout va.
J'ai du mal à comprendre comment une telle protection pourrait être mise en place.
Le seul moyen d'y arriver est d'avoir un CD spécialement gravé en fonction d'un truc qui identifie sa machine.
Ca n'est possible que :
- Si on envoie une disquette à microsoft par la poste et qu'on attend un CD personnalisé en retour. Pratique, rapide, fiable,... ahahah
- On downloade le soft en ligne. Mais tout le monde n'a pas l'internet (et puis ça va utiliser des ports à la noix filtrés par tous les firewalls des entreprises) .
Alors ? Comment voulez-vous acheter une logiciel, dans sa boite, avec un CD utilisable sur un seul ordinateur ? On peut éventuellement envisager un CD en carton, qui s'autodétruirait après trop de rotations dans un lecteur, mais à part ça....
Et comment "l'ordinateur" est-il identifié ? C'est plutot une installation de zindoz qui serait identifiée, d'après un nombre aléatoire généré lors de l'install de zindoz (et stocké dans c:\win\secret.key.do.not.copy ahhahhaha) .
C'est plutot génant : windows se met à merder, il faut que je reformate mon dur et que je réinstalle tout (grand classique zindozien) . Je peux installer l'OS (pardon, le progiciel), mais... plus aucun des logiciels que j'ai acheté ?
Admettons maintenant que l'identification se base vraiment sur le hardware. J'ajoute une barette de RAM ou j'achete un nouveau CPU et hop, plus aucun de mes logiciels ne fonctionne ?
Bon imaginons que si, ils fonctionnent dans les deux cas précédents, c'est un miracle technique que j'ai du mal à comprendre, mais revons un peu.
Mon PC rame trop sous zin, je vire tout pour mettre BeOS, QNX et GNU/Linux. Et j'en achete un autre pour foutre zin (là c'est vraiment des suppositions, j'ai jamais eu de zin sur mes machines) . Et ? Je fous mes CD à la poubelle ? Je les renvoie à Kro avec une disquette et j'attends 2 mois pour pouvoir réinstaller mes softs ?
Bref, le système tel qu'il est décrit dans cet article n'est pas concevable, tant du point de vue théorique que pratique ou tout simplement logique.
Le seul moyen d'approcher le "un cd, une machine" c'est d'en revenir aux bons vieux dongles. Les machins que l'on colle sur le port série. Mais si c'est tout ce qu'a trouvé Microsoft, euh... ce n'est pas franchement révolutionnaire. Je ne doute meme pas un seul instant que bien des gens ont désormais l'entrainement nécessaire pour rendre inefficaces ces dongles en quelques coups de debugger.
Donc soit Microsoft livre du hard avec le soft, soit on ne peut que downloader les logiciels de Whistler en ligne, soit cet article n'est qu'une invention.
Quoi qu'il en soit, ça ne devrait avoir aucune influence sur les personnes qui préferent un OS.
150 Millions de Francs + 37 Millions + ... argl ! Non mais ils leur faudra combien de siècles pour rentabiliser ça avec de pauvres bannières de pub ?
Je n'arrive toujours pas à comprendre pourquoi des investisseurs claquent un pognon monstrueux dans des start-up qui n'ont aucune chance de rapporter quoi que ce soit. Ces types là ne voient pas le bide monstrueux que font la plupart des start-up d'informatique ? Pourquoi est-ce-qu'ils n'investissent pas dans l'immobilier ou autre chose de plus intelligent ?
Si je crée une start-up qui affiche le chiffre "8" en gothique sur une page Web (inédit, grande premiere mondiale, très e-business), vous croyez que je peux lever combien de millions ?
[^] # Re: utilitaire
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
[^] # Re: utilitaire
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 1.
-Jedi.
# REISERFS : Episode 2
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 5.
*** REISERFS AUJOURD'HUI ***
Les performances des versions actuelles de ReiserFS dépendent énormément de
ce que l'on en fait. Pour les accès en lecture, c'est en général beaucoup
plus rapide qu'Ext2, surtout si l'on s'amuse à faire des déplacement un peu
partout dans les fichiers. En écriture... ça dépend. C'est souvent comparable
à Ext2, mais la journalisation ajoute quelques limitations. Tout d'abord,
les appels à fsync() ou fsyncdata() sont lents. Car actuellement, appeler
ces fonctions conduit à une synchronisation complete du journal. Toutes les
transactions sont réalisées, y compris celles concernant d'autres fichiers
que celui sur lequel on appelle fsync(). Pour cette raison, des logiciels
comme les serveurs de mail et les bases de donées sont plus lents en mise à
jour avec ReiserFS que Ext2. Solution radicale pour accélérer tout ça :
enlever la journalisation.
ReiserFS est aussi très rapide pour accéder à des répertoires contenant des
millions de fichiers. En effet, tous les noms sont indexés dans une table de
hash pour les repérer rapidement (c'est ça, le R5 hash, TEA hash, etc...) .
C'est très intéressant, car pour une application genre 'forum' par exemple,
il n'y a aucune honte à coller tous les messages dans un répertoire, un
fichier par message. Ca ne pose aucun problème, c'est simple à coder et
c'est très rapide. L'Ext2 tire très vite la langue dans des conditions
similaires.
Et pour encore plus de performances dans une telle situation, on peut
désormais accéder aux fichiers directement à partir de leur numéro d'inode.
Aucune recherche n'est donc effectuée, l'accès est immédiat. Ce sont des
travaux qui ont été réalisés pour l'optimisation de Squid, mais d'autres
applications peuvent en tirer partie.
ReiserFS a un autre intéret : il peut vous faire gagner de l'espace disque
(voir l'épisode 1 - plusieurs choses dans un même bloc) . Ce sont les
'tails'. Prenez une partition ext2, convertissez-là en ReiserFS et ... oh
miracle, vous avez environ 5% de place en plus qu'avant. Tout dépend de la
taille des fichiers, mais tous les petits fichiers de config y gagnent.
D'un autre coté, l'écriture (et surtout le fait d'y ajouter des données)
dans ces fichiers 'compactés' est plus lente qu'en temps normal. Vous pouvez
accélérer les choses en montant vos filesystems ReiserFS avec l'option
'-notail'.
Sinon, puisque quelqu'un parlait d'un problème avec Lilo... Le problème
venait justement de l'histoire des tails. Lilo a du mal à charger des données
qui débutent en plein milieu d'un secteur. Un appel système a donc été rajouté
sur les versions récentes de ReiserFS pour 'décompacter' un fichier. Cet
appel est utilisé sur les versions récentes de Lilo. Votre partition /boot
(ou /) peut donc utiliser les tails sans problème, pensez juste à mettre à
jour votre Lilo.
Quid des autres filesystems....
Ext3 : malgré son numéro de version faiblard, il est assez stable. Mais très
lent. Trop lent même. Intéret : on peut migrer de ext3 vers ext2 et
inversement facilement.
Tux2 : instable, encore beaucoup de travail à y apporter, mais le concept
est intéressant et l'auteur bosse bien dessus.
XFS et JFS : quelqu'un qui a testé longuement les derniers snapshots peut
nous en parler ?
Quoi qu'il en soit, le meilleur filesystem "traditionnel" (organisation
linéaire pour les applications, pas de plug-ins) est à mon avis celui de
Netapp. Il a d'ailleurs été programmé par l'équipe qui avait pondu le XFS à
l'époque. Mais je doute qu'il soit un jour porté sur nos linuxettes.
-Jedi.
# REISERFS - Premiere partie
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 5.
*** POURQUOI A ETE CREE REISERFS ? ***
Lorsque Monsieur Reiser, Hans de son prénom, étudiait à Berkeley, il a eu
comme tous ses petits camarades, une thèse de fin d'étude à rendre. Et en
guise de sujet, il a choisi les filesystems. Après avoir étudié un peu tout
ce qui avait été fait dans le domaine, il s'est appercu qu'ils reposaient
tous sur les memes concepts archaiques :
- Les données sont organisées dans des fichiers, situés dans une
arborescence de répertoires. Ces données se présentent sous la forme d'un
triste ensemble linéaire.
- On peut ajouter des données à la fin d'un fichier, écrire par dessus
celles qui sont déjà présentes ou tronquer la fin d'un fichier. C'est tout,
aucune autre opération.
A cause de ces deux points, programmer des applications est souvent un
casse-tête. Les applications manipulent des données. Des données
structurées. Des données qui ont des liens entre elles. Des données que l'on
peut trafiquer dans tous les sens en mémoire. Mais dès l'instant où il faut
les sauvegarder, les charger, les indexer sur disque, bref... les placer
dans un système de fichiers, c'est la galère. Il faut trouver un moyen de
linéariser toutes ces structures, définir une nouvelle représentation qui
n'a aucun rapport avec celle en mémoire et qui est à des années lumière
d'une idéale représentation théorique. Prenons un exemple simple : une liste
chaînée. En mémoire, c'est simple, hop, hop, hop, chaque élément est composé
d'un champs qui pointe vers un autre élément. Maintenant effectuons la même
chose dans un fichier... oh-oh... ça engendre déjà quelques complications,
surtout si toutes ces données sont dynamiques... Il va falloir commencer à
se creuser la tête pour imaginer un "format de données", cette chose qui
représente la principale source d'incompatibilités et de soucis entre les
logiciels...
Pour limiter la casse, on peut passer par des moteurs de bases de données,
qui nous présentent une interface un peu moins limitée que
open/fseek/read/write/ftruncate ... Ces moteurs vont trafiquer des données
présentées sous une certaine forme pour finalement les recoder autrement sur
disque dur, au prix d'une charge processeur et disque incroyables pour lire
quelques malheureux octets. Il existe aussi maintenant des langages tels que
XML qui prouvent bien le manque qui existe pour la représentation de données
structurées sur un disque dur.
Plutot que d'employer des artifices ou de demander aux programmeurs
d'adapter leurs applications aux limitations d'un filesystem... pourquoi ne
pas voir les choses autrement ?
Par exemple, au lieu d'accéder à des données à l'aide d'un chemin, pourquoi
n'y accederait-on pas par mots-clefs ? Si notre application représente
facilement des arbres en mémoire, pourquoi ne serait-il pas possible d'avoir
un système de fichiers adapté à la structure que l'on utilise ?
L'idée serait par exemple d'avoir un système de plug-ins, pour que le
filesystem s'adapte aux applications. La programmation devient beaucoup plus
simple, et les performances sont optimales. Cela permet au passage de mettre
les traditionnelles bases de données à la poubelle dans bien des cas.
Hans Reiser a continué sa reflexion sur l'organisation des fichiers dans les
principaux filesystems. Bizarre... une division en 'blocs', un index et une
liste de blocs libres, tout ça localisé dans un coin (tout au début du
disque pour la plupart, en plein milieu pour HPFS) ... les données
elles-memes réparties un peu n'importe comment sur le disque, là où il y a
de la place...)
C'est bizarre... Pourquoi ne pas mettre les méta-données à coté des données
concernées ? Ce serait plus simple et plus rapide. Pourquoi cette notion de
blocs ? Ne pourrait-on pas placer données et métadonnées dans un seul bloc,
voir plusieurs petits fichiers dans un meme bloc ? On gagnerait du coup de
l'espace disque et des performances (un seul secteur à lire pour plusieurs
fichiers, méta-données et contenu) . Apparemment, tous les filesystems
traditionnels ont négligé les petits fichiers.
Un disque dur est principalement mécanique. Sa pauvre petite tete n'a pas
une vitesse infinie. Pourquoi n'essayerait-on pas de placer les données au
mieux pour en limiter les déplacements ? Quitte à déplacer et à réorganiser
ces données sur le disque pour que, dès qu'un meilleur emplacement pour des
données soit disponible, il soit utilisé ?
Autre reflexion... Se balader dans de gros fichiers prend du temps. Car un
gros fichier n'est que très rarement linéaire sur le disque... il est en
plusieurs morceaux... Mais... Pourquoi ne pas organiser les données (et pas
seulement les indexes) sous forme d'un B-tree ? Il serait alors toujours
aussi rapide d'accéder à n'importe quel point d'un fichier. Ah oui il faut
rééquilibrer l'arbre régulierement pour que ça reste un b-tree... C'est pas
si évident que ça à coder...
En fait toutes ces idées sont excellentes. Repartir sur de nouvelles bases
(après tout très logiques) pour un filesystem est une aventure passionnante.
Mais c'est un travail énorme. Le pauvre petit Hans ne pouvait pas faire ça
tout seul. Alors, une fois son diplôme en poche, il a fondé Namesys Venture,
convaincu quelques investisseurs de lui donner du pognon pour commencer...
Et embaucher des programmeurs pour travailler sur le projet.
Le moteur de recherche Ecila a été assez rapidement intéressé pour
sponsoriser le projet, en particulier pour une indexation par mots-clefs. La
société Namesys est née. Elle a ensuite changé de nom pour passer à ReiserFS
à cause de quelques escrocs qui ont quitté la barque en cours de route.
Bon, dans le prochain épisode, je tenterai de répondre aux questions
suivantes : quel intéret aujourd'hui, face à Ext2, Ext3, Tux2, XFS et JFS.
Et dans le dernier épisode : le futur.
-Jedi.
# La France n'existe pas...
Posté par j . En réponse à la dépêche Ginger : la révolution à roulettes. Évalué à 1.
[^] # Re: DJB
Posté par j . En réponse à la dépêche Publicité mensongère de Sendmail, Inc. ?. Évalué à 1.
Mais Monsieur Reiser et son filesystem n'ont aucun rapport avec le sujet de la news, alors on va s'arreter là pour aujourd'hui.
-Jedi.
[^] # Re: DJB
Posté par j . En réponse à la dépêche Publicité mensongère de Sendmail, Inc. ?. Évalué à 1.
Mon bouquin est fini depuis longtemps, et continue d'etre actualisé sans cesse (http://www.weka.fr(...) et après c'est dans les nouveautés) . Cela dit, je pense que d'etre abonné à toutes les mailing-lists de développeurs et d'utilisateurs en rapport avec les logiciels qu'on utilise régulierement vaut très largement le meilleur des bouquins sur Linux. Ce qui est raconté dans le bouquin est principalement un condensé des discussions qui ont pu se tenir sur les listes lkml, reiserfs, qmail, etc...
-Jedi.
# DJB
Posté par j . En réponse à la dépêche Publicité mensongère de Sendmail, Inc. ?. Évalué à 4.
Et pourtant... quand on a mis le pied dans le djb-ware, on a du mal à installer des systèmes sans ses logiciels. Malgré leur interface très déroutante et les documentations succintes, ils sont rapides, peu gourmands en ressources, ne plantent jamais et sont sécurisés jusqu'à la moelle.
Ce ne sont jamais des usines à gaz, mais tout un tas de petites briques qui s'assemblent les unes dans les autres, laissant facilement place à d'autres briques pour la personnalisation.
Je vous recommande en particulier les daemontools : ils permettent de lancer et de superviser ses démons avec 'supervise', 'svc', 'svscan' et 'fghack', des outils très, très, très pratiques qui simplifient bien l'administration système et aident à fiabiliser les services.
Tinydns est aussi un excellent choix comme serveur DNS, meme si au premier abord, la configuration peut paraitre vraiment... originale !
Concernant Qmail, vous pouvez trouver quelques outils et patches non référencés sur qmail.org à l'adresse suivante : http://www.jedi.claranet.fr(...) ... En particulier un patch qui permet de compresser/décompresser les messages email de façon transparente. Pratique pour les commerciaux qui envoient des powerpoint et du word à tout va.
-Jedi.
# Bizarre...
Posté par j . En réponse à la dépêche protection des futurs windows. Évalué à 1.
Le seul moyen d'y arriver est d'avoir un CD spécialement gravé en fonction d'un truc qui identifie sa machine.
Ca n'est possible que :
- Si on envoie une disquette à microsoft par la poste et qu'on attend un CD personnalisé en retour. Pratique, rapide, fiable,... ahahah
- On downloade le soft en ligne. Mais tout le monde n'a pas l'internet (et puis ça va utiliser des ports à la noix filtrés par tous les firewalls des entreprises) .
Alors ? Comment voulez-vous acheter une logiciel, dans sa boite, avec un CD utilisable sur un seul ordinateur ? On peut éventuellement envisager un CD en carton, qui s'autodétruirait après trop de rotations dans un lecteur, mais à part ça....
Et comment "l'ordinateur" est-il identifié ? C'est plutot une installation de zindoz qui serait identifiée, d'après un nombre aléatoire généré lors de l'install de zindoz (et stocké dans c:\win\secret.key.do.not.copy ahhahhaha) .
C'est plutot génant : windows se met à merder, il faut que je reformate mon dur et que je réinstalle tout (grand classique zindozien) . Je peux installer l'OS (pardon, le progiciel), mais... plus aucun des logiciels que j'ai acheté ?
Admettons maintenant que l'identification se base vraiment sur le hardware. J'ajoute une barette de RAM ou j'achete un nouveau CPU et hop, plus aucun de mes logiciels ne fonctionne ?
Bon imaginons que si, ils fonctionnent dans les deux cas précédents, c'est un miracle technique que j'ai du mal à comprendre, mais revons un peu.
Mon PC rame trop sous zin, je vire tout pour mettre BeOS, QNX et GNU/Linux. Et j'en achete un autre pour foutre zin (là c'est vraiment des suppositions, j'ai jamais eu de zin sur mes machines) . Et ? Je fous mes CD à la poubelle ? Je les renvoie à Kro avec une disquette et j'attends 2 mois pour pouvoir réinstaller mes softs ?
Bref, le système tel qu'il est décrit dans cet article n'est pas concevable, tant du point de vue théorique que pratique ou tout simplement logique.
Le seul moyen d'approcher le "un cd, une machine" c'est d'en revenir aux bons vieux dongles. Les machins que l'on colle sur le port série. Mais si c'est tout ce qu'a trouvé Microsoft, euh... ce n'est pas franchement révolutionnaire. Je ne doute meme pas un seul instant que bien des gens ont désormais l'entrainement nécessaire pour rendre inefficaces ces dongles en quelques coups de debugger.
Donc soit Microsoft livre du hard avec le soft, soit on ne peut que downloader les logiciels de Whistler en ligne, soit cet article n'est qu'une invention.
Quoi qu'il en soit, ça ne devrait avoir aucune influence sur les personnes qui préferent un OS.
-Jedi.
[^] # Re: Proxy
Posté par j . En réponse à la dépêche Opera en béta 4. Évalué à 1.
proxy.rtchat.com:8080
Ca a l'air de fonctionner...
-Jedi.
# Gloups
Posté par j . En réponse à la dépêche interview de david bitton, pdg d'oreka. Évalué à 1.
Je n'arrive toujours pas à comprendre pourquoi des investisseurs claquent un pognon monstrueux dans des start-up qui n'ont aucune chance de rapporter quoi que ce soit. Ces types là ne voient pas le bide monstrueux que font la plupart des start-up d'informatique ? Pourquoi est-ce-qu'ils n'investissent pas dans l'immobilier ou autre chose de plus intelligent ?
Si je crée une start-up qui affiche le chiffre "8" en gothique sur une page Web (inédit, grande premiere mondiale, très e-business), vous croyez que je peux lever combien de millions ?