manatlan a écrit 1590 commentaires

sudo apt-get update
sudo apt-get upgrade

C'est "pas faux" ...
ça va mettre à mal l'ora de la distrib, ça c'est certain ...

Pour relativiser, autant ce prob que le précédent, ne concerne que "très peu" de monde ... les ubuntiens avec des nvidia et les drivers proprios qui ont upgradé dans le laps de temps où les repository officiels étaient buggués ...(8h le premier et 5h celui-là, je crois)

Après, parmis ces gens là, ils y a certes des newbies qui ne se retrouvent qu'avec leurs yeux pour pleurer, et qui seront deg (j'imagine pas le gars qui a eu les 2 ;-( ).
Les autres, plus experimentés, s'en sortiront, en downgradant sur le précédent.
(moi même, j'ai eu le malheur de tomber dans la mauvaise tranche, et j'ai du faire pas mal de console pour m'en sortir ... ça faisait un bail que j'avais plus taté du tty )

C'est d'autant plus bête, que ça fait 2x en 3 semaines, sur une distrib censée être ultra stable ;-( ... alors qu'il n'y a jamais eu ce genre de prob sur les précédentes.
C'est assez grave quand même, et ça va faire du tord à ubu ... ça craint

A la première bourde, je m'étais dit qu'au moins "ça leur servira de leçon", et je pensais sincèrerement qu'ils ne pourraient plus jamais refaire ce genre de bourde.

Après tout, c'est du libre, du gpl, on est libre ou non de l'utiliser ...

Mais je reste un ubunteros convaincu ... et je me dis encore, que là, maintenant c'est sure : ils ne feront plus jamais ce genre de bourde ! MS (mark) va crier un bon coup ;-)

NON !
si tu parles des clés
- browser.cache.memory.capacity (a creer)
- browser.sessionhistory.max_total_viewers
tu règles vraiment pas grand chose ... même avec une capacity à 2048 et un max_total_viewers à 0 ...

Firefox prends au minimum (completement vide) 200 mo ...

Là, je suis sous windows ;-( ... et a côté j'ai un "VisualStudio2005 team system" ((la grosse artillerie) beurrkk), avec une grosse solution (50 projets), en mode debug, avec plein de fichiers ouverts : ça prends 180mo ...
(sous windows c'est vraiment génant ! sous linux, ça va, car le cache système est mieux géré)

Firefox prends énormément de mémoire, et c'est vraiment un problème

tout est là : http://pyjamas.pyworks.org/

C'est le port de GWT (google web toolkit) en python ! ça avance assez vite, et ça reprends toute l'infrastruture GWT ... Du ajax de haut vol, avec des container et tout qui va bien ...

C'est evidemment du GPL ...
Mais je ne crois pas que ça soit déjà très utilisable ...

Excellente question !
et si c'est le cas, comment redemmarera t on les gdm, ssh et autres mpd ?

Voilà une config de base (certes orienté dev python ;-)
http://www.bigbold.com/snippets/user/manatlan/tag/scite

charles bronson est mort ?

pas de plugin pour imageshack ...
mais ça ne devrait vraiment pas être complexe à implémenter
(cependant j'en voit pas trop l'intérêt)

Le contour rouge s'affiche quand la photo ne contient pas d'exif, et je crois que c'est un champ date que j'utilise pour determiner si l'exif est présent ou non ...

la réponse se trouve à partir de ce post, sur les forums ubu-fr

http://forum.ubuntu-fr.org/viewtopic.php?pid=438744#p438744

pour reinstaller les 2 packages fautifs du dépot officiel :

sudo apt-get install --reinstall libvte4/dapper libvte-common/dapper

et tout rentre dans l'ordre

> dans le genre, je demande pourquoi celui qui package
> a laisser passer un truc pareil ... a croire qu'il a compilé
> et packagé dans la foulée, sans passer par la case test
> et validation ...

euhhh ... ceux qui packagent tout ça, permettent, avant tout, d'installer et de profiter simplement d'XGL/Compiz et de ses évolutions ultra rapide ! (encore un énorme merci à ces gars/héros !!!!)
Ceux qui utilisent ces dépots sont censés savoir que tout ça est en developpement intensif ! (d'ailleurs ça se voit : il n'y a pas un jour sans update depuis qques mois ;-)

non le stylo optique fait mal au bras ... (TO7 powaaaa)
le plus sympa, ce serait avec un gun optique, en visant, confortablement installé dans son fauteuil

> on dépends d'une entreprise.

certes, mais ça garantie aussi la continuité de services, et l'accès worldwild, et l'unicité d'un compte ...

mais pareil, je n'utilise pas encore mon compte gmail/jabber comme compte principal ... ;-)

> Il n'est pas possible d'utiliser de passerelles,

?!? alors c'est depuis peu ...

je te garantie, qu'il y a 2 mois, j'ai configurer qques comptes jabber/gmail, avec des passerelles sur icq/msn (avec un client comme psi, pas le client officiel bien evidemment)... sans prob ! et ils fonctionnent toujours !

moi j'y passerai bien totallement, mais un truc m'agace plus que tout, c'est les messages offline, qui sont gérés dans les mails ;-(

la soluce pour toi, ne serait ce pas de migrer définitivement vers un compte jabber sur gmail ?
je pense que c'est bien centraliser cette chose là, et tu ne devrai peut être pas avoir des probs de latence
de plus c une adresse que tu peux garder à vie ....

t'en veux une ?

pertinent ...
tu m'as fait découvrir kazehakase ;-)
déjà, c'est celui qui se lance le plus vite
ensuite, il possède le minimum syndical au niveau du réglage des onglets, de la navig a la souris, au clavier ...
du coup, il est bien placé entre firefox et epiphany/galeon (qui sont vraiment trop light niveau config) ...
Je garde !

(j'en reviens pas comme il se lance vite ?! (ça rappelle IE sous win))

il fallait lire :

exemple :
<tag>ursula</tag>
à transformer en
<tag key="u">ursula</tag>

sinon, dans le svn, il affiche maintenant à coté des tags (dans le treeview), la touche de raccourci ....

et comme je suis fou, je viens de l'implémenter rapidement dans le SVN de jbrout ...

il suffit d'associer une touche à un tag, dans le fichier ".jbrout/tags.xml"

exemple :
ursula
à transformer en
ursula

ainsi, dans jbrout, on selectionne plusieurs photos, et on appui sur "u", et ça mettre le tag ursula sur les photos selected

evidemment, pour l'instant c light (et il faudra une interface de gestion/association)
ça ne doit prendre que les touches ascii, je pense ...

mais ça reponds déjà à 95% de la problématique ...

Le taggage via checkbox dans le treeview, je comptais le mettre en mode fullscreen (mais ça tarde ;-). Car sur qques photos, c plus pratique de voir en grand et de pouvoir taguer (photo de groupe, par exemple)

quant à ma manière de tagguer, je fais clairement les 2 ...
- soit je selectionne qques photos, puis y d'n'd les tags
- soit je selectionne plusieurs tags, puis d'n'd sur une photo
et il m'arrive fréquemment de selectionner plusieurs photos, et y d'n'd plusieurs tags en une fois ...

non tout ça est bien pensé pour aller au plus vite ...

le coup de touches pour les tags, ça me plait bien ... car effetivement, sur 70% de mes photos, j'ai qques tags qui reviennent très souvent (ma fille, ma copinne, par ex.), et du coup, ça pourrait carrément le faire !

tel que c'est fait actuellement ...
il y a un XML par user ... ( dans son home)
Jbrout n'est pas particulèrement développer pour le multi-user. Mais les xml se mettront à jour, dès qu'une opération est réalisée sur une photo, ou qu'un refresh est initié sur un album.
Dans tous les cas, il n'y a pas de risque de compromettre ses données.

Pour le tagguage, c'est uniquement au drag'n'drop (je ne vois pas de façon plus simple ?!)
de plus, dans jbrout, la multi-selection, que ce soit des tags ou des photos, peut être faites en cliquant avec la molette (héritage du superbe rox-filer) ... (pas obliger d'utiliser shift/control)
du coup, tu peux tagguer tes photos très rapidement, en buvant même une kro dans l'autre main !

> En tout cas l'extension nautilus j'attends ça avec impatience !!

je n'ai pas dit que j'allais le faire ... je n'ai pas assez le niveau pour rentrer dans gnome ... désolé

reponse à golum et noname, d'une pierre de coup.

C'est des points de vue qui méritent d'exister.

Il est evident qu'on ne peut pas tout mettre dans iptc ou xmp (quoique techniquement xmp, qui est du xml, permet de mettre tout et n'importe quoi, là où IPTC a sa structure figé). Si un prog doit garder des caractéristiques d'affichage d'une image, là oui : c'est une info perso, il doit la stocker en base, et non dans la photo.
Si c'est un tag, un commentaire : il faut le mettre dans la photo !
On est d'accord ...

Mais le temps d'essayer (et d'avoir les moyens) de normaliser cette BDD, on sera plus là ;-) ... (iptc a au moins 10ans, et xmp : 4 ans)
Ce n'est de loin pas la meilleure soluce. Le top serait le filesystem pour moi.
(J'ai déjà tenter de transformer jbrout en une extension nautilus, mais je n'ai pas plus pousser (mais ça doit être faisable), avec inotify et cie)

Si j'ai développé jbrout, ce n'est pas pour en faire un programme qui va perdurer toujours, ou devenir la référence ... c'est uniquement pour pouvoir gerer mes photos en tentant de respecter le peu de standards, en attendant mieux ...
Dès qu'un programme fait plus que jbrout, et respecte des standards qui me vont, je n'aurai aucun prob à basculer dessus...

Et je ne desespere pas voir un jour nautilus utiliser les tags IPTC des clichés pour nourrir ses métadonnées ...

La base de données a énormément d'inconvénients. (si tu déplace/supprime/renomme des fichiers, en dehors de ton programme, tu peux mettre à mal ta bdd, ton programme, ....)
Tout en sachant qu'actuellement, et encore pour longtemps, ces bdds ne sont pas encore compatibles inter-programmes...
Tout ça pour moi, pour l'heure, est plus que redhibitoire !
(maintenant chaque prog peut incorporer un plugin d'export vers une autre bdd, certains ont déjà commencé je crois savoir)

Jbrout fait un peu les deux, le filesystem et son xml ...(et possede un export qui tue les tags iptc ;-) )
détruire le XML n'est pas grave, il peut le reconstruire from scratch (tout étant dans le FS) ... déplacer des photos/répertoires d'un autre programme ... pareil, rien n'est perdu, faut juste raffraichir ...
Mais comme dit, jbrout ne gère pas grand chose (le minimum syndical à mes yeux), à part les dates exif, les tag iptc, les comment jpeg ... rien que des infos qui ont leur place DANS la photo...

Tout le problème est là. Il existe des "standards" ... il y a IPTC et XMP .
Ces 2 systèmes sont en concurrence, et stocke les infos dans les photos. IPTC est assez vieux, et pas mal utilisé ... et XMP, c'est iptc en xml dans la photo (soutenu pas adobe).
Parmi les logiciels que tu cites, le seul qui tague en tentant d'utiliser un standard nativement est jbrout, avec l'iptc ;-). ça commence à peine à venir dans les autres.
Faire un standard pour les BDD n'est pas la solution, sachant que l'info DOIT etre stocké DANS la photo ! Maintenant, il faut choisir IPTC ou XMP.
Jbrout fait de l'iptc, car c'est les seuls api que j'avais pour ça ;-)
Si on me donne des bindings python sur XMP, moi je les intègre vite fait dans jbrout, et je gère les 2 ;-)

Pour l'anecdote, avant d'avoir les bindings python sur iptc, je stockais déjà les tags dans la photos, dans les "jpeg comment", avec les version 0.1.X ... et avec la version 0.2.x, j'avais ecrit une procédure de migration des tags du jpegcomment vers keywords/iptc ...
si xmp s'impose, j'aurai aucun prob à faire migrer de iptc à xmp

Aussitôt dit, aussitôt fait ... me voilà ;-)
merci pour la pub, et le commentaire ...

Cependant, le screenshot est un peu vieux, et ne correspond pas tout à fait à la version actuelle ... voilà un plus récent : http://jbrout.free.fr/gfx/capture.jpg
(le listview des thumbnails est plus moderne, merci fred)

pour compléter:
Jbrout stocke effectivement les tags dans les tags keywords/IPTC ... les commentaires dans le "jpeg comment" (plus utilisé que la description iptc) ... la rotation est lossless grace à jpegtran.
Jbrout utilise le filesystem comme espace de stockage. Un album est un répertoire, et par conséquent un album peut contenir des sous albums. Les commentaires sur les albums sont stockés dans un fichier txt à la racine du repertoire.
Jbrout n'utilise donc pas de BDD, et stocke donc les infos dans les photos/répertoires (garantissant la perennité des saisies), dans le filesystem. Mais gère à côté un fichier XML uniquement pour pouvoir faire des recherches très rapides ! Je vais bientôt dépasser les 40000 photos, et ça bronche pas encore ...
et jbrout possède un système de plugins, qui permettent d'exporter ses photos (generer une gallery html, exporter/redimensionner pour de futurs transfert, ou carrément faire office de serveur web d'appoint pour vite présenter ses photos à un tiers)

Comme dit bibinsa, c'est également en python, et donc portable (quoique la version win, je ne la package plus trop, car je ne boot plus dessous ;-). Jadis, c'était en python + wxpython, mais ça posait pas mal de problème de portabilité win/linux dès que je tentais de sortir des sentiers battus. Maintenant, depuis la série 0.2.X, c'est du pygtk, et donc, ça fonctionne à l'identique qqsoit la plateforme. (mais je perds la plateforme mac, sans x11)

Par contre, tous les devs pythons sont les bienvenus dans jbrout ;-)

et faut noter qu'il a fait des efforts ... il n'a pas mis que l'url ;-)