gpe a écrit 799 commentaires

  • [^] # Re: Un protocole commun

    Posté par  . En réponse à la dépêche Scanners : une nouvelle version de sane et un rapide tour d'horizon. Évalué à 4.

    Est-ce certain que tous les scanners fournissent une interface de si haut niveau ? Ni y en a-t-ils pas qui déportent tout le pilotage des déplacements sur la machine hôte ?
  • [^] # Re: Un protocole commun

    Posté par  . En réponse à la dépêche Scanners : une nouvelle version de sane et un rapide tour d'horizon. Évalué à 3.

    Et puis franchement, j'imagine que je suis fabriquant de scanners. Je file la doc, je file les source de mon premier pilote... et désormais je n'ai plus _jamais_ à coder un pilote. Je fais mon job de fabricant, je fais des économies, ça me fait de la pub. Et je me demande bien comment mes concurrents sont assez stupides pour ne pas avoir fait la même chose.

    ça ne marche pas comme modèle. Quand tu fabriques un matos tu es obligé de fournir un pilote et de le maintenir. Tu ne peux pas te permettre de dépendre de quelqu'un d'autre et d'attendre son bon vouloir pour que ton produit soit fonctionnel.
    Je le vois bien déjà dans le monde pro en s'adressant à des boîtes qui font du dev. On a essayé de juste fournir le matos avec les API les docs pour permettre à nos clients de développer selon leurs spécificités sur notre matos. Résultat:
    « - ah vous ne fournissez pas de pilote ?
    - euh non mais vous avez des exemples.»
    Ils essaient et peu de temps après ils appellent le support parce que ça ne fonctionne pas. Tu te tapes donc beaucoup de support pour réussir à faire fonctionner leur code. Bref au final on écrit des pilotes complets que l'on maintient et c'est bien plus simple comme cela.
    Donc penser que l'on peut fabriquer du matos sans jamais avoir à coder des pilotes me semble une utopie. Mais cela n'empêche pas de fournir les moyens pour ceux qui veulent coder leur propre version bien sur.
  • [^] # Re: Et la sauvegarde ? (et mon auto-pub ??)

    Posté par  . En réponse à la dépêche Rapide état des lieux de la photo numérique sous linux. Évalué à 3.

    C'est bien beau la sauvegarde en ligne mais vu les débits montants de l'ADSL j'ai abandonné cette idée depuis fort longtemps.
  • [^] # Re: corriger des pixels défectueux ?

    Posté par  . En réponse à la dépêche Rapide état des lieux de la photo numérique sous linux. Évalué à 0.

    sur les reflex Olympus tu as une fonction intégrée de "pixel mapping" pour gérer ce problème.
  • [^] # Re: Digikam

    Posté par  . En réponse à la dépêche Rapide état des lieux de la photo numérique sous linux. Évalué à 2.

    As-tu essayé Vuescan (http://www.hamrick.com/) ?
  • [^] # Re: Digikam

    Posté par  . En réponse à la dépêche Rapide état des lieux de la photo numérique sous linux. Évalué à 1.

    Je ne voudrais pas lancer un trol PC vs Mac mais c'est un peu limité comme argumentation. Sur un Mac tu peux aussi choisir de mettre un autre écran. Et l'avantage du Mac tient surtout à son OS, qui pour quelqu'un qui s'intéresse juste à la photo sans se passioner pour l'informatique, reste à mon avis plus abordable que Windows ou les diférrents GNU/Linux.
  • [^] # Re: Raw ?

    Posté par  . En réponse à la dépêche Rapide état des lieux de la photo numérique sous linux. Évalué à 0.

    Raw vs jpeg d'une rare inutilité ?

    Pourtant certains pro ne font que du jpeg tandis que d'autres ne font que du Raw...
    Le débat existe donc bel et bien que tu le veuilles ou non. Après libre à toi de choisir le raw s'il convient mieux à ton usage. Mais laisse la liberté d'avoir un autre choix qui corresponde mieux à leur usage qui peut-être fort différent du tien.
  • [^] # Re: Nautilus browser vs spartial

    Posté par  . En réponse à la dépêche GNOME 2.30 sort le poisson de l'eau. Évalué à 1.

    Vignette ou pas vignette je ne vois pas bien comment tu fais pour retrouver une image parmi 20000 dans un même dossier ?
  • [^] # Re: Nautilus browser vs spartial

    Posté par  . En réponse à la dépêche GNOME 2.30 sort le poisson de l'eau. Évalué à 2.

    Met un utilisateur devant un bureau gnome, demande lui d'extraire simplement une archive dans le chemin dans laquelle elle se trouve, il pourra cliquer 50 fois sur extraire, il ne se passera RIEN.

    Ben tu fais comme tous ceux que je connais: clic droit sur l'archive puis extraire ici, non?
  • [^] # Re: En parlant de poissons, c'est bientôt paques

    Posté par  . En réponse à la dépêche GNOME 2.30 sort le poisson de l'eau. Évalué à 1.

    killall gnome-panel
  • [^] # Re: Mauvais utilisateur.

    Posté par  . En réponse à la dépêche "Montage audio-vidéo libre" chez Eyrolles Accès Libre . Évalué à 2.

    Kdenlive était bien mais peut être trop simple, même pour les travaux simple ça devenait irritant de se sentir limité.

    Moi je ne suis pas un pro loin s'en faut mais j'ai eu besoin de faire un montage simple et contrairement à toi j'ai trouvé kdenlive trop compliqué. Kino correspondait mieux à ce que je cherchais mais malheureusement il ne gérait pas la HD ...
  • [^] # Re: OpenCascade nunca fue liberado

    Posté par  . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 1.

    Négatif opencascade n'est pas dans non-free pour Debian, il est dans main ...
  • [^] # Re: Réponse aux deux premiers commentaires

    Posté par  . En réponse à la dépêche Linux aux petits oignons : texte intégral gratuit en ligne. Évalué à 1.

    Parce que «tout le monde» ne comprend pas le terme «distribution». Alors que pour «tout le monde» le terme «linux» est un terme générique même si imprécis, comme mobylette ...
  • [^] # Re: Le petit monde des terminaux 2G et 3G

    Posté par  . En réponse à la dépêche OsmocomBB : Pour un GSM complètement libre !. Évalué à 1.

    Oui c'est beaucoup plus clair comme cela. Merci. ;)

    Il y a aussi des fabricants qui prennent le baseband chez un fournisseur, la radio chez un autre et colle leur propre stack par dessus.
  • [^] # Re: il force le trait...

    Posté par  . En réponse à la dépêche Projet OsmocomBB: Questions/réponses avec Harald Welte. Évalué à 1.

    Le MSM6250 est un baseband 3G et il inclu donc la 2G GSM mais je ne suis pas certain que Qualcomm ait fait des baseband 2G GSM pur. Par contre des 2G CDMA ça c'est certain.
  • [^] # Re: Le petit monde des terminaux 2G et 3G

    Posté par  . En réponse à la dépêche OsmocomBB : Pour un GSM complètement libre !. Évalué à 1.

    D'expérience, je peux vous dire qu'aucun fabricant de mobile se tapera lui-même l'intégration d'une protocole stack sur une radio si il n'a pas sa propre solution en interne.

    Pas sur de bien comprendre cette phrase. Peux-tu préciser?

    C'est au fournisseur de chipset de fournir la preuve que le baseband (radio +pile protocolaire).

    Manquerait pas la fin de la phrase ?

    Dans ma précédente boite, ils ont décidé de changer la radio. Ils ont pris plus d'un an de retard pour tout refiabiliser et tout revalider.
    Résultat: la maison mère à jeté l'éponge et ils tout arrêté. Et pourtant à la grande époque il y avait 300 personnes en Europe bossaient sur le dev et la valid.


    C'est sur qu'un changement de radio ce n'est pas anodin mais ça se fait...
  • [^] # Re: il force le trait...

    Posté par  . En réponse à la dépêche Projet OsmocomBB: Questions/réponses avec Harald Welte. Évalué à 1.

    Les baseband de Qualcomm sont des 3G et pas des GSM de base (je ne crois pas qu'il en fasse d'ailleurs, seulement des CDMA je crois). Donc oui les baseband 3G ont en général tous une MMU et ont en grande majorité deux CPU (mais pas tous) mais ce n'est absolument pas le cas des baseband GSM.
    Après je n'ai pas dit qu'il avait complètement tord mais qu'il forçait le trait. Il faut bien voir qu'un GSM ce n'est pas un PC. Un ARM7TDMI à 26MHz, 1 à 2 Mio de flash et 256 à 512 Kio de RAM suffisent pour faire un tél. GSM basique. Alors fatalement il faut faire des compromis et les OS sont bien plus léger qu'un noyau Linux. De plus sur de tels systèmes basiques le client n'installe pas d'application. Donc les besoins de protections sont moindres et sont surtout mis en place afin de détecter les problèmes (débordement de piles, fuites mémoires, etc.). Tout se complique sur les mobiles récent où l'on peut installer des applis extérieures...
  • [^] # Re: il force le trait...

    Posté par  . En réponse à la dépêche Projet OsmocomBB: Questions/réponses avec Harald Welte. Évalué à 2.

    Non sur les téléphones basiques il n'y a qu'un seul proc (je ne compte pas le DSP) qui fait tout: pile GSM et gestion de l'IHM. Un ARM7TDMI suffit largement!
  • # il force le trait...

    Posté par  . En réponse à la dépêche Projet OsmocomBB: Questions/réponses avec Harald Welte. Évalué à 1.

    [...] dans des conditions de sécurité déplorables : « Ils font souvent tourner l'ensemble du code en mode superviseur, sans aucune protection logicielle. Il n'y a pas de pages non exécutables, il n'y a pas de protection de la pile, etc. L'interface utilisateur et la pile protocolaire tournent dans un même espace d'adressage sans séparation des privilèges ».

    Il force pas mal le trait. Les protections de piles existent, il y a des protections mémoires, mais bien souvent il n'y a pas de MMU dans les chipsets, seulement des MPU.
    Après il faut bien voir que quand on parle d'un tél seulement GSM la partie applicative est quand même réduite à pas grand chose (en gros l'IHM). En gros à part quelques SMS ça ne contient pas de données sensibles. Ce n'est pas comme un smartphone qui de toute façon embarque 2 CPU (un pour l'applicatif, l'autre pour la partie telecom) et donc la problématique est différente.
  • [^] # Re: adoption ?

    Posté par  . En réponse à la dépêche OsmocomBB : Pour un GSM complètement libre !. Évalué à 1.

    Le "blindage" est déjà nécessaire et dans les 2 sens car toutes les infra ne se comportent pas exactement de la même façon et de même pour les mobiles.

    Moi ce que je me demande c'est qui va payer la certif de cette pile GSM ?
  • [^] # Re: adoption ?

    Posté par  . En réponse à la dépêche OsmocomBB : Pour un GSM complètement libre !. Évalué à 4.

    Pour pouvoir vendre un appareil GSM il doit effectivement être certifié. Mais tu as juste besoin d'une certif GCF (Global Certification Forum) pour l'Europe et PTCRB aux USA.
    Tu as besoin d'une certif opérateur uniquement pour vendre ton produit sous la marque de l'opérateur.
  • [^] # Re: adoption ?

    Posté par  . En réponse à la dépêche OsmocomBB : Pour un GSM complètement libre !. Évalué à 4.

    Non, les opérateurs ne décident pas de ce qui tournent sur le réseau. A partir du moment où t'as une SIM de l'opérateur, tu peux l'utiliser dans n'importe quoi.
  • [^] # Re: adoption ?

    Posté par  . En réponse à la dépêche OsmocomBB : Pour un GSM complètement libre !. Évalué à 2.

    4 piles GSM dans le monde ? Je pense qu'il doit en oublier.
    Les cite-t-il ?
  • [^] # Re: openwrt vs dd-wrt

    Posté par  . En réponse à la dépêche Sortie d'OpenWrt Kamikaze 8.09.2. Évalué à 1.

    oulà ça devient compliqué pour ma petite tête.
    Sur le wiki de dd-wrt je lis: «DD-WRT is a third party developed firmware released under the terms of the GPL [...]». Comment quelque chose sous GPL peut-il violer la GPL ?
  • # openwrt vs dd-wrt

    Posté par  . En réponse à la dépêche Sortie d'OpenWrt Kamikaze 8.09.2. Évalué à 3.

    Question d'un néophyte : lequel choisir ? Qu'elles sont les différences majeures, avantages/inconvénients ?