Simon_N a écrit 22 commentaires

  • # Liste de tous les protocoles

    Posté par  . En réponse au message [X-Window] Pages de man sous KDE. Évalué à 1.

    Pour obtenir la liste de tous les protocoles disponibles sous KDE, il est possible d'aller voir l'aide, en passant par le protocole "help" : dans la barre d'URL de konqueror, ou l'exécution rapide, taper "help:kioslave".
  • [^] # Re: Ben dis donc !

    Posté par  . En réponse à la dépêche Gestion de la mémoire virtuelle du noyau 2.5.x. Évalué à 10.

    Tout à fait. C'est dans des circonstances exceptionnelles, dans lequelles on juge habituellement que la machine est inutilisable, qu'on est en train de faire des progrès.
    Et pour l'utilisateur moyen qui n'en retire pas de bénéfice direct (à part de pouvoir se vanter d'utiliser un OS allant 100 fois plus vite qu'hier, ce qui ne veut rien dire), on en retirera de bonnes choses. Je pense par exemple aux serveurs d'applications J2EE et aux BD, ces gros monstres qui utilisent énormément de threads et de mémoire... Ils tourneront probablement bien mieux. Et donc les entreprises continueront à aider les développements autour de "Linux", ce qui aura sûrement un impact positif même sur nos applis de tous les jours.
    Donc ce sont de bonnes nouvelles.
  • [^] # Re: c++ su><or

    Posté par  . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 2.

    #include <iostream>

    void toto(void *(*f)(void *))
    {
    f(0);
    }

    char *titi(char *x)
    {
    cout << "OK" << endl;
    return 0;
    }

    int main()
    {
    toto((void *(*)(void *))titi);
    }
  • [^] # Re: c++ su><or

    Posté par  . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 2.

    Tu peux toujours utiliser des pointeurs de fonctions en C++ si tu veux.
    L'avantage du C++, c'est que c'est (quasiment) un sur-ensemble du C. Il fournit (presque) tout ce que permet le C, et bien plus encore, tout en générant un code aussi optimisé, si le compilo est correct.
    Programmer les templates en C avec des macros, j'ai déjà donné. Je crois que je ne referai plus jamais ça.
  • [^] # Re: c++ su><or

    Posté par  . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 10.

    La différence est qu'en C++ tu le fais avec des conteneurs (templates), alors qu'avec la glib tu fais ça avec des pointeurs sur fonction. En pratique, le code généré en C fait des indirections à gogo, alors que dans le C++ tout peut être optimisé à fond.
  • [^] # Re: Normal

    Posté par  . En réponse à la dépêche KaZaa : industrie vs musique. Évalué à 10.

    Je ne suis pas tout à fait d'accord avec la comparaison... On condamnerait un marchand d'armes s'il vendait ses armes à des particuliers, sans respecter les lois de distribution des armes.
    Par contre, je suis plutôt d'accord sur la comparaison avec les extincteurs...
    Les outils de P2P sont un moyen de distribution de d'information très efficace. C'est l'usage qui en est fait qui n'est pas très légal.
    La grande question est de savoir si quelqu'un fait du business avec les oeuvres piratées. C'est ceux là qui devraient aller en taule.
  • [^] # Re: Comment ?

    Posté par  . En réponse à la dépêche Entrevue avec Daniel Robbins de Gentoo. Évalué à -1.

    "le nombre de périodes de temps CPU indivisibles" par seconde (normal pour des HZ)... Donc plus il y en a par seconde plus elles sont courtes. C'est chaque période qui est indivisible. Il me semblait que le nom HZ était suffisamment parlant pour me comprendre... Désolé.
  • [^] # Re: Comment ?

    Posté par  . En réponse à la dépêche Entrevue avec Daniel Robbins de Gentoo. Évalué à 0.

    Relis bien...
    Si tu prends la main plus vite, c'est qu'on te l'a donné plus vite. On dit donc la même chose. J'avoue que mon explication n'a pas été très claire. Mais elle est correcte.
  • [^] # Re: Comment ?

    Posté par  . En réponse à la dépêche Entrevue avec Daniel Robbins de Gentoo. Évalué à 10.

    C'est le nombre de périodes de temps CPU indivisibles accordées aux processus gourmands en CPU. Plus HZ est grand, plus le système est réactif car tu donnes plus vite la main à un autre processus qui a besoin du CPU.
  • # rdate

    Posté par  . En réponse au message [Terminal] Mettez-vous à l'heure. Évalué à 1.

    Sous Redhat et Mandrake, la commande netdate n'existe pas. Par contre, il y a rdate : rdate -s nom.de.serveur
  • [^] # Les translators du Hurd

    Posté par  . En réponse à la dépêche Archives auto-extractibles. Évalué à 6.

    "Je crois qu'il est peut-etre mieux de developper des systemes de fichiers virtuels ou l'on peut naviguer dans les archives."

    Le Hurd le permet déjà grâce au mécanisme des translators. N'importe quel utilisateur peut ajouter un translator en tout point du système de fichier sur lequel il a un droit d'écriture. Ce translator est un programme qui se comporte comme un système de fichiers, qui tourne avec les droits de son propriétaire. Ca permet de "monter" un répertoire ftp distant par exemple. Théoriquement, ça peux permettre aussi de parcourir des archives
    ".tar.gz" comme si elles étaient déjà décompressées.
    Ce serait super cool si Linux avait ça aussi. Je me demande si je ne travaillerai pas sur ce projet un jour...
  • # Sauvegardes par synchronisation de copies

    Posté par  . En réponse à la dépêche Sauvegardes pas chères.... Évalué à 10.

    Pour les sauvegardes, outre un système de backup dont je dispose au travail, il existe deux outils très utiles. Le très connu rsync, mais aussi unison http://www.cis.upenn.edu/~bcpierce/unison(...) . J'utilise quotidiennement unison pour synchroniser mon compte entre plusieurs machines : un PC chez moi, un portable, mon PC de bureau, et un serveur de projet. Ca me permet de travail sur n'importe quelle machine de mon choix, et de répercuter les modifs sur les autres machines. Evidemment, il faut régler à la main les conflits sur les fichiers modifiés sur les deux machines depuis la dernière synchronisation. Je ne sais pas où on est dans le domaine des systèmes de fichiers sur CD, mais si on avait un système de fichiers RW sur CDR ou CDRW, on pourrait utiliser unison et rsync très efficacement. Pour le multicd, c'est une autre histoire.
  • [^] # Re: ca va plus vite ?

    Posté par  . En réponse à la dépêche Une distribution à compiler soi-même. Évalué à 6.

    Je suis tout à fait d'accord. Il vaut mieux optimiser le facteur commun de tous les programmes de sa machine, évidemment !
  • [^] # Re: ca va plus vite ?

    Posté par  . En réponse à la dépêche Une distribution à compiler soi-même. Évalué à 10.

    Tout dépend du soft. Il faut utiliser un profiler pour voir où il passe son temps. Si c'est dans la glibc, il vaut mieux qu'elle soit optimisée. Mais en général, le temps est perdu principalement dans les E/S et dans le code de l'application, rarement dans la glibc. Donc ce n'est pas toujours crucial qu'elle soit optimisée.
  • [^] # Re: LILO avec une image

    Posté par  . En réponse à la dépêche LILO bouge encore !. Évalué à 10.

    Il faut taper sur E pour éditer les lignes de commandes de noyau, et là tu peux changer les paramètres à passer au noyau, et donc lui ajouter le paramètre "single".

    Quand tu as fini d'éditer, ESC puis B pour booter.

    Ca ne change pas les paramètres de boot de manière permanente, c'est seulement pour ce boot là.
  • [^] # Re: Rediffusion

    Posté par  . En réponse à la dépêche Emission sur Echelon a la television. Évalué à 1.

    Merci, je vais tenter l'expérience.
  • [^] # Re: Rediffusion

    Posté par  . En réponse à la dépêche Emission sur Echelon a la television. Évalué à 3.

    Je crois qu'on est nombreux à attendre ton DivX maintenant ! Au fait, quelqu'un sait-il enregistrer en haute résolution à partir d'une carte tuner TV ? Quels outils utilisés vous ? Je penche pour une solution d'enregistrement avec encodage mpeg à la volée puis recompression DivX derrière, mais je n'arrive pas à faire marcher l'encodeur de mplayer avec ma carte TV (il échange le bleu et le rouge dans l'image !).
  • [^] # Rediffusion

    Posté par  . En réponse à la dépêche Emission sur Echelon a la television. Évalué à 8.

    Le 15/01 à 4h15. C'est-à-dire cette nuit.
  • [^] # Re: Désagrément ...

    Posté par  . En réponse à la dépêche Nouveaux drivers Nvidia. Évalué à 1.

    Il prend peut-être beaucoup d'espace mémoire, mais cet espace mémoire est généralement de l'espace PCI. Par exemple, une partie de la RAM de la carte vidéo est comptée là dedans. Ainsi que l'espace utilisé par tous les registres d'accès à la carte. Ca ne veut pas dire que c'est de la RAM de la carte mère qui est consommée.
  • [^] # Re: Disponibilité des traductions

    Posté par  . En réponse à la dépêche Traduction en francais de kernel traffic #139. Évalué à 3.

    L'idée semble intéressante. Il faut trouver des gens qui puissent s'impliquer dans de tels projets.
    Mais je souhaite que cet effort de traduction complet du KT continue. Ca m'intéresse beaucoup. Il faudrait pouvoir obtenir des stats d'accès à la traduction déjà faite pour voir si l'effort en vaut la peine. Mais il faut aussi qu'avant la pub ait été faite sur tous les sites de news Linux francophones. Il faudrait peut-être aussi demander à Zack Brown de faire de la pub pour toutes les traductions qui ont été faites récemment... Les francophones directement concernés qui ne lisent pas Linuxfr verraient alors l'info.
  • [^] # Re: Disponibilité des traductions

    Posté par  . En réponse à la dépêche Traduction en francais de kernel traffic #139. Évalué à 10.

    La question est bien là : les techniciens du noyau savent déjà lire l'Anglais... Je fais partie de ceux qui touchent au noyau, et ça fait longtemps que je lis ces condensés... en Anglais. Néanmoins, si la version Française sortait aussi le lundi ou peut-être un ou deux jours plus tard, je crois que je la préfèrerais largement à la version en Anglais. C'est quand même bien plus reposant et rapide de lire du Français que de l'Anglais.
    S'il y a trop de de délai, ça ne me servira pas beaucoup.
    D'où ma question : quel peut-être le délai de traduction ? Plus il sera court, plus le public sera intéressé !

    En attendant, félicitations pour cette page, je l'ai déjà lue, mais je la relirai avec plaisir en Français.
  • [^] # Re: Sérieux !

    Posté par  . En réponse à la dépêche Bug dans KMail: mettez à jour !. Évalué à 1.

    Alors à mon avis, tu ne connais pas encore tout de l'informatique.
    Sous Unix, une grande partie des données stockées non compressées le sont souvent en formant texte, lisible par l'humain. C'est le cas de tous les fichiers de config, des pages web (ça, c'est valable partout), les entrées de /proc et aussi des répertoires de mail. Donc les nombres sont souvent écrits en décimal. Il est donc possible qu'on ait des problèmes avec des puissances de 10 et non des puissances de 2.