martinc a écrit 166 commentaires

  • [^] # Re: mozilla ?

    Posté par . En réponse à la dépêche Que réserve l'avenir aux projet KDE et Gnome ?. Évalué à 10.

    C'est surtout gnome qui utilise mozilla via le widget gtkmozembed (qui utilise gecko). C'est ce qu'utilise galeon par exemple (il y a en tout 3 classe de widget de gestion du HTML).

    Mais mozilla n'est pas une appli gnome.
  • [^] # Ca aurait du

    Posté par . En réponse à la dépêche Entrevue avec Mark Mitchell, GCC's Release Engineer. Évalué à 10.

    Selon un document interne a Intel (j'en ai fait partie), il y aurait du y avoir des contributions d'intel a GCC3 pour les itanium et les IA32 (le netburst).
    Maintenant ca date de plus d'un an, et je ne sais pas ce qu'il s'est passé depuis...
  • [^] # Re: Dans le même genre

    Posté par . En réponse à la dépêche Sortie de la Red Hat 7.3. Évalué à 1.

    Ca ils l'ont fait (et même en compilant avec un prefix /usr/bin ca marche).

    Normalement il n'y a pas de problème, car en python on utilise distutils, qui reconnait la version de python pour laquelle tu installes le paquets. Le problème c'est qu'il y a pas mal de (vieux) modules qui n'utilisent pas distutils (malgré qu'ils soient pour python2) et qui attendent un python en >2.
  • [^] # Re: non mais!

    Posté par . En réponse à la dépêche Le Québec en avance sur la France?. Évalué à 7.

    Demande leur plutôt ce qu'ils ont eu en échange de cette offre...
  • [^] # Re: se surprendre à flipper

    Posté par . En réponse à la dépêche Sortie de la Red Hat 7.3. Évalué à -2.

    Ca explique bien des choses alors ;)
  • [^] # Dans le même genre

    Posté par . En réponse à la dépêche Sortie de la Red Hat 7.3. Évalué à 9.

    Y'a /usr/bin/python qui est toujours python 1.5.2 alors que la 2.2 est stable de chez stable.

    Mais RH utilise bcp de scripts et extension python qui ne se buildent qu'avec la 1.5.2. Du coup tu peux pas mettre python2 en tant que python. Et la ca fait chier pour pas mal de scripts qui n'utilisent pas distutils (le système de package python).

    Ca va puer le gros patch pour gnome2, qui nécessite obligatoirement python2...
  • [^] # Re: Pourquoi encore un langage ? Et PyQt ?

    Posté par . En réponse à la dépêche Qt Script for Application. Évalué à 3.

    Un des avantages serait peu etre que le langage serait intégré par defaut dans le toolkit, ce qui est un avantage pour la distribution (ala tcl/tk). C'est un des gros pb de pyQt (et pyGtk): tu dois distribuer trois applis/bibliothèques: Qt, python et le wrapper.
    Au final ca peut poser bcp de pb, surtout quand tu vises le multiplateforme.
  • [^] # Bizarre

    Posté par . En réponse à la dépêche Boot Everywhere Linux. Évalué à 3.

    Sur les iso woody non officielle que j'ai téléchargé y'a quelque semaine le bf2.4 etait sur le CD3...
  • [^] # Re: Un poil HS mais dans le sujet

    Posté par . En réponse à la dépêche gphoto2 est sorti. Évalué à 5.

    Oui mais la moi je cherche un truc qui va plus loin:

    - génération de preview
    - extraction des paramètres exif
    - préférence d'affichage par photo (la rotation se faisant a l'affichage pour conserver le fichier brut)
    - Un champ de description
    - un système de recherche et d'indexage (les photos etants sur CD)
    - Un suivi des enfants de la photo brute (savoir ou sont les fichiers traités)

    Bon je sais ca existe pas. J'ai un peu regardé gtktalog, il a l'air de supporter des plugins, ca peut donc etre interessant.
  • # Un poil HS mais dans le sujet

    Posté par . En réponse à la dépêche gphoto2 est sorti. Évalué à 10.

    Y a t-il quelqu'un qui connait/utilise un système d'archivage/indexage/cataloguage de photo sous linux?
    En gros une BD de description et un système d'index des CD de sauvegarde.

    Il y a bien gtktalog, mais il a l'air plus orienté fichier que photo.
  • [^] # Re: Faire les poubelles...

    Posté par . En réponse à la dépêche Dreamworks choisit Linux. Évalué à 5.

    car comme dit précedement ils ont énormément d'outils, que porter ces outils (y'a eu un article il y a quelque temps la dessus) sous winNT demandait trop de ressource et leur aurait couté une fortune, donc le choix de linux était déja valide (mais aussi les autres unix). Ensuite le fait de ne plus etre dependant d'un vendeur et de son bon vouloir ont fait le reste.

    La grande nouvelle est surtout qu'ils sont passé sous linux sur leur stations de travail, car les renderfarms sont depuis longtemps sous linux. Ils disent bien que ca n'a été possible qu'en ayant le serveur X de HP pour attendre les améliorations de XFree coté 3D et qie le coté actif et de partage de l'opensource y est pour bcp.
  • [^] # Re: C'est bien mais c'est pas assez

    Posté par . En réponse à la dépêche Dreamworks choisit Linux. Évalué à 10.

    "And when we can," he says, "we try to feed our kernel and video changes back into the community."

    Certe ce n'est pas leurs outils proprio mais c'est déja ca. En plus ca permets de mettre plus de poids pour résoudre certains problèmes. Enfin ne vendons pas la peau de l'ours avant la charrue, on a encore rien vu.

    Ceci dit, RH semble avoir le vent en poupe auprès des compagnies américaines en ce moment...
  • [^] # Re: Parlons un peu plus...

    Posté par . En réponse à la dépêche Gentoo Linux : portail français. Évalué à 4.

    le fil du rasoir (bleeding edge): elle apporte très vite les dernières versions de soft comme <troll>XFree86 4.2.0</troll>

    Bon ceci dit, moi elle a déja planté en installant/compilant Xemacs.
  • [^] # Re: Un métier

    Posté par . En réponse à la dépêche Design de GUI. Évalué à 7.

    Arf, on y est pas encore alors, le fileselector de gtk2 mets le bouton ok a droite et le cancel sur sa gauche...
  • [^] # Re: Il n'y a pas que sous Linux...

    Posté par . En réponse à la dépêche Design de GUI. Évalué à 10.

    Dans le test gnome, ce ne sont pas des débutants, ils doivent avoir une experience des GUI. Ce qui me fait doucement rigoler c'est que bcp se sont noté 5 (cad experts) pour windows :).

    Les articles sont très orienté gnome, c'est normal de la part d'Havoc et de Sun, vu que c'est la dessus qu'ils travaillent. J'avoue que je ne m'interesse que très peu a KDE, car je ne l'utilise pas (ni gnome directement d'ailleurs).

    Ensuite quel est l'interet de faire un test avec des gens non orienté Windows? Dire que notre interface a nous c'est la meilleure du monde? eh oh faut arreter le syndrome de la plus grosse!
    On parle d'amener des utilisateurs, cad des gens qui bossent avec des ordinateurs par obligation, pas forcement par plaisir.
    Des utilisateurs qui ont des tâches a faire, le plus vite possible et sans passer 3 jours a comprendre comment le faire (ne leurs parlez même pas d'automatisation ou de macro...). Oui on peut éduquer les utilisateurs, mais pas la totalité d'entre eux.
    La plupart (totalité?) d'entre eux sont sous microsoft windows, plus rarement sur mac, et ca il ne faut jamais l'oublier. Ca n'autorise pas de faire les même erreurs que microsoft, mais oblige a etre cohérent avec un standard de facto (même si on cherche a détruire ce pseudo standard).
  • [^] # Re: Il n'y a pas que sous Linux...

    Posté par . En réponse à la dépêche Design de GUI. Évalué à 10.

    Le poids de Microsoft Windows est de toute façon inévitable. L'auteur pointe bien sur le fait de ne pas copier les interfaces, d'innover dans le domaine et surtout de ne pas commettre de fautes de conception de l'interface.

    Le test pointe beaucoup d'assomption typiquement unix (login, man par exemple) qui sont parfaitement incompréhensible par un utilisateur desktop moyen (cad ne voulant rien connaitre de l'intimité de linux).
  • [^] # Re: Il n'y a pas que sous Linux...

    Posté par . En réponse à la dépêche Design de GUI. Évalué à 10.

    Je peux aussi citer comme exemple mon père, qui utilise winXP sur son laptop, il ralait comme un putois car sous la recherche de winXP, impossible de trouver comment fixer une date de recherche précise, et ce même dans l'onglet avancé.

    Simplification ne veux pas dire simplisme!

    PS: je me suis planté dans l'URL du test gnome, j'ai pas linké le debut du test.
  • [^] # Re: Ouch!

    Posté par . En réponse à la dépêche Bricolez en USB. Évalué à 3.

    Y'a aussi FTDI http://www.ftdichip.com/ qui fait une FIFO sur port USB, l'avantage est qu'il n'y a plus de driver ni de firmware a developper, ni de pb de vendorID. Mais c'est une boite relativement jeune (en fait ce sont des pourvoyeurs d'IP), dont les produits sont peu distribués.
  • [^] # Re: ST7263

    Posté par . En réponse à la dépêche Bricolez en USB. Évalué à 5.

    gdb c'est généralement du gcc, donc du 16/32bits (y'a des exceptions), je sais j'ai écris des stubs (et patchs) pour gdb. Et c'est hachement mieux DDD que l'analyseur logique (autre missile thermonucléaire a tuer les moustiques, surtout sur un bus 32bits). Le printf c'est sur ligne série quand même, ca peux se mettre sur une RS232, donc sous minicom. Mais souvent c'est la seule méthode que l'on a, comme par exemple faire bagotter une sortie pour savoir combien de temps on passe dans une routine d'interruption, sans rajouter trop d'overhead.
  • [^] # Re: Ouch!

    Posté par . En réponse à la dépêche Bricolez en USB. Évalué à 5.

    Il me semble que les PIC sont en low-speed seulement. Il y a aussi philips qui en a un pas mal (PID11 ou un truc du genre). Mais le pb reste le support du µC sous linux. La seule entorse que j'ai fait pour le cypress, c'est de décompresser l'archive du kit (un .exe) sur un win, afin de récuperer les examples de code. Enfin le(s) EZUSB(s) il(s) ro><e(nt)
  • [^] # Re: ST7263

    Posté par . En réponse à la dépêche Bricolez en USB. Évalué à 6.

    Hélas pas vraiment le choix, a part peut etre wine ou wmware (mais ce n'est toujours pas du linux). sdcc (lien plus haut) supporte pas mal d'architectures, mais pas toute. GCC supporte surtout les 16/32 bits. Donc on fait comme on a toujours fait sous linux: on choisi en fonction de la compatibilité. Ce qui ajoute déja un problème sachant qu'on choisi a 50% les µC en fonction de leur dispo. Coté programateur, il y a ponyprog http://www.lancos.com/prog.html , je crois pas qu'il supporte le STM. Mais tu as les atmels risc ou 8051 (un bon choix le 8051) et les pics. Il tourne sous linux. Y'a aussi les 68hc(8)11 qui se programment via port série (mais ils commencent a etre sérieusement obsolètes). Le gros problème que tu vas rencontrer c'est l'absence d'outils de debug. Une fois démarré (partie en blind debug), tu peux utiliser les ports avec une led ou un oscillo, et ensuite un port série avec un embryon de printf().
  • [^] # Re: Master ou slave?

    Posté par . En réponse à la dépêche Bricolez en USB. Évalué à 10.

    L'usb est très limité de ce coté la, d'ailleurs on parle de host/peripheral et pas de master/slave. Le traffic est initié par le host seulement (aucun moyen pour un periph d'initier ou d'interrompre un host). Il existe un mode INT, qui est en fait une forme de polling. A savoir qu"il est seulement possible d'envoyer 1000 frames/s (toute les 1ms seulement). Ce qui limite très sérieusement la BP quand on travaille avec des petits paquets et en mode bulk (64 bytes par paquets). Pour utiliser toute la BP il faut passer en isochrone (cad sans controle de flux, un peu comme tcp et udp). Ensuite il ne peut y avoir qu'un seul host sur un bus (du moins la spec ne parle pas de multi host). Ce qui fait qu'il n'y a pas de periphs qui peuvent se comporter en host. Toute ces limitations ont été faite pour le coût et la simplicité de dev des periphériques. Sinon le pb d'elektor c'est qu'ils fournissent très rarement le code des microcontrolleurs. Ca limite sérieusement les possibilité de réalisation (sachant qu'assez vite ce n'est plus dispo chez eux).
  • # Ouch!

    Posté par . En réponse à la dépêche Bricolez en USB. Évalué à 10.

    C'est quand même 42€ le bitonio, qui fonctionne en low speed. Au boulot, j'ai travaillé sur un chip USB de cypress egalemenne, le EZ-USB. Bien plus performant, il dispose d'un coeur USB complet (hi-speed, cad 12Mbit/s) et d'un microcontrolleur de type 8051 et d'un nombre d'IO conséquent. Le seul pb est qu'il existe seulement en CMS, et est indisponible en france. Mais a savoir que certain adaptateurs USB<->IDE utilisent ce chip, en ayant leurs IO sur un port type IDE... Moyennant un remplacement d'eeprom (ou sa suppression), on récupère une carte de dev... J'ai fait tout le developpement sous linux, pour le microcontrolleur j'ai utilisé SDCC http://sdcc.sourceforge.net , qui bien que pas très optimisé est tout de même largement fonctionnel. Du coté USB sous linux, la libusb fait tout le boulot, en user-mode (c'est la que l'on voit l'avantage des micro-kernels). Le code du µC est chargé via l'USB, le tout etant géré par le hotplug. Il ne faut pas oublier que normalement il faut se procurer un vendorID auprès de l'usbif (1500$), ce qui interdit de fait la diffusion d'un tel montage/programme sans en avoir un officiel. Il faut quand même une petite expérience de blind debug (parent du malloc spéculatif) pour commencer le dev sur le µC...
  • [^] # Re: Compilateur?

    Posté par . En réponse à la dépêche HP: un super ordinateur sous Linux. Évalué à 6.

    Jai eu vu la roadmap des compilo ia32/ia64 d'intel, et il était/est bien prévu de contribuer au code de gcc3 afin d'y apporter des optimisation ia32/64. Maintenant ca date un peu (un an environ) et je ne garanti rien la dessus, la crise étant passée par la...
  • [^] # Re: Afficheur USB... ou i2c

    Posté par . En réponse à la dépêche Afficheur LCD sous Linux. Évalué à 2.

    Oui le SMBus et l'I2C sont en pratique compatible (y'a juste qques contraintes en plus en SMBus: frequence mini, et pullup bcp plus faible et qques points obscurs du protocole I2C). Ce bus existe depuis le chipset BX d'intel (pour les autres je sais pas).

    C'est comme ca que j'ai ajouté a ma carte mère (Abit KR7A) une sonde pour lire la temp interne du CPU (un athlon XP) via un chip spécialisé.

    Matrix-Orbital a des LCD qui peuvent se brancher sur un port I2C (mais ils sont chers, comme les modèles RS232).