Certes, mais le problème après est qu'il faut que ça marche et que ce soit performant.
J'attends de voir les retours sur 4.7.3, ça a l'air intéressant.
Note bien qu'un système de fichier normal a déjà un coût important puisque qu'il masque l'organisation du disque et si tu accèdes a plusieurs fichiers c'est dans un ordre assez aléatoire plutôt que d'utiliser l'ordre des blocks sur les disque (*).
Sauf ce coût là, on y est tellement habitué que personne n'y pense (et puis proposer d'utiliser les numéros de blocks plutôt que des noms de fichier, ça va pas aller bien loin ;-) ), mais si Nepomuk a un cout en perf raisonnable, je serai vraiment curieux de voir ce que les devs de GoboLinux peuvent faire avec Népomuk..
*: dans le papier: As an example, a tar of the Linux kernel tree was 82.5 seconds using GNU tar, while our modified tar completed in 17.9 seconds.
[^] # Re: les binaires, bof
Posté par reno . En réponse à la dépêche /usr friendly. Évalué à 2.
Certes, mais le problème après est qu'il faut que ça marche et que ce soit performant.
J'attends de voir les retours sur 4.7.3, ça a l'air intéressant.
Note bien qu'un système de fichier normal a déjà un coût important puisque qu'il masque l'organisation du disque et si tu accèdes a plusieurs fichiers c'est dans un ordre assez aléatoire plutôt que d'utiliser l'ordre des blocks sur les disque (*).
Sauf ce coût là, on y est tellement habitué que personne n'y pense (et puis proposer d'utiliser les numéros de blocks plutôt que des noms de fichier, ça va pas aller bien loin ;-) ), mais si Nepomuk a un cout en perf raisonnable, je serai vraiment curieux de voir ce que les devs de GoboLinux peuvent faire avec Népomuk..
*: dans le papier: As an example, a tar of the Linux kernel tree was 82.5 seconds using GNU tar, while our modified tar completed in 17.9 seconds.