M a écrit 3002 commentaires

Oui c'est tout à fait ça.

D'ailleurs, sans plug-in additionnel, VDR ne peut pas décoder le MPEG-2, il utilise le décodeur hardware de la carte satellite.
De même il n'a pas notion de multi-client par défaut et il faut rajouter un plugin.
Le problème étant que tout les plugins VDR sont plus ou moins bien maintenu et stable.

Par exemple l'archi client/server avec vdr-streamdev est assez bugé, et le local n'a pas moyen propre de s'éteindre.

PS : y a aussi mplayer qui sait sortir sur la sortie TV de la carte satellite.

c'est que la gestion de la mémoire dans un naviguateur devient aussi complexe que dans un système d'exploitation (avec des problème de fragmentation de mémoire et donc des algo de plus en plus complexe à implementer) et que donc sans une attention portée la dessus, pas de salut.
C'est la libc qui implémente en grande partie l'allocateur mémoire, pas le kernel qui ne fournit qu'un tas (avec brk, sbrk, mmap). Au passage vu que le kernel maîtrise la mmu, même si la mémoire physique est fragmenté, il peut la faire apparaître contiguë en virtuel (au appi).

Pour ceux qui connaisse MythTV :
- est ce qu'il est capable de sortir sur une carte dvb-s FF.
- est qu'il y a moyen de gérer plusieurs clients (un en local, d'autre via le réseau).
- est ce qu'il est capable de programmer le pc pour se réveiller automatiquement (pour un enregistrement par exemple) en utilisant /proc/acpi/alarm par exemple. Ou encore d'éteindre le pc, quand il n'y a plus de client actif.
- est ce qu'il gère le diseqc et permet de voir la qualité du signal

Pour le moment j'utilise VDR et malgré certains défauts j'ai toujours pas trouvé de logiciel équivalent.

Un même "multiplex" permet de transmettre jusqu'à 6 chaînes en même temps, multiplexées sur un seul canal.
Il peut transmettre autant de chaîne que la bande passante le permet.
C'est peut etre 6 sur la TNT, mais c'est plus sur le sat.

oui un code pin est censé être nécessaire pour établir une connexion.
Sauf que des fois pour faciliter la vie de l'utilisateur, les fabriquants de téléphoner le font sauté...

Ce qui est un signe que l'architecture est pourrie: le rendu de l'aperçu devrait être fait dans un autre processus..
Pas forcement besoin d'avoir d'un autre processus :
- soit l'utilisation d'un code robuste qui gère les cas foireux (ils peuvent facilement valider leur code avec plein du fichier random)
- soit l'utilisation d'un langage de haut niveau qui gère des exceptions

Firefox se plante quand un plugin se plante ce qui n'est pas normal pour beaucoup de plugin, qui devraient être dans des processus séparés.
Je suis pas sur que ca soit toujours posible (notament pour des questions d'incrustation dans le navigateur).

Je sais pas si c'est prevu, mais un mode photocpieur serait assez pratique. Ca serait un mode ou l'on sélectionne le scanneur/l'imprimante(et éventuellement leur paramètres), puis on appuie sur un bouton ca scane et ca imprime.

C'est assez pratique pour "photocopier" des documents pour les personnes qui maîtrise pas trop l'informatique.

Il y a quand même l'option -std= de gcc
Sauf que ca ne verifie pas tout si je me souviens bien.

et également dans la glibc, il y a un certain nombre de define qui définissent ou non certaines fonctions (cf /usr/include/features.h).
Idem c'est tres vite limité.
Par exemple certaines fonctions POSIX ont des extensions linux sans garde fou (ie define a definir).

Il n'y a pas non plus de séparation ISOC/POSIX.

D'un autre coté quand on voit ce qui ce passe chez un certain microsoft c'est gère mieux :
- Ils sont pas foutu d'avoir un compilo qui s'approcherait des standards C.
- ils ont des includes pas standard qui font que des compilos comme gcc (mingw) ne peuvent pas forcement bien les parser et à cause de leur licence on ne peut pas les patcher.
- leur libc est à l'image de leur compilo.
Bref c'est que du bonheur de faire du code portable en prenant en compte windows (ca me rappel le code html pour ie).

Pour le couple gcc/glibc, ce que je regrette c'est que les gens ne se rende pas forcement compte de ce qui est standard et ce qui ne l'est pas.
Et malheureusement, je crois pas qu'il existe de moulinette qui donnerait la conformité du code (ISOC, POSIX, BSD, extension gcc, extension glibc, extension linux, ...).

oui mais il donne sur x86 des binnaires plus lent que les precedentes version de gcc...

et pour des chiffres regardes http://sourceforge.net/forum/forum.php?thread_id=1830216&(...)


Times for decoding a 1440x1080 Dirac stream (with inter) of 3880 frames:

- CPU only implementation: 2671126.326 ms = about 1.5fps
- GPU accelerated implementation: 188548.063 ms = about 21fps

These timings were done by gstreamer on this machine:
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
GPU: Geforce 8800GTX

Faut-il encore que ton gpu supporte le dirac (ou soit programmable pour le faire). Et ton P3-450 doit avoir une vielle carte graphique ?

Et puis Schrödinger a déja du code "cuda" pour tourner sur les gpu nvidia (avec le pilote proprio je suppose).

Ben essayes la bibliothèque Schrödinger qui est censé être plus optimisée.

Mais bon ça n'empêche pas que ce type de codec (dirac ou snow) sont très gourmand. C'est utile pour de l'archivage sans perdre trop de qualité, pour du realtime ca devient plus chaud.

Pour JPEG-2000, les brevets pesant dessus n'ont pas aidé...

Ca aurait été sympa de faire un petit topo sur jnode et sur ce que ça apporte et ce qu'ils comptent en faire.

Sinon j'ai essayé le live cd dans qemu, mais ca plante.
Ils ont pas prévu une version user-mode qui ce lance dans une jvm java classique ? Ca pourrait sympa pour testé (et même pour faire du dev hors driver).

Au passage ca pourrait etre marrant de le faire tourner dans jpc [1] : faire tourner un OS java pour x86 dans un simulateur x86 en java :)

[1] (http://www-jpc.physics.ox.ac.uk/index.html)

Le monde du logiciel libre se préoccupe surtout de la compatibilité au niveau source (API) et pas au niveau binaire (ABI). Seuls les grands groupes voulant distribuer des binaires sans le code source correspondant ont un intérêt crucial en l'existence d'une norme de compatibilité telle que LSB.

He ben linux n'est pas prêt de devenir grand publique alors :


james veux essayer le nouveau jeu libre qui viens de sortir. Pas de chance, pour le faire marcher sur sa distro il faut le recompiler. Apres quelques heures a se battre pour faire compiler le bousin, il redémarre sous windows et fait marché la version windows du jeu en quelques minutes



delopman a fait une petite appli sympa (un jeux a la con ou un petit utilitaire) et voudrait la partager avec tout le monde. Il a soit le choix de fournir que les sources, mais c'est pas tres convivial. Il peut aussi faire un paquet pour chaque distro, mais c'est pas cool pour lui.


[...]

Pourquoi ne pas virer tar pour garder que cpio.
Au passage le format tar est defini dans posix, sa serait bete de le jeter...

Une autre parade c'est de garder les données sensible le moins de temps possible en RAM.

On peut aussi imaginer une fonction de verouillage du pc qui stocke la RAM dans un swap crypté et l'efface(en fait c'est un suspend to disk) qui est fait avant de quitter le PC ou au bout d'un timeout.

Comme la RAM n'est pas initialisée au boot,
Tu oublis le bios qui remet la RAM à 0...

C'est d'ailleurs ce qui empeche de recupérer des données d'un kernel panic. Par contre la RAM video n'est pas remise à 0.

Il y a de la doc qui explique toute l'infrastructure du noyau ?
Oui il y a un make pdfdocs; plein de bouquins qui explique l'API de linux (http://lwn.net/Kernel/LDD3/ par exemple), son archi, ...; des articles dans les magazines spécialisé.

Je dis pas que la doc ne sert a rien, mais pour pouvoir en ecrire il faut du monde
Pas forcement, ca fait aussi parti des méthodes de dev : je rajoute une nouvelle interface, je mets des commentaires doxygen, ou je la décrits dans un README.

que ca ce reduit a une trentaine de personnes
Ben c'est sur que quand le projet detenu par peu de personne ca n'encourage pas à la doc (vu qu'ils connaissent tous tres bien le code), par contre à grande echelle ca ne passe pas.

Je pense pas que developer un driver soit si complique que ca, il suffit juste d'etre assez interesse pour devenir passione.
Tu te basses sur quoi pour dire ça ? ta boule de cristal ?
T'as au moins essayer de regarder un peu comment fonctionne la chose ?

PS : je connais pas gnome, mais je suis presque sur que l'API des différents bibliothèques importante sont documenté.

C'est d'autant plus compliqué qu'il y a peu de doc expliquant toute l'infrastructure

c'est fou, il y a aussi un emulateur en java qui permet de faire tourner Linux dans son navigateur : http://www-jpc.physics.ox.ac.uk/index.html

Ho mais tu triches, ton code générer par llvm n'est pas exécuter nativement comme pour gcc, mais dans une VM qui fait des optimisations JIT.

Et je pari que comme par hasard, le code est friand d'optimisation JIT...

Je suppose que LLVM s'est fait un mode GCC dans lequel l'assembleur cible est le bytecode LLVM. Bien évidemment, il profite des optims du processus de compilation de GCC.
Ha, dans ce cas ça fait un truc quand même assez tordu :
- gcc converti le langage dans sa representation interne.
- Il fait des optimisation dessus (générique et propre à la cible). Dans notre cas c'est quoi la cible LLVM ou l'archi finale ?
- Ensuite cette representation serait converti en bytecode LLVM.
- Ce bytecode serait ensuite retransformé par LLVM.
- Puis on générerait enfin le code assembleur.

Et comment il vont faire avec clang ?

hé bien justement il n'y a pas d'équivalent:
llvm-gcc 4.2 ...

Oui mais à terme ils comptent abandonner gcc ? Non ?