Larry Cow a écrit 5011 commentaires

Sur un Olympus, tu n'as pas d'autre choix que le Jpeg comme _format_? En ce qui me concerne, sur un appareil de la même marque mais agé de plus d'un an, j'ai possibilité de sortir mes images au format TIFF. Je ne prétends pas que les données du TIFF ne soient pas compressées d'une manière ou d'une autre, mais en tous cas j'ai le choix du format.

En revanche, pas de RAW, apparement.

Merci pour ce texte "calme" et argumenté, ça nous change de certaines argumentations "enflammées" et vides de sens.

Cela dit, j'aimerais bien savoir d'où il vient. C'est toi qui l'a rédigé? Si non, c'est qui?

Pour bien faire, personne n'aurait un texte du même goût rédigé par un pro-non? Avec une liste étayée de trucs qui posent problème dans le TCE... :)

Dans le cas de l'intégration d'ObjectiveC++ dans la branche principale de GCC, c'est manifestement des personnes de chez Apple qui font la majeure partie du boulot : le mainteneur du frontend ObjC++ - Mike Stump, de mémoire - signe ses posts avec une adresse @apple.com. Après, il fait peut-être cela sur son temps libre, mais la plupart des gens qui bougent alentour semblent également être de chez Apple.

J'ai pas d'actions chez ces gens-là (j'ai même pas de matériel de chez eux), mais je trouve qu'il y a largement pire en matière de collaboration avec le libre.

Si vous avez des infos sur des contributions d'Apple pour le libre, ayez la sympathie de nous en faire part.

Mmmh, Darwin? Rendez-vous? Les patches ObjectiveC++?

ps: désolé, c'est très mal argumenté, j'suis fatigué :)

Pareil, il est tard.

C'est pas spécialement XUL qui renforce la tendance à utiliser HTTP, c'est les webservices. L'idée c'est d'avoir un client relativement simple et standard (un navigateur web, éventuellement enrichi, par exemple) qui parle a un serveur relativement standard (un apache muni de PHP, toujours par exemple) pour n'avoir qu'à maintenir (ou faire maintenir par quelqu'un d'autre) que l'application elle-même, et pouvoir changer de fournisseur très simplement pour le reste.

Sauf si les webservices se développent davantage. Mozilla, par exemple, forme une plateforme très séduisante pour une entreprise : elle peut déployer une application métier relativement complexe (avec interface graphique dédiée et centralisation des données) aussi simplement qu'un site web (merci XUL).

Pour le moment, je vois deux obstacles majeurs : le manque d'information (qui fait que peu de décideurs ont percuté, et que peu d'informaticiens seraient capables d'être rapidement productifs en XUL) et la dépendance d'une telle solution à Moz/FF/TB. Une fois que XULRunner sera utilisable, le second obstacle ne devrait plus obstacler beaucoup.

Bien évidemment, le quidam lambda s'en balance sévèrement. Maintenant, s'il ne peut pas consulter son webmail ou ses horaires de train de manière optimale ("votre navigateur ne supporte pas les normes SOAP/XSLT/Xpath, pour profiter pleinement de notre applicatif, veuillez installer une version plus récente"), il va commencer à avoir envie de changer.

Effectivement, ce n'est pas pour tout de suite, mais d'ici une paire d'années on pourrait commencer à voir ce genre de choses.

Euh, oui, je pensais plus à un jeu totalement différent d'un point de vue technique, mais réutilisant l'univers (et éventuellement les graphismes) de Wesnoth. Modifier le jeu pour en faire son pendant temps-réel, je ne vois pas trop l'intérêt.

quelques noms d'utilisateurs experimentés que l'on rencontre sur le serveur : moi, dubhe, zzz, pikel, Somedeadguy, kaindi, Drazz(...), et j'en oublie sans doute.

En général, on dit "machin et moi", pas "moi et machin" :]

J'espère maintenant que ce super jeu pourra inspirer des devellopeurs (+ graphistes...) désirant faire un wargame en "temps réel" (et non au tour par tour) du genre warcraft3. Le "forker" (ou l'améliorer) pour remplacer le tour par tour par du "temps réel" (ou par le rendre possible) est un premier objectif assez réalisable.

Clairement, ça serait sympa (encore que, je ne sais pas ce que l'auteur en pense) de voir des jeux dérivés apparaître. Un jeu d'aventure, par exemple, ou un jeu de rôles. L'univers semble assez riche pour permettre ce genre de choses.

L'inconvénient majeur de Freenet est lié à la technologie employée (attention au troll): Java. C'est typiquement le genre de soft qu'on aimerait bien laisser en tâche de fond sur une machine aveugle (un vieux serveur dans un coin), mais la nécessité d'installer une machine virtuelle rend la chose plus périlleuse.

Une alternative séduisante est le projet Entropy (http://entropy.stop1984.com/),(...) qui reprend le principe de Freenet dans un logiciel codé en C. Il reprend également le protocole de communication avec le noyau de Freenet, de manière à pouvoir réutiliser les frontends de ce dernier. En outre, il propose une fonctionnalité de news directement dans son interface web.

Par contre, as-tu le MIDI qui marche ?

Si tu penses à du MIDI hardware, oublie: ça fait belle lurette qu'on ne trouve plus de synthétiseur sur la plupart des cartes sonores.

Pour du MIDI soft, je suppose qu'installer Timidity++ règlera le problème. En tous cas, sous Gentoo ça marche au poil.

J'ai moi-même foutu une Gentoo sur ce genre de portable, et ça n'est effectivement pas de la tarte. Il est vrai qu'à part la carte vidéo qui demande un peu de bidouillage, le reste marche à peu près tout seul (sauf peut-être les fonctionnalités liées à l'ACPI).

Ceci étant dit, tu sembles te réjouir de l'ouverture des sources par VIA, et c'est effectivement une bonne nouvelle. Cependant, il est important de garder à l'esprit qu'il ne s'agit-là que d'un premier pas, et que les mauvaises habitudes de VIA concernant l'OpenSource ne sont pas (encore?) lettre morte.

Pour ce qui nous concerne - les drivers Unichrome - on gardera à l'esprit que les drivers libres sont largement plus utilisables que ceux ouverts récemment par VIA. En outre, il semble que VIA n'ait pas encore abandonné son entreprise de fork de logiciels libres pour y ajouter des extensions perso (je pense aux versions VIA de mplayer et de xine). Un jour, on devrait leur expliquer que c'est tout aussi efficace (largement plus, en fait) de transmettre leurs patchs aux équipes concernées plutôt que d'obliger les utilisateurs à choisir entre le support matériel et les dernières fonctionnalités.

Je ne vois pas le problème éthique dans le cas des doubles licences. Le choix est clairement posé: soit tu fais du libre (fut-il interne et non diffusé), et auquel cas tu as accès au sources selon les termes d'une licence libre (dans le cas de QT et de MySQL, c'est en plus offert gracieusement). Soit, pour des raisons qui t'appartiennent et qui sont certainement très honorables, tu désires produire un logiciel sous une licence non-libre, et auquel cas tu l'obtiens également sous une licence non-libre.

Je trouve qu'au contraire c'est une très jolie démonstration de la liberté du libre (!) : on a même la liberté de ne pas être libre :)

L'intérêt majeur du portage de KDE, c'est le portage des _applications_ de KDE. L'environnement, il n'intéressera au mieux que les adeptes du tuning à la LiteStep (si tant est qu'il fonctionne).

En revanche, pouvoir disposer de Kontact ou de KOffice sur l'ensemble des machines d'un parc, ça a un intérêt énorme, y compris pour le libre : ça permettra de mettre en place des solutions hétérogènes à base de KDE (ou de bouts de KDE pour ce qui est des machines Windows). Ça ne peut qu'améliorer la qualité globale de KDE.

Mais non il n'y a pas de solution simple, efficace, libre (gratuite au pire) et sans risque pour ecrire sur du NTFS avec Linx.

Je proteste, Captive correspond à tous tes critères:

* c'est simple. Ca ne nécessite pas de module noyau spécifique (juste FUSE, qui sert à d'autres choses très intéressantes comme EncFS). La simplicité d'installation varie selon les distributions, mais la mienne (gentoo) ne m'a pas franchement cassé les pieds. Même pas eu besoin de leur GUI à deux sous.

* c'est relativement efficace. La lecture via Captive est plus lente que la lecture native, certes. Mais l'écriture via Captive est utilisable, à la différence de l'écriture native. Donc bon...

* c'est gratuit (et largement libre). Le code qui charge le driver Microsoft est tout ce qu'il y a de plus libre. Le driver MS est chargé depuis ton installation de Windows, et donc ne te coûte rien. De toutes façons, vouloir écrire du NTFS avec un Linux, ça n'a de sens que si on a un Windows pas loin.

* rien n'est vraiment sans risque, mais comparé au support read-write du noyau, Captive est vraiment pépère.

Après, effectivement, quand ça marche pas ça énerve. La seule différence avec le support NTFS du noyal, c'est qu'on peut se démerder pour le faire marcher sans un être un linux-guru.

... du but de ton interdiction. Si tu cherches à empêcher que l'utilisateur lance "par erreur" le logiciel en double (une sorte d'anti-boulet, en somme), il est assez simple de créer un fichier de "lock" lorsque le programme est lancé, et de refuser de démarrer si le fichier est déjà présent (un tel fichier peut, par exemple, se créer dans ~/.tonprogramme/ ou dans /tmp). Le seul inconvénient de cette approche est qu'en cas de crash, il faut effacer manuellement le fichier-verrou.

Une bidouille permettant d'éviter l'effacement manuel : à la création du fichier verrou, ajouter dedans le PID du processus en cours. En cas de lancement d'une instance du programme, vérifier non seulement l'existence du fichier, mais aussi l'existence d'un processus de même PID que ce qui est indiqué dans le fichier.

Dans tous les cas, tout cela est faisable aussi bien en Perl (gtk ou pas), en Python, en C, en Bash, ...

Par contre, si tu cherches à éviter que l'utilisateur ne puisse parvenir à lancer deux instances du même programme, c'est plus difficile: il pourra toujours éditer ton code et désactiver le test. Pour ça, en dehors d'une solution hard à la palladium (et encore), je ne vois pas trop.

Ben en fait, c'est pas tant avec la langue de Shakespeare qu'avec le langage musical que j'ai du mal. En français, j'arrive encore à peu près à m'en sortir. Comprendre un texte anglais sur le sujet (au hasard, la doc de lilypond), c'est hard mais ça passe. Par contre, raconter mes problèmes de musique en anglais, ça passe pas du tout :)

Plus sérieusement, j'ai trouvé un hack immonde pour mes histoires de couplets, en insérant suffisamment de \skip au début des mes lignes de lyrics de manière à ce que le refrain soit "seul". Ça reste bien gruik.

La constatation de Nietzsche est justifiée : les trois grands monothéismes (et d'autres confessions, par ailleurs) sont très exigeants pour quiconque désire les embrasser scrupuleusement.

Là où cela devient plus discutable, c'est quand il en déduit que le but est de culpabiliser les foules. Car on peut également voir comme but le fait de vouloir tirer tout le monde vers le haut, et on ne tire pas les gens vers le haut en proposant un objectif atteignable par tout le monde (et à plus forte raison un objectif déjà atteint). Cet espèce de nivellement par le bas est certainement bon pour l'ego, mais pour l'expérience humaine on repassera.

Aux dernières nouvelles, M. R. Stallman serait responsable des dernières épidémies de MSBlaster et de Sasser. En effet, ce sinistre personnage aurait exhorté les utilisateurs d'ordinateurs à ne pas utiliser d'antivirus, alors qu'il s'agissait de la meilleure manière de se protéger de ces calamités.

M. Stallman n'a souhaité faire aucun commentaire, mais certains de ses plus fervents supporters prétendent que M. Stallman n'a jamais prôné le refus des antivirus, mais l'utilisation d'un obscur système d'exploitation ne nécessitant pas d'antivirus. Quand bien même ce serait vrai, il apparaîtra comme évident à quiconque n'est pas déjà contaminé par les idées rétrogrades de M. Stallman qu'une telle solution est inefficace, utopique et dépassée.

J'aime beaucoup la petite note qui tue:

Changes: This release has been ported to Java.

:)

... c'est qu'on tombe parfois sur des perles. Comme ce (manifeste) poisson d'avril made in ThinkGeek.

Enjoy.

http://www.thinkgeek.com/stuff/41/fundue.shtml(...)

et aussi dans le pacquet http://packages.gentoo.org/ebuilds/?mplayer-1.0_pre6-r2(...)(...) (y faut chercher :p)

Un indice? Parce que je trouve rien de vraiment suspect. Sauf peut-être que ce qui est prévu au niveau du renommage du flag "avi" n'a pas été fait, mais ça semble assez judicieux, vu que ce flag ne semble contrôler que l'installation des codecs binaires win32.

Enfin je vois pas. Vraiment. Au secours.

Comme l'an dernier, les gars de ScummVM donnent dans le poisson "oh ben dommage que ce soit pas vrai". Ils nous annonçaient alors un regroupement des compétences de ScummVM (émulateur de jeux Lucas) et de Sarien (émulateur de jeux Sierra). Cette fois-ci, c'est Dragon, un moteur de jeu compatible RenderWare, dédié au portage de Broken Sword 3.

La capture d'écran est, à première vue, particulièrement crédible: les bouts de code qui apparaissent semblent vraiment faits pour tromper le monde. Joli poisson, même si je préfère quand il y a un indice indiscutable de la piscivité latente de l'information.

Un FAI te fournit de la connectivité (un accès vers le reste d'Internet). Pour pouvoir le faire dans de bonnes conditions, il a besoin d'avoir lui même une connectivité importante. Deux moyens lui permettent d'y parvenir :

- il peut demander à un prestataire de lui en fournir. Auquel cas, il est dans la même situation vis-à-vis de ce prestataire que toi vis-à-vis de lui : un client, seules les chiffres sont différents (beaucoup plus cher, beaucoup plus de bande passante, pas du tout le même type de lien, etc.). Ce prestataire lui fournira, à priori, de la connectivité vers le "monde" tout entier. C'est, de mémoire, ce que l'on appelle une relation de "transit".

- l'autre solution, très prisée par les petits opérateurs qui réduisent ainsi leur ardoise, consiste en ce que l'on appelle le "peering". Le principe est le suivant: je suis un opérateur A, et dans un des centres ou je suis présent se trouvent également les machines d'un opérateur B. Les gens de chez B et moi-même décidons de mettre en place un lien privilégié, sur ce site, entre nos deux réseaux. Les deux routeurs concernés (le leur et le mien) ne laissant passer sur ce lien que le trafic dirigé vers le réseau d'en face. Ainsi, même si cela ne nous exempte pas d'un transit important, cela nous permet de faire passer tout le trafic entre nous par notre lien de "peering" (gratuit) plutôt que par le lien de "transit" (pas gratuit du tout et même très cher).

Seul difficulté : il faut négocier, car un gros opérateur n'a pas forcément intérêt à ce qu'un petit fasse un peering avec lui. L'argument numéro 1 de ces négociations, c'est l'intérêt du contenu de son réseau pour les gens du réseau d'en face. Dans le cas de Free, les pages perso (nombreuses et gratuites) ont été - fut un temps - d'un poids intéressant dans les négociations de peering avec les plus grands. L'idée étant "ok vous avez des tuyaux plus grands, et en nous donnant accès à votre réseau vous nous faites un beau cadeau, mais nos abonnés adorent notre réseau, si petit soit-il, et cela vous fera faire de grosses économies de mettre en place un lien privilégié entre nous".

Ce qu'on nomme plus haut "points de peering" correspond au poids d'un réseau donné dans des négociations de ce genre.

La GPL n'oblige pas en accepter les termes pour utiliser le logiciel.

Cool ça, c'est Sigma design et consorts qui vont être content.

Blague à part, la GPL ne se comporte pas différement des autres licences logicielles : elle définit un ensemble de règles qui régissent l'utilisation du logiciel (droit de l'exécuter ou pas, droit de l'ouvrir pour voir comment il est fait ou pas, ...). Utiliser le logiciel n'est "légalement" possible que si tu acceptes les termes de sa licence (ou d'un des licences disponibles, dans le cas d'un multiple licensing à la QT).

La différence entre la GPL et d'autres licences plus restrictives, elle tient au fait que d'une part la GPL n'impose rien de particulier pour l'utilisation ("l'exécution") du logiciel, ce qui rend l'acceptation de la licence triviale. D'autre part, là ou d'autres licences interdisent explicitement la modification du logiciel, la GPL l'autorise à certaines conditions. Pour cette utilisation, l'acceptation de la GPL demande donc un peu plus de reflexion. Mais ça ne signifie aucunement qu'une utilisation "simple" ne nécessite pas d'accepter la GPL.

Par exemple, Gaim me semble plus abouti que Kopete.

Mmmh, je n'ai pas dû utiliser Gaim depuis longtemps alors (et pourtant je ne jurais encore que par lui il y a une paire de mois). Parce que Kopete, au moins sur KDE3.3 (à plus forte raison en 3.4) lui tient la dragée haute. Je pense notamment au "browsing" des fonctionnalités Jabber, qui m'ont toujours terriblement manqué dans Gaim.

Qui plus est, vouloir faire un bureau KDE avec Gaim comme IM, ça serait limite balot, vu comme Kopete est bien intégré au reste de KDE (Kontact, tout ça).