Il faut qu'elles soient disponibles si tu le demandes, c'est tout.
Et non il faut soit qu'on te fournisse les sources en même temps, soit qu'on te les proposes par écrit :
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
J'ai moi aussi découvert ce truc il y a quelques semaines, j'avais préparer un journal, mais j'ai pas trouvé le temps de le finir.
Bon, finies les allusions salaces. Le Canon dont on parle ici,
c’est votre appareil photo. Et CHDK est un microcode² alternatif
pour tous les appareils Canon pourvus du microcode
« DiG!C » (PowerShots, Ixus…).
En fait c'est plutôt une sorte de rootkit qui met des hook dans le firmware officiel et qui s'en sert pour accéder a des réglages bas niveau, ajouter de nouvelles fonctionnalités, ...
Mais pour le moment je l'utilise pas trop, il y a peu de fonctionnalité qui me sont vraiment utile, et je trouve le truc pas très bien intégré (je sais que c'est pas leur faute).
Même pour le RAW, c'est qu'un dump du capeur photo et du coup il faut la couplé avec une image jpeg pour récupérer toute les données exif (au contraire des fichiers raw officiel qui embarque toutes les infos). Et vu que le firmware canon n'est pas au courant que ces images raw sont sauvé sur la flash ça peut donné des résultats étrange : suppression à la main, mauvais calcul du nombre de photo restante, pas visible via l'interface usb si elle n'ont pas la bonne extension et que l'appareil n'a pas redemaré, ...
PS : une fonctionnalité qui peut être intéressante, c'est celle qui permet de supprimer les pixels mort.
Si au lieu de troller pour savoir si OOXML est vraiment legitime ou pas, pourquoi ne pas rendre ODF indispensable ?
C'est à dire avoir un bon support d'ODF dans maximum de logiciel (suite bureautique, export latex/docbook/..., moulinette de traitement de donnée, génération automatique de document, ...)
Parce que pour le moment c'est le *.doc et *.xls qui sont les formats qui ont le plus de change d'être compris par tout le monde.
Enfin les différents constructeurs n'embarque pas forcement le même type de flash et elle ne sont pas cascadé de la même manière, ...
J'oubliais : tu parlais d'optimisation des fs classique par rapport à la tête de lecture. Mais là aussi il faut optimiser le fs suivant l'organisation des différentes flash qui compose le disque (oui il y en a rarement qu'une seule).
Et effet on peut voir ca comme un RAID-0 et pour masquer la latence d'accès à la flash il faut bien repartir les écritures sur les différentes flashs.
Un petit complément un peu plus orienté sur l'utilisation dans le domaine des flashs dans l'embarqué.
Déja avant de parler des systèmes de fichiers flash, MTD à ses limites :
- pas de support des flashs de plus de 4Go
- pas de support de contrôleur avec dma (en tout cas pas de manière simple)
Ce algorithme est implémenté par les constructeurs de disques SSD dans des microcontrôleurs faisant le lien entre la mémoire flash et l'interface sata. C'est certes transparent pour l'utilisateur mais cela signifie que les systèmes de fichiers traditionnels, avec toutes leurs limitations et tout leur code complexe dédié à la minimisation des temps d'accès par le bras de lecture, vont continuer à être utilisé.
C'est surtout que l'on ne sait pas trop ce qu'il fait et s'il est vraiment robuste. De plus ces algorithmes pour être efficace doivent être optimisé pour certains patterns et donc certains filesystem.
Néanmoins ces disques SSD à base de mémoire flash sont affligés d'un défaut important puisqu'ils ne supportent qu'un nombre restreint de cycles d'écritures (typiquement de l'ordre de 100000).
C'est pire que ça. Là tu parles de la NOR.
Mais c'est de la NAND, où les blocks où l'on écrit les données ne sont pas garanti (sauf le premier). Donc ils peuvent être mauvais en sortie d'usine ou au cours du temps.
Il est donc nécessaire d'utiliser des algos de corrections d'erreur "ecc" pour récupérer les données si le block "fatigue". Il faut aussi être capable de déplacer les données d'un secteur fatigué et de le marqué comme mauvais s'il ne marche plus.
Le gros problème de JFFS2 est qu'il a besoin d'examiner tous les blocs mémoires au moment du montage du système de fichiers afin de construire l'index qui est conservé en RAM.
Il y a le mode sumary qui permet de ne pas examiner tous les blocs mémoires au moment du montage du système. Un résumé est stocké à la fin de chaque "block".
De plus YAFFS fait la même chose (sauf s'il est éteint proprement dans quel cas il sauve un son état en flash).
Un autre problème de jffs2 c'est qu'il est très gourmand en RAM.
YAFFS [...] Ce système a été conçu spécifiquement pour la mémoire flash NAND et il est donc a priori bien adapté aux disques SSD.
Il a les même problème que jffs2 : temps de montage et conso RAM linéaire par rapport a la taille de la flash (la pente est seulement plus faible). Donc non il est pas très adapté au gros média.
De plus ce fs ne gère pas bien la NAND et notamment les bit flips sur les lectures.
PS : les slides présentant yaffs2 et ses évolutions futures sont dispo quelque part sur le net.
UBI et UBIFS Comme cette couche UBI est déjà présente dans le noyau il parait éminemment logique de construire un système de fichiers gérant les disques SSD par dessus cette infrastructure afin de profiter de ses avantages et de factoriser le code noyau
Plus précisément, pour diviser les difficultés celui qui voulait faire jffs3 a développé UBI d'abord, puis UBIFS.
Comme tu le soulignes UBI+UBIFS est très gros. Sera t il simple d'embarquer un support partiel (lecture seul) dans les bootloader ?
Sera t il simple de le garantir sans bug (ou au moins de l'auditer).
Un autre avantage est qu'UBIFS utilise un cache pour les données (writeback) ce qui permet d'éviter d'écrire les données de façon strictement synchrone.
Est-ce un résultat souhaitable sur des périphérique embarqué qui peuvent être éteint n'importe quand ?
De plus tous ces file systèmes sont inadapté dans le cas de disque (ou périphérique) externe : on voudrait par exemple les monter en mass storage partout, ce qui implique l'émulation disque dur et du FAT... Et du coup on est obligé de passé par des flash translation layer qui émule un disque dur sur la flash. C'est ce que l'on trouve dans les SD, clef usb et SDD.
En conclusion pour les SDD il faudra que les fabriquant propose une interface qui permette de desactiver la FTL. Mais cela pose des problèmes.
D'abord ça oblige à creer un nouveau protocole de communication avec ces disques.
De plus ces disques ne seront plus bootable par les bios à moins d'écrire en flash le même format que celui qu'utilise le microcontrôleur du disque...
Enfin les différents constructeurs n'embarque pas forcement le même type de flash et elle ne sont pas cascadé de la même manière, ... Actuellement c'est masqué par la FTL.
Il faudra aussi que des filesystemes flash fasse leur preuve sur les gros média et que MTD soit améliorer.
Mais arrête de raconter n'importe quoi, il est *évident* qu'il est important de préserver le maximum de diversité, et qu'il ne faut pas réduire les cultures à une palette alors qu'on a tout le spectre à disposition !
Ca me rappel un discours que j'ai entendu sur un reportage ARTE il y a quelque temps.
J'ai pu le truc en tête, mais c'était assez abérant. C'etait du style :
sous pretexte de conservé la diversité, il fallait cloner ces espèces ou essayer de les introduire ailleurs.
Avec le clonage on élimine les mécanismes de sélection naturel (et donc de diversification puisse qu'on reproduit le même individu) et en les introduisant ailleurs on bouleverse des eco systèmes (et on peut faire disparaître d'autre espèce du milieux).
Donc oui il faut préserver le maximum de diversité, mais pas faire n'importe quoi, avoir une vision global à l'échelle de la planete et sur le long terme.
Le probleme de NUT c'est qu'il faudrait qu'il sorte un jour :
nut (comme snow (codec video à ondelette)) ont beau etre tres prometteur, le soucis c'est qu'ils ont été concu par une ou deux personnes, mais depuis plus grand chose (et personne ne bosse vraiment dessus).
Peut-être est-ce l'interprète. A-t-on des informations sur l'identité de la dame qui chante ? Auquel cas, ses droits ont expiré avant 1910 (les droits voisins ne durant pas aussi longtemps qu'aujourd'hui à l'époque, je prends large).
Oui mais le fait de scanner, numériser la chanson (ie de faire des transformation dessus) ont fait acquérir des droits à ces personnes.
C'est la même chose pour les documents scanné de la bnf qui ont parfois des licences.
C'est juste que la partition Linux est embarquée dans un fichier de la partition windows, à priori, donc juste un bootloader et un driver de fs un peu particuliers en gros j'imagine.
Pour le bootloader celui ci s'interface avec le bootloader de windows, ce qui permet de ne pas modifier le MBR.
Ensuite le bootloader sait recupere le kernel et l'initrd sur la partition windows et apres le rootfs est monté en loopback depuis la partition windows.
C'est effectivement assez pratique pour tester sans tout casser ni avoir les pb de lenteur des live cd.
Ben gallium est encore en développement et aucune carte ne marche de manière stable dessus.
Même intel ne sait pas s'ils resteront sur mesa-dri ou passeront sur gallium [1].
Et puis mesa-dri n'est pas prêt de disparaître vu le nombre de carte qu'ils supporte (et le boulot que ca serait de tous les porter).
Ca me rappel les drivers ralink qui utilisait la stack wifi dernier cri (qui n'était pas dans le noyau) alors que d'autre continuait à développer sur l'ancienne : les drivers ralink était très compliquer à utiliser.
[1] http://article.gmane.org/gmane.comp.video.mesa3d.devel/10087 If existing DRI drivers
get to continue living side-by-side with gallium stuff, then until
gallium proves to be a significant win for our chipsets we can go ahead
and ignore it, it sounds like.
Je suis t'a fait d'accord avec toi (et je comprend pas ton moinsage).
Il faut mieux mettre un firewall sur le point d'entrée que se reposer sur la configuration de chaque machine (d'autant plus qu'on peut vouloir autoriser des données à circuler sur le réseau local, sans qu'elles en sortent).
Au passage avec l'ipv6 on nous vante la fin les problème propre au nat. Mais bon par exemple pour sip, si le routeur a un parfeu qui bloque les flux entrant qu'on soit en ipv4 ou ipv6, on aura toujours besoin de truc comme stun ?
Posté par M .
En réponse à la dépêche Mythtv 0.21.
Évalué à 2.
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).
Posté par M .
En réponse à la dépêche Mythtv 0.21.
Évalué à 2.
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.
Posté par M .
En réponse à la dépêche Mythtv 0.21.
Évalué à 4.
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.
Posté par M .
En réponse au journal Le bluespam.
Évalué à 4.
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).
[^] # Re: A mon avis...
Posté par M . En réponse au journal Microsoft vs Alcatel vs Linux. Évalué à 8.
Et non il faut soit qu'on te fournisse les sources en même temps, soit qu'on te les proposes par écrit :
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
# libre
Posté par M . En réponse au journal Enlarge Your Canon. Évalué à 6.
J'ai moi aussi découvert ce truc il y a quelques semaines, j'avais préparer un journal, mais j'ai pas trouvé le temps de le finir.
Bon, finies les allusions salaces. Le Canon dont on parle ici,
c’est votre appareil photo. Et CHDK est un microcode² alternatif
pour tous les appareils Canon pourvus du microcode
« DiG!C » (PowerShots, Ixus…).
En fait c'est plutôt une sorte de rootkit qui met des hook dans le firmware officiel et qui s'en sert pour accéder a des réglages bas niveau, ajouter de nouvelles fonctionnalités, ...
Mais pour le moment je l'utilise pas trop, il y a peu de fonctionnalité qui me sont vraiment utile, et je trouve le truc pas très bien intégré (je sais que c'est pas leur faute).
Même pour le RAW, c'est qu'un dump du capeur photo et du coup il faut la couplé avec une image jpeg pour récupérer toute les données exif (au contraire des fichiers raw officiel qui embarque toutes les infos). Et vu que le firmware canon n'est pas au courant que ces images raw sont sauvé sur la flash ça peut donné des résultats étrange : suppression à la main, mauvais calcul du nombre de photo restante, pas visible via l'interface usb si elle n'ont pas la bonne extension et que l'appareil n'a pas redemaré, ...
PS : une fonctionnalité qui peut être intéressante, c'est celle qui permet de supprimer les pixels mort.
# meilleur format
Posté par M . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 3.
C'est à dire avoir un bon support d'ODF dans maximum de logiciel (suite bureautique, export latex/docbook/..., moulinette de traitement de donnée, génération automatique de document, ...)
Parce que pour le moment c'est le *.doc et *.xls qui sont les formats qui ont le plus de change d'être compris par tout le monde.
[^] # Re: Bof
Posté par M . En réponse au journal encore une règle ISO de violé.... Évalué à 4.
[^] # Re: Complément...
Posté par M . En réponse à la dépêche Les systèmes de fichiers pour disques SSD. Évalué à 10.
J'oubliais : tu parlais d'optimisation des fs classique par rapport à la tête de lecture. Mais là aussi il faut optimiser le fs suivant l'organisation des différentes flash qui compose le disque (oui il y en a rarement qu'une seule).
Et effet on peut voir ca comme un RAID-0 et pour masquer la latence d'accès à la flash il faut bien repartir les écritures sur les différentes flashs.
[^] # Re: terriblement efficace ?!
Posté par M . En réponse à la dépêche Les systèmes de fichiers pour disques SSD. Évalué à 4.
Ca sert à rien vu que l'on passe encore par le controlleur de la sd qui émule la flash comme un disque.
Et l'auteur du patch en question dit: "the mtd layer doesn't deal with media larger than 4GB anyway at this point"
Et c'est toujours vrai.
# Complément...
Posté par M . En réponse à la dépêche Les systèmes de fichiers pour disques SSD. Évalué à 10.
Déja avant de parler des systèmes de fichiers flash, MTD à ses limites :
- pas de support des flashs de plus de 4Go
- pas de support de contrôleur avec dma (en tout cas pas de manière simple)
Ce algorithme est implémenté par les constructeurs de disques SSD dans des microcontrôleurs faisant le lien entre la mémoire flash et l'interface sata. C'est certes transparent pour l'utilisateur mais cela signifie que les systèmes de fichiers traditionnels, avec toutes leurs limitations et tout leur code complexe dédié à la minimisation des temps d'accès par le bras de lecture, vont continuer à être utilisé.
C'est surtout que l'on ne sait pas trop ce qu'il fait et s'il est vraiment robuste. De plus ces algorithmes pour être efficace doivent être optimisé pour certains patterns et donc certains filesystem.
Néanmoins ces disques SSD à base de mémoire flash sont affligés d'un défaut important puisqu'ils ne supportent qu'un nombre restreint de cycles d'écritures (typiquement de l'ordre de 100000).
C'est pire que ça. Là tu parles de la NOR.
Mais c'est de la NAND, où les blocks où l'on écrit les données ne sont pas garanti (sauf le premier). Donc ils peuvent être mauvais en sortie d'usine ou au cours du temps.
Il est donc nécessaire d'utiliser des algos de corrections d'erreur "ecc" pour récupérer les données si le block "fatigue". Il faut aussi être capable de déplacer les données d'un secteur fatigué et de le marqué comme mauvais s'il ne marche plus.
Le gros problème de JFFS2 est qu'il a besoin d'examiner tous les blocs mémoires au moment du montage du système de fichiers afin de construire l'index qui est conservé en RAM.
Il y a le mode sumary qui permet de ne pas examiner tous les blocs mémoires au moment du montage du système. Un résumé est stocké à la fin de chaque "block".
De plus YAFFS fait la même chose (sauf s'il est éteint proprement dans quel cas il sauve un son état en flash).
Un autre problème de jffs2 c'est qu'il est très gourmand en RAM.
YAFFS [...] Ce système a été conçu spécifiquement pour la mémoire flash NAND et il est donc a priori bien adapté aux disques SSD.
Il a les même problème que jffs2 : temps de montage et conso RAM linéaire par rapport a la taille de la flash (la pente est seulement plus faible). Donc non il est pas très adapté au gros média.
De plus ce fs ne gère pas bien la NAND et notamment les bit flips sur les lectures.
PS : les slides présentant yaffs2 et ses évolutions futures sont dispo quelque part sur le net.
LogFS
Il ne gère pas vraiement les NAND pour le moment : http://marc.info/?l=linux-kernel&m=120702790910653&w(...)
UBI et UBIFS
Comme cette couche UBI est déjà présente dans le noyau il parait éminemment logique de construire un système de fichiers gérant les disques SSD par dessus cette infrastructure afin de profiter de ses avantages et de factoriser le code noyau
Plus précisément, pour diviser les difficultés celui qui voulait faire jffs3 a développé UBI d'abord, puis UBIFS.
Comme tu le soulignes UBI+UBIFS est très gros. Sera t il simple d'embarquer un support partiel (lecture seul) dans les bootloader ?
Sera t il simple de le garantir sans bug (ou au moins de l'auditer).
Pour le moment on a pas de benchmark très complet (petite flash/très grosse flash). http://osl.sed.hu/wiki/ubifs/index.php/Mount_results montre des résultats pas terrible.
Un autre avantage est qu'UBIFS utilise un cache pour les données (writeback) ce qui permet d'éviter d'écrire les données de façon strictement synchrone.
Est-ce un résultat souhaitable sur des périphérique embarqué qui peuvent être éteint n'importe quand ?
De plus tous ces file systèmes sont inadapté dans le cas de disque (ou périphérique) externe : on voudrait par exemple les monter en mass storage partout, ce qui implique l'émulation disque dur et du FAT... Et du coup on est obligé de passé par des flash translation layer qui émule un disque dur sur la flash. C'est ce que l'on trouve dans les SD, clef usb et SDD.
En conclusion pour les SDD il faudra que les fabriquant propose une interface qui permette de desactiver la FTL. Mais cela pose des problèmes.
D'abord ça oblige à creer un nouveau protocole de communication avec ces disques.
De plus ces disques ne seront plus bootable par les bios à moins d'écrire en flash le même format que celui qu'utilise le microcontrôleur du disque...
Enfin les différents constructeurs n'embarque pas forcement le même type de flash et elle ne sont pas cascadé de la même manière, ... Actuellement c'est masqué par la FTL.
Il faudra aussi que des filesystemes flash fasse leur preuve sur les gros média et que MTD soit améliorer.
# performance
Posté par M . En réponse à la dépêche AbiWord 2.6.0. Évalué à 3.
La derniere fois que j'avais tester (il y a 1an) c'etait tres lent de les ouvrir.
[^] # Re: Ça me semble raisonable
Posté par M . En réponse au journal (BIO) Kokopeli condamnée à payer 88000 € d'amende. Évalué à 3.
Ca me rappel un discours que j'ai entendu sur un reportage ARTE il y a quelque temps.
J'ai pu le truc en tête, mais c'était assez abérant. C'etait du style :
sous pretexte de conservé la diversité, il fallait cloner ces espèces ou essayer de les introduire ailleurs.
Avec le clonage on élimine les mécanismes de sélection naturel (et donc de diversification puisse qu'on reproduit le même individu) et en les introduisant ailleurs on bouleverse des eco systèmes (et on peut faire disparaître d'autre espèce du milieux).
Donc oui il faut préserver le maximum de diversité, mais pas faire n'importe quoi, avoir une vision global à l'échelle de la planete et sur le long terme.
# ...
Posté par M . En réponse au journal Connaissez vous le format NUT?. Évalué à 4.
nut (comme snow (codec video à ondelette)) ont beau etre tres prometteur, le soucis c'est qu'ils ont été concu par une ou deux personnes, mais depuis plus grand chose (et personne ne bosse vraiment dessus).
[^] # Re: Licence ?
Posté par M . En réponse au journal Thomas Edison battu par un français !. Évalué à 5.
Oui mais le fait de scanner, numériser la chanson (ie de faire des transformation dessus) ont fait acquérir des droits à ces personnes.
C'est la même chose pour les documents scanné de la bnf qui ont parfois des licences.
[^] # Re: Pas tout à fait ...
Posté par M . En réponse au journal Webkit passe l'acid test 3. Évalué à 10.
[^] # Re: Wubi
Posté par M . En réponse à la dépêche Ubuntu 8.04 Bêta. Évalué à 3.
Pour le bootloader celui ci s'interface avec le bootloader de windows, ce qui permet de ne pas modifier le MBR.
Ensuite le bootloader sait recupere le kernel et l'initrd sur la partition windows et apres le rootfs est monté en loopback depuis la partition windows.
C'est effectivement assez pratique pour tester sans tout casser ni avoir les pb de lenteur des live cd.
[^] # Re: Bof
Posté par M . En réponse au journal Accélération 3D ATI : Ça débute !. Évalué à 3.
Même intel ne sait pas s'ils resteront sur mesa-dri ou passeront sur gallium [1].
Et puis mesa-dri n'est pas prêt de disparaître vu le nombre de carte qu'ils supporte (et le boulot que ca serait de tous les porter).
Ca me rappel les drivers ralink qui utilisait la stack wifi dernier cri (qui n'était pas dans le noyau) alors que d'autre continuait à développer sur l'ancienne : les drivers ralink était très compliquer à utiliser.
[1]
http://article.gmane.org/gmane.comp.video.mesa3d.devel/10087
If existing DRI drivers
get to continue living side-by-side with gallium stuff, then until
gallium proves to be a significant win for our chipsets we can go ahead
and ignore it, it sounds like.
[^] # Re: Emacs et bzr
Posté par M . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 4.
# ...
Posté par M . En réponse à la dépêche Correction grammaticale dans OpenOffice.org. Évalué à 4.
Il en était ressortit qu'il restait beaucoup de travail à faire avant d'avoir quelque chose d'utilisable.
[1] https://linuxfr.org//2008/02/16/23702.html
[^] # Re: Emacs et bzr
Posté par M . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 7.
Apparemment Bazaar a été choisi par rms car c'est un projet GNU, pas parce que c'est celui qui répond le mieux au cahier des charges...
[^] # Re: toujours pas de firewall ?
Posté par M . En réponse au journal Nouveautés ipv6 chez Free. Évalué à 3.
Il faut mieux mettre un firewall sur le point d'entrée que se reposer sur la configuration de chaque machine (d'autant plus qu'on peut vouloir autoriser des données à circuler sur le réseau local, sans qu'elles en sortent).
Au passage avec l'ipv6 on nous vante la fin les problème propre au nat. Mais bon par exemple pour sip, si le routeur a un parfeu qui bloque les flux entrant qu'on soit en ipv4 ou ipv6, on aura toujours besoin de truc comme stun ?
[^] # Re: To wear or not to wear level ?
Posté par M . En réponse au journal Interrogation à propos d'une carte compact flash. Évalué à 3.
Et il te bouffe plein de RAM.
Et que logfs n'est toujours pas sorti en stable ...
Y a aussi ubifs a surveiller
[^] # Re: ...
Posté par M . En réponse à la dépêche Mythtv 0.21. Évalué à 2.
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.
[^] # Re: Consommation
Posté par M . En réponse au journal Firefox et consommation de mémoire. Évalué à 5.
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).
# ...
Posté par M . En réponse à la dépêche Mythtv 0.21. Évalué à 2.
- 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.
[^] # Re: transpondeur?
Posté par M . En réponse à la dépêche Mythtv 0.21. Évalué à 4.
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.
[^] # Re: Fermer son Bluetooth
Posté par M . En réponse au journal Le bluespam. Évalué à 4.
Sauf que des fois pour faciliter la vie de l'utilisateur, les fabriquants de téléphoner le font sauté...
[^] # Re: Windows 95
Posté par M . En réponse à la dépêche GNOME 2.22 : évolution perpétuelle. Évalué à 3.
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).