Krunch a écrit 4022 commentaires

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.

XLiveCD allows users of Microsoft Windows to connect to remote Unix computers, run graphical applications and have the graphics displayed on their desktops. The software runs from the CD without being installed.

http://xlivecd.indiana.edu/(...)

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

Un GSM c'est pas une petite plateforme ?

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

je souhaiterais vraiment comprendre l'engouement qui accompagne ce langage

Je ne connais pas (encore) Lisp mais il me semble qu'il est assez difficile de comprendre l'intérêt d'un langage sans l'utiliser. Donc plutôt que d'attendre une bonne raison pour t'y mettre, commence maintenant et tu aura ta bonne raison plus tard. Lisp me semble être un langage assez différent des langages classiques que pour qu'il soit intéressant à apprendre sans autre but que pour apprendre quelque chose de nouveau qui permet d'avoir un autre point de vue. Tout ce qu'il faut c'est un peu de littérature sur le sujet pour se lancer mais je ne pense pas que ça soit bien difficile à trouver.

Personnellement je connaissais le C avant Java et même si je n'aime pas trop Java et que je programmais déjà assez "objet" en C avant, le fait d'apprendre Java m'a permis de comprendre un peu mieux la POO, les exceptions et la reflection par exemple. Je programmerai probablement pas en Java par choix dans l'avenir mais je regrette pas de l'avoir appris.

D'un autre côté j'ai assez peu d'expérience donc il est possible que ce que je viens de dire ne soit pas très pertinent.

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

Heureusement que tu le précises.

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

J'ai pas de setup.exe qui traine non plus mais j'ai la "chance" d'avoir un contact msn qui me spam de liens vers un .scr.

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

C'est pas plutôt

bash: ./setup.exe: cannot execute binary file

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

Imagine MS vendant des mauvais logiciels avec Tux [...] sur la boîte ?

Moi j'ai ça dans linux/Documentation/logo.txt

It was created by Larry Ewing, and is freely usable as long as you acknowledge Larry as the original artist.

Donc légalement ya rien qui empèche Microsoft d'associer Tux à ce qu'ils veulent il me semble.

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

Si tu fais confiance aux serveur Jabber utilisés, il n'y a pas moyen de retrouver l'IP du correspondant non plus (enfin pas plus facilement qu'avec IRC).

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

et peut être aussi Box Backup http://www.fluffy.co.uk/boxbackup/(...)

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

D'un autre côté pour chiffrer de GAIM à GAIM, autant passer par Jabber dont le protocole de chiffrement des messages est standardisé.

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

Non c'est plutôt "si tu l'veux va falloir contribuer (ou attendre)". D'un autre côté c'est vrai que le choix de la première page est discutable je trouve.

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

Hu ? Depuis quand les discussions MSN sont-elles chiffrées ?

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

http://samizdat.mines.edu/howto/(...)

:op

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