Larry Cow a écrit 5011 commentaires

Le probleme n'est pas que technique.

En effet. Les développeurs de KDE ont été aux premières loges pour assister aux débuts chaotiques d'Apple en tant que contributeur à un projet libre et communautaire. Ce qui peut les avoir refroidis.

Disons qu'avec CouchDB, c'est ton code qui est responsable de la structure de tes données.

Avec une couche SQL, c'est normalement à la base de données t'imposer la structure à ton code. Ce qui était particulièrement utile pour les grosses DB centralisées d'entreprise, où chaque service tape dedans à sa guise sans forcément consulter ses petits copains avant. Fut un temps, le SQL était l'interface, et chacun développait dessus. L'utilisateur était développeur, en un sens.

Sauf qu'aujourd'hui, le SQL disparaît de plus en plus derrière des couches d'abstraction, on voit des bases de données servir de manière complètement mono-utilisateur - et je ne parle pas du serveur de DB, mais bien de la DB elle-même : quand une application PHP est la seule à taper sur sa base de données, que le développeur est obligé de faire le grand écart pour conserver une cohérence de schéma entre sa base et son code, on peut légitimement se demander l'intérêt du SQL.

On n'est plus au XXè siècle : le SQL n'est plus une interface frontale, mais tend plutôt à se voir reléguée aux arrière-boutiques. Dans ces conditions, c'est peut-être à la fois une bonne raison et une bonne occasion pour regarder ce qui se fait à côté, non?

Quel rapport avec le Spanning Tree Protocol?

'ai entendu parler d'une société française dans le monde de la finance qui utilise voldemort pour traiter des petabytes de données.

On ne doit pas prononcer son nom!

(pardon)

Objectivement, la plupart de ces fonctionnalités existent sur les plateformes Linux. Pas forcément activées par défaut, pas forcément exemptes de défauts, pas forcément toutes sur toutes les plateformes, mais elles existent.

Après, l'intégration, c'est autre chose. C'est le boulot de Gnomes et autres KDEs.

Tu peux jeter un oeil à çà : https://launchpad.net/eoec

J'avais été bluffé par les possibilités il y environ un an, mais je n'ai pas eu le temps de pousser l'expérimentation plus loin.

En gros, ce truc te facilite grandement la fabrication d'un extension en Python.

Normalement, 1024 octets ça s'appelle désormais un Kio, et plus un Ko. Le Ko vaut maintenant exactement 1000 octets, pour rester cohérent avec le SI. L'ennui c'est qu'effectivement, personne n'utilise cette nouvelle notation à part les fabricants de disques durs, qui trouvent fort pratique de vendre 1000 octets au prix de 1024. Donc on pouvait légitimement s'attendre à ce que leurs "blocs de 4K" soient des blocs de 4000 octets.

Dans le cadre "chat" à gauche de Gmail, tu dois pouvoir accéder aux détails du contact et choisir "block". De manière générale, ça peut se gérer dans Google Contacts (sachant qu'au pire tu le vire de tes contacts).

Seule une petite partie de Wave était basée sur XMPP - en gros la communication entre serveurs. L'interface entre leur client et le serveur n'était même pas assez documentée, de l'avis des gens qui bossaient sur des alternatives. Et c'était _vraiment_ la misère à déployer.

Ici, ils réutilisent largement de l'existant (les flux habituels, la partie "publication" d'Atom qui trainait un peu à être adoptée, leur PSHB qu'ils poussent depuis quelques temps déjà, ...) qu'on a _déjà_ en place. Il est (et sera de plus en plus) possible de faire communiquer de diverses manières nos plateformes avec Buzz, sans sortir l'artillerie lourde pour les trucs basiques.

Après effectivement, ils promettent du OAuth et du Webfinger, tout ça. C'est très bien, et si ça peut aider à pousser un peu à l'adoption de ces technos, plutôt que de nous enfermer dans une dépendance toujours plus grande aux APIs de Twitter ou Facebook...

C'est un sacré argument pour défendre des pratiques plus que limites de google avec buzz.

Personne ne te force à utiliser un compte Google, ni ne te fait croire que Google ne collecte pas de données personnelles. Tu es libre. Et la liberté implique la responsabilité.

Tu donnes des infos personnelles à Google, ne viens pas te plaindre qu'ils en fassent ce qu'ils en ont toujours fait. Ça fait des années qu'on (que je, en tous cas) beugle que mettre ses photos de vacances chez Google c'est limite. Ça fait des années qu'on me prend pour un paranoïaque en phase terminale. Alors ne comptez pas sur moi pour m'apitoyer.

Pour ma part j'ai un compte Google, mais je sais que ce que je lui transmets est à considérer comme "public". Google ne sont pas des anges, c'est une entreprise commerciale avec des objectifs et tout. Dans l'ensemble, ils sont assez respectueux des règles du jeu (vis-à-vis du libre, et de l'écosystème informatique de manière générale), mais en termes de vie privée et de discrétion ce n'est pas ça. Et c'est limite dicté par leur business plan.

Pour l'authentification en clair, apparemment c'est du DIGEST-MD5, donc moins pire quand même.

Dans ces cas-là, fais-toi une galerie perso, sur un site Free ou ailleurs. Le microcosme Google ne brille pas par sa discrétion, si c'est une surprise pour toi c'est un peu flippant.

En même temps, depuis le temps que tout le monde le dit, que tout mettre chez Google c'est moyen pour la vie privée, s'il y a encore des gens pour se faire avoir. Et chez Facebook aussi, de toutes manières, vu comment un simple tag dans une photo peut te donner accès aux albums complets d'un parfait inconnu.

En dehors de ça, Buzz propose une interconnexion (grandissante) avec le monde extérieur via des protocoles documentés tels que Atom, PubsubHubbub, etc.

Et ça, ça permettrait à relativement brève échéance de faire communiquer ta propre infrastructure avec les gens qui utilisent Buzz. De manière décentralisé. Genre ce que promettait Wave depuis le début, mais en beaucoup plus simple (et donc beaucoup plus à même d'arriver pour de vrai).

En tous cas, j'ai effectivement testé Buzz - mon compte Gmail ne me servant qu'à gérer mes abonnements aux différentes MLs du libre - et c'est propre, bien fait et bien intégré. Certes, l'approche actuelle (on partage tout, avec possibilité de départager) est un peu limite, mais l'information est claire, et le lien pour couper le cou de Buzz n'est pas caché derrière 30 sous-menus.

http://www.douglasadams.com/dna/pedants.html :)

C'est clair. Ca ne sert à _rien_ de se fabriquer de la misère avec ça.

Depuis qu'on a fait le forum des Halles, quoi?

Tout dépend de ce qu'on entend par "lieu public", il y a une ambiguïté :

* lieu relevant d'une autorité publique (une mairie, un ministère, un hôpital, une caserne, la voie publique, etc.)
* lieu destiné à accueillir du public, mais relevant d'une autorité privée : cinéma, bowling, ...

Sauf à mettre en commun les moyens de plein de gens, par exemple une sorte de "WebCrawling@Home". Un peu ce que fait Yacy.

c'est un peu comme les laveurs de pare-brise avec leur eau toute dégueulasse

Non, ça c'est carrément de la vente forcée : tu n'as pas le temps de signaler que tu n'es pas intéressé que ta visibilité est réduite à zéro par leur savon. Après, sauf à ce qu'il te reste du lave-glace, tu n'as d'autre choix que de leur payer leur prestation pour qu'ils la terminent.

Il ne "faut" pas un TB2 modifié, mais ça aide. En gros, pour l'utilisation de SOGo, tu as plusieurs choix :


* l'interface web. Très complète, mais ne fonctionne pas en mode déconnecté et (un peu) moins agréable à utiliser qu'un client lourd.
* Thunderbird+Lightning "tous nus". Ici, pas d'extension SOGo-esque. Tu as accès à tes calendriers par CalDAV, il te suffit d'ajouter le calendrier par son URL (envoyé par SOGo dans ta boîte mail au moment de sa création).
* Thunderbird+Inverse Lightning. Même principe, sauf que le Lightning fourni par Inverse/SOGo a quelques améliorations (FreeBusy) et bugfixes qui n'ont pas (encore?) rejoint la branche officielle.
* TB+IL+SOGo Connector. Ici, ça change peu de choses pour les calendriers, de ce que j'ai pu voir, par contre ça permet de faire la même chose avec les carnets d'adresses : accès à un carnet d'adresses distant via son URL SOGo.
* TB+IL+SOGo Integrator. Un (tout petit) peu plus compliqué à déployer, mais ici tu as carrément l'interface pour régler les permissions sur tes calendriers/carnets et lister les partages de tes petits camarades.

Note: Merci à Ludovic de me corriger si jamais je me mélange entre Connector et Integrator, j'ai peut-être fait une fausse manip' mais je n'ai pas bien vu l'intérêt de Connector comparé à Integrator.

Du coup, Theora a pour lui une certaine universalité pour le contenu vidéo "de premier ordre" (i.e. pas isolé dans une VM Flash) : si on se tourne vers Theora, on cible un navigateur de plus.

Reste à savoir si ce principe de "contenu vidéo de premier ordre" intéressera suffisamment de monde. Pour faire du Youtube-like, c'est assez inutile : le plugin Flash est là, et il convient à la plupart des utilisateurs. Par contre, avec l'avènement des plateformes mobiles ou le retour d'une certaine "intelligence" (via javascript) dans le navigateur, ça pourrait avoir un sens.

Sauf que sous Debian au moins, tu as un Avahi qui tourne, et ce par défaut, et ce depuis un moment. Et c'est pratique en maudit.

Sous Windows, il faut installer le "bonjour" d'Apple, ce qui bien qu'automatiquement ajouté à Safari et/ou iTunes reste chiant.

Mais sous Linux/Mac (desktop), une implémentation de Zeroconf c'est très courant.

Apparemment, sur la version Windows de Chrome, les vidéos de http://openvideo.dailymotion.com s'affichent bien sans Flash.

Juste bravo. Cela fait un petit moment que je suis le projet (et avant ça, l'activité de nos lascars dans le monde de GNUstep - Ludovic étant à la base si je ne m'abuse de l'excellent GNUmail.app) mais je n'avais pas essayé de l'installer depuis longtemps. Le dépôt Debian fonctionne bien, et avec quelques adaptations [1] j'ai un collecticiel qui marche et qui s'interface avec Thunderbird et tout. Sans pour autant devoir abandonner mon infrastructure actuelle comme avec les concurrents (Zimbra ou Zarafa, notamment).

[1] Essentiellement le fait de _devoir_ passer par un "mod_proxy" Apache, sinon les CSS ne sont pas prises en compte par Firefox, car fournies avec le mauvais type MIME (application/octet-stream au lieu text/css) par le serveur par défaut.

D'un autre côté, vu qu'on ressort toujours les mêmes exemples de victoire commerciale sur la technique, on peut supposer que tous les autres "conflits" de ce genre se sont soldés par une victoire de la technique, non?