dufresne luc a écrit 19 commentaires

Avec un appareil Nikon (au moins sur le D50), le format raw (.nef) est en fait un tiff qui contient un jpeg et le raw. Le jpeg est produit par l'appareil photo en mode "basse qualité".

Gqview (ou son successeur geeqie) ne fait qu'afficher ce jpeg. Cela permet donc un affichage rapide et pas trop moche.

Pour extraire le jpeg du nef, on peut utiliser l'utilitaire nefextract
http://pages.quicksilver.net.nz/pepe/d70/nefextract.c.bz2

Et gqview fait la même chose que nefextract, le code venant de cet outil

dans src/format_nikon.c on peut lire:
* Authors:
* Raw NEF jpeg extraction based on nefextract.c by Joseph Heled,
* in addition nefextract.c is based on dcraw by Dave Coffin.

On peut aussi se demander à quoi sert l'option sur les nikons pour enregistrer en raw+jpeg, qui enregistre en fait 2 fois le jpeg, une fois dans le raw, et une fois dans un fichier.

Pour les autres marques d'appareil photo, aucune idée. Mais "use the source luke", tout est dans: src/format_MARQUE.c (j'ai l'impression qu'a chaque fois un jpeg est sorti du raw)

Y-a-t il une vérité la dessus ?

Autant que :
etc = Editable Text Configuration
emacs = Escape Meta Alt Control Shift.
vi = Very Irritating
(exemples trouvés sur la page slashdot)

Bon la vrai question c'est que veux dire usr ;-)

user !

Sauf que tous les noms de répertoires sous unix sont des abréviations et non pas des acronymes. De plus un contenu texte éditable c'est un pléonasme.

Pour illustrer tout cela, allons sur un bon vieux hp-ux:
/etc/init (lien vers /sbin/init) est très éditable... je conseille à tous ceux qui ont trop de temps libre d'aller un peu le modifier.

Sous AIX, il n'est pas dur de trouver un peu de code binaire. Par exemple /etc/loadext (Oracle Kernel Extension Loader for AIX)

Et sur une debian dans /etc/splashy on a des images jpg, des polices...

Enfin pour ceux que cela passionne, je conseille la lecture de la page suivante:
http://ask.slashdot.org/article.pl?sid=07/03/03/028258

Enfin pour moi etc = etcetera, mais cela n'empêche pas d'y faire un peu de ménage et de ne pas y mettre de binaires

http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFIC(...)

Patch qui d'ailleurs fonctionne très bien. Je viens juste de corriger un dernier petit bug (difficile à rencontrer et reproduire).

Je pense qu'une nouvelle version pourra être mise en ligne dans quelques jours.

Les applications Gtk+ ne devraient donc avoir aucun mal à supporter la spé... sauf que après vérification, mes applis écritent en Gtk+ n'utilisent pas cette fonction

Il y pire...
J'ai écrit libetc, et mes applis Gtk+utilisent toujours un bon vieux répertoire caché dans $HOME. J'ai la flemme de rajouter deux lignes pour récupérer $XDG_CONFIG_HOME !

Et comme aucun soft n'utilise $XDG_CONFIG_HOME, deux trois lignes en C permettent de forcer la main à ces logiciels trop anciens:
http://ordiluc.net/fs/libetc/

On pourrait aller plus loin dans la démarche, par exemple en redirigeant toutes les lectures/écritures dans une base de données par exemple...

D'où la commande: "hpacucli controller all show" pour retrouver le contrôleur.

Quelques informations supplémentaires seraient bien utiles, avec un message aussi bref on a envie de répondre STFG.

Il faut donc préciser que la commandé indiquée n'a rien à voir avec les redhat, mais est une commande fournie par hp pour interroger/configurer un array raid HP sur un serveur proliant.

Ensuite les histoires G4 / G5 n'ont, je pense rien à voir avec des macintosh, mais sont plutôt la génération sur serveur proliant.

Pour donner une réponse plus précise, il serait aussi intéressant de savoir ce que la commande lancée donne. Car là pour répondre il faut une boule de cristal.

Pistes à étudier:
- peut être que le controlleur n'est pas sur le slot 1 (ici c'est le slot 0)
"hpacucli controller all show" permettra de répondre à la question
- peut être que la commande est mal installée (par ex, il manque une bibliothèque...)

Enfin, ici ça marche, quelque soit le serveur hp

A mon avis le problème est le même que si le programme démarre et va ouvrir la bibliothèque avec dlopen et appelle des fonctions en utilisant dlsym.

Si le programme ne peut pas fonctionner sans la bibliothèque, c'est clairement un travail dérivé. Même si il n'y a pas de lien lors de la compilation. Le lien se fait à l'exécution (avec LD_PRELOAD ou dlopen/dlsym).

Il me semble bien pourtant que cela veut dire et caetera. Cela contient tout ce qui n'a pas sa place ailleurs (par ex, les scripts de démarrage dans /etc/init.d ne sont pas pour moi des fichiers de config).

D'ailleurs si on regarde sur une machine HP-UX, on trouve dans /etc pleins de liens symbolique vers des binaires dans /sbin ou /usr/sbin

Merci, je vais incorporer ça dans la prochaine version. Je suis loin de faire du C tous les jours. Je prend tout ce qui améliore le code !

Le principe d'Unix sous AIX et HP-UX c'est d'avoir $HOME = / pour l'utilisateur root. Ca fait un beau bazarre au bout d'un certain temps si on ne crée pas un /root ou quelque chose du genre.

Et pour gconf y a aussi des trucs qui existent sur les Unix classique. La base ODM sous AIX est un exemple. Ils y en a qui aiment... moi je trouve que pour faire des sauvegardes/restaurations ca complique la vie.

Si il n'y avait qu'un seul logiciel à patcher... la réponse serait oui, bien sûr. Mais là il faudrait tout patcher.

Et par rapport à gftp, on peut imaginer un bouton : afficher / cacher les fichiers de config. Mais le jour où on veut envoyer son .profile il faut retourner dans les préférences et faire la manip inverse... c'est lourd.

Je préfère que mes fichiers de configuration soient là où je le souhaite. J'imagine bien que pour certaines personnes cela ne pose pas de problèmes d'avoir 400 fichiers cachés. Pour moi si. Par exemple j'ai des trucs du genre:

% ls -lta ~/ | tail -n 3
-rw-r--r-- 1 luc luc 852 1997-07-23 15:29 .FilesMagic
-rw-r--r-- 1 luc luc 59 1997-07-20 21:12 .xkoules.opt
-rw-r--r-- 1 luc luc 55 1997-07-18 15:54 .life

Je ne sais même plus à quoi cela correspond.

Le marteau piqueur serait d'envoyer tout ça dans une base mysql. Là ce n'est qu'environ 600 lignes de C.

Remarque le coup de la base Mysql ca pourrait servir pour partager sa config entre plusieurs machine (si on n'aime pas nfs et compagnie). Faut que je réflechisse à ça !!!

Le problème se pose aussi avec les applis liées statiquement. On peut toujours imaginer un module dans le noyau. Enfin dans ces cas là je préfere tout de même laisser écrire l'application là ou elle veut. Faut être tordu pour ne pas utiliser les fonctions de la libc pour lire/écrire un fichier.

J'ai testé le truc avec firefox, thunderbird, gnome, kde, openoffice... A première vue cela semble fonctionner. Enfin pour faire des tests vaut peut être mieux créer un nouveau compte, ce que je fais pour le moment. Mais je pense que maintenant c'est utilisable. Je vais donc pas tarder à utiliser ça avec mon compte de tous les jours. Mon seul problème c'est que j'ai un bug avec gimp.

Merci beaucoup pour cette information. Je ne connaissais pas cette variable (il faut dire que le nom est un peu tordu !). Cela fera parti des prochaines modifications.

Cela fonctionne bien avec la version RC2 de l'installeur: J'ai testé le RAID1 et le RAID5

Par contre pour créer les volumes RAID c'est un petit peu ardu si on ne sait pas comment fonctionne le RAID logiciel sous Linux.

En résumé il faut pour chaque filesystem: créer une partition sur chaque disque, la déclarer en tant que RAID linux (type = fd dans fdisk), ensuite on peut créer le volume RAID avec toutes les partitions et finalement on crée un filesytem dessus.

Il faut aussi être très prudent avec le bootloader. Pour lilo je ne sais pas quel est le support du RAID, pour grub il est inexistant. Donc grub ne sait pas booter sur une parition /boot en RAID5, pour le RAID1 on s'en sort en copiant grub manuellement sur tous les disques.

Pour éviter de multiplier les partition (nb de filesystems x nr de disques), on peut créer une grande partition et faire un grand volume RAID. On met dessus un LVM, et on crée autant de LV que l'on veut sur lesquels on met ses filesystems. En plus on gagne en flexibilité (par exemple: possibilité de modifier la taille des filesystem à chaud avec les dernier noyau 2.6). On se rapproche de la gestion des disques de certains Unix propriétaires.

Par contre avec le LVM grub ne sait plus du tout booter. Il est donc utile de créer une petite partition pour mettre /boot au début de tous les disques, et d'y installer manuellement tout ce qui est nécessaire à grub.

La section interessante de la doc de l'installeur debian est là:
http://d-i.alioth.debian.org/manual/fr.i386/ch06s03.html#di-partiti(...)

Cette doc pointe vers le LVM howto:
http://www.tldp.org/HOWTO/LVM-HOWTO.html(...)
et vers le RAID howto:
http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html(...)
qui à mon avis doivent être interessants à lire avant de mettre en place une telle configuration

J'ai debuté avec "Programmation en perl" de Larry Wall et Tom Christiansen: http://www.oreilly.fr/catalogue/pperl3.html(...) . Ce livre est une référence (écrit par l'auteur du langage).

Il existe d'autres livres chez oreilly qui doivent être pas mal : http://www.oreilly.fr/perl.html(...) . Le livre "Introduction à Perl" est peut être plus facile d'accès : http://www.oreilly.fr/catalogue/intro-perl-3ed.html(...)

Sinon la doc de perl est accessible avec la commande perldoc "perldoc perltoc".

On peut par exemple avoir des infos sur le livre "Programmation en perl" avec "perldoc perlbook" où l'on voit que perlfaq2 contient une liste de bouquins sur perl. CQFD !

ouaip, j'ai cliqué trop vite. Il faudrait prévoir une interface de correction entre le moment où la nouvelle est enregistrée sur le serveur et le moment ou la nouvelle est approuvée. Car là je me suis dis, pas grave le modérateur corrigera...