M a écrit 2988 commentaires

Pour le 2), le .htaccess n'est pas très portable. Vu que tu n'a pas l'air d'autoriser des telechargements direct, il suffirait que tu stockes les fichiers avec une extension inoffensive.

Sauf que c'est bien subjectif comme critère ;)

Je pense qu'on a maintenant bien débattu sur le changement qui aurait dû arriver si l'ISO avait fait son boulot correctement et qui n'arrivera pas, mais j'ai du mal à partager le catastrophisme ambiant. On a deux normes ISO, soit. L'une est une vraie norme, l'autre c'est de la merde. OK. Mais est-ce de l'optimisme que de penser que tout n'est pas si noir dans cette affaire?
Oui si au lieu de s'apitoyer, on rendait le format ODF plus attractif :
- avoir un support correct dans plusieurs suite bureautique
- avoir un support dans les framwork python/java/perl/... pour le manipuler facilement
- avoir des outils qui travailles dessus (diff, correction orthographique, ...)
- [...]

Comme tu le dis la force du libre c'est pas le coté commercial, mais sa grande qualité et ses possibilité d'évolution infinie (chacun peu rajouter son grain de sel).

Euh.... Fonctionelement c'est quoi la différence ?
Le périph a des états internes que tu ne connais pas, et que tu ne peux pas sauver en RAM.
Tu es donc obligé de passer par une phase de reset et reconfiguration pour retomber sur tes pattes.

D'ailleurs en cherchant plus d'info sur le sujet j'ai enfin compris pourquoi ACPI etait une un truc qui fonctionne super mal et bourre de probleme surtout sous Linux. Il a tout simplement ete fait dans cette optique!

Le gros pb de l'ACPI c'est que c'est du code proprio qui est écrit par les fabricants des chipsets des cartes mères.
C'est du code fait à l'arrache, qui n'est testé que sous windows, et qui peut être compilé avec le compilo Microsoft (qui comme tout ses compilos ne suit pas les specs à la lettre).

Pour certains truc les développeur Linux en sont rendu à copier le fonctionnement de Windows...


Sinon à une époque Intel avait eu une grande idée (avec l'EFI ???) d'étendre ce mécanisme de code proprio interprété au code des drivers des composants de la carte mère.


PS : tant que j'y suis, il parait que certaines stack réseau pour booter sur le réseau depuis le bios sont bien buggé. Le problème de fond est donc qu'avec la carte mère, on récupère du code proprio bas niveau tout pourris et sans specs.

Bref, il y a un gros soucis de sauvegarde et de restauration d'état dans beaucoup de drivers.
Encore faut il que ca soit possible : certains peripherique ne supporte pas simplement la sauvegarde/restoration de contexte en sauvant/restorant les registes.

Il est parfois bien plus simple de faire un bon reset du controlleur et le reconfigurer.

qiv est assez sympa pour visualiser des images rapidement.

On peut même avec certaines combinaison de touche copier/déplacer des images dans un répertoire. Pratique pour supprimer/sélectionner des photos

"A l’heure actuelle, des milliards de dollars d’infrastructures de compression vidéos vont être littéralement jetés par les fenêtres lorsque de nouvelles normes comme la h.264 seront adoptées",
Oui mais bon vu qu'a chaque nouvelle norme les puissances de calculs change aussi le problème reste le même : sur le cell d'aujourd'hui qui est capable d'encoder du h264 en temps réel qui me dira qu'il sera assez puissant pour faire la même chose en h265 ou équivalent ?

Vous n’avez pas à vous débarrasser de votre ordinateur à chaque fois que Microsoft lance une nouvelle version de ses logiciels.
Qu'est qui se passe s'il n'y a pas de mise a jour soft ? On se retrouve pas la même situation (ne me parler pas de développer soit même les évolutions)

PS : il faut voir aussi qu'en fasse les recepteurs (tnt/satelitte/...) décode avec des solutions en dur. Donc l'évolution est quand même bloqué...

Je ne suis pas un spécialiste, mais h.264 est un vrai standard. Mplayer le supporte nickel (lecteur et codage) via le projet http://developers.videolan.org/x264.html .
Comme dit dans un autre poste c'est via ffmpeg.
Mais le support de h264 n'est pas complet. cf http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/66542/(...)

peut etre que le fit-pc consomme juste moins que n'importe laquelle des solutions que tu proposes (5W c'est vraiment peu)
heu, les processeurs arm/mips que l'on trouve dans les solutions embarqué consomme vraiment très peu.
Par exemple http://www.arm.com/products/CPUs/ARM926EJ-S.html : @470MhZ il consome 110mW ....

Et pour l'utilisation en poste web, il y a plein d'autre chose a rajouter à la conso : disque dur, écran, ...

certes c'est léger mais une Libreboîte Hd c'est un 300MHz qu'il y a dedans
Mais qui a une puce à coté qui fait tout le boulot...
C'est comme si sur ton PC tu mettais une carte REALMAGIC de sigma design...

Avec quelques copains, on envisage de commander quelques mini-pc "fit-pc" (http://www.fit-pc.com/new/fit-pc/specification.html ). C'est idéal pour faire un petit firewall et/ou un petit poste web/bureautique.
Bof pour le "petit firewall" autant acheter un routeur du commerce qui tourne sous linux et que l'on peut tuner avec des trucs comme openwrt

Pour des NAS, idem autant utiliser des trucs du commerce qui tourne sous Linux (genre le SL-35xx http://laforge.gnumonks.org/weblog/2008/01/20/#20080120-lear(...)

Pour une utilisation multimédia, il faut soit un cpu puissant, soit des accelerateurs hardware.

Et pour un petit poste burautique autant recycler les vielles machines [1] ?


[1] l'idéal étant de connaître des entreprises qui se débarrasse de leur matos info obsolète.

J'avoue que j'ai du mal avec l'ergonomie de VLC, je sais que c'est configurable mais au lieu de m'embêter j'utilise mplayer.

Parreil.
A une époque j'avais même tenté d'enrichir les raccourci/OSD pour avoir un truc similaire à mplayer.

[mode chipotage]

C'est plutot du shell unix (posix) que du Linux.
[/mode chipotage]
Sinon un lien vers opengroup, pour avoir les man posix pourrait etre intéressant. Par exemple http://www.opengroup.org/onlinepubs/009695399/utilities/mv.h(...) pour mv.

Oui, mais ca apporte quoi de concret ?

D'après ce que j'ai vu rien de fabuleux.

Oui mais c'est du théorique où tu écris uniformément dans toute la flash, ou tout les "secteurs" de la flash sont de bonne qualité, à chaque écriture du remplit complètement l'unité d'écriture de la flash.

En effet avec 10^6 cycles d'écriture possible, sur un disque de 2Go, ça donne 2*10^6Go au total, soit pour une écriture journalière de 50Go, plus de (2*10^6Go/50Go ~ 140*265 ) jours, soit 140 ans.

Je pense pas, ce qui va devoir etre revu, c'est qu'il faut limiter les accès au disque.
Ca peut se traduire par :
- une convervation plus longtemps en cache mémoire avant de flusher les donnée sur le disque
- désactiver l'option du fs qui stocker le temps du dernier accès
- monter les fs temporaire en RAM (/tmp, /var/tmp, ...)

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.)

Et la cerise sur le gâteau c'est que c'est libre : https://tools.assembla.com/chdk/browser

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.

Sauf que le pdf c'est pas ce qu'il y a de plus top pour l'édition

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 patch http://marc.info/?t=116731222600007&r=1&w=2 à priori pour les CPU/SoC qui incluent une interface MMC, donc plutôt de l'embarqué.

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.

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.

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.

Les performances se sont elles améliorer sur les gros documents (plus de 100 pages) ?

La derniere fois que j'avais tester (il y a 1an) c'etait tres lent de les ouvrir.