Cédric Foll a écrit 158 commentaires

  • [^] # Re: Avancées technologiques du prochain Kernel

    Posté par  . En réponse à la dépêche Avancées technologiques du prochain noyau Linux. Évalué à 5.

    Tu confonds O(f(x)) et o(f(x)).

    O(f(x)) c'est «du même ordre que f(x)»
    o(f(x)) c'est «négligeable devant f(x)»

    Par exemple en +infini
    -3x^2+2x-1 = O(x^2)
    -3x^2+2x-1 = O(x^3)

    Dans un dvl limité on peut utliser les deux

    (1) exp(x) = 1 + x + o(x) (en 0)
    (2) exp(x) = 1 + x + O(x^2) (en 0)

    (1) signifie «plus un terme négligeable devant x»
    (2) signifie «plus un terme d'ordre x^2»
  • [^] # Re: Avancées technologiques du prochain Kernel

    Posté par  . En réponse à la dépêche Avancées technologiques du prochain noyau Linux. Évalué à 5.

    Petite remarque:
    O(1000000 n) = O(n)
    O(k^2 + 100 k) = O(k^2)
    On garde que le terme de plus haut degré (dans les expressions polynomiales) sinon que le terme qui «croit le plus vite».

    F(x) = O(g(x)) <=>
    Il existe K tel que F(x)<=K*g(x) pour x assez grand.

    Donc pour g(x) on vire la constante devant et tout ce qui sert à rien. On s'arrange pour que g(x) soit le plus simple possible.

    Pour être plus précis on peut utiliser un ~ (équivalance).
    On a alors (en simplifiant un peu, car on néglige le cas ou g(x) prend parfois 0)
    F(x) ~ g(x) <=> F(x)/g(x) -> 1
  • [^] # Re: Avancées technologiques du prochain Kernel

    Posté par  . En réponse à la dépêche Avancées technologiques du prochain noyau Linux. Évalué à 3.

    Par exemple un algo en O(n^2) qui met 3 secondes pour processer un tableau de 100 entiers mettra 9 secondes pour en processer 200.
    non il metra 12 secondes.
    (2*n)^2 = 4 * n^2

    Pour un algo linéaire, quand on a x fois plus de données ça prend x fois plus de temps. exemple: une addition de tableaux de x elements.
    Pour un algo quadratique (O(n^2)), quand on a x fois plus de données ça prend x^2 fois plus de temps. Exemple: un tris de listes "naif" (genre tris à bulle)
    Pour un algo exponetiel (O(exp(n)) quand on a x fois plus de données on va se tirer une balle ;-). Exemple le voyageur de commerce ou comment trouver le plus cours chemin passant par n points.
    Pour un algo en temps constant, quelque fois l'augmentation du nb de données, le temps reste le même.
    Les algo en O(n*ln n) sont les tris de listes intelligents (merge sort, quick sort, ...).
  • [^] # Re: Log du trafic réseau

    Posté par  . En réponse au journal Log du trafic réseau. Évalué à 1.

    Je valide.
    C'est un excellent logiciel.

    Il tourne en tant que serveur web et donne un tas d'info supères sympas à utliser.
  • # Re: Les distributions Linux ne sont pas prêtes pour le bureau.

    Posté par  . En réponse à la dépêche Les distributions Linux ne sont pas prêtes pour le bureau.. Évalué à 10.

    En fait je suis myen d'accord avec ça.

    Je pense que pour un utilisateur lambda tout seul chez lui, qui aime pas forcément l'info, qui sais pas ce qu'est une adresse ip, qui confond intrrnet et le web, qui a du mal à maitriser la diff entre un repertoir et un fichier (au hazard mes parents ;-)) et qui utilise juste un peu un pc pour écrire deux trois doc sous word, acheter en ligne ou écrire qq maisl avec linux il va pas s'en sortir pour l'instant même avec un mandrake.
    "Comment on fait avec le le cd wanadoo pour aller sur internet quand on a linux ?" et autre pb de ce genre.

    Par contre si il y a qq'un qui maitrise l'installe et la config il n'y a plus de pb. Il est aussi facile d'UTILISER windows que GNU/linux

    Installer des nouveaux périph, configurer une connection internet, c'est un autre pb pour un "nul en info qui de toute façon ça fait chier les ordinateurs et qui n'a pas envie de chercher à comprendre".
  • [^] # Re: Trusted Debian 1.0

    Posté par  . En réponse à la dépêche Trusted Debian 1.0. Évalué à 6.

    Ben ça va être un exploit dans le compte de l'utilisateur
    Non, il va faire ça sur un prog suid root.
    Et le type se retrouve root sur la machine.

    C'est donc en effet utile sur un serveur avec beaucoup de comptes de pouvoir eviter les buffer overflow.
  • [^] # Re: Trusted Debian 1.0

    Posté par  . En réponse à la dépêche Trusted Debian 1.0. Évalué à 10.

    Tu peux tjs essayer de lancer un nessus dessus.
    cf www.nessus.org
    La aussi tu as juste à cliquer sur le bouton ok (j'exagère à peine) et tu te retrouves avec une grosse baterie de tests et un rapport de vulnérabilités.
  • [^] # Re: Quelques liens & remarques

    Posté par  . En réponse à la dépêche Étude sur le SPAM. Évalué à 3.

    Oui mais tant que l'apprentissage n'est pas terminé et que les résultats ne sont pas satisfaisants (et c'est encore mon cas) j'ajoute juste (SPAM) dans le sujet. En aucun cas le message est viré.
    Ainsi les utlisateurs n'ont plus qu'a regler leur messagerie pour mettre dans un repertoir particulier tous les messages commençant par ce tag.
  • [^] # Re: Quelques liens & remarques

    Posté par  . En réponse à la dépêche Étude sur le SPAM. Évalué à 8.

    J'ai entrainé mon filtre sur les messages que j'avais dans ma boite.
    Ensuite j'ai fait un mails à tous les utilisateurs pour me demander de m'envoyer les erreurs (ie un non spam étiqueté spam et réciproquement).
    J'ai ensuite un prog qui automatise l'apprentissage (en gros je forward le mail à une adresse donnée qui renvoie sur bogofilter)
    J'ai aussi un e-mail qui m'est envoyé chaque nuit pour me faire qq stats sur le filtrage de bogofilter (classements du nb de spams envoyés par exépditeur et par domaine au cours des dernières 24 heures). Ceci me permet de détecter les falses positives évident assez rapidement et d'entrainer le filtre dessus.

    Pour le taux de réussite, il est calculé à partir d'un échantillon significatif ;-) (ce que je reçoit (sur mes 150 mails par jour) ainsi que ce que reçoivent les collègues qui sont dans le même bureau que moi.
  • [^] # Re: Étude sur le SPAM

    Posté par  . En réponse à la dépêche Étude sur le SPAM. Évalué à 10.

    Attetion: L'adresse source (la prétendue adresse de l'expéditeur) peut être forgée.
    Ainsi en faisant cela on peut faire du mail bombing à destination d'un inocent.

    De toute façon ce n'est jamais une bonne idée de se faire justice soit même, et de telles pratiques peuvent entrainer des poursuites. Le mil bombing c'est ilégal, ça peut faire écrouler un serveur de messagerie et pénaliser toutes les personnes utilisant ce serveur (et pas seulement que le spammeur à supposer qu'il soit géné).
  • # Quelques liens & remarques

    Posté par  . En réponse à la dépêche Étude sur le SPAM. Évalué à 10.

    Je suis admin syst et réseaux d'un domaine recevant 30 000 messages (venant de l'exterieur du domaine) par semaine. Sur ces message, plus de 3000 sont du spam (soit plus de 1/10).
    Je détecte principalement le spam grace à bogofilter (filtre baysesian qui tourne sans aucun pb sur le serveur de mail (GNU/Linux, Postfix, P4 avec 512 Mo de ram).
    Il detecte 95% des spams et on déplore 5-10 falses positives par jour.

    J'utilise aussi un gros fichier contenant une grande liste d'adresses e-mail de spammeur, de domaines de spammeurs. Cette liste contenant 180 000 entrées est mise à jour toutes les demi heures.
    cf http://basic.wirehub.nl/spamlist-usage.html(...)
    Les autres systèmes (spamhaus, filtre sur le sujet, ...) bloquent très peu de spam. (20-30 par jour).
    En fait cette liste bloque à peu pret 50%du spam et bogofilter les 50% restant.

    Une annécdote amusante sur un le "king of spam" pris à son propre jeux:
    http://www.counterpane.com/crypto-gram-0304.html#1(...)
  • # Mon exp de snort

    Posté par  . En réponse à la dépêche IDS en Open Source. Évalué à 10.

    Je suis admin d'un parc assez important (une 30 de machines en DMZ), g un serveur avec MySQL dessus, g installé acidlab sur mon poste.

    Plusieurs machines ont snort d'installés et elle envoient leur alertes sur le serveur MySQL et je visualise/efface les alertes à partir de mon poste grace à ACIDLAB.

    Cela fonctionne vraiement super bien. Le pb est par contre le grand nb d'alertes et la difficulter à correler tout ça. Ce qui fait que je regarde juste les trucs graves et passe à coté de pas mals de choses faute de temps.

    Qq'un a des experiences avec SnortSnarf, SnortCenter, SnortCon ?
  • [^] # Re: IDS en Open Source

    Posté par  . En réponse à la dépêche IDS en Open Source. Évalué à 10.

    Oui ce projet est en effet très prometteur. Qui plus est il est dvl par une équipe française.

    Je l'ai testé sur ma DMZ il marche très bien et sa spécif modulaire est très bien pensée.

    Le seul problème pour l'instant est l'absence d' outil pour visualiser les alertes aussi performant qu'acidlab. Deux projets d'interace web sont en cours de développement.
  • [^] # Re: Vos meilleures adresses sur la sécurité, contre-attaque

    Posté par  . En réponse à la dépêche Vos meilleures adresses sur la sécurité, contre-attaque. Évalué à 10.

    J'ajoute la ml crypto-gram: http://www.counterpane.com/crypto-gram.html Un e-mail le 15 de chaque mois écrite par Bruce Schneier (c'est l'auteurs de plusieurs livre sur la sécurité, l'inventeur de BlowFish et TowFish). C'est vraiment une reférence en sécu. Son mail contient un éditot sur un sujet donné, une revue de presse de la sécu. C'est assez pointut (en particulier lorsque le sujet est la crypto) mais très instrucif et éclairé. Vraiment excellent pour se tenir au courant.
  • [^] # Re: Oui, mais...

    Posté par  . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 4.

    1) Il n'y pas de destructeurs
    Ce n'est pas entierment vrai.
    # Création
    a = Object.new
    # destruction
    a = nil

    Lorsque qu'un objet est libéré grace qu GC, une méthode peut être appelé (pour fermer des sockets, des fichiers, ce genre de trucs) ceci grace à define_finalizer().

    exemple:
    include ObjectSpace

    a = "A"
    b = "B"
    c = "C"

    define_finalizer(a, proc {|id| puts "Finalizer one on #{id}" })
    define_finalizer(a, proc {|id| puts "Finalizer two on #{id}" })
    define_finalizer(b, proc {|id| puts "Finalizer three on #{id}" })

    renvoie:

    0x4018d4f0
    n finals=>1
    Finalizer three on 537684600
    0x4018d504
    n finals=>0
    Finalizer one on 537684610
    n finals=>0
    Finalizer two on 537684610

    La forme des structures de contrôle de type while... end ...
    Tout d'abord la plupart des éditeurs reconnaissent Ruby (vim, emacs, scite, ...).
    Mais l'arguement est recevable.
  • [^] # Re: Interview de Matz le créateur de Ruby

    Posté par  . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 2.

    Exactement. Et il est même possible de se passer de swing tellement il est simple d'intégrer des biblio écrite en C dans du code Ruby. C'est d'ailleur un des points forts de Ruby, la simplicité d'intégrer du C.
  • [^] # Re: Interview de Matz le créateur de Ruby

    Posté par  . En réponse à la dépêche Interview de Matz le créateur de Ruby. Évalué à 10.

    J'ai déjà dvl des projets assez importants en Ruby: -serveur TCP multithread (a noté que le support des threads en Perl n'est pas finalisé): aucun pb en termes de perfs (avec une dizaine de clients simultanées). -prog faisait des DoS/Bench en surchargent de requetes un serveur lancé via inetd (ou autre) (une cinquentaines de thread en simultanées): aucun pb coté de perfs (le serveur tombe bien avant le prog Ruby). -Attaque force brute sur login/password vers serveur http, telnet, ftp, ... (encore pleins de threads): aucun pb. -Nombreux scripts parsants des gros fichiers logs (500 Mo) avec stockages dans des list ou des hash: diff avec Perl négligeable (mais c vrai que Perl va plus vite (+ ou - 50%)). -Développement d'un perceptron multicouche pour faire de la reconnaissance de forme: inutilisable que ce soir Perl ou Ruby (mon prog Ruby tournait un we quand mon prog en C tournait en 30 minutes). Donc en général quand on utilise des langages de scripts c que le vitesse n'est pas un paramettre critique, les résultats de Perl et Ruby sont comparables dans ce genre de situations (prog système/réseaux)
  • [^] # Re: Perl en ligne de commande

    Posté par  . En réponse à la dépêche Perl en ligne de commande. Évalué à 2.

    Ruby vaut vraiment le coup !!! Son apprentissage est plus facile que celui de Python (et a fortiori à celui de Perl) Le livre de référence sur Ruby est en ligne et libre d'accès (http://www.rubycentral.com/book/). Le langage est très bien pensé, il allie la consision et l'expressivité de Perl à la construction objet de Python. En fait les avantages de Pythons sont : -un nombre plus important de librairies -plus répendu en occident que Ruby (au Japon c'est le contraire). En bref c'est le langage idéal pour faire du prototypage, de l'algorithmique, de l'admin système et réseau.
  • [^] # Re: surcharge d'opérateurs en Python

    Posté par  . En réponse à la dépêche Perl en ligne de commande. Évalué à 3.

    Oui mais on peu sucharger que certains opérateurs. Tu définis en Ruby une classe Matrice avec les méthode mul, add et puis. Il suffit de faire ensuite: Class Matrice def +(m1,m2) return m1.add(m2) end def *(m1,m2) return m1.mul(m2) end def **(m1,nb) return m1.ouis(nb) end end et ensuite m3 = m1+m2 m4 = m1*m2 m5 = m1 ** -1 En Python pour le '+' il faut définir __add__ (c pas très jolie) et pour les deux autre je ne sais pas comment faire (et si c'est possible). Et puis c'est assez peu utilisé en Python. Par exemple, pour les regexp, en Ruby, l'opérateur =~ de la class String est surchargé et on obtient ainsi la même syntaxe que Perl.
  • [^] # Re: Et aux Pythons codeurs que l'on peut faire de l'objet sans se prendre la tête.

    Posté par  . En réponse à la dépêche Perl en ligne de commande. Évalué à 2.

    Je trouve que Python est assez lourd niveau syntax car on ne peut pas surcharger les opérateurs et qu'il y a peu de syntax sugar.

    Donc à mon sens Ruby possède l'avantage de Perl en ce qui concerne la concision du code (syntax sugar + surcharge) et la cohérence de Python en ce qui concerne l'approche Objet. Ruby est même encore plus objet que Python.
  • [^] # Re: Perl en ligne de commande

    Posté par  . En réponse à la dépêche Perl en ligne de commande. Évalué à 0.

    Encore qq une translates parce qu'elles sont amusantes (les autres sont possibles aussi mais elles m'ennuient).

    perl -e 'print reverse <>' file1 file2 file3
    -> cat file1 file2 file3 | ruby -e 'puts $stdin.readlines.reverse'

    perl -nle 'print scalar reverse $_' file1 file2 file3 ....
    -> ruby -ne 'print $_.reverse' file1 file2 file3 ...

    perl -lne '$_ = lc $_; print if $_ eq reverse' /usr/dict/words
    -> ruby -ne 'print $_ if $_ == $_.reverse'
  • # Re: Perl en ligne de commande

    Posté par  . En réponse à la dépêche Perl en ligne de commande. Évalué à 10.

    perl -lane 'print $F[0] + $F[-2]'

    devient en Ruby
    ruby -ne 'puts split[0]+" "+split[-2]'

    perl -ne 'print if 15 .. 17'
    -> ruby -ne 'puts if 15..17'

    perl -ne 'print unless 10 .. 20'
    -> ruby -ne 'puts unless 15..17'

    perl -ne 'print if /^START$/ .. /^END$/'
    -> je sais pas le faire :-( (en une ligne)

    perl -ne 'print unless /^START$/ .. /^END$/'
    -> idem :-((

    perl -ne 'print if $. >= 15; exit if $. >= 17;'
    -> ruby -ne 'puts $_ if $. >= 15; exit if $. >= 17'

    etc etc ...

    C juste histoire de montrer aux Perleur que Ruby est aussi pratique. Et aux Pythons codeurs que l'on peut faire de l'objet sans se prendre la tête.
  • [^] # Re: 2 idées

    Posté par  . En réponse à la dépêche Critères de personnalité d'un code. Évalué à 10.

    L'indentation est la preuve même d'ordre que quelqu'un met dans ses idées
    Pauvres programmeurs Pythons ...

    On pourrait citer:
    -Le choix du nom des variables, des fonctions.
    -Le style de programmation (Objets, procédurale, ...) avec la coérence (un gros "main" ou pleins de petites fonctions, des objets bien propre ou un gros objet qui fait tou).
    Les algos utilisés (itératifs, impératifs, ...).
    Le choix du langage (Perl-> poète, Python -> psychorigide, lisp -> pervers, Ruby -> malin , ...). Non c n'est pas un troll ;-)
  • [^] # Re: Login n°104 - Mars 2003 est en kiosque

    Posté par  . En réponse à la dépêche Login n°104 - Mars 2003 est en kiosque. Évalué à 5.

    Là je ne suis pas d'accord.
    Linux mag reste un excellent magazine (j'ai même l'impression qu'il est de mieux en mieux).
    Pour login:, par contre je suis d'accord.
  • [^] # Re: Login n°104 - Mars 2003 est en kiosque

    Posté par  . En réponse à la dépêche Login n°104 - Mars 2003 est en kiosque. Évalué à 1.

    Il répond quoi l'ami Stalleman ?
    J'ai pas trop envie d'acheter login juste pour sa réponse en fait.