gaaaaaAab a écrit 1431 commentaires

  • [^] # Re: Emacs ou vim?

    Posté par  . En réponse au message J'ai besion d'un IDE et j'en trouve pas °o°. Évalué à 3.

    Ctrl-p, Ctrl-n pour de la complétion "bête"
    l'omni complétion est encore expérimentale (:help omni) mais ça viendra un jour =)
  • [^] # Re: Rien d'autre à faire ?

    Posté par  . En réponse au journal IPOT (IP over Time), c'est possible, avec une preuve !. Évalué à 2.

    en même temps, moment nostalgie, rappelez vous, c'était il y a trois ans (Sarkozy n'était pas président à l'époque):
    http://www.pcinpact.com/actu/news/26930-Concert-de-critiques(...)
  • [^] # Re: plutôt distribué

    Posté par  . En réponse au message A la recherche du meilleur outil .... Évalué à 2.

    L'outil technique n'est qu'un élément de la gestion de conf. Ce que tu décris, ça me paraît plutôt être un problème de process. Utiliser un gestionnaire de conf centralisé est un moyen de pallier le problème que vous rencontrez, mais ça serait sûrement possible d'aboutir au même résultat avec d'autres outils.
  • # plutôt distribué

    Posté par  . En réponse au message A la recherche du meilleur outil .... Évalué à 2.

    Ce n'est pas le cas aujourd'hui, mais si j'avais du code à diffuser, ça serait via un gestionnaire de conf distribué sans hésitation.

    Sans connaissance particulière de gestionnaire de conf, je serais aussi parti sur du distribué.

    J'utilise cvs chez moi, mais vraiment pour une seule raison (je veux dire, en dehors du fait que ça marche) : c'est un outil que je connais déjà très bien.

    du coup, si tu n'es pas plus à l'aise que ça avec svn, je te conseillerais plutôt de taper sur du distribué. Quant à savoir lequel .. heu ... joker ?

    (pas d'expérience sur migration de svn vers autre chose non plus)
  • [^] # Re: Ca veut dire quoi bronsonisé ?

    Posté par  . En réponse au journal Filip Nikolic bronsonisé .... Évalué à 2.

    et bé en voilà qu'est pas prêt de se bronsonisé ... le comique de répétition
    ou alors plusieurs fois
  • # heu ?

    Posté par  . En réponse au message recupere les paramettres d"un programme associé à un alias. Évalué à 3.

    exec /usr/informix/bin/dbaccess $*
    ou pas ?
    pas sûr d'avoir compris la question non plus, mais exec $0, c'est de toute façon pas très très utile :).
  • [^] # Re: sed, c'est dien

    Posté par  . En réponse au message Afficher deux champs depuis un log. Évalué à 3.

    heu, c'est pas le contraire ?
    de ce que je vois dans tes deux lignes, la première correspond le motif "said: blabla : d'autres trucs" tandis que la seconde est "said: blabla". Or la regex de mon commentaire s'appuyait sur la présence d'une seconde occurence du caractère ":".

    C'est ce que je signalais dans mon commentaire précédent, il faut regarder tous les formats possibles après le said pour établir une regex qui matchera à tous les coups.

    Fais un:
    grep "status=bounced" /var/log/mail.log |grep -o "said.*"


    En partant des résultats de ce grep, tu pourras essayer d'établir une regex qui découpe ce motif à ta convenance, et la ré injecter dans le sed initial.
  • # sed, c'est dien

    Posté par  . En réponse au message Afficher deux champs depuis un log. Évalué à 3.

    cat + 2 grep et un sed, ça fait beaucoup pour un truc qui peur se faire avec un seul sed :)

    Un de tes problèmes ici est que ton grep -o restreint ta ligne à ce qui correspond à ton motif, et ton motif actuel exclut ce qui se trouve après > (donc ce qu'il y a après le said)


    sed -ne 's/.*to=<\([^>]*\)>.*status=bounced.*said:[^:]*:/\1/p' /var/log/mail.log


    concernant le motif commençant à "said", je m'appuie sur ton exemple car je ne connais pas le format général d'une ligne de bounced. Il faut potentiellement généraliser pour traiter les lignes qui ne serait pas du genre "said: du blablabla : le texte que tu veux"
  • [^] # Re: ma surprise

    Posté par  . En réponse au journal Caramail revit, mais était-il mort ?. Évalué à -3.

    Tu as visiblement un problème avec GMail ou Google qui se trouve au niveau de l'affect et non de la raison

    Je dirais plutôt une saine application du principe de précaution. La meilleure garantie que Google continuera à se comporter "éthiquement" (j'utilise ce mot à défaut de mieux) est de ne pas leur donner les "moyens" (idem) de ne plus le faire.
  • [^] # Re: HS : installé comment ?

    Posté par  . En réponse au message Postfix sur NAS DNS-323. Évalué à 2.

    je ne suis pas sûr que ça répondra, mais pour le dns 323 (dont je suis aussi un heureux propriétaire), une très bonne ressource : http://wiki.dns323.info/
    et aussi une debian dispo là : http://www.ohloh.net/p/debnas
    Après, si postfix n'est pas dispo, il peut se recompiler, vu que gcc, lui, l'est.
    Du coup, pour un dns 323, c'est possible de faire des compils directement sur l'architecture cible, de récupérer d'un repository ou de cross compiler (mais curieusement, ça arrive moins souvent ;)
  • [^] # Re: merci

    Posté par  . En réponse au message Ark en ligne de commande. Évalué à 3.

    avec cette option (que je ne connaissais pas, comme quoi un commentaire pas très constructif (je parle du mien hein) peut déboucher sur quelque chose ;), ça fait 13 packages de moins. Il n'en reste plus que ... 43. Encore un petit trop pour moi.
  • # merci

    Posté par  . En réponse au message Ark en ligne de commande. Évalué à 5.

    $ sudo apt-get install ark
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    The following extra packages will be installed:
    ghostscript gs-common gstreamer0.10-alsa gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-x htdig kaboom kde-icons-oxygen kdebase-runtime kdebase-runtime-bin-kde4 kdebase-runtime-data kdebase-runtime-data-common kdelibs-bin kdelibs5 kdelibs5-data khelpcenter4 libarchive1 libclucene0ldbl libdjvulibre-text libdjvulibre21 libdv4 libgraphviz4 libgs8 libilmbase6 liblqr-1-0 libmagickcore2 libmagickwand2 libopenexr6 libphonon4 libqt4-opengl libqt4-svg libsoprano4 libstreamanalyzer0 libstreams0 libvisual-0.4-0 libvisual-0.4-plugins libxcb-shape0 libxcb-shm0 libxcb-xv0 libxine1 libxine1-bin libxine1-console libxine1-ffmpeg libxine1-misc-plugins libxine1-plugins libxine1-x libxml2-utils libzip1 oxygen-icon-theme p7zip-full phonon-backend-gstreamer pmount psfontmgr soprano-daemon

    mais non merci :)

    Sinon, je vois dans les commentaires des trucs comme s'embêter à réfléchir(mention spéciale du jury), je n'ai pas à réfléchir ou plus besoin de réfléchir, je suis un peu horrifié. En l'occurrence, le mot réfléchir serait avantageusement remplacer par "se souvenir", "apprendre", "se rappeler", "penser à", ...
  • [^] # Re: Erreur de conception ?

    Posté par  . En réponse au message SELECT * FROM matable WHERE n'importeQuelChamp = 'maValeur'. Évalué à 6.

    Ca va tant que tu n'as pas trop de données, parce que faire des concaténation et des like sur des chaînes de caractères en full scan, en terme de perfs, y a du potentiel de pas glop ...
  • [^] # Re: Erreur de conception ?

    Posté par  . En réponse au message SELECT * FROM matable WHERE n'importeQuelChamp = 'maValeur'. Évalué à 4.

    cf mon commentaire précédent http://linuxfr.org/comments/1060861.html#1060861

    C'est possible d'élaborer en rajoutant le nom de la table dans le prototype de la table précédente.

    J'ai déjà vu une application résoudre ce genre de problème de cette façon, en rajoutant des tables dédiées à la recherche. Le hic, c'est qu'il faut du coup alimenter ces tables à la volée et que ça rajoute pas mal de complexité au code.
    L'avantage, c'est que ça scale mieux que devoir faire une recherche multi champs multi table dans une seule grosse requête SQL monstrueuse. Tu peux aussi découper plus finement ta recherche en indexant mot par mot dans ces tables dédiées, plutôt qu'en indexant la totalité du contenu des champs.
  • [^] # Re: A essayer...

    Posté par  . En réponse au message SELECT * FROM matable WHERE n'importeQuelChamp = 'maValeur'. Évalué à 8.

    sur le principe, c'est quand même un peu malsain de pas savoir ce que tu es en train de chercher.

    Tu peux aussi avoir une table (valeur, type, id) triée sur valeur, ou type ferait référence au type de champ, et id pointerait sur l'id de la ligne contenant ta valeur. (c'est des noms moisis, c'est juste un exemple vite torché).

    Tu chercherais valeur dans cette table et le résultat de cette recherche te permettrait immédiatement d'identifier quel(s) champ(s) de quelle(s) ligne(s) contient ta valeur.
  • [^] # Re: titre catastrophiste

    Posté par  . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 4.

    le risque serait une interdiction d'utiliser et de distribuer tout ce qui utilise un noyau

    aux Etats-unis ...
  • [^] # Re: titre catastrophiste

    Posté par  . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 2.

    Venant d'un expert comme toi qui lance des DDOS sur les réseaux sociaux juste pour soutenir ton argumentation (http://linuxfr.org/~farvardin/28636.html ), ton commentaire prend toute sa dimension ;-)
  • [^] # Re: titre catastrophiste

    Posté par  . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 2.

    arg ! bretelle
  • [^] # Re: titre catastrophiste

    Posté par  . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 3.

    Merci pour ce remontage de brettelles salutaire !

    pardon m'sieur, j'ref'rais pus !

    Veuillez ignorer mes messages précédents et remplacer par la mise au point suivante :

    Aaaaaahh ! c'est l'apocalypse ! Le Libre est en danger ! On va tous mourir !

    merci de votre attention

    --> []
  • [^] # Re: titre catastrophiste

    Posté par  . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 10.

    pour comprendre, il faut revenir aux raisons pour lesquelles SCO a porté plainte. En gros, si j'avais bien suivi à l'époque, IBM avait acheté à SCO le droit de voir les sources de l'Unix d'ATT mais avec un NDA assez sévère. Des gens d'IBM ont contribué à Linux.
    SCO affirme que les employés d'IBM qui ont contribué à Linux sont les même que ceux qui avaient accès au code d'Unix, et que donc le noyau Linux est un derivative work d'Unix.

    Rien de tel pour les *BSD (qui sont bien des unix, mais pas dans le périmètre de la plainte de SCO)

    Ne rentrons pas dans le détail de la qualité de l'argument, tout a été soigneusement démonté à l'époque. Relisez groklaw comme suggéré dans un autre commentaire. Il serait temps de laisser ce troll mourir ;)
  • [^] # Re: titre catastrophiste

    Posté par  . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 2.

    Réécrire des bouts du noyau (ou autre), c'est déjà galère
    certes. Et ? C'est impossible ?

    ou alors j'ai loupé quelque chose cette été !!!
    ouais, mais c'était pas cet été. Depuis quelques temps déjà, Debian expérimente l'intégration d'autres noyaux que Linux. Y a eu une Debian/Hurd, des Debian/BSD.
    Il me semble que c'est d'ailleurs pour ça que les packages du noyau (autrefois kernel-2.6*) ont été renommé en linux-image-2.6*.

    sinon, je l'ai peut-être mal dit dans mon commentaire, mais pour moi, le vraiment pire qui pourrait arriver serait de devoir ré écrire des bouts de noyau. Maintenant, la probabilité qu'on en arrive jusque là est vraiment très faible, et vraiment pas à court/moyen terme.
    Dans l'absolu, je prétend aussi que la fin du noyau Linux ne signe pas la fin du logiciel libre, et ça, ça me parait difficilement contestable.

    Pour finir, c'est une histoire qui va se régler entre SCO, Novell, IBM, Redhat, ... Ca prendra du temps parce que les machins légaux entre grosses boites prennent toujours du temps, mais je serais vraiment surpris que ça sorte un jour de ce périmètre.

    C'est simplement le titre du journal que je remet en cause.
  • # titre catastrophiste

    Posté par  . En réponse au journal SCO ressussite et peut menacer de nouveau le Libre.. Évalué à 4.

    mais y a pas beaucoup d'enjeu pour le "Libre".

    Le pire qui pourrait arriver, c'est que les développeurs du noyau Linux soient obligés de réécrire des bouts du noyau. C'est tout.
    Soyons ultra pessimistes, y a plus le droit d'utiliser Linux du tout, ça sera l'occasion de se pencher sérieusement sur debian/bsd !

    bref, déjà que je ne me faisais pas trop de soucis pour Linux, je m'en fais encore moins pour le "Libre".
  • [^] # Re: quelques surprise parfois

    Posté par  . En réponse au sondage La date de péremption des produits laitiers. Évalué à 3.

    et accessoirement pour qu'il soit frais quand t'aimes bien le lait frais
  • # templates

    Posté par  . En réponse au message Rapport en xhtml/html + svg. Évalué à 2.

    tu peux peut-être aussi creuser du côté des templates genre Cheetah [1] ou autres

    [1] : http://www.cheetahtemplate.org/
  • [^] # Re: fsck peut être long

    Posté par  . En réponse au message Démarrage de Linux: [ fs2ck et framebuffer ]. Évalué à 2.

    pour compléter, plus elle est grande et plus elle est remplie, plus fsck est long
    Vivement btrfs !