Krunch a écrit 3860 commentaires

Quelque chose comme ça ?
http://www.editions-eyrolles.com/Livre/9782212114386/(...)
Bon en fait c'est plutôt le CD qui accompagne le livre :)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ca ressemble plutôt à un lecteur défectueux ça.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ben tu n'es pas libre de l'utiliser comme tu veux en quelques sortes. C'est pour la même raison que les gens de *BSD (surtout OpenBSD) ne considèrent pas la GPL comme une licence vraiment libre.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

http://lists.debian.org/debian-legal/2003/08/msg00530.html(...)
http://www.gnu.org/philosophy/apsl.html(...)

Si j'ai bien compris Debian ne considère pas ça comme une licence "libre" parce que tu es obligé de redistribuer la source, même si tu ne redistribues pas le binaire (j'ai juste survolé les deux liens que j'ai donnés).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tu peux essayer de recopier ce que tu peux de l'iso sur ton HD avec dd_rescue puis le monter en loopback.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et si les serveurs sont sur le même sous réseau, il y a CARP.
http://ucarp.org/(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

même google n'est pas à l'abris d'un attentat, catastrophe naturel, incendie

J'arrive plus à retrouver l'article mais il me semble avoir lu il y a quelques semaines qu'un des "datacenters" de Google a subi un incendie assez important sans qu'il n'y ait de downtime. Avec suffisamment de moyens, c'est pas très compliqué de faire un truc assez décentralisé pour qu'il soit pratiquement impossible d'avoir une panne "globale".

Mais c'est pas parce que je pense que ça peut être techniquement fiable que je pense que ça soit "bien" non plus (monopoles sux, toussa).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Celui là ? http://lyon69style.free.fr/barge.wav(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je crois que le risque n'est pas tellement là. Avec un gros cluster bien fait, il est pratiquement impossible de perdre beaucoup de données ou d'avoir du downtime conséquent même avec énormément de clients (documente toi un peu sur l'architecture de Google par exemple).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

mboxgrep(1) pour être précis mais pourquoi ne pas implémenter ça directement dans le système de fichier pour ne pas avoir à appeller le programme explicitiement (cf mes posts précédents dans ce thread) ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Non parce qu'avec maildir tu n'as qu'une seule hiérarchie possible (à moins de s'amuser à faire des ln(1) de partout mais c'est pas vraiment pratique à maintenir). Avec un (maildir|mbox)fs tu peux "créer" des répertoires et "regrouper" les mails de la manière que tu veux à la volée. Tu ne saurais pas vraiment accéder au répertoire "mails/tata mathilde" pour trouver tous les mails concernant tata mathilde avec juste maildir. Tu dois avoir des scripts à côté. Tandis qu'avec un (maildir|mbox)fs comme je le conçois, il y a un script/programme aussi mais tu n'as pas besoin de l'appeller explicitement.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ce que je propose dans mon post précédent devrait aussi fonctionner avec maildir. Et si tu y tiens vraiment, tu peux implémenter le maildirfs avec un scrit shell qui utilise grep.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Rien n'empèche de faire un système de fichiers virtuel qui permettrait de monter sa mailbox et d'y faire des recherches sur des mots clés uniquement en utilisant le système de fichiers. Dans ton exemple tu irais chercher dans le répertoire mailbox/tata mathilde/ et tu aurais une liste des mails (un par fichier) qui contiennent l'expression "tata mathilde". Evidemment si on veut que ça soit efficace ça doit être indexé automatiquement par le mboxfs aussi. Mais ça ne remet pas vraiment en cause l'utilisation du système de fichiers pour ce type d'utilisation.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

il suffit de taper l'URL dans la boîte de fichiers.
La question suivante, c'est de savoir comment on peut unifier ca avec Gnome-VFS ou autres.

Quoi de mieux donc que de gérer ça directement au niveau du système de fichiers ? Ca serait pas intéressant de pouvoir faire $EDITOR /ftp/example.org/foobar/baz.html ? Pas besoin de gérer ça au niveau de l'application. Sauf éventuellement pour traduire l'URL en chemin d'accès sur le système de fichiers. Et un daemon (factotum dans le cas de Plan9) à part qui s'occupe de l'autentification. Mais là encore, l'application n'a pas à s'en occuper, c'est juste le ftpfs qui doit discuter avec le daemon pour savoir quel user/passwd envoyer au serveur. Le problème de Gnome-VFS et le machin de KDE c'est que c'est spécifique à ces systèmes. Si on fait ça au niveau de l'OS comme sous Plan9 ou Hurd (les translators), on a plus ce problème.

Pour les pipes j'ai pas creusé la quesion mais les gens de Plan9 l'on fait (je sais pas ce que ça donne par rapport à dcop): http://cm.bell-labs.com/sys/doc/plumb.html(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Le système de fichier nécessite de relancer une recherche dans l'ensembles des données si on veut faire une recherche similaire, à chaque fois.

D'où l'intérêt de tenir l'index à jour lorsque les fichiers sont crées/détruits/modifiés. C'est ce qui est fait avec les système de fichiers journalisés mais à un niveau plus bas. Je vois pas pourquoi ça ne serait pas faisable pour les méta-données "utiles" à l'utilisateur.

Pour regrouper plusieurs fichiers en un seul document on peut les regrouper dans un .tar.gz et le "monter" comme un répertoire (sous Linux par défaut c'est pas possible mais ya sûrement un module targzfs qui traine quelque part, et au pire c'est pas compliqué à faire avec FUSE ou v9fs).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Sous Plan9, tu peux changer de "namespace" très facilement. C'est à dire que tu peux changer ta vision du système de fichiers. Un peu comme un chroot mais en mieux: tu peux assembler différentes arborescences pour créer la tienne (genre unionfs). À partir de là on peut imaginer un système de fichier plus "user-friendly" avec les trucs "inutiles" en moins qui sera celui de l'utilisateur lorsqu'il se log, tandis que le reste du système ne change pas.

http://cm.bell-labs.com/sys/doc/names.html(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Le langage C a d'ailleurs été écrit dans cette optique : être suffisamment de bas niveau pour permettre de jouer au niveau de l'optimisation

Heu moi j'avais compris que le C au départ c'était plutôt pour faire un truc portable puisqu'à cette époque pratiquement tous les OS étaient écris entiérement en assembleurs. Donc rien à voir avec les performances il me semble.

Sinon je crois que ce que tu cherches c'est Plan9 (et peut-être GNU Hurd). Enfin pour l'interface graphique je sais pas trop comment ça marche chez eux mais le "tout est fichier" est encore plus poussé que sous Unix.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Il faut utiliser le caractère "\r" qui fait revenir le curseur au début de la ligne. Pour un exemple de barre de progression tu peux aller voir le code de wget par exemple. Où utiliser ça (pas testé, mais ça compile):

typedef struct {
        int width;
        FILE *stream;
        char *bar;
} progress_bar;

progress_bar *init_progress_bar(FILE *stream, int width) {
        progress_bar *res;
        res = malloc(sizeof(progress_bar));
        res->stream = stream;
        res->bar = malloc(sizeof(char)*(width+1));
        res->width = width;

        memset(res->bar, ' ', width);
        res->bar[width] = '\0';
        fprintf(res->stream, "|");
        fprintf(res->stream, res->bar);
        fprintf(res->stream, "|\r|");
        memset(res->bar, '=', width);
        return res;
}

void update_progress_bar(progress_bar *bar, int progress) {
        bar->bar[progress] = '\0';
        fprintf(bar->stream, bar->bar);
        bar->bar[progress] = '=';
}

void free_progress_bar(progress_bar *bar) {
        free(bar->bar);
        free(bar);
}

Si tu reprends ça, oublie pas d'ajouter les vérifications d'usage au début de chaque fonction (buffer overflow, toussa).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ya un truc bizarre dans libetc.h quand même.

* libetc - Copyright (C) 2005 Luc Dufresne <luc@ordiluc.net>
[notice GPL]
/* code pasted from various glibc include files */
[code]

À moins que tu n'ais écrit les .h de la glibc toi même :)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Moi j'avais cru comprendre que la pile TCP/IP ajoutée à Windows du temps de 95 (ou quelque part par là ?) venait des BSD mais qu'elle a été réecrite par la suite. Mais bon je connais pas grand chose à l'histoire de Windows non plus.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Pour Perl il y a perlfs aussi mais ça a l'air un peu mort.
http://perlfs.sf.net/(...)
Sinon tu peux être intéressé dans 9P.
http://cm.bell-labs.com/magic/man2html/5/0intro(...)
http://v9fs.sf.net/(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tu peux chiffrer tous les binaires et les déchiffrer au démarrage. Evidemment ça veut dire que la clé se trouve en clair quelque part sur le disque/ROM/... mais il faut encore la trouver. Donc il ne reste plus qu'à "obfuscater" le code qui récupère/utilise la clé.

Je sais pas si c'est comme ça que ça a été utilisé dans ce cas ci.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Normalement ça ira pas mieux ça, il y a toujours le "*" qui se transforme en la liste de fichiers. Par contre find /video/\* ... devrait fonctionner je pense (ou même find /video/ -type f ...). Sinon for i in $(ls) ; do cp $i /repertoire/de/destination/ ; done ou encore find /video/\* | xargs -i cp \{\} /destination/.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Sinon un truc du genre

$ source /home/foobar.sh

devrait fonctionner aussi (cf man bash).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

http://honeynet.org/misc/chall.html(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.