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).
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, ...).
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.
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 :)
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.
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.
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é.
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.
Bravo pour cet article très complet sur l'évolution du driver nouveau.
J'y ai participé occasionnellement et ce que je regrette c'est que l'on ai pas eu un support de la 3D très basique avec dri.
Pas un truc de la mort qui utilise toutes les fonctionnalité du hardware, mais un truc tout pourri qui soit un peu l'équivalent du support des cartes intel i810. [1] Si je veux un support 3D performant, je peux installer les drivers proprio qui marche pas trop mal.
Sur certaines cartes pour avoir un support correct de la gestion de plusieurs FIFO il a fallu presque 1 an.
La gestion de plusieurs FIFO est surtout intéressant pour la 3D (X en utilise une, le drm une autre (mais pour le moment je crois quel ne sert pas à grand chose)).
Le reverse engineering des commandes 3D, pour les cartes assez ancienne, est assez complet depuis quelque temps (même s'il reste surement certains pb qui seront découvert lors de leur utilisation). La gestion des textures à été enrichie lors de l'implémentation des versions accélérées d'EXA.
Une première implémentation mesa/dri [2] est assez ancienne (c'est celle ci qui a servit par exemple au LCA 2007 il y a 1 an). Sur les NV10, glxgears marchotte depuis presque 6 mois.
Tout ceci aurait pu laisser supposer un support basique de la 3D assez vite, mais gallium 3D est apparu.
Or pour les possesseurs de vielle carte (j'ai une NV17), on peut espérer maintenant un support 3D qu'à très long terme : il faut attendre que gallium 3D se stabilise, que la couche de support des cartes anciennes soit rajouté.
Or à ce moment là je crois que je n'utiliserais plus cette carte : elle sera soit morte (le ventillo à déjà cramé), soit je l'aurais remplacé par une autre carte (par exemple les nouvelles ATI avec pilote libre).
Je souhaite longue vie au projet nouveau et j'espère qu'il ne se terminera pas comme nvtv (appli pour faire marcher la sortie tv sous Linux) ou rivatv (driver pour faire marcher les tuner tv sous Linux) qui sont tous les 2 morts.
[1] qui permet tout de même de jouer à neverball, tuxracer, xmoto.
[2] au passage dri est très mal documenté...
A la lecture de la news, j'ai quelques point que je ne comprend pas.
J'avais cru comprendre que LLVM transformait un code intermédiaire en assembleur.
Un frontend (gcc, clang) se chargeant de convertir le langage source utilisé dans ce langage intermédiaire.
Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
On nous parle pas du tout de bibliothèque rattaché au langage.
Par exemple quelle libc llvm-gcc/clang supporte ?
Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?
PS :
Un inconvénient à LLVM est qu'il n'est pas bootstrapable facilement, c'est à dire qu'il aura toujours besoin que le système de destination ai déjà un compilo c++.
[1] Le frontal utilisé passe de GCC 4.0 à GCC 4.2 afin d'améliorer les performances.
Ben si c'est ce que fait RT-linux & co.
L'intérêt c'est que l'OS RT fait tout ce qui est critique (stack GSM, ...) et on délégue au Linux ce qu'il l'est moins (multimedia, GUI, réseau, ...) et que l'OS RT ne gére pas d'origine.
# Phocopieur
Posté par M . En réponse à la dépêche GNOME Scan 0.6 : vulgariser la numérisation. Évalué à 2.
C'est assez pratique pour "photocopier" des documents pour les personnes qui maîtrise pas trop l'informatique.
[^] # Re: gcc lave plus blanc ?
Posté par M . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 2.
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.
[^] # Re: gcc lave plus blanc ?
Posté par M . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 5.
- 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, ...).
[^] # Re: Surtout...
Posté par M . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 3.
[^] # Re: Qualité ?
Posté par M . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 6.
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
[^] # Re: CPU/GPU nécessaire?
Posté par M . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 5.
Et puis Schrödinger a déja du code "cuda" pour tourner sur les gpu nvidia (avec le pilote proprio je suppose).
[^] # Re: Qualité ?
Posté par M . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 5.
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.
[^] # Re: Question bête (comme d'hab' quoi)
Posté par M . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 10.
# ...
Posté par M . En réponse à la dépêche JNode version 0.2.6. Évalué à 3.
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)
# Compat binaire
Posté par M . En réponse à la dépêche Linux Standard Base 3.2. Évalué à 5.
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.
[...]
[^] # Re: La liste des critiques est incomplete
Posté par M . En réponse à la dépêche Linux Standard Base 3.2. Évalué à 4.
Au passage le format tar est defini dans posix, sa serait bete de le jeter...
[^] # Re: Parade
Posté par M . En réponse au journal Comment voler facilement des données chiffrées. Évalué à 3.
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.
[^] # Re: l'interret ?
Posté par M . En réponse au journal Comment voler facilement des données chiffrées. Évalué à 2.
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.
[^] # Re: Fichtre, ça va vite
Posté par M . En réponse au journal AMD libère un guide programmation 3D des R5xx. Évalué à 4.
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é.
[^] # Re: Fichtre, ça va vite
Posté par M . En réponse au journal AMD libère un guide programmation 3D des R5xx. Évalué à 1.
# virtualisation
Posté par M . En réponse au journal JNode l'OS en Java. Évalué à 4.
[^] # Re: Performances ?
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 3.
Et je pari que comme par hasard, le code est friand d'optimisation JIT...
[^] # Re: questions
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
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 ?
[^] # Re: questions
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
llvm-gcc 4.2 ...
Oui mais à terme ils comptent abandonner gcc ? Non ?
[^] # Re: Performances ?
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 3.
Ben propose tes patchs a gcc.
Sur cible ARM, gcc se prend une grande claque par rapport à RVCT .
Qui est le compilo de ARM et qui ne gère que ARM.
De plus le passage gcc3.x à gcc 4.x à quand même améliorer les choses en taille et vitesse.
PS : pour llvm, regarde le README arm pour juger l'état
# bravo ... mais regret
Posté par M . En réponse à la dépêche Un point sur le projet Nouveau. Évalué à 6.
J'y ai participé occasionnellement et ce que je regrette c'est que l'on ai pas eu un support de la 3D très basique avec dri.
Pas un truc de la mort qui utilise toutes les fonctionnalité du hardware, mais un truc tout pourri qui soit un peu l'équivalent du support des cartes intel i810. [1] Si je veux un support 3D performant, je peux installer les drivers proprio qui marche pas trop mal.
Sur certaines cartes pour avoir un support correct de la gestion de plusieurs FIFO il a fallu presque 1 an.
La gestion de plusieurs FIFO est surtout intéressant pour la 3D (X en utilise une, le drm une autre (mais pour le moment je crois quel ne sert pas à grand chose)).
Le reverse engineering des commandes 3D, pour les cartes assez ancienne, est assez complet depuis quelque temps (même s'il reste surement certains pb qui seront découvert lors de leur utilisation). La gestion des textures à été enrichie lors de l'implémentation des versions accélérées d'EXA.
Une première implémentation mesa/dri [2] est assez ancienne (c'est celle ci qui a servit par exemple au LCA 2007 il y a 1 an). Sur les NV10, glxgears marchotte depuis presque 6 mois.
Tout ceci aurait pu laisser supposer un support basique de la 3D assez vite, mais gallium 3D est apparu.
Or pour les possesseurs de vielle carte (j'ai une NV17), on peut espérer maintenant un support 3D qu'à très long terme : il faut attendre que gallium 3D se stabilise, que la couche de support des cartes anciennes soit rajouté.
Or à ce moment là je crois que je n'utiliserais plus cette carte : elle sera soit morte (le ventillo à déjà cramé), soit je l'aurais remplacé par une autre carte (par exemple les nouvelles ATI avec pilote libre).
Je souhaite longue vie au projet nouveau et j'espère qu'il ne se terminera pas comme nvtv (appli pour faire marcher la sortie tv sous Linux) ou rivatv (driver pour faire marcher les tuner tv sous Linux) qui sont tous les 2 morts.
[1] qui permet tout de même de jouer à neverball, tuxracer, xmoto.
[2] au passage dri est très mal documenté...
# questions
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 6.
J'avais cru comprendre que LLVM transformait un code intermédiaire en assembleur.
Un frontend (gcc, clang) se chargeant de convertir le langage source utilisé dans ce langage intermédiaire.
Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
On nous parle pas du tout de bibliothèque rattaché au langage.
Par exemple quelle libc llvm-gcc/clang supporte ?
Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?
PS :
Un inconvénient à LLVM est qu'il n'est pas bootstrapable facilement, c'est à dire qu'il aura toujours besoin que le système de destination ai déjà un compilo c++.
[1]
Le frontal utilisé passe de GCC 4.0 à GCC 4.2 afin d'améliorer les performances.
[^] # Re: Performances ?
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
[^] # Re: point de départ
Posté par M . En réponse au message Achat clé Bluetooth avec driver libre. Évalué à 3.
C'est normal vu que c'est l'interface spécifier dans la norme bluetooth.
[^] # Re: Septique...
Posté par M . En réponse au journal TRON RTOS (OS temps réel japonais). Évalué à 9.
L'intérêt c'est que l'OS RT fait tout ce qui est critique (stack GSM, ...) et on délégue au Linux ce qu'il l'est moins (multimedia, GUI, réseau, ...) et que l'OS RT ne gére pas d'origine.