ndesmoul a écrit 363 commentaires

Et participer au développement de deCSS et/ou le redistribuer?

Sur un paysage je vois mal où intervient le relief...

Par contre dans certaines condition comme un léger contrejour un appareil ne saura pas rendre correctement l'image: soit tu règles l'exposition sur la partie sombre de l'image et le reste est brûlé, soit tu règles sur la partie claire et on ne voit rien dans les parties sombres.
Du coup la photo rendra moins bien que ce que l'oeil perçoit. D'où l'intérêt du HDR (à condition qu'il soit bien utilisé) qui permet de combiner les parties correctement exposées de plusieurs photos.

C'est vrai que Celestia est assez impressionnant! Pas tellement pour la terre, GoogleEarth fait mieux (mais pas en libre). Mais j'ai par exemple trouvé une texture haute résolution de Mars assez impressionnante.

Dans le domaine de Celestia, Magrathea semble apporter une gestion du relief à partir de donnée topographiques. J'ai pas l'impression (je me trompe peut-être) que Celestia le fasse (GoogleEarth si).

De toute façon un peu de concurrence ne fait jamais de mal (pour les consommateurs en tout cas)!

Pour l'intuitivité de QT, aucune idée, j'ai jamais essayé.


- Qt Designer genere du XML
Qt Designer est une petite merveille a utiliser.
Le code genere se trouve dans un fichier separee et pour s'interfacer avec c'est propre et clean. La derniere fois que j'ai utilise des generateurs SWING ca collait tout dans le meme fichier (ca a peut etre change depuis)

Le designer de la dernière version de NetBean génère également du XML. Pour l'avoir essayé un peu il est plutôt pas mal. A voir pour un vrai projet mais je conseille tout de même à ceux développant une GUI java d'y jetter un coup d'oeil. Ca pourrait les intéresser.


- Qt s'integre 10x mieux au desktop que SWING sous Linux et Windows

Ca s'est clair. Encore que ce qui me dérange le plus c'est que les polices de caractères ne sont pas lissées avec Swing. Ca devrait bientôt être le cas ceci dit.


- Une interface Qt c'est rapide !


Pour avoir essayé des versions récentes de Swing, je trouve que c'est plutôt réactif. J'ai même trouvé NetBean (Swing) plus réactif que Eclipse (SWT). Le tout sous Linux. En même temps c'est sans doute SWT qui est un peu buggé...
Je me demandai d'ailleurs si j'allais pas essayé SWT pour voir mais QT me semble beaucoup plus intéressant.

L'autre avantage c'est qu'on va pouvoir développer plus facilement des applications Java pour KDE. Bah, oui moi j'aime pas le C++.
Avec Java qui devrait être libéré par SUN, ça pourrait devenir intéressant.

Et quelles sont en bref ces fonctionnalités non graphiques de QT?

Swing est effectivement une API relativement bien conçue (enfin les goûts et les couleurs, hein), mais les layouts par défaut, c'est à dire livrés avec le JDK sont soit trop limités, soit trop complexes à utiliser (GridBagLayout, Grrr). Mais rien ne t'empêche de développer ton propre layout ou plus simplement d'en récupérer un adapté à tes besoins. Il y en a pas mal de disponibles bien mieux foutus.

J'aimerai également attiré l'attention sur l'éditeur graphique de la dernière version de NetBean. J'ai un peu joué avec et il m'a paru très facile d'utilisation et permettant un placement facile des composants (et sans soucis pour bien aligner les composants). Le code Java généré a l'air propre mais de toute façon l'éditeur ne te permet pas d'y toucher: l'interface créé est sauvegardé dans un format basé sur du XML à partir duquel est généré le code.

Je suis pas allé très loin avec mais à mon avis ça mérite un coup d'oeil.

Ceci dit je trouve que pouvoir utilisé QT avec Java est une excellente nouvelle. Je préfère cette solution à SWT et QT tourne sur énormément de plateformes différentes donc la portabilité ne semble pas être un problème.

Mais bon j'attend d'avoir essayé.

PS: pour les adeptes du GridBagLayout, je sais qu'il y a une logique d'utilisation derrière (si si) et qu'on finit par arriver à un résultat correct mais c'est quand même prise de tête.

J'adore cette animation. Merci beaucoup pour ce moment de franche rigolade. Mais c'est tellement vrai!! (oui j'ai utilisé des gridlayouts et cette animation fait presque office de documentaire...)

Tout à fait. A part que beaucoup de personnes au delà de 30 ans entendent toujours les fréquences extrêmes, mais là n'est pas la question.

A mon avis, les premiers CD classiques n'étaient pas bons car pour gommer les "imperfections" étaient appliqués trop de filtres, qui ont pour effet secondaire de dénaturer le son. Les premiers CD sonnaient parait-il très métalliques.
Du coup entre la version microsillon (sur laquelle on n'appliquait pas ces filtres) et la version CD, c'était le microsillon qui sortait gagnant.
La situation s'est heureusement améliorée (pour les cd classiques) mais je ne saurai dire jusqu'à quel point.

Tout ça pour dire que si le microsillon sonne mieux aux oreilles de certains ce n'est sans doute pas dû au support en lui-même mais principalement à la différence du traitement appliqué au signal.

xfs_fsr , euh ça marche que pour les systèmes XFS...
Et pour les systèmes ext2/3 ? (et les autres pendant qu'on y est)

Le coup du disque dur tampon est effectivement la méhode la plus rapide et efficace mais pas toujours accessible.

Même si les systèmes de fichier sous Linux gèrent mieux la fragmentation que leurs homologues sous Windows (FAT et NTFS), ils n'éliminent pas totalement le problème. Surtout si le disque est déjà bien rempli. Et dans ce cas allouer l'espace fichier au fur et à mesure est une mauvaise idée car le système de fichier ne va pas pouvoir optimiser l'emplacement des zones disques allouées.

Au bout d'un moment tu t'étonnes d'avoir des taux de transfert ridicules... (Oui c'est du vécu). Et le problème est qu'il n'existe pas à ma connaissance d'outil de défragmentation sous Linux. Donc à moins d'avoir un gros disque pour faire tampon, c'est difficile à résoudre.

Sinon, si tu déplaces ton fichier final vers un autre disque où que tu le copie ailleurs sur le même disque (et efface ensuite l'original), le problème est différent.

A mon avis il est préférable d'allouer à l'avance l'espace pour les fichiers. S'il le fait par petit bout au fur et à mesure tu te retrouves avec un fichier en petit morceau et à la longue un disque complètement fragmenté.

Principalement le support de systèmes de fichier de très grande capacité. La limite actuelle est de 8 TB, ce qui commence à être un peu juste (pas encore pour l'utilisateur lambda bien sûr...).

La nouvelle version permettrait d'aller jusqu'à 1024 PB (c'est quelle unité ça?).

cf. http://lwn.net/Articles/187321/

Et comment se positionne ce projet par rapport à Liberty, lui aussi un concurrent (décentralisé) de Passport?

Non, ce logiciel ne convient pas. Je n'ai peut-être pas été assez clair, mais ce que je veux c'est une sortie PDF à fournir à un labo qui va m'imprimer un livre photo sur plusieurs pages et avec plusieurs photos par page.

KPhotoAlbum, comme Digikam sont des logiciels dédiés à la gestion de photos. Ils permettent des classer ses photos selon différents critères, d'assigner des mots clés ,etc.

Ces logiciels sont très bien mais l'export se limite à des galleries html (en moins évolué qu'un logiciel comme JAlbum).

Ce que je recherche serait plutôt quelque chose qui permette et aide la mise en page des photos (plusieurs photos par page, rotation éventuelle, commentaires etc.).

Un tel logiciel pourrait ressembler au logiciel de présentation d'OpenOffice, mais dédié à la génération d'un album photo.
En effet ce dernier (via son export pdf) permettrait peut-être de faire cela mais n'est pas franchement adapté.

Ca peut venir de la configuration dans le fichier /etc/fstab

Pour autoriser l'écriture sur un disque FAT il faut qu'il y ait un paramètre umask adéquat sur la ligne correspondant à ton disque FAT. Un truc comme ça:

/dev/hda1 /mnt/vfat vfat umask=0000 0 0

La page web suivante contient pleins d'infos (en anglais):
http://gentoo-wiki.com/HOWTO_Mount_Windows_partitions_(DOS,_(...)

Certes ça serait bien de le faire et il me semble qu'une disposition européenne vise à augmenter la proportion de carburant vert par rapport au pétrole. C'est très bien, ...sauf que il y a tout de même un petit problème: même en consacrant la totalité des surfaces agricole en France, on ne pourrait pas (et de loin) subvenir à nos besoins actuels en carburant en France. Surtout que l'agriculture intensive amène d'autres problèmes.

Donc le carburant vert c'est mieux que le pétrole mais il faudra tout de même réduire notre consommation.

Chez moi ça ne marche pas...

$ wine MadTracksDemo.exe
fixme:vxd:VXD_Open Unknown/unsupported VxD L"sice.vxd". Try setting Windows version to 'nt40' or 'win31'.
fixme:vxd:VXD_Open Unknown/unsupported VxD L"siwvid.vxd". Try setting Windows version to 'nt40' or 'win31'.
fixme:vxd:VXD_Open Unknown/unsupported VxD L"ntice.vxd". Try setting Windows version to 'nt40' or 'win31'.
Loading required GL library /usr/X11R6/lib/libGL.so.1.2
err:wave:DSDB_MapBuffer Could not map sound device for direct access (Input/output error)
err:wave:DSDB_MapBuffer Create string value : "HardwareAcceleration" = "Emulation" in the registry
under [HKEY_CURRENT_USER\Software\Wine\DirectSound].
wine: Unhandled exception (thread 0009), starting debugger...
WineDbg starting on pid 0x8

Je vous fais grâce de la suite.

$ wine --version
Wine 20050725

Dommage, ça avait l'air marrant.

La commission n'a jamais demandé à Microsoft le code source de Windows. Ce qu'ils veulent c'est une documentation technique complète de certains protocoles utilisés par Windows, de manière à permettre l'interopérabilités avec d'autres acteurs et favoriser les offres concurrentes. Dans l'optique de faciliter une concurrence libre et non faussée il me semble qu'ils sont dans leur rôle et leur bon droit.

Le code source ça ne vaut pas une doc technique, et en plus tu risques d'avoir des pb (juridiques j'entend) si tu le ré-utilise.

Bah Amarok (connait pas fspot) gère des mp3, ogg, et autres formats de fichier qui intègrent leur propre système de tag directement dans le fichier. Ils font avec l'existant quoi. Et puis au moins pas de risque de perdre les tags en transferant un fichier.

Cf. Linux Mag de ce mois pour un article sur les ACL (gestion des droits étendus) et EA (gestion des attributs). D'après l'article ce système qui permet d'assigner des attributs à n'importe quel fichier (mais en dehors de celui-ci) fonctionne sur tous les FS de Linux mais nécessite de les monter avec une option spéciale.

Il parait que KDE3.5 intègre maintenant cette fonctionnalité (je suis encore en 3.4), mais pas encore Gnome.

En tout cas ça a l'air assez puissant comme système et ça ne brise pas la compatibilité. Reste maintenant à bien l'intégrer dans les environnements de bureau et avec les outils de recherche comme Kat et compagnie.

Certes mais vu qu'il souhaite que cela tienne sur 8 caractères ASCII...

Donc en fait c'est un hachage et pas une signature.

Sinon oui, un md5sum fait parfaitement l'affaire. La taille de sortie de md5 est de 128 bits soit 16 octets. La sortie est en hexa soit 32 lettres et chiffres. Rien ne t'empêche de tronquer le résultat pour avoir la bonne taille.

Pour mémoire, même si un seul bit du fichier est modifié, la sortie md5sum sera complètement différente. Le tronquage ne devrait donc pas être un problème. Et réussir à obtenir une collision avec la fonction de hachage MD5 reste tout de même très difficile. Et si t'es parano il y a toujours sha1sum.

8 caractères ça fait 2^32 codes possibles, soit plus de 4 milliards.

Certes mais la fréquence radio d'un mobile est de plusieurs GHz, ce qui fait une longeur d'onde de quelques centimètres. Une carte sans contact usuelle c'est du 13.56MHz ce qui fait une longueur d'onde de plusieurs mètres.

Où je veux en venir? Et bien en radioastronomie par exemple, la surface des réflecteurs de radiotélescopes ressemble souvent plus à un grillage qu'à une surface lisse. Ces instruments observent souvent sur des longeurs d'onde de l'ordre de plusieurs cm (21cm pour la raie d'hydrogène). Et apparemment dans ce cas un maillage plus fin ne sert à rien.

C'est juste une illustration pour montrer qu'il est sans doute plus facile de faire une cage de Faraday avec une carte sans contact (maillage peu serré suffisant) qu'avec un mobile.

Maintenant je n'y connais pas grand chose dans le domaine et je dis peut-être une bétise.

Ou alors tout simplement inclure une feuille d'alu dans la couverture du passeport ce qui bloque toute transmission tant que le dit passeport est fermé.

C'est reparti !

Et d'ailleurs, réponse de Linux à Till Kamppeter :


I personally just encourage people to switch to KDE.

This "users are idiots, and are confused by functionality" mentality of
Gnome is a disease. If you think your users are idiots, only idiots will
use it. I don't use Gnome, because in striving to be simple, it has long
since reached the point where it simply doesn't do what I need it to do.

Please, just tell people to use KDE.

Linus


Hum..., manifestement il utilise KDE...

Oh, un troll KDE contre Gnome. Ca faisait longtemps ;)
Ceci dit je suis assez d'accord avec ce qu'il dit.