M a écrit 3005 commentaires

  • [^] # Re: script

    Posté par  . En réponse au journal Requête aux devs de logiciels libres. Évalué à 1.

    1- Ouvrir le schema de l'application. Ici ça sera /etc/gconf/schemas/desktop_gnome_background.schemas
    Ce fichier n'existe pas chez moi, pourtant j'ai des applis qui utilisent gconf

    C'est clair que c'est atrocement compliqué et totalement hors de portée
    La preuve je suis bloqué au 1.

    On peut très facilement imaginer pourquoi c'est difficile à implémenter: gestion des conflits, réconciliation, état incohérents etc. Si le sujet t'intéresse, tu peux proposer un patch je pense.
    Si on veut faire un truc aussi complexe autant utilisé une base de donné de type sqlite

    Tu peux nous proposer une solution fonctionnellement équivalente et beaucoup plus simple
    Un truc plus simple :
    - des fichiers de conf classique clef valeur (comme sshd_config) par exemple.
    Ce fichier contient des commentaires et les valeurs par défaut : la doc est dans le fichier de config [tout du moins pour les fichiers globaux, pour les fichiers user c'est discutable de dupliquer la doc]
    - un démon optionnel peut vérifier si les fichiers sont modifiés (via ionotify) et signalé au appli correspondante quel doive relire le fichier de config. La notification peut se faire par signaux (les fameux SIGHUP), ou alors un mécanisme plus complexe.
    - si tu veux vraiment gérer les confits, tu peux mettre ces fichier sur un gestionnaire de revision : le fichier est pris en compte une fois que tu l'a commité. En bonus tu gagne un historique qui peut te permettre de récupérer une version qui marchait.

    PS : Question pour la route comment tu modifies les paramètres gconf de gdm ?
    PS2 : Comment tu lances un appli qui dépend de gconf dans une sandbox (limité à un process, isolé du reste du système).
  • # script

    Posté par  . En réponse au journal Requête aux devs de logiciels libres. Évalué à 1.

    Et le mieux c'est les projets qui font des scripts avec XML comme fontconfig [1].
    M'enfin l'étape au dessus c'est des trucs à la gconf, où c'est tellement complexe qu'on ne peut pas l'éditer à la main.


    [1]

    <code>
    <?xml version="1.0"?>
    <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
    <fontconfig>
    <!--
    If the font still has no generic name, add sans-serif
    -->
    <match target="pattern">
    <test qual="all" name="family" compare="not_eq">
    <string>sans-serif</string>
    </test>
    <test qual="all" name="family" compare="not_eq">
    <string>serif</string>
    </test>
    <test qual="all" name="family" compare="not_eq">
    <string>monospace</string>
    </test>
    <edit name="family" mode="append_last">
    <string>sans-serif</string>
    </edit>
    </match>
    </fontconfig>
    </code>
  • # gamma

    Posté par  . En réponse au journal Resolution independance. Évalué à 2.

    Au passage pour avoir des couleurs correctes, j'ai du configurer le gamma.

    Les valeurs correctes était dans un profile de couleur du fabriquant (icm).
    Et ben qu'elle galère pour trouver un outil qui puisse le lire. Merci iccdump de argyll

    Ensuite la configuration du gamma à l'air de varier suivant le driver xgamma, xrandr, nvidia-settings, ...
  • [^] # Re: Une question d'habitude ?

    Posté par  . En réponse au journal Resolution independance. Évalué à 3.

    À moins que tu aies des problèmes de vue, peut-être devrais-tu essayer de t'habituer à de telles résolutions ?
    Ben oui je suis un peu myope.
    Et pour avoir essayé de travailler à de forte résolution, je me suis choppé des mal de tête.
  • [^] # Re: Aucun problème pour ma part

    Posté par  . En réponse au journal Resolution independance. Évalué à 3.

    Ca ne résout pas tout par exemple firefox [1] ne scale pas les éléments en pixel. Ca peut sembler logique sauf que le développeur web n'a pas forcement pensé à ce que donnerait le rendu sur un écran à fort DPI.

    Ensuite certains terminaux (rxvt, xterm) ne s'adapte pas.
    Idem mon WM icewm a l'air de s'en foutre.

    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=512522
  • [^] # Re: Ecran plus petit

    Posté par  . En réponse au journal Resolution independance. Évalué à 1.

    C'est sur que c'est plus grand : la hauteur (y) est la même, et le 16/9 est plus large (x).
  • [^] # Re: Pas si bon écran que ça

    Posté par  . En réponse au journal Resolution independance. Évalué à 3.

    C'est pas si simple que ça : suivant les applis l'info peut être récupéré ailleurs [1]. Par exemple dans gconf pour les appli gnome... Xft.dpi est aussi utilisé.

    Ensuite le pb, c'est que pas mal de truc sont codé en pixel (page web, icone, ...)


    [1] http://scanline.ca/dpi/
  • # forum

    Posté par  . En réponse au journal Resolution independance. Évalué à 6.

    opps je voulais poster dans un forum. Tant pis.

    Cela aura le mérite de lancer le débat sur l'indépendance de la résolution qui a l'air d'arriver dans les autres OS (Windows 7 et MacOSX).
  • [^] # Re: Écoute GSM

    Posté par  . En réponse au journal Le chiffrement du GSM cassé ?. Évalué à 6.

    Dans les slides de la conf, ils dissent que le chiffrement est optionnel est choisi par la base (ie pas ton téléphone)
  • # ...

    Posté par  . En réponse au journal Le système de fichiers exFAT, dans la lignée des autres FAT, une menace pour la compatibilité des appareils mobiles avec les systèmes libres. Évalué à 4.

    L'entreprise finnoise Tuxera, qui est à l'origine du driver libre ntfs-3g, propose un driver pour exFAT... sous licence propriétaire, en raison des accords (payants) qu'elle a dû passer avec Microsoft pour pouvoir publier ce driver. Déjà que les développeurs du noyau devaient il y a quelques mois à peine trouver des contournements intelligents aux brevets portant sur FAT [3], il est difficile d'envisager que les systèmes libres puissent un jour lire des données exFAT.
    Pour info sur la LKM, il y a plus d'1 an, il y avait un patch [1] qui permettait de lire les partitions exFAT...

    [1] http://marc.info/?l=linux-kernel&w=2&r=1&s=exFAT(...)
  • [^] # Re: Gestion des flux rss

    Posté par  . En réponse au journal Chrome disponible sous linux. Évalué à 3.

    D'un autre cote google propose déjà un lecteur de rss.Je vois pas pourquoi il concurrencerait leur service.

    Idem pour un lecteur mail.
  • # orange ouvre les logiciels libres de sa livebox

    Posté par  . En réponse à la dépêche Revue de presse de l'April pour la semaine 48. Évalué à 3.

    C'est un beau foutage de gueule. Un journal https://linuxfr.org/~mat_/29095.html expose la situation.

    Et l'April met ça dans sa revue de presse sans checker un minimun la véracité de la chose...
    Ils sont pas censés défendre le logiciel libre et essayer de la faire respecter par les fournisseurs de box.

    Parce que là ça décrédibilise un max l'open source :


    - libriste : he boss, on ne peut pas mettre des morceaux de la busybox (GPL) dans notre soft proprio
    - boss : pourquoi ?
    - libriste : ben parce que c'est du code GPL
    - boss : pas de risque tout me monde s'en fou, regardes free & co
  • [^] # Re: De toutes façons...

    Posté par  . En réponse au journal Orange publie le code source de la Livebox ... ou presque. Évalué à 4.

    En général, les dev ne se font pas chier à coder un vrai système cryptographique à clé publique/privée, il se contente d'une solution simple.
    C'est étrange comme les messages ressemble à u-boot [1]...
    Or u-boot est sous GPL, il suffit de demander les sources pour en avoir l'algo utilisé.

    Sinon je connais plusieurs boites qui ont utilisés un système à clé publique/privée. Le plus gros problème étant que souvent ce code n'est pas dans l'asic donc :
    - on peut le dumper si on devient root [2]
    - il n'est pas toujours possible de mettre des protections hardware pour empêcher de le reflaser de manière soft (eeprom avec WP/NOR avec secteurs de verrouillé).
    - on peut les reflaser de manière hard.



    [1] http://www.google.fr/search?hl=fr&q=%22Using+default+env(...)
    [2] la personne du blog livebox-mini semble y être parvenu, donc elle pourrait le faire
  • # not a 0day

    Posté par  . En réponse au journal 0day sur FreeBSD !. Évalué à 4.

    Le bug serait connu depuis un certain temps : http://c-skills.blogspot.com/2009/11/always-check-return-val(...)
  • [^] # Re: Exemple d'utilisation

    Posté par  . En réponse au journal executions de commandes shell en parallele: par. Évalué à 4.

    Plus simple (et plus pourris) :


    #! /bin/sh

    LIMIT=4

    para()
    {
    while [ $(jobs | wc -l) -ge $LIMIT ]
    do
    sleep 1
    done
    echo "starting $1"
    $@ &
    return 0;
    }


    para sleep 10
    para sleep 100
    para sleep 1
    para sleep 10
    para sleep 1
    para sleep 10
    para sleep 1
    para sleep 10

    echo "end..."
    wait
  • [^] # Re: Exemple d'utilisation

    Posté par  . En réponse au journal executions de commandes shell en parallele: par. Évalué à 3.

    Oui, mais bon le resultat n'est pas le même


    echo toto
    echo titi
    echo tata

    est déterministe

    echo toto & echo titi & echo tata ne l'est pas. Le résultat peut être :

    toto
    titi
    tata

    ou bien

    tata
    titi
    toto


    [...]

    Quand a ajouter une limite à partir duquel "&" est bloquant c'est encore pire.
    On fait quoi pour les scripts qui lance une série de programmes qui ne rende jamais la main ...
  • [^] # Re: roudme

    Posté par  . En réponse au journal Changer le mode d'arrondi IEEE754 avec roundme. Évalué à 3.

    En tout cas il ne connait pas le concept de fonction macro pour eviter de dupliquer du code : toutes les fonctions dans math.c sont un copier/coller (indentation identique) à une chaine près...
  • [^] # Re: C'est le moment où on regrette de pas avoir attendu une chouille !

    Posté par  . En réponse à la dépêche Open Graphics lance la production de l'OGD1. Évalué à 1.

    L'accélération Xv est arrivée avec le drm des r600/r700 dans le kernel 2.6.31. Ça marche nickel pour lire pleins de films.
    Donc on en est au niveau du driver "open source" [1] nv. C'est formidable...

    [1] bon d'accord il est peut etre offusqué mais il marche.
  • [^] # Re: Push

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 4.

    Le navigateur ne fait pas à la fois client et serveur, il initie une connexion TCP vers le serveur sur laquelle on ouvre des flux bidirectionnels, le serveur comme le client peut donc envoyer des données.
    Donc on est obligé de maintenir une connection tcp pour chaque client. J'espère que les serveurs seront costaud pour tenir la charge.
  • [^] # Re: Un serveur qui fait du push

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 3.

    Tu veux dire faire un truc comme http://www.w3.org/Protocols/HTTP-NG/ ?
  • [^] # Re: Un serveur qui fait du push

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 5.

    J'espere que leur mecanisme de push passera les firewall, NAT & co.
  • [^] # Re: Mais wine marche !

    Posté par  . En réponse à la dépêche Faille locale dans les fonctions pipe_*_open() du noyau Linux. Évalué à 3.

    C'est faux, j'ai pris un vieux jeux win16 (il y en a plein sur les sites abandonware) et ca marche.

    Le seul pb, c'est pour les jeux dos utilisant vm86 et des jeux qui font des trucs un peu louche.

    Du coup on se demande pourquoi autant de machine n'ont pas un mmap_min_addr non null...
  • [^] # Re: Vérification à faire avec Ubuntu

    Posté par  . En réponse à la dépêche Faille locale dans les fonctions pipe_*_open() du noyau Linux. Évalué à 3.

    Les versions récentes de dosemu aussi : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505247#17
  • [^] # Re: SIP is dead ?

    Posté par  . En réponse à la dépêche Skype envisage une libération partielle du client Linux. Évalué à 2.

    C'est pas H.323 qui est/était préféré par les opérateur telco ?
  • [^] # Re: Question

    Posté par  . En réponse au journal Linux, Gentoo, et gcc dans un bateau.... Évalué à 2.

    A mon avis, GCC, parceque lorsqu'une optimisation rend le code plus lent, ce n'est guère pertinent.
    Ben le pb, c'est que gcc a tendance a inline a fond en -O3 et qui est nefaste pour les caches.