snotling0 a écrit 65 commentaires

Si on met le critère de prix en n°1, quelqu'un connaît d'autres matériels grand public vraiment pas chers qui fonctionnent sous Linux ?

Moi j'ai juste besoin d'un CPU de base, de quoi avoir un peu de stockage (Flash) et une connectivité USB et Ethernet. Pas de vidéo, d'audio, etc.

Bref, du genre du NSLU2 mais en peut-être un peu plus récent :-)

A moins que je m'oriente vers une "Neufbox 4 open source", ce qui aurait l'avantage de ne pas rajouter de matériel laissé branché en permanence...

C'est intéressant comme projet.
Ca me fait penser que faudrait que je m'attaque aux bibliothèques associatives, bien que peu d'entre elles doivent avoir une 'visibilité' sur le Net (catalogue en ligne).

Euh, d'après ce que j'ai compris, le CCFr est la combinaison de :
1. catalogue de la Bibliothèque nationale de France
2. catalogue des bibliothèques universitaires (SUDOC)
3. catalogue de fonds 'particuliers' de certaines bibliothèques municipales

Donc c'est pas vraiment équivalent à mon service, qui est notamment destiné avant tout aux ouvrages 'habituels', que l'on peut emprunter en particulier.

Ah zut, ils nous embêtent ces Espagnols :-)
Moi qui m'étais déjà creusé la tête pour trouver un nom -- et n'en avait pas trouvé de pertinent d'ailleurs, d'où le repli sur un nom branchouille Web 2.0 !
Reste à faire une version en espagnol :-)

Quel que soit le moyen d'importer les livres, ce que tu pourrais faire c'est peut-être proposer un export en Z39.50.
L'autre truc qui me dérange, plus au niveau architectural, c'est l'aspect centralisé actuel de la chose (si j'ai bien compris l'idée). Il serait intéressant d'imaginer un système de réplication et/ou fédération de cette information, un peu comme l'architecture DNS.

Si je comprends bien, tu voudrais pouvoir interroger le catalogue fédéré via Z39.50 ?
Mais je vois pas bien l'idée de décentralisation. Ou alors ça voudrait dire que mon service ne serait qu'un 'annuaire' de serveurs Z39.50, auxquels il faudrait se connecter au final pour faire les interrogations de catalogues ?

Un des problèmes avec la technologie -- et les implémentations ! -- Z39.50, c'est qu'il y a toujours plein de subtilités embêtantes. Tous les serveurs n'ont pas le même 'profil Z39.50', c'est-à-dire n'acceptent pas les mêmes critères de recherche, etc. Autre exemple : certains ont besoin de l'ISBN exact (10 ou 13) pour trouver le (bon) résultat, d'autres font la 'traduction' automatiquement.

(D'ailleurs, c'est pour ça que j'ai basé mon service de recherche sur l'ISBN, car c'est le seul critère de recherche à peu près fiable au final.)

De plus, comme je fais du screen scraping, tout n'est pas accessible en Z39.50 nativement, c'est moi qui héberge une passerelle Web / Z39.50, via le logiciel SimpleServer.
Et puis d'ailleurs, le protocole Z39.50, c'est un peu d'une autre époque : pas moyen de faire de mashup avec ça, car 'inatteignable' depuis un navigateur Web...
Reste SRU/SRW que je pourrais facilement offrir comme service, grâce au logiciel yazproxy que j'utilise déjà en interne (réutilisation/limitation de connexions, cache, etc).

Mais, même après tout ça, reste le problème que Z39.50/SRU/SRW est trop bas niveau pour la plupart des utilisations de ce service : il faut un genre de 'protocole métier'.
Exemple : en plus de l'ISBN, mon service Web acceptent les identifiants produits de Chapitre.com et Fnac.com. Impossible à supporter ça en Z39.50, car il y a une étape 'métier' faite sur mon serveur.
Autre problème : un serveur Z39.50 peut contenir les catalogues de plusieurs bibliothèques différentes (ex: SUDOC, catalogue régional). Mon service Web permet lui de spécifier un ensemble de recherche plus 'fin' que le serveur, comme le niveau d'une ville précise.
En clair, mon service Web cache toute la complexité des recherches Z39.50 :-)

Ouep, c'est une bonne idée d'utiliser le SUDOC !
En fait, j'ai prévu de le faire mais c'est pas trivial à mettre en place : http://bibli.othequ.es/blog/?p=16

Comment récupère tu les données des Biblio pour les fédérés dans un premier temps deja, depuis leur OPAC, leur serveur Z39-50 ? ( ca doit limité à trés peu de BM vu l'utilisation qu'il est fait des serveur Z39-50.... )

En effet, j'essaie d'utiliser des serveurs Z39.50 en priorité car c'est très simple à interroger.
Cependant, il n'y en a pas des masses -- mais il y en a, il faut plus ou moins aller 'à la pêche'. Au final, je suis donc contraint à faire du screen scraping. Pas top mais on fait ce qu'on peut :-)

[...]
Il n'y a donc pas à chercher quoi que ce soit que tu n'aurais pas cherché de toute façon (sur Amazon ou autre), et pas de risque de se faire pointer une bibliothèque à 500 km.

En effet, c'est une très bonne explication :-)

Petite suggestion : la signification du symbole /!\ devrait être documentée.

Pas faux, je vais rajouter des explications pour ce cas. Merci du conseil.

encore une extension qui va attendre 50 ans avant de voir son adoption par Apple & MS

Pour info, le rédacteur de la RFC CardDAV bosse chez Apple : cf. http://tools.ietf.org/html/draft-daboo-carddav-04

Bien sûr, ça ne rend pas obligatoire l'adoption de ce standard par Apple, mais ça va y contribuer je pense :-)

malheureusement je ne sais pas s'il y a même de norme comme CalDav pour les calendrier afin d'avoir un minimum d'interoperabilité.

Il s'agit de CardDAV.
Une branche SVN du serveur Cosmo de l'OSAF supporte ce protocole.
Voir également du côte de SOGo: http://www.inverse.ca/english/contributions/sogo_connector.h(...)

Comme d'hab', une recherche "CardDAV" sur Google en apprendra beaucoup...

je me suis toujours demandée pourquoi aucune appli externe n'avait été développée afin que IE puisse à l'instar de Firefox afficher les appli XUL ? Un plug-in de rendu XUL (sans nécessairement la présente native de Gecko) pour IE (mais aussi pour Safari/Konqueror d'une part et Opera de l'autre) est ce réellement impossible ?

Il semble que ce soit déjà possible : http://www.iol.ie/~locka/mozilla/control.htm

- si vous utilisez l'IMAP, la précision des quotas imposé par votre fournisseur de mail dans la barre de statut

Je dois être miro, mais je n'ai pas vu cette fonctionnalité. Quelqu'un pour confirmer ?

Toujours pas de support des fichiers tnef :

Est-ce que l'extension LookOut pourrait aider ?
http://lookout.mozdev.org/

Le mythe habituel...
À dire que les autres sont des cons, tu en oublies que tu racontes des conneries:

Mon cher Wikipedia me dit :
http://en.wikipedia.org/wiki/Solar_cell#Solar_cells_and_ener(...)
ainsi que pour la France précisément :
http://www.outilssolaires.com/pv/prin-bilan.htm

Donc aller 5 ans on va dire, par rapport à une "durée de vie" de 20 ans au minimum, mon petit doigt me dit que ton discours est du pipeau.

Mais, c'est vrai l'installation massive en Allemagne par exemple est le fait de cons... Ou le complot de l'industrie allemande du PV ?

Il ne s'agit pas d'être gogo et de croire que cette production va résoudre tous les problèmes du monde mais de là à dire que c'est même pas rentable énergétiquement, c'est un peu fort de café! Surtout quand on "utilise" des surfaces "perdues" que sont les toits/façades -- à moins d'y mettre de la végétation peut-être...

Une situation a la Danoise: Ne sachant pas stocker l'electricité, il faut encaisser les baisses de production de l'éolien avec des moyens bcp plus réactifs qu'une centrale nucleaire... D'ou ce paradoxe: Ce sont les pays qui ont le plus d'éoliennes qui ont aussi le plus de centrales dégueulasses à charbon/gaz/fuel!!! Bel exemple!

En clair, l'éolien ne peut être déployé massivement sans centrales fossiles ?
Malheureusement, c'est faux.
Fin 2006, 1500 MW éoliens étaient installés en France.
Or, avec l'infrastructure de distribution actuelle, RTE lui-même ne voit pas de problème à monter au moins jusqu'à 10 000 MW.

D'après une de leurs études publiée fin 2004 [1] :

« On retiendra de ce rapide tout d'Europe que l'intégration massive d'éoliennes dans un système électrique dépend surtout des conditions naturelles : qualité du gisement de vent, possibilités de foisonnement, ressource hydroélectrique. A ce titre, la situation française est bien mieux adaptée à l'éolien qu'en Allemagne ou au Danemark. »

« On le constate, l'existence en France de trois gisements de vent quasiment dé-corrélés permet un foisonnement de la production d'éolienne qui réduit de manière significative son intermittence. »

« Malgré l'intermittence, un parc éolien participe à l'équilibre offre-demande, contribuant ainsi à l'ajustement du parc à hauteur d'une fraction de la puissance éolienne installée. C'est la puissance substituée, définie comme la puissance d'un moyen de production conventionnel qui peut être substituée par un parc éolien pour un même niveau de qualité de fourniture, soit encore une durée annuelle moyenne de défaillance égale. Pour le parc de référence de 10 000 MW, la puissance substituée est de 2 860 MW. »

« On constate aujourd'hui que les fluctuations inter-journalières de consommation sont principalement régulées par les effacements tarifaires, les échanges frontaliers et le parc hydraulique. […] Pour un parc éolien de 10 000 MW, l'aléa de vent n'est pas de nature à modifier fondamentalement ce principe de gestion de la production. »

Donc 2860 MW de puissance substituée, soit l'équivalent, si je ne me trompes, de 3 tranches de centrales nucléaires.
Alors, si on se décidait enfin à adapter l'infrastructure de distribution de RTE, qui supporterait des productions décentralisées, on peut penser qu'on pourrait relever cette limite.

Quant au Danemark : http://www.planete-eolienne.fr/danemark.html

[1] http://www.planete-eolienne.fr/production.html