Sébastien Koechlin a écrit 849 commentaires

Si c'est du HID (Human Interface Devices), c'est normalisé et Linux doit être capable de l'utiliser. Tu as même un device associé pour communiquer.

Y'a plus qu'à se plonger dans les méandres de HID.

Voici un peu de lecture : http://www.frogmouth.net/hid-doco/linux-hid.html

Dans le principe c'est la même chose, avec quelques différences :

Les magnétoscopes sont déjà vendues dans le commerce; le problème légal ne se pose pas de ce coté.

Aujourd'hui, qu'est ce qui interdit de faire des magnétoscopes qui récupère les données du net plutot que des canaux hertziens ? Ce n'est pas un problème technique, il y a déjà un magnétoscope P2P en vente en europe je crois. Le problème c'est: La loi.

Les diffusants, radio et télévisions payent les droits sur les oeuvres qu'ils distribuent pour tous les consommateurs dans la zone de couverture. Sur internet, des millions de personnes peuvent publier sans s'acquiter des droits associés, sans controle, depuis n'importe quel pays...

Sur les écrans modernes et les cartes qui le supportent, le protocole DDC permet à l'écran d'informer l'OS de ses paramêtres, en particulier sa résolution, sa taille physique, ses fréquences maximales.

C'est supporté par XFree86 et x.org et utilisé à moins de ne pas mettre certains paramêtres pour bloquer ce mécanisme.

Sous Debian, le paquet read-edid permet de faire cette lecture à la main bien qu'il soit moins complet que l'implémentation de X

Si je regarde dans un /var/log/XFree86.0.log auquel j'ai accès, je trouve:

(II) LoadModule: "ddc"
(II) Reloading /usr/X11R6/lib/modules/libddc.a
...
(II) ATI(0): VESA BIOS detected
(II) ATI(0): VESA VBE Version 2.0
(II) ATI(0): VESA VBE Total Mem: 8128 kB
(II) ATI(0): VESA VBE OEM: ATI MACH64
...
(II) ATI(0): VESA VBE DDC supported
(II) ATI(0): VESA VBE DDC Level 2
(II) ATI(0): VESA VBE DDC transfer in appr. 2 sec.
(II) ATI(0): VESA VBE DDC read successfully
(II) ATI(0): Manufacturer: IBM  Model: 198d  Serial#: 16843009
(II) ATI(0): Year: 1998  Week: 2
(II) ATI(0): EDID Version: 1.1
(II) ATI(0): Analog Display Input,  Input Voltage Level: 0.700/0.700 V
(II) ATI(0): Sync:  Separate
(II) ATI(0): Max H-Image Size [cm]: horiz.: 28  vert.: 21
(II) ATI(0): Gamma: 2.88
(II) ATI(0): DPMS capabilities: StandBy Suspend; RGB/Color Display
(II) ATI(0): redX: 0.625 redY: 0.340   greenX: 0.310 greenY: 0.592
(II) ATI(0): blueX: 0.149 blueY: 0.062   whiteX: 0.297 whiteY: 0.319
(II) ATI(0): Supported VESA Video Modes:
(II) ATI(0): 720x400@70Hz
(II) ATI(0): 640x480@60Hz
(II) ATI(0): 640x480@72Hz
(II) ATI(0): 640x480@75Hz
(II) ATI(0): 800x600@60Hz
(II) ATI(0): 800x600@75Hz
(II) ATI(0): 1024x768@87Hz (interlaced)
(II) ATI(0): 1024x768@60Hz
(II) ATI(0): Manufacturer's mask: 0
(II) ATI(0): Supported Future Video Modes:
(II) ATI(0): #0: hsize: 640  vsize 480  refresh: 85  vid: 22833
(II) ATI(0): #1: hsize: 800  vsize 600  refresh: 85  vid: 22853
(II) ATI(0): Supported additional Video Mode:
(II) ATI(0): clock: 52.6 MHz   Image Size:  262 x 198 mm
(II) ATI(0): h_active: 960  h_sync: 972  h_sync_end 1080 h_blank_end 1260 h_border: 0
(II) ATI(0): v_active: 529  v_sync: 530  v_sync_end 540 v_blanking: 557 v_border: 0
(II) ATI(0): Monitor name: IBM G51
(II) ATI(0): Ranges: V min: 55  V max: 100 Hz, H min: 30  H max: 54 kHz, PixClock max 70 MHz
(II) ATI(0): Serial No: 66-GT344

Il y a tout un tas de paramêtres qu'il n'est plus nécessaire de mettre dans le fichier de configuration de X.

(Oui, c'est un écran qui fait l'objet d'un rappel, c'est en cours http://www.pc.ibm.com/g51recall/ )

L'organisation diffuse des disques "officiels" et estime que le nombre de téléchargement de ses sources est indicatif du téléchargement de toutes les copies non officielle.

Le pouvoir d'achat et le degré d'utilisation d'internet n'est pas homogène au sein de la population "consomateur" d'art.

Les ados sont noyés de publicités et ont un petit budget, les oeuvres qui leur sont destinés vont beaucoup être échangés sur le net et très peu vendues sur support physique. La durée de vie des oeuvres est très courte et la consommation est énorme.

Les retraités qui ont vécu la majeur partie de leur vie sans internet ont moins le réflexe ou la compétence d'aller chercher de la musique dématérialisés, ils sont attachés aux supports et ont plus les moyens de se les offrir; les ventes de support vont être sur-représentés. Ils suivent moins la mode et achète rarement un tube ou l'oeuvre d'un auteur jeune.

Ce mécanisme a donc toutes les chances d'être faussé.

Ensuite s'il y a une license globale; pendant combien de temps continuera-t'on à vendre des disques pour faire la mesure ? En moins d'une année, on aura des boitiers musicbox tout intégrés, branchés à internet, capable de rechercher, de récupérer, de stoquer et de jouer des Go de musique sans avoir besoin d'un ordinateur.

Les habitudes vont changer, plus personne ne va vouloir s'encombrer de disques a très faible densité d'information, souvent avec des protections anti-copie qui gènent l'utilisateur (protections utilisés dans les autres pays), qu'il faut aller acheter ou se faire livrer; qu'il faut ripper pour passer sur son balladeur Mp3 ou Ogg.

Et puis la musique, c'est bien, mais la représentation artistique des supports à toutes les chances de changer; les films ont fait un bon très rapide dans la part des échanges P2P, depuis peu de temps ce sont les épisodes de séries télévisées; les BD scannées n'ont pas beaucoup de succès mais existent néanmoins; les livres, les animations, les jeux...

Loliwin est un "truc" tellement connu qu'il n'est même plus la pleine de dire ce que c'est ?

Après on s'étonne que Linux soit un truc confidentiel pour adolescents boutonneux.

L'antenne ne peut plus fonctionner dans le sens qu'elle ne peut plus fournir l'énergie nécessaire pour alimenter la puce, ce n'est pas une question d'émission.

Lorsqu'elle a une forme carrée, le champs électrique dans lequel elle est plongée permet d'alimenter la puce P.

 _________
/    .    \
|    .    |
|    .  P<
|    .    |
\_________/

Lorsqu'on referme le passeport, elle est pliée, elle ne présente plus les propriétés, d'après mes souvenirs d'électromagnétisme, qui permet de récupérer une tension alternative à ses bornes

 ____
/  __].
| /   .
| >P  .
| \__ .
\____].

Je ne suis pas un spécialiste de la question, mais je pense que techniquement, il n'est pas très compliqué d'empècher la lecture d'un passeport s'il est fermé.

Les mécanismes de puce sans contact fonctionnent généralement de la manière suivante :

Une puce très basse consommation est reliée à une antenne constitué de plusieurs enroulements de fils, sérigraphié sur le support. Cette antenne permet, lorsqu'elle est dans un champ électrique alternatif, à la fois d'alimenter la puce et d'emettre (en perturbant le champ).

Ceci ne fonctionne que si l'antenne peut capter le champ électrique; donc si on bloque cette propriété, la lecture n'est plus possible.

Pour cela, il y a déjà je pense une solution non mécanique: Inclure l'antenne dans le bord du passeport.

Lorsque celui-ci est ouvert, il forme une antenne de la taille d'un passeport ouvert.

Lorsqu'il est fermé, l'antenne est pliée en deux et ne peut plus fonctionner.

Le SVIDEO n'est pas envisageable, tu n'auras pas un second écran, tu auras un tas de taches.

J'ai pratiqué le xinerama sur deux cartes vidéos (AGP & PCI). Ca fonctionne bien.
Le seul défaut que l'on peut lui trouver, c'est la lenteur du bus PCI pour la "petite" carte. Lorsqu'on déplace une fenêtre et que ce n'est pas accéléré, ça saccade clairement.

Je ne te conseille pas d'acheter une carte PCI neuve, leur rareté font qu'elles sont maintenant très chères. On en trouve pas mal sur ebay.

Il faut faire attention
- A ce qu'elle soit bien supportées par X.org
- A ce qu'elle ait la mémoire vidéo nécessaire; si tu veux faire du 1280x1024 en 32 bits ça fait 5 Mo de Ram. Il vaut mieux être large (double buffering, cache des fontes et des pixmaps)

A l'usage, je fais le travail principal sur l'écran principal, et toutes les applications plus accessoires tournent sur l'autre écran: gaim, xosview, pycoincoin...

C'est un peu plus lent, mais pour y faire de la 2D, ça ne m'a jamais posé de problèmes.

Si tu es le seul à utiliser ce clavier, tu peux remapper les touches de manière logiciel; la fonction ne correspondra plus à ce qui est écrit dessus, mais ça évite de massacrer son clavier. Au pire un petit autocollant sur les touches le temps de s'habituer (une fois que l'autocollant se décole, c'est mémorisé).

Jadis j'avais transformé le Caps-Lock en Shift et transformé les touches windows des premiers claviers 105 touches en { [ et ] } justement parce que le AltGr donne les combinaisons les plus douloureuses pour les mains.

Toi tu utilises peut-être tout en local; mais ce n'est pas le cas de tout le monde.

Avec linux, on peut installer une solide machine pour lancer tout un tas de programmes récents (OpenOffice, Mozilla, Evolution...) et brancher dessus deux douzaines de postes obsolètes en XDMCP. Ca permet à beaucoup d'associations d'installer des postes à faible coût, ça permet aux pays moins occidentaux de faire quelque chose de nos déchets informatiques dont on les abreuve généreusement pour réduire leur fracture numérique, ça permet de dépanner à distance un ami ou un client qui a un problème, ça permet de conserver son bureau et d'y accéder de partout, de travailler à distance sur son ordinateur.

Et quand tout est en local, il y a les extensions de mémoire partagée et les sockets qui évitent tout le coût des piles TCP/IP.

Le système client serveur, c'est toute la force d'Unix. Loin d'être encombrant, c'est une conception qui est toujours d'actualité. A tel point que microsoft l'a copié avec son terminal server.

Testing n'est pas une distribution complète, c'est un extrait de unstable qui est fait selon un certain nombre de règles automatiques :

http://www.debian.org/devel/testing.fr.html

Il est donc tout à fait normal que des paquets puissent être présents dans stable et dans unstable mais pas dans testing.

Au moment de la sortie de Sarge, la version de testing est passé en stable.

Depuis la sortie de Sarge, de nouvelles versions ont été mises dans unstable, aucune n'a satisfait les critères nécessaire pour être copiée dans testing, ou la mise à jour d'une librairie, pour des raisons de dépendance, à conduit à la suppression de ce paquet.

http://ftp-master.debian.org/testing/update_excuses.html indique les raisons:

# digikam (- to 0.8.0-1-1)

* Maintainer: Debian KDE Extras Team
* 18 days old (needed 10 days)
* Ignoring medium urgency setting for NEW package
* out of date on m68k: digikam (from 0.7.4-5) (but m68k isn't keeping up, so nevermind)
* digikam (source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc) is buggy! (1 > 0) http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&d(...)
* Not considered
* Depends: digikam kdelibs (not considered)
* Depends: digikam libgphoto2 (not considered)
* Depends: digikam libkexif (not considered)
* Depends: digikam libkipi (not considered)

La raison de la non inclusion dans testing est indiquée.

Si les frais de port sont impostants, il serait peut-être intéressant d'organiser une commande groupée pour les faire baisser, ou de rassembler quelques commandes et de discuter avec un magasin pour qu'il l'ajoute à son catalogue avec l'assurance d'en vendre déjà une dizaine.

Il n'y a pas de bug. Mozilla fait exactement ce qu'on lui demande de faire.

Lorsqu'on est identifié sous LinuxFR et que l'on réclame une page au serveur, il envoi dans les entêtes :


Expires: Mon, 17 Jul 1978 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache


Il est donc tout à fait normal qu'il ne garde pas la page en mémoire. Ca ne sert à rien de crier et de se plaindre que Firefox ne copie pas tous les bugs des autres navigateurs, il fait ce qu'on lui demande et c'est très bien.

En plus ton message est carrément irrespectueux. Essaye de te mettre un peu à la place d'un développeur qui bosse sur Firefox et qui lit ton message. Penses-tu, même si tu avais raison, que ça l'inciterait à passer du temps pour corriger le problème ? Il y a un bugzilla ou équivalent pour rapporter les bugs.

Bref, ton message n'a aucun intérêt en dehors de mettre en avant tes insultes gratuites et ta reconnaissance inexistante pour une minorité de développeurs bénévoles sur lesquels tu craches.

Moi j'ai un serveur X normal lancé par xdm ou autre, qui tourne sur la machine en permanence.

Lorsque je veux utiliser une autre sortie, je lance une seconde instance de X en précisant un layout différent.

Normalement, j'ai deux écrans; donc je travaille en xinerama. Seulement le second écran me sert parfois pour une autre machine, dans ce cas je veux restreindre l'affichage au premier écran. Le layout différent est déclaré pour n'utiliser que l'écran qui reste disponible, et je n'ai pas d'applications fantomes.

Le clavier virtuel à coup de laser est aussi quelque chose qui existe pour les PDA, ça permet de transporter un clavier de taille raisonnable dans un volume ridicule.

Les retours que j'en avais eu est qu'il est très désagréable de ne pas avoir de retour tactile des touches, la frappe est un peu ambigüe; ça convient pour une solution d'apoint; mais pas en utilisation quotidienne.

Un bus i²c était conçu pour faire 2 mêtres il me semble; mais en pratique on n'a aucun problème à dépasser cela. J'ai une interface série/i²c qui ne travaille pas très vite, et j'ai déjà branché des éléments à une dizaine de mètres, je n'ai jamais essayé plus (kit herakles http://www.selectronic.fr/article.asp?article_ref_entier=60.(...) ).

Il y a deux problèmes qui limitent la distance :

- La capacité de la ligne, qu'il est possible de contourner. Plusieurs montages sur le net ou dans des livres proposent des buffers i²c qui sont censé permettre des transmissions de plus de 100 mètres. Il existe même des composants spécialisés pour réaliser cette fonction.

- La vitesse de transmission, pour que les signaux des deux bouts de la ligne s'emboitent bien (ack). Avec une vitesse de 100 kbps en mode classique et 400 kbps en mode rapide, je ne pense pas que cela soit un problème à moins d'avoir une ligne qui s'approche du kilomètre. Il faudrait faire le calcul.

J'ai du mal à comprendre pourquoi est-ce qu'il y a des contraintes de résolution fixe.

- De plus en plus de portables et d'écran utilisent des résolutions spéciales, 16/9ème ou déformée.

- Beaucoup de gens qui ont essayé Xinerama ne peuvent plus s'en passer, ce qui donne des résolutions qui n'ont aucune chance d'être dans la liste.

- Sous X, depuis la nuit des temps, on peut régler la résolution au pixel pret, verticalement et horizontalement.

Quelle contrainte impose de fixer à l'utilisateur une liste de 6 résolutions pré-définie ?

Ensuite il faudra se battre pour faire rentrer dans la tête des gens que Linux ne tourne pas que sur des PC.

Les fabriquants de logiciels closed source, de drivers binaires ou de plugins ont un peu trop tendance à l'oublier.

Pour le problème du pavé numérique, ce n'est qu'une question de déclaration clavier, rien ne t'interdit de corriger cela si tu veux un point.

Quand aux caractères qui semblent mal placés, on s'y fait vite.

Moi j'aime bien ce clavier, il est joli et il fait hub USB ce qui est quand même super-pratique.

C'est surtout une question de préférence.

Personnellement, je préfère enregistrer mes données dans une base de donnée. Le SGBD tourne déjà et est déjà sauvegardé; et les manipulations sont, je trouve, bien plus pratique en SQL; on peut modifier un grand nombre de page avec une seule requête; si jamais on fait une fausse manip on peut faire un rollback; on s'interface facilement avec n'importe quel autre outil sans avoir à implémenter une gestion de fichiers; on n'a pas besoin de gérer 36 fonctions et autant de cas d'erreur (erreur sur la recherche de fichier, erreur sur l'ouverture du fichier, erreur sur la lecture du fichier, erreur à la fermeture du fichier...).

Je comprends que l'on puisse avoir des contraintes matérielle qui interdise l'usage d'une base, ou un manque de maitrise; mais il me semble que les bases de données ont été conçues justement pour manipuler les données, et qu'elles le font très bien.

Je ne vois pas le rapport entre la gallerie et le téléchargement de photos.

Il se trouve que, généralement, lorsqu'un navigateur reçoit un contenu ayant un Mime-type qu'il ne sait géré ni en interne, ni à l'aide d'un programme externe, il propose de le sauvegarder sur disque. Cela n'est en rapport qu'avec le navigateur et la configuration du serveur; le logiciel de type "gallerie de photos en php" n'est pas concerné.

Avec pratiquement tous les navigateurs, il est également possible de sauver l'image reçu, même si le navigateur l'a afficher dans la fenêtre principale.

SQL, c'est pas très cohérent, c'est un langage, j'imagine que tu parles d'un SGBD ?

Un décodeur HTML, ça ne veut pas dire grand chose, mais par contre un parser XML, surtout qu'avec les nouveaux formats de documents, ça va devenir de plus en plus utile...

Je rigole...

Un grand absent à mon avis: le traitement des chaines de caractères. Quoi qu'on fasse, dans un programme moderne, que ce soit du java, du perl, du PHP ou du C, passe beaucoup de temps a tripoter des chaines de caractères, les charsets varient, les ordinateurs et les programmes dialogues, les formats sont multiples...

De se débarasser ? Surtout pas malheureux.

Au contraire, il est en train d'être intégré partout. Il y a vigor pour vi et xmms :

http://vigor.sourceforge.net/screenshots/(...)

La vérification des clefs étrangères impliquent un coût lors des écritures (insert/update/delete), mais dans une base bien conçue, tout cela se fait par des indexes et le coût est faible.

Par contre, les avantages dépassent de loin la baisse de performance (généralement non visible si la machine est bien dimensionnée):

- Implique moins de code, et non plus de code. Les programmes ont beaucoup moins de cas à traiter puisque les contraintes imposent une certaine forme aux données et il y a moins de cas d'erreurs à traiter.
- Implique que personne ne peut mettre des anneries dans la base et perturber les programmes qui l'utilisent.
- Implique que les informations sur la structure des données sont présentent dans la base, sans qu'il soit nécessaire d'écrire du code, et sans qu'il soit nécessaire de coder les contraintes dans chaque programme qui accède à la base.

Si tu te poses la question des performances, tu devrais peut-être stoquer tes données dans des fichiers, il n'y a pas de contrainte d'intégrité et les performances sont meilleurs qu'avec un SGBD

C'est IBM qui a conçu l'IBM-PC, ce sont eux qui ont limité la RAM adressable du premier PC à 640 Ko.