Pinaraf a écrit 3671 commentaires

  • [^] # Re: Diodes Toshiba \o/

    Posté par  . En réponse à la dépêche Le noyau Linux 2.6.36 est disponible. Évalué à 9.

    Gadget ou pas, j'en ai entendu parler plus d'une fois de ces diodes qui ne fonctionnent pas sous Linux, ça fait plaisir.

    Mon dieu, des utilisateurs potentiels ?!
    Plus sérieusement, tout test serait le bienvenu sur différents modèles Toshiba...
    Les fichiers pour contrôler les diodes sont dans /sys/class/leds/toshiba::illumination normalement.
  • # Confusion

    Posté par  . En réponse à la dépêche VirtualBox disponible en version 3.2.10. Évalué à 10.

    Quel dommage de dire que Virtualbox est sous GPL puis de citer des fonctionnalités qui ne sont présentes que dans la version propriétaire...
    Tout le support de l'USB ne marche que dans la version propriétaire, de même pour le support du RDP...

    http://www.virtualbox.org/wiki/Editions
  • [^] # Re: Tiens tiens

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

    Elle est dispo depuis plus longtemps qu'aujourd'hui : depuis juillet pour la première milestone...
  • [^] # Re: le basic c'est obligatoire?

    Posté par  . En réponse au journal Écriture d'une macro dans OpenOffice.org. Évalué à 2.

    Pas forcément, tu peux choisir de ne pas l'installer il me semble... (paquet python-uno sous debian)
  • [^] # Re: j'ai pas bien compris

    Posté par  . En réponse au journal Écriture d'une macro dans OpenOffice.org. Évalué à 3.

    Ce qui correspond à la transformation en image du tableau...
  • # Trop d'antennes ? Y'a une solution simple...

    Posté par  . En réponse au journal "Free Mobile : la ville de Paris sous pression pour limiter le nombre d'antennes". Évalué à 10.

    Combien a-t-on de réseaux cuivre en France ? Combien a-t-on de réseaux électriques ?
    Pourquoi a-t-on besoin de 3, maintenant 4 réseaux de téléphonie mobile ? C'est une dépense inutile pour les opérateurs, et ne peut que rendre plus compliquée la couverture de 100% de la population.
    Le réseau doit appartenir à l'état, pas aux opérateurs.
  • [^] # Re: le basic c'est obligatoire?

    Posté par  . En réponse au journal Écriture d'une macro dans OpenOffice.org. Évalué à 5.

    Je m'auto-cite : «OpenOffice.org est programmable en plusieurs langages de programmation, mais je ne me focaliserai ici que sur le StarBasic, simple et surtout ne dépendant pas d'un interpréteur externe...»
  • [^] # Re: j'ai pas bien compris

    Posté par  . En réponse au journal Écriture d'une macro dans OpenOffice.org. Évalué à 3.

    Quand tu veux faire un tableau "simple" mais avec des formules, tu vas le faire dans le tableur. Puis lorsque tu voudras insérer ce petit tableau dans ton texte, tu n'auras pas le choix : il faudra soit le transformer en image, soit insérer un objet tableur qui ne s'intègre pas au flot de texte... Cela ne te permet plus de mettre en page convenablement les tableaux, comme le reste du texte.
  • [^] # Re: Comparaison

    Posté par  . En réponse au journal Écriture d'une macro dans OpenOffice.org. Évalué à 7.

    Il faut bien délimiter la comparaison : que cherche-t-on à faire ?
    Automatiser une tâche simple, c'est-à-dire vraiment ce qu'est une macro, ou faire une vraie extension au logiciel, ce qui ressemble plus à un "plugin" ?
    Dans le cas vraiment de la macro, OpenOffice.org a une API mieux documentée, mais les outils de création de macro sont largement en dessous des outils de Microsoft Office (en tout cas de Word et d'Excel) : ils ne t'aident pas à rédiger ton code, ils ne t'aident pas à trouver à ta place les bons appels dans l'API...
    Par contre, pour réaliser une extension à OpenOffice.org, cela me semble plus simple et surtout bien moins limité. Je n'ai pas d'exemple à fournir pour l'instant, mais dans un futur journal je présenterai une extension OpenOffice.org en Java dont la réalisation sous Microsoft Office me paraît largement plus délicate.
  • [^] # Re: Trop cool... Mais quel intérêt ?

    Posté par  . En réponse au journal Comparons les performances Javascript de Firefox et Chrome. Évalué à 2.

    Et qui t'a dit que le tableur google rame à cause du JS ? Ton petit doigt ?
    Ça peut très bien être un problème au niveau du DOM, au niveau de l'affichage...
    Le JS a atteint, et ce depuis 2 ans facilement sur les navigateurs modernes, un niveau suffisant pour 99% des applications qu'on pourrait en faire. Quel est l'intérêt d'optimiser ça encore ?
  • [^] # Re: Trop cool... Mais quel intérêt ?

    Posté par  . En réponse au journal Comparons les performances Javascript de Firefox et Chrome. Évalué à 5.

    Quel est l'intérêt d'aller 2 fois plus vite sur, mettons, 5% du temps "réel" consommé par la page web ?
  • [^] # Re: Trop cool... Mais quel intérêt ?

    Posté par  . En réponse au journal Comparons les performances Javascript de Firefox et Chrome. Évalué à 4.

    Oui, on est trop bête :) On avait oublié.
    C'est pas ce que j'ai dit, c'est juste que c'est "à la mode" que depuis que Microsoft en parle finalement, avant, à part quand y'a eu le support de cairo dans mozilla, j'ai pas souvenir d'avoir entendu parler d'accélération graphique.
    Et si y'a déjà de l'accélération graphique dans Firefox sous Linux actuellement, ça veut dire qu'elle est largement défaillante vu que Konqueror ne fait aucun effort particulier là dessus et a des performances graphiques supérieures...
    (NB: Chrome est pas mieux que Firefox pour les perfs graphiques sous Linux)
  • # Trop cool... Mais quel intérêt ?

    Posté par  . En réponse au journal Comparons les performances Javascript de Firefox et Chrome. Évalué à 7.

    C'est bien mignon de voir les navigateurs se bouffer le nez sur des pouillèmes de secondes sur des benchmarks JavaScript, mais ça change quoi ?
    Ça sert à quoi ?
    Quand on voit les performances graphiques de Firefox ou Chrome, ils feraient mieux d'arrêter de se bagarrer sur le JS et de passer aux autres problèmes. Ça tombe bien, ils commencent à le faire, mais il a quand même fallu un sacre bout de temps avant qu'ils n'y pensent.
    Il y a quelques temps, j'avais pour rire testé un ou deux benchmarks de microsoft à la fois sur firefox, arora et konqueror (KHTML). Le vainqueur du benchmark fut .... konqueror, pour ses performances graphiques au dessus de celles de firefox et d'arora.
    J'espère que l'utilisation de l'OpenGL dans Firefox fera avancer les choses.
  • [^] # Re: Pire

    Posté par  . En réponse au journal Aptitude (Debian) : la grande désillusion. Évalué à 3.

    Et corrigez moi cette horreur syntaxique : j'ai oublié un r à horreur !
  • # Pire

    Posté par  . En réponse au journal Aptitude (Debian) : la grande désillusion. Évalué à 3.

    Il y a pire !
    Les daicideurs pressés devraient immédiatement supprimer cette horeur communiste de leur parc informatique, car aptitude contient, j'ai du mal à le dire tellement le choc et l'émotion me nouent le clavier, aptitude contient, disais-je, un démineur !
    Toute une symbolique hippie, une dénonciation du développement militaire de nos beaux pays, et cela passe devant nous sans que personne ne s'en offusque ou ne s'en rende compte !
  • [^] # Re: Dans la jungle des CMS, difficile de s’y retrouver...

    Posté par  . En réponse à la dépêche Sortie de Plone 4. Évalué à 4.

    Ruby On Rails n'est pas un CMS. Il faudrait plutôt parler de Typo pour comparer quelque chose en Ruby avec Plone.
    Ruby on rails est à typo ce que Zope est à Plone... Plone et Typo sont des utilisateurs des frameworks sous-jacents...
  • [^] # Re: Site du même type

    Posté par  . En réponse à la dépêche Évolutions de la rentrée sur LinuxFr.org. Évalué à 4.

    À mon avis, vu le lien sur le souriard, je dirais toolinux, mais ce n'est qu'une vague suggestion au pifomètre bien sûr...
  • [^] # Re: Fausse bonne idée

    Posté par  . En réponse à la dépêche De l'efficacité du fichier hosts.. Évalué à 9.

    En plus, j'ai un doute sur les performances, j'imagine que certains clients un peu poussifs pourraient mettre beaucoup de temps à parser le fichier, plus qu'à faire une requête DNS en tous cas.
    Je confirme que la lecture de ce fichier, à partir d'un nombre conséquent d'entrées (plus d'un million), devient proprement calamiteuse. C'est ce qui m'a fait abandonner ce système.
    De plus, rediriger vers 127.0.0.1 fait que si vous utilisez pour du développement un serveur Web, vous aurez droit à un certain nombre de "blagues" sous forme de requêtes inutiles qui apparaîtront...
    Perso, je redirige certains vrais gêneurs vers ::dead, sinon le reste est filtré par noscript + adblock... J'ai notamment la ligne suivante :

    ::dead facebook.com fbcdn.net www.facebook.com graph.facebook.com

    Mais un fichier hosts de plusieurs centaines milliers de lignes, faut pas déconner, c'est mauvais pour certaines applis (à l'époque, je ne sais plus quel client jabber c'était qui ne supportait vraiment pas ça)
  • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

    Posté par  . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 2.

  • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

    Posté par  . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 8.

    Pour l'ACPI, c'est pas que du Intel... Y'a ce point également à ne pas oublier : http://antitrust.slated.org/www.iowaconsumercase.org/011607/(...)
    "It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work", Bill Gates
    Traduction approximative :
    "Cela serait dommage que nous et nos partenaires fassions le travail et qu'au final Linux fonctionne bien sans devoir faire ce travail."
  • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

    Posté par  . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 4.

    Microsoft, avec Vista, a entièrement refait son architecture graphique.
    MacOS X ne peut pas supporter la technologie Optimus pour l'instant, idem pour Windows XP (mais bon vu son âge...)
  • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

    Posté par  . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 5.

    Tu n'as pas répondu à la question : en quoi est-ce hostile à Linux?
    Dans l'exemple de ton commentaire, je vois du matos qui évolue, du code qui est fait pour Windows pour s'adapter, et ce code pas fait pour Linux. Ce n'est pas de l'hostilité, juste personne pour payer un dév pour faire pour Linux.

    Je résume le code de la DSDT vu que c'est pas clair apparemment :
    if (OS == windows) {
    trucQuiMarche();
    } else if (OS == linux) {
    trucQuiPlanteLamentablement();
    }
    La correction, c'est d'enlever le test et de ne faire que trucQuiMarche, qu'il s'agisse de windows ou linux.
    Quand le compilateur AML de Microsoft introduit du bytecode invalide (qui plantait à une époque l'interpréteur de Linux), c'est pas hostile, c'est "l'évolution" ?
    C'est "l'évolution" qui dit qu'il faut que ce qui est simple ne doit plus l'être et que seul ce qui est compliqué mérite d'exister ?
  • [^] # Re: Remplir les besoins des utilisateurs != Hostile a Linux

    Posté par  . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 2.

    Dans mes exemples, j'ai mis l'ACPI. Si ça c'est pas de l'hostile à Linux franchement, que te faut-il de plus ? Un système où le BIOS filtre sur l'OS, un système où un bytecode les trois quarts du temps non conforme est indispensable au fonctionnement de la machine...
    Quand linux ne boote plus parce qu'on a augmenté la quantité de RAM et que la DSDT fait mal le mapping mémoire pour Linux, franchement, t'as de quoi chialer (et c'est du vécu)
  • [^] # Re: ARM.... Android .... Copains.

    Posté par  . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 6.

    Donc à côté de ça, il "suffit" que la lib OpenGL écrive dans son propre buffer, au lieu de vouloir l'écrire directement sur l'affichage, et de faire un lien entre les deux. Je me demande même si ce n'est pas possible même en étant en dehors du driver nVidia, étant donné que CUDA marche.
    "Au pire", il doit être possible de lancer un serveur X sur la carte nVidia (sauf si le driver refuse parce qu'il ne trouve aucune sortie... ce qui est probable en fait.), d'avoir un genre de VNC qui affiche le contenu du serveur X de la nVidia, sur le serveur X de l'intel.

    Hum, raté...

    Tout d'abord, en effet, le pilote nvidia ne trouve pas de sortie, et donc il refuse de lancer un serveur X.

    Sinon, pour la partie OpenGL, c'est assez complexe. OpenGL seul ne peut pas marcher, quel que soit l'OS. Il faut systématiquement un complément qui fournisse le contexte sur lequel le rendu se fera. Dans le cas de Windows, il s'agit de WGL. Dans le cas du serveur X, il s'agit de GLX.
    Pour faire fonctionner Optimus en cassant le moins de choses possible sur l'architecture de X, il faudrait détourner la libGL et être capable de créer un contexte dans le pilote nVidia qui serve à faire le rendu dans un buffer qui soit dans le framebuffer de l'IGP Intel. Ce qui bloque sérieusement actuellement, c'est la création de ce contexte il me semble.
  • [^] # Re: ...

    Posté par  . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 3.

    Au passage la platforme ion2 de nvidia en est réduite à un gpu sur bus pci-e alors que le ion était un vrai chipset (contrôleur usb, ddr)
    En effet, le contrôleur mémoire est intégré au CPU. Et comme intel force sûrement encore la vente du chipset avec le CPU, ben nVidia a décidé de se simplifier la vie et de ne faire plus qu'un GPU à l'aide d'Optimus. Je ne vois pas comment leur reprocher ça...