Octabrain a écrit 1685 commentaires

Il doit être un peu énervé depuis qu'il a vu ça : http://www.milw0rm.com/exploits/5979 (pas juste du code, c'est bien sale et plein d'insultes)

Vite fait, si tes données peuvent être transformées en une liste de tuples : http://paste.stgraber.org/9698
Sans trop réfléchir, je pense que c'est du n^2 log(n)

'Te faut un wget modifié : http://sam.zoy.org/blog/2007-04-23-use-sshd-and-httpd-on-the(...)

> J'assume ma blague_a_la_con et mon -10 bien mérité, mais c'était vraiment de l'humour de mauvais gout pas drole
Mais je vois même pas en quoi c'est de l'humour, tu dis juste de ne pas utiliser le système de fichiers simplement parce que son auteur aurait commis un meurtre. C'est vraiment pas de l'humoir noir ou une quelconque forme d'humour. C'est juste un dénigrement pour une raison débile (le meurtre en question n'a même pas de lien avec le système de fichiers.
Quand bien même c'est de l'ironie, ça n'en fait pas pour autant de l'humour.

C'est parce que c'est même pas une blague, et c'est pas drôle non plus. C'est juste une insulte.

Il supporte ACL, xattr, etc. ?

Il t'a dit (en gros) qu'on pouvait utiliser les options loop et offset dans le fstab, pour faire le losetup avec la commande mount.

Sinon, "alias pampam=sudo"

La commande "locale" dit quelle locale est utilisé actuellement.
La commande "locale -a" liste les locales disponibles sur ton système.
La locale peut être changé séparément pour chaque processus avec la variable d'environnement LANG (en fait, il y a d'autres variables pour une gestion plus fine).

Par exemple la commande "LANG=C ls /nexiste_pas" renverra un message en anglais, mais ne changera la locale que pour ce processus "ls", en tapant "ls /nexiste_pas" après, tu auras un message dans la locale "précédente" (par exemple en français)

Ça sert à quoi d'échanger un système propriétaire contre un autre ?

Depuis le début, ".-" veut dire "CHF" ? Il parle en morse pour économiser la bande passante ?

En photo, je crois (mais je ne suis pas connaisseur)

on peut avoir des unités peut-être ?

pour l'instant, je n'ai essayé que "HyperEstraier", mais je ne m'en suis pas beaucoup servi.
Pour indexer, je fais :
estcmd gather -cm -sd NOMDEBASE DOSSIERDELOGS
mais j'utilise des options en plus pour qu'il n'indexe que le texte "intéressant" des logs : dans le cas de logs IRC, je ne garde pas le changements de modes sur un channel ou les joins/parts. Pour ça, j'ai fait un petit filtre shell, et je lui dis de passer les .log à travers ce filtre.
Pour chercher, il y a une simple commande shell qui affiche les "extraits" du résultats comme le fait google par exemple :
estcmd search -vh NOMDEBASE EXPRESSION
(EXPRESSION peut contenir des expressions compliquées ou régulières)

http://hyperestraier.sourceforge.net/ (disponible dans les paquets de certaines distributions)

[J'essaye de faire un UI pour ça]

(pardon, j'ai mal lu, les specs y sont)

Les drivers sont-ils libres ? Y a-t-il des specs ? Ont-ils l'accélération graphique matérielle ? Qu'en est-il du support des cartes "legacy" ?

Quel nom de merde ! :)

Selon Wiktionary, ça veut dire : une petite plante, un enfant ou un chou de Bruxelles. SproutCore signifie donc Cœur du chou de Bruxelles, mais la concurrence s'appelle Éclair, ou Lumière de l'argent...

http://mapage.noos.fr/echolalie/l1233.htm

Non, car bash ne peut que se connecter, pas écouter les connexions. Au contraire, zsh permet les 2, et n'est pas limité à une connexion par hôte et port :)

Franchement on a vu mieux comme soft peu portable...
Je répète ce que j'ai répondu plus haut :
Que ça été porté ne signifie pas forcément que c'est portable, il a peut-être fallu qu'ils réécrivent de grosses parties du code, qui ne serait donc pas portable.
Les ports en question ne sont pas intégré chez l'upstream FUSE, pourquoi, sinon parce que ce seraient des grosses modifications et qu'ils ne voudraient pas les "couvrir" ?

J'ai regardé le code de la partie noyau de FUSE disponible sur SourceForge, et il n'y a pas une ligne de support pour d'autres OS que Linux, que des "linux.h", des appels spécifiques à Linux, etc. Ce n'est absolument pas portable.
Les "portages" en question ont donc dû être réécrits à partir de rien (pour la partie noyau).


Le problème c'est que kio ou autre ne permettent pas à une application de le voir de manière transparente. Donc même si c'est portable ça ne fait pas tout, il faut que les applications comportent de quoi le lire.
J'ai également déjà répondu plus haut : soit on choisit d'écrire un(des) module(s) noyau, qui ne peut pas être écrit de façon portable, mais on supporte toutes les applications, soit on écrit une bibliothèque en espace utilisateur (style KIO), qui ne supporte pas toutes les applications (mais déjà pas mal pour un utilisateur lambda qui se restreindrait à son environnement KDE/GNOME), mais qui peut être largement plus portable qu'un module noyau.

> On ne parle pas de porter tous les modules noyaux dans notre cas, mais seulement fuse.
Comme j'ai dit précédemment, le code qui se trouve dans le noyau n'est à mon avis pas souvent portable. Le VFS des *BSD doit être bien différent de celui de Linux ou de celui de Windows. Peut-être même que la différence avec les VFS des micro-noyaux comme Hurd est encore plus grande.

> D'ailleurs comme dit plus bas, il me semble que fuse a été porté sur d'autre OS.
Je l'ai moi-même dit. Que ça été porté ne signifie pas forcément que c'est portable, il a peut-être fallu qu'ils réécrivent de grosses parties du code, qui ne serait donc pas portable.
Les ports en question ne sont pas intégré chez l'upstream FUSE, pourquoi, sinon parce que ce seraient des grosses modifications et qu'ils ne voudraient pas les "couvrir" ?

> Ha, et les détournements d'appels systèmes c'est portable ?
Je voulais dire que les KIO/etc. sont portables, je ne parlais pas des détournements puisque j'ai dit "moins de support des applications" (implicitement). (Cela dit, c'est possible sous windows avec des "hooks" je crois (mais je n'ai jamais fait))

> Moais tout les os le suive pas les standard (genre windows).
L'éventuelle couche d'abstraction, doit à mon avis être bien plus fine et moins dérangeante que la totale non-portabilité du code de modules noyaux.

> Et puis le pb avec kio, gvfs, ... c'est que tu ne peut utiliser que des applis specifiques.
Effectivement, il est difficile de faire mieux (à part avec des détournements d'appels systèmes, style LD_PRELOAD) en restant uniquement en espace utilisateur. C'est donc un échange, espace noyau et plus de support des programmes contre espace utilisateur et plus de portabilité. Mais je ne crois pas qu'on débattait de ça.

La partie noyau FUSE est peu portable, ce qui est dans le noyau est peu portable. Les noyaux n'ont absolument pas vocation à être portables entre eux (dans le sens "interopérable", je ne parle pas de la portabilité entre architectures matérielles).
Il y a quelques vagues "portages" (mais il n'y a par exemple rien pour OpenBSD), qui doivent se synchroniser avec l'upstream FUSE à chaque fois.

De plus, FUSE doit obligatoirement être chargé par le noyau. Si l'administrateur n'en veut pas, tu ne pourras rien faire. Si c'est uniquement en espace utilisateur, l'administrateur aura beaucoup plus de mal à t'empêcher. D'ailleurs il y verra peut-être moins d'inconvénients si ça ne touche pas au noyau. (Sans parler d'éventuels problèmes de sécurité)

> Au contraire, kio, gvfs, ... sont moins facilement portable puisque dépendent de beaucoup plu de lib.
Et bien, si ces libs sont bien écrites, elles sont portables sans de grosses difficultés, car elles n'utilisent que des choses standard, donc plutôt portables.

> je prefere calculer un hash puisque je n'ai pas besoin du mot en temps que tel, j'ai juste besoin d'etre capable de savoir si il est egal a un autre mot.

pour savoir si 2 mots sont égaux, il n'y a pas d'autre choix que strcmp.
Même hash ⇏ Même objet
mais
Même objet ⇒ Même hash
et sa contraposée :
Pas même hash ⇒ Pas même objet

J'oubliais, les KIO/GnomeVFS/etc. se font essentiellement en espace utilisateur, c'est-à-dire beaucoup plus portable que FUSE ou les solutions carrément dans le kernel (étant donné que ce n'est ni standardisé, ni très utilisé).

Le VFS de Linux ne supporte que les "chemins" (truc à base de "/" et de "non-/"). Les KIO/GnomeVFS supporte les URLs (ou URN ou URI, je sais pas trop), un truc un peu plus structuré, et peut-être plus puissant dans certains cas.