D'autant que Adobe Flash va être rendu disponible pour ARM en décembre
En répondant à un commentaire sur l'autonomie du bouzin, au début, j'ai cru que t'allais parler de comment on pourrait peut-être avoir une autonomie de 2H en utilisant flash ...
Oui effectivement, il faut faire en sorte de "sauvegarder" la pile quelque part. Mais comme Vala se base sur du C, et que ce mécanisme serait d'assez bas niveau (i.e. pas accessible depuis le C "classique"), j'ai supposé qu'il s'appuyait sur certaines fonctionnalités de gcc.
Pour moi, Vala n'est qu'une surcouche qui ne réimplémente pas des choses aussi fondamentales que ça. Peut-être que je me trompe, je ne connais pas vraiment bien le projet, mais j'aimerais bien savoir alors comment il fait.
Ha, et une petite remarque désargéable (oui, j'aime bien être désagréable) : citer Lisaac pour ça alors que pleins d'autres langages plus connus (à peu près tous les langages fonctionnels, .Net, Scala et plein d'autres) le gèrent, ça fait un peu fanboy de Lisaac .... (oui, je dois avoir l'air d'un fanboy Scala)
Je ne suis pas d'accord pour le temps de réponse : pour moi, ce qui différencie l'iPhone de tout le reste, c'est quand même sa réactivité et sa fluidité. Même si, pour le coup, ça ne vient pas de la technologie tactile, mais de l'implémentation du système.
Pour moi, un système qui laggue, même un peu, c'est insupportable.
Non, que tu _aies_, c'est du subjonctif. Sans parler des participes passés / infinitif que tu inverse presque tout le temps ... Relis toi un peu plus !
Bah, dans les framework Python que je connais (en fait, surtout Django), je vois assez peu de moyen de faire des conneries (oui, il y en aura toujours ...). Les "remèdes" décrits ici sont faits pour palier le manque de sécurité intrinsèque du langage et l'amateurisme de ses utilisateurs (OK, pas tous), ce qui n'est pas le cas (selon moi) pour Python, qui est (toujours selon moi) un bien meilleur langage que PHP et dont les utilisateurs sont plus "avertis" (parce que moins diffusé, je te l'accorde).
OK, j'ai juste détaillé parce que je ne comprenais pas complètement ta réponse.
Pour le code "crade", bah, juste la forme du code qui fait vraiment codé à la va vite, et les appels à system("dbus-send ...") qui font encore plus à la va vite (lancer un shell qui va lancer une appli qui va appeler une lib, alors qu'appeler la lib directement serait quand même plus "propre" ... et sûrement plus rapide, quand on voit le lag dans leurs démos !)
Effectivement, mais comme l'indiquait windu.2b, quel intérêt de le faire à ce niveau ? Désolé, mais techniquement tu es très vague et ça ne veut pas dire grand chose sur l'implémentation ...
En fait, je suis allé voir le code, et :
- Il faut un driver (dans le kernel) pour le chip qui gère le capteur (normal)
- Mais ils ont aussi implémenté les évènements kernel pour un périphérique d'entrée multitouch, dans le sens où le capteur est présenté sous la forme d'un périph /dev/input/event* (classique) qui envoie des évènements spéciaux correspondant à tous les points qui sont "actifs" sur la surface à ce moment.
Ensuite, il faut juste un programme qui sache prendre en compte ce genre de périphérique. Leurs démos sont des programmes en user-space qui lisent ce périphérique et qui envoient des évènements DBUS à X. (le code et le concept sont très crades, mais ils le disent bien et présentent ça sous la forme d'un "proff of concept")
Donc, ils présentent la base dans le kernel, mais niveau user-space, pour moi, ce sera implémenté dans X dans le futur. Le truc c'est qu'on pourra aussi "facilement" utiliser ce genre de périphérique en dehors de X.
On n'est pas obligé de relayer des informations fausses non plus. Bon après, c'est vrai, il fallait chercher si ça se faisait ou pas déjà sous linux en libre (j'avoue que je ne savais pas, et ce journal m'a fait croire qu'on ne pouvait pas en dehors de Nero).
Mhhh, je ne vois nulle-part de capteur de température. Qu'il y ait écrit qu'il y a un "contrôle automatique de la vitesse" ne veut pas dire qu'il y a un capteur, souvent, juste qu'il peut moduler sa vitesse. Après, c'est à la CM de lui dire (oui, certains constructeurs aiment bien s'approprier le travail qu'une autre partie du système fait).
Mais ces objets, ils sont indépendants de Motif, non ? Motif il te sert uniquement pour l'interface autour je suppose ?
Donc tu peux très bien faire ta tambouille en C++, et garder le C pour l'interface Motif.
Bon, je suis d'accord que ma réponse est un peu "dit moi ce dont tu as besoin, je t'expliquerais comment t'en passer", mais c'est ce qui me paraît le plus simple pour moi.
Je pense que le capteur de vitesse de ton ventilo est mort.
Au démarrage, le système doit appliquer une grosse tension pour le faire démarrer (normal), et doit (hypothèse) la réduire quand il voit qu'il commence à tourner (il a pris de l'élan). Sauf que là pour lui, il ne tourne jamais, et un gros coup de tension permanent ne doit pas aider à démarrer.
Ha ok, merci, maintenant ça me paraît évident, c'est vrai que les débits se font souvent en kilo/mega_bit_ par second, et les capacités en kibi/mebi_byte_.
Ce qui me fait "peur" dans cet article, c'est qu'il dit bien que quel que soit le prix auquel ils vendent Windows, l'important c'est qu'il soit partout (je résume peut-être un peu trop ...). Ce qui correspond bien à leur technique de ne jamais voir un PC avec autre chose que Windows.
Par ailleurs, ce prix me fait quand même halluciner quand on voit le prix des boîtes. Je ne trouve pas ça normal que la différence soit si énorme, mais bon, c'est la loi du "marché" ...
Bon, c'est assez étrange que ça aille mieux, mais pas encore complètement bien ...
À la vue du diagnostic plus haut et de l'interprétation de nicolasi, je vote pour un bug du driver, vu que si tu vois une différence de ton côté entre single user et "full desktop", c'est que ça ne vient probablement pas du d-link.
Après, trouver d'où ça vient exactement .... houlala.
Le truc ce serait de tester avec un noyau plus récent, voir si ça a pas déjà été corrigé (ce serait con, on aurait l'air malin avec notre discussion de 3km ...)
Ha, et puis d'avoir le modèle de ta carte, ainsi que le driver utilisé.
Ça pue! y a un bug soit dans le driver (peut-être résolu dans une version plus récente du noyau) soit dans le firmware du d-link (voir si il y a une version plus récente).
Effectivement, on se rapproche du problème ...
[^] # Re: Une autonomie annoncée de 8H en moyenne ???!?
Posté par benoar . En réponse au journal ARM sort l'artillerie lourde. Évalué à 4.
En répondant à un commentaire sur l'autonomie du bouzin, au début, j'ai cru que t'allais parler de comment on pourrait peut-être avoir une autonomie de 2H en utilisant flash ...
[^] # Re: à part moi, ...
Posté par benoar . En réponse à la dépêche Qui cherche à contrôler l'Internet ?. Évalué à 2.
[^] # Re: je suis pas convaincue
Posté par benoar . En réponse à la dépêche Sortie de Vala 0.7.6. Évalué à 5.
Pour moi, Vala n'est qu'une surcouche qui ne réimplémente pas des choses aussi fondamentales que ça. Peut-être que je me trompe, je ne connais pas vraiment bien le projet, mais j'aimerais bien savoir alors comment il fait.
Ha, et une petite remarque désargéable (oui, j'aime bien être désagréable) : citer Lisaac pour ça alors que pleins d'autres langages plus connus (à peu près tous les langages fonctionnels, .Net, Scala et plein d'autres) le gèrent, ça fait un peu fanboy de Lisaac .... (oui, je dois avoir l'air d'un fanboy Scala)
[^] # Re: je suis pas convaincue
Posté par benoar . En réponse à la dépêche Sortie de Vala 0.7.6. Évalué à 3.
[^] # Re: Temps de réponse?
Posté par benoar . En réponse au journal Tactile sans tact. Évalué à 2.
Pour moi, un système qui laggue, même un peu, c'est insupportable.
[^] # Re: Intérêt ?
Posté par benoar . En réponse au journal Tactile sans tact. Évalué à 4.
[^] # Re: /o\
Posté par benoar . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
[^] # Re: Multitouch dans le noyal ?
Posté par benoar . En réponse à la dépêche [Toulibre] Présentation sur les interfaces multi-tactiles dans le noyau le 23 septembre 2009. Évalué à 2.
Pour le code "crade", bah, juste la forme du code qui fait vraiment codé à la va vite, et les appels à system("dbus-send ...") qui font encore plus à la va vite (lancer un shell qui va lancer une appli qui va appeler une lib, alors qu'appeler la lib directement serait quand même plus "propre" ... et sûrement plus rapide, quand on voit le lag dans leurs démos !)
[^] # Re: vente directe ?
Posté par benoar . En réponse au journal Acer diminue le montant du remboursement de Windows. Évalué à 10.
[^] # Re: typo
Posté par benoar . En réponse au journal Un appel a tous les "Benjamin Bayard". Évalué à 2.
[^] # Re: capteur du ventilo mort
Posté par benoar . En réponse au message Ventilateur au comportement bizarre. Évalué à 2.
[^] # Re: capteur du ventilo mort
Posté par benoar . En réponse au message Ventilateur au comportement bizarre. Évalué à 2.
[^] # Re: Multitouch dans le noyal ?
Posté par benoar . En réponse à la dépêche [Toulibre] Présentation sur les interfaces multi-tactiles dans le noyau le 23 septembre 2009. Évalué à 2.
En fait, je suis allé voir le code, et :
- Il faut un driver (dans le kernel) pour le chip qui gère le capteur (normal)
- Mais ils ont aussi implémenté les évènements kernel pour un périphérique d'entrée multitouch, dans le sens où le capteur est présenté sous la forme d'un périph /dev/input/event* (classique) qui envoie des évènements spéciaux correspondant à tous les points qui sont "actifs" sur la surface à ce moment.
Ensuite, il faut juste un programme qui sache prendre en compte ce genre de périphérique. Leurs démos sont des programmes en user-space qui lisent ce périphérique et qui envoient des évènements DBUS à X. (le code et le concept sont très crades, mais ils le disent bien et présentent ça sous la forme d'un "proff of concept")
Donc, ils présentent la base dans le kernel, mais niveau user-space, pour moi, ce sera implémenté dans X dans le futur. Le truc c'est qu'on pourra aussi "facilement" utiliser ce genre de périphérique en dehors de X.
[^] # Re: blu ray
Posté par benoar . En réponse au journal Sortie de Nero Linux 4. Évalué à 4.
[^] # Re: Multitouch dans le noyal ?
Posté par benoar . En réponse à la dépêche [Toulibre] Présentation sur les interfaces multi-tactiles dans le noyau le 23 septembre 2009. Évalué à 2.
# /o\
Posté par benoar . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 1.
[^] # Re: capteur du ventilo mort
Posté par benoar . En réponse au message Ventilateur au comportement bizarre. Évalué à 2.
[^] # Re: Y accéder en C ?
Posté par benoar . En réponse au message Binding C++ pour Motif. Évalué à 3.
Donc tu peux très bien faire ta tambouille en C++, et garder le C pour l'interface Motif.
Bon, je suis d'accord que ma réponse est un peu "dit moi ce dont tu as besoin, je t'expliquerais comment t'en passer", mais c'est ce qui me paraît le plus simple pour moi.
[^] # Re: Infos supplémentaires de lm-sensors
Posté par benoar . En réponse au message Ventilateur au comportement bizarre. Évalué à 2.
Au démarrage, le système doit appliquer une grosse tension pour le faire démarrer (normal), et doit (hypothèse) la réduire quand il voit qu'il commence à tourner (il a pris de l'élan). Sauf que là pour lui, il ne tourne jamais, et un gros coup de tension permanent ne doit pas aider à démarrer.
[^] # Re: ta box et un NAS
Posté par benoar . En réponse au message faire un mini server web economique. Évalué à 2.
[^] # Re: kilo
Posté par benoar . En réponse à la dépêche Nouvelle version 2.6.31 du noyau Linux. Évalué à 3.
# Il est très lucide
Posté par benoar . En réponse au journal Quand Microsoft communique sur le prix de la vente liée de Windows. Évalué à 3.
Par ailleurs, ce prix me fait quand même halluciner quand on voit le prix des boîtes. Je ne trouve pas ça normal que la différence soit si énorme, mais bon, c'est la loi du "marché" ...
[^] # Re: capteur du ventilo mort
Posté par benoar . En réponse au message Ventilateur au comportement bizarre. Évalué à 2.
[^] # Re: On sais jamais...
Posté par benoar . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
À la vue du diagnostic plus haut et de l'interprétation de nicolasi, je vote pour un bug du driver, vu que si tu vois une différence de ton côté entre single user et "full desktop", c'est que ça ne vient probablement pas du d-link.
Après, trouver d'où ça vient exactement .... houlala.
Le truc ce serait de tester avec un noyau plus récent, voir si ça a pas déjà été corrigé (ce serait con, on aurait l'air malin avec notre discussion de 3km ...)
Ha, et puis d'avoir le modèle de ta carte, ainsi que le driver utilisé.
À lundi.
[^] # Re: On sais jamais...
Posté par benoar . En réponse au message Défaut d'accès réseau filaire en changeant de LAN. Évalué à 2.
Ça pue! y a un bug soit dans le driver (peut-être résolu dans une version plus récente du noyau) soit dans le firmware du d-link (voir si il y a une version plus récente).
Effectivement, on se rapproche du problème ...