Matthieu Moy a écrit 3255 commentaires

Digikam a un truc pour le batch resizing si on veut faire ça dans un clikodrome. De mémoire, c'est un plugin KIPI, donc ça doit être dispo aussi dans Kphotoalbum.

> Dans tous les cas, .f-spot est généralement dans $HOME et c'est ce qu'on
> sauvegarde/ne formate pas même si on réinstalle from scratch, non ?

Quand on fait les choses proprement, oui, mais quand on fait des backups à coups de

$ cp ~/* /media/backup

(ou son équivalent avec l'interface graphique de ton choix), les fichiers cachés ne sont pas sauvegardés. C'est bête, mais j'ai eu le problème avec un débutant, qui n'arrivait même pas à sauvegarder son ~/.mozilla/ avec K3B.

> Le passage par gimp ne sert quasiment plus qu'a redécouper l'image rectangulaire ensuite.

Ça dépends. Si les images se recolent mal (typiquement, un mec qui est passé devant au mauvais moment et qui apparait coupé en deux par défaut), un passage par Gimp peut sauver la mise : à coup de selection, floutage de selection, et découpage, on choisit facilement la zone de transition entre les photos.

> Ah et les DRM c'est du poulet?

Tu es conscient quand même que si on abolit la propriété intellectuelle, on légalise de fait les DRM ?

> Il a fait rembourser 49.90¤ qu'il croit être les frais d'installation des logiciels, se basant pour cela sur les frais d'installation facturés par Surcouf quand ils installent manuellement Windows.

Ça ne me parait pas totalement abérent : Acer ne donne pas le prix des composants du « pack » (ordinateur + logiciel + installation), donc le juge prend le pire cas.

C'est clair que ça n'a pas coûté 50¤ à Acer de faire l'installation, mais tant qu'à faire une erreur d'estimation, je trouve pas ça anormal qu'elle soit en faveur du plaignant.

Grande en toi est la force, petit scarabé. Mais ta formation n'est pas achevée ...

http://linuxfr.org/~psychoslave__/25337.html

Bah, c'est simple :

Si je te demande de faire un programme de calcul du PGCD en C, tu préfères :

1) écrire le programme

2) faire tourner un programme qui génère tous les programmes C, et appuyer sur Entrée quand tu as trouvé le bon

?

(sérieux, j'espère que ce journal est au 2ème degré ...)

Je me permet de supposer que l'ensemble de ce journal est à prendre au 2ème degré, mais je vais quand même répondre.

> De toute manière, comme je l'ai précisé, je ne compte pas partir sur des fichiers textes, mais binaire.

Ce qui montre bien que tu n'as rien compris à mon calcul, puisque justement, je parle de binaire. Avec du texte, comme précisé plus bas, tu pourras peut-être monter à quelques mots, mais certainement pas à un truc suffisament non-trivial pour être copyrightable.

> À partir de combien de bits peut on consédérer un nombre comme non trivial?

Alors, on va prendre un exemple simple. Suppose que quelqu'un pose sa main sur ta joue. C'est une caresse, c'est gentil. Suppose maintenant que quelqu'un lance sa main de toutes ses forces sur ta joue, et t'envoie à l'hopital sous la force du choc. C'est un coup, c'est répréhensible par la loi.

À partir de quelle vitesse de la main considère-t-on que le geste est un coup ?

Ah, tiens, une limite arbitraire, un truc laissé à l'appréciation du juge. Bah oui, c'est comme ça un peu partout en droit, pas juste en propriété intellectuelle.

Allez, si tu trouves des thunes, tu auras 1000To de stockage.

Tu auras généré tous les fichiers possibles de taille <6 octets. Si la loi de Moore continue, d'ici quelques dizaines d'années, tu auras généré toutes les possibilités de textes de 10, voire 11 caractères, qui sait. Si on continue comme aujourd'hui, on gagne près d'un bit tous les 18 mois !!

Tiens, justement, c'est le genre de textes sur lesquels le copyright ne s'applique pas, car considérés comme trop triviaux.

(6 octets = 48 bits, soit 2^48 possibilités, donc, 48*2^48 bits de taille de stoquage, ce qui fait environ 1600To)

Maintenant, tu as deux choix : attendre que la taille des disques te permette de stoquer tous les programmes de taille 1Go, et alors faire un procès à Microsoft pour plagiat, ou alors chercher une faille dans ton raisonnement.

La seconde solution pourra porter ses fruits plus rapidement.

Je suis bien d'accord avec toi, mais avec kmail/korganizer, en IMAP simple, perte de données, en cached IMAP, ça marche.

Si j'ai bien compris, korganizer va simplement chercher les fichiers directement dans le cache IMAP de kmail.

http://lists.kde.org/?l=kde-pim&m=117503451925618&w=(...)

La solution sur IMAP (Cached IMAP) marche a peu près. Ça merdoie des fois (de temps en temps, j'ajoute un truc au calendrier, il m'averti d'un conflit entre cet événement et lui-même, et quoi que je fasse, il recommence en boucle. Ensuite, quand je tue korganizer et kmail, et que je les relance, j'ai n copies de l'événement, correspondant aux n fois ou j'ai accepté une résolution de conflit dans la boucle par exemple), mais sur cette solution particulière, j'ai jamais eu de perte de donnée.

Je suis assez déçu, parce que je pense que mon cas est déséspérément classique (besoin de synchro entre deux machines, pas trop de possibilité d'installer un serveur dédié), et j'ai eu besoin de passer par deux cas de perte de données silencieuse pour arriver à un truc valable. La tentation de passer du côté obscure à Google calendar est grande.

Attention, avec korganizer, aux dernières nouvelles, si deux instances essayent d'accèder au même fichier distant, tu peux perdre ton calendrier purement et simplement. Ça m'est déjà arrivé deux fois, oublié de fermer mon korganizer du boulot, j'arrive chez moi, il télécharge en sftp, hop hop, et oh, un calendrier vide !

Je suppose que quand tu passes de 1 à 1, c'est une augmentation de 100% ?
Et quand tu passes de 1 à 0, c'est une augmentation de 0% !

Avec Korganizer, tu as une option pour stoquer les infos sur un serveur IMAP, et te créant un compte dans Kmail, de type "cached IMAP". Mais c'est pas hyper bien fait à mon gout. Par exemple, si tu met IMAP tout court, il ne râle pas, mais il perd des données. Quand j'ai signalé ça sur la mailing-list, en gros, la réponse était « Ah bah oui, bien sûr que tu vas perdre des données, c'est pas fait pour. Fallait prendre cached imap ».

http://gcc.gnu.org/gcc-3.2/c++-abi.html

The main point of the GCC 3.2 release is to have a relatively stable and common C++ ABI for GNU/Linux and BSD usage, following the documentation at http://www.codesourcery.com/cxx-abi/

Oui, je connais. Mais honnetement, comparer ça au mode plan de word, c'est méchant pour Word. Le mode plan, c'est un vrai mode d'édition (du temps où j'utilisais word, je l'utilisait pour toute la rédaction, et je passais en mode page au moment du fignolage principalement), tu tappes du texte, titres, paragraphes, ... après, tu peux avoir le plan des titres, afficher ou masquer certains titres ou paragraphes, afficher la première ligne de chaque paragraphe, ... (en encore, je ne connais que ce qui se faisait dans Word 97, je suppose que ça a encore pas mal évolué depuis).

Le navigateur, c'est bien aussi, mais ça remplace pas.

Je ne sais pas ce qu'il en est avec GCC 4, mais en tous cas, GCC 3.2 devait avoir une ABI stable, et tout et tout, et ça n'a pas duré bien longtemps.

Même avant, je crois ;-).

Malheureusement, ça n'est pas si surprenant. L'équipe d'OOo est réduite, et le code est parfaitement imbitable ce qui rends les contributions extérieures difficiles. Du coup, malheureusement, ça n'est pas la seule fonctionalité que les gens demandent depuis des années et qui n'ai pas encore vu le jour. Il y a au moins le mode plan (il y a le navigateur dans OOo, mais le mode plan à la word, c'est aussi un mode d'édition) que beaucoup de gens considèrent comme le point bloquant pour la migration, et qui n'intéresse pas plus que ça les développeurs.

Si une distribution Linux était à la place de Windows (i.e. en position de quasi-monopole, ce qui n'est pas près d'arriver vu qu'il y a une concurrence relativement équilibrée entre les distributions), et si un environnement de bureau concurrent s'estimait laisé, je pense qu'on pourrait avoir le même genre de procès, oui. Mais ça fait beaucoup de si.

(D'ailleurs, est-ce que Kubuntu n'est pas juste une prévision de Canonical pour éviter de se prendre un procès le jour où ubuntu aura 95% de parts de marché ? ;-) ).

Ça dépends du langage. En C, l'ABI est relativement stable, pas de problème au changement de compilo. En C++, l'ABI change assez régulièrement, une applie compilée avec une version de g++ de pourra pas forcément linker avec une bibliothèque compilée avec une version plus ancienne (de mémoire, il y a eu cassage d'ABI C++ avec gcc 4.0, 3.2, 3.1 et 3.0 au moins).

Ça, c'est parce que vous n'avez pas vu la cité des enfants perdus.

Le coup de la souris avec un aimant au bout de la queue, et du fromage rapé, c'était quand même un peu plus original que de passer par la fenêtre ...

> Monotone a une approche originale. [...] une version peut avoir plusieurs filles.

Oui, mais c'est ce que font la plupart des gestionnaires de versions actuels (enfin, sauf si on considère Subversion comme un gestionnaire de versions :-P ). bzr, hg, git au moins sont basés sur le même principe.

On pourrait disserter des heures là dessus, mais GNU Arch n'est pas « décentralisé » dans le même sens que les autres (git/bzr/hg/mtn/...) : Avec par exemple git, quand je fais "git clone git://kernel.org/l/archive/de/linus/", je me retrouve avec quelque chose qui est techniquement équivalent à la branche de Linus, mais sur mon ordinateur. Ce n'est pas « une branche de ... », c'est vraiment le même. D'ailleurs, si je suis hyper intelligent, si ça se trouve, un jour, les gens trouveront que c'est ma branche qui doit être la référence, et celle de Linus qui est un clone de la mienne.

Avec GNU Arch, on distingue deux choses :

* La notion de mirroir. Oui, je peux faire un mirroir d'une archive, mais ce n'est pas quelque chose d'équivalent : le mirroir est read-only, je ne peux pas commiter dessus.

* La notion de "tag" (ou branche, en fait). Je peux dire "ma branche est le successeur de la branche officielle", et là, je peux commiter. Mais c'est ma branche. Elle a une identité différente, ...

Avec les autres systèmes, les deux notions sont confondues. Ça a l'air subtil, mais c'est une différence pas négligeable. Par exemple, avec git, si je parle de la revision 2ab504fe, je peux avoir cette révision, peut-être que quelqu'un d'autre l'aura aussi dans son archive, ... Avec GNU Arch, si je parle de la revision Matthieu.Moy@imag.fr--arch/xxx--yyy--zzz--patch-42, c'est une révision qui est dans mon archive et dans celle de personne d'autre.

Oui, mais pour moi, le fait de pouvoir être sûr de revenir exactement dans le même état plus tard, et de pouvoir parler de cet état avec d'autres gens, ça devrait être la norme, pas l'exception.