gpe a écrit 799 commentaires

Et pour le téléchargement des pack de mise à jour : rien n'empêche d'utiliser un LiveCD Linux sur la machine à installer ;-)

Comment fais-tu avec un LiveCD pour faire un WindowsUpdate?

> En gros c'est l'inverse de la philosophie d'Empathy, non?
Je comprends pas vraiment.

Je faisais allusion au message de cassidy à 12h02:

Sinon ce que je ne sais pas faire avec gnome autrement qu'avec jpilot c'est partager les données de mon vieux palm 3 avec sylpheed, etc.

Un truc qui m'énerve profondément c'est que par exemple quand tu ouvres le calendrier de l'applet horloge de Gnome et que tu double cliques sur une date et bien il commence à te lancer Evolution et te demande de configurer ta messagerie!!! C'est quoi le rapport avec le fait de cliquer sur date????

mouais...
EDS c'est : "The data server, called "Evolution Data Server" is responsible for managing mail, calendar, addressbook, tasks and memo information."

ça fait pas un peu trop pour un seul homme? En gros c'est l'inverse de la philosophie d'Empathy, non?

Pimlico et Soylent ne font pas parti de Gnome, non? En tout cas je ne les ai pas chez moi...

Bref je cherche toujours l'équivalent de Kontact et de l'ex Gnome-pim...

Actuellement j'utilise jpilot car Sylpheed sait s'interfacer dessus.

Oui tu as peut-être raison au niveau cups ça se limite peut-être au ppd, mais au niveau global un ppd ne suffit pas. Je ne maîtrise pas assez les différentes parties constituantes d'un pilote entre cups et le reste, mais par exemple pour les imprimantes HP il faut cups, hplip, hpijs. Et pour la HP B9180 il y a des problèmes de licence qui fait que l'on a pas de pilote pour cette imprimante sous Linux. Je me disais donc qu'avec cette exception de licence ça permettait de faire le pilote mais en proprio. Mais tu as sûrement la partie qui devrait être proprio dans ce cas doit plutôt être dans hplip/hpijs que dans cups?

On n'aura pas non plus tout ce qu'Apple et autres développeront initialement pour MacOS mais qui pourraît être porté sur d'autres plateformes si le code était ouvert. En gros, ce qui est le plus intéressant, les pilotes eux-mêmes, non?

Tant mieux, parce que le système est vraiment beaucoup plus réactif avec ce scheduler (même par rapport à SD, que j'utilisais jusqu'à présent mais maintenant que -ck n'est plus maintenu il faut bien se mettre à jour) !

Déjà que je trouve un Linux normal (2.6.18) bien plus réactif et fluide qu'un Windows XP alors avec CFS...

mea culpa. Gthumb utilise libopenraw pour la génération des miniatures et dcraw pour l'affichage ensuite. Mais je ne pense pas que gthumb s'oriente vers du développement de raw, je pense qu'il se cantonnera à de la visualisation.

ok je comprends mieux. En fait c'est la surcouche ufraw par rapport à dcraw que tu voudrais en lib pas uniquement son c½ur qui fonctionnellement est identique à dcraw.

- la librairie OpenRaw, le jour où elle commencera à faire plus qu'extraire les miniatures...

C'est la voie choisie par Gthumb il me semble, non?

Pour le futur, il y a d'autres alternatives possibles à dcraw :

- le core de UFraw, si un jour il est exporté en tant que libraire.

Là je ne comprends pas trop vu qu'UFraw est basé sur dcraw?

Vi à 31 ans, Vim 16 ans, GNU Emacs 23 ans, ...

Moi ce qui me gêne dans les IDE c'est que chacun réinvente son propre éditeur de texte alors qu'il y en a déjà pléthore et que bien souvent ils sont moins bon que ceux déjà existant.
Pour le reste ils s'appuient sur des éléments déjà existant mais pas pour cet élément majeur qu'est l'éditeur, pourquoi?
Bref je ne suis pas prêt d'échanger mon baril de vim contre 2 barils d'Anjuta ou Eclipse ou autre.

- Les données ne sont pas libres

Dans ce cas 2 paquets.

- Les données ne dépendent pas d'une archi comme les binaires

Un paquet n'est pas obligatoirement dépendant d'une archi

vous entendez quoi par telecom?
Si je suis électronicien chez FT faut mettre électronicien ou telecom?
C'est qu'en même bizarre de mélanger métier et secteur d'activité!

Ah ok! Je croyais que c'était un paquet Debian également, je n'avais pas compris que c'était à installer à la main.
Question idiote: pourquoi ne pas tout mettre dans le paquet Debian?

et on le trouve où ce paquet?

Il n'y aurait pas un problème avec le paquet Debian?
Il ne fait que 840Kio et ne contient donc presque rien...

+1 pour Silent Service sur Atari ST!!!
C'était fin années 80, début années 90.

Ah ouais Silent Service, toute ma jeunesse! J'ai passé des journées entières à y jouer sur Atari ST au lieu de réviser mon bac (argh!).
Faut que je teste Danger from the Deep ça m'a l'air pas mal!

Certes, mais cette population qui s'amuse à se compiler un noyau en avance de phase est réduite. Surtout que si j'ai bien compris le passage d'un 2.6.18 à un 2.6.21 ou 22 peut poser quelques soucis, il y a eu pas mal de changement à partir du 2.6.19, non?

Perso, ça doit faire cinq ans que je n'ai pas compilé un noyau (depuis que je suis passé en Debian) et que je ne suis pas prêt à m'y remettre parce que je n'en vois pas l'intérêt, parce que je n'ai pas le temps, parce que quand j'ai du temps je préfère le passer à autre chose, etc.
N'étant pas non plus décidé à abandonner ma Debian pour une Fedora 7, j'attends donc sans impatience particulière que qu'un noyau compatible PowerTOP arrive dans Debian testing.

Tout ceci explique à mon avis le faible nombre de retour sur PowerTOP et qu'il ne faut pas s'en étonner.

Un petite déception : très peut d'utilisateurs témoignent des problèmes qu'ils rencontrent (pourtant Arjan est très newbie friendly. Franchement) et n'indiquent pas leurs découvertes d'applications ou modules noyau les plus gourmands (condition sine qua non pour que le problème soit corrigé). À moins que les utilisateurs de PowerTOP soient tout simplement très peu nombreux.

Les utilisateurs doivent-être assez peu niombreux car des distri qui soient en 2.6.21 ça ne coure pas les rues, non?
Perso je suis en 2.6.18, donc PowerTop je l'essaierai le jour ou ma distri passera en 2.6.21.

A peine plus gourmand que Xfce? Faudrait pas pousser quand même. Dans ce cas on peut aussi dire que Gnome consomme à peine plus que Kde et par conséquent à peine plus que xfce!
La réalité est que Kde est à mi-chemin entre Gnome et Xfce.

Bien sûr je suis d'accord mais ce que je voulais dire c'est que la communauté n'a pas le monopole du développement des drivers et que si une entreprise développe elle-même les drivers en sources libres et en fournissant les specs de son matériel, c'est quand même mieux que si elle ne fournit que les specs, non?
Parce que les specs c'est bien joli mais en général ça ne dit pas tout et bien souvent sans le support du fabricant tu peux galérer longtemps (je parle d'expérience, c'est mon boulot).

Contrairement aux dépêches sur Gnome où il y a toujours un kdeiste pour venir troller, dans cette dépêche sur kde aucun gnomiste ne vient troller. Décidément Gnome est vraiment supérieur à Kde! ;-))))

Ok je sors, bon week-end!

Si les drivers sont en sources ouvertes, pourquoi la communauté n'en voudrait pas?