Raphaël SurcouF a écrit 2609 commentaires

Étant donné que les différentes versions d'Ubuntu s'appuient sur une seule version de Gnome à la fois, il n'est guère difficile de retrouver la version de ce dernier.
Et quand les distributions n'ont pas de versions, les utilisateurs te donneront simplement le nom de la distribution (genre : Debian, par exemple, où certains utilisateurs sont incapables de dire quelle version ils ont parce qu'ils ont une unstable).
En outre, dire qu'on utilise Linux 2.6.24, c'est bien gentil, mais ça ne suffit pas à connaître tout le contexte d'utilisation. La version est une chose mais elle ne fournit pas à elle seule tous les paramètres.
Et puis bon, on va pas commencer à dire Ubuntu GNU/Linux/Gnome/Evolution/Firefox/etc. sinon, on n'a pas fini avec les noms à rallonge.

Hélas, quand les normes sont méconnues des développeurs, cela donne ce genre de pratique...

À la BPA (Banque Populaire des Alpes), on utilise également CyberPlus mais on n'a pas ce type d'informations. Par contre, on a droit aux avertissements contre l'hameçonnage.

Et tu postes régulièrement tes fichiers sur fr.comp.sauvegardes.perso, histoire d'être sûr de pouvoir les y retrouver le jour J ? ;-)

Non, non, c'est tout à fait cela.
En fait quand tu interroges un serveur LDAP, rien ne te permet de savoir si les données que tu remontes ne sont pas :
- stockées dans la base BDB locale du serveur OpenLDAP ;
- stockées dans la base SQL que le serveur OpenLDAP interroge ;
- stockées dans l'AD de ton entreprise que le serveur OpenLDAP interroge ;
- sans parler du fait qu'il peut remanier les données à l'aide de règles de ré-écriture.

Le client LDAP n'a pas à savoir ni se préoccuper de la manière dont les données sont stockées.

Il ne faut pas perdre de vue que LDAP (et SNMP aussi) est avant tout un protocole d'accès à des données présentées de manière hiérarchique et de façon totalement indépendante de la manière dont les dites données peuvent être réellement « stockées ».
La nature des données, leurs inter-dépendances entre elles, leurs contraintes sont définies par des schémas (des MIB pour SNMP). Il existe des schémas dits standards par opposition aux schémas propriétaires dont les OID font partie d'une branche nommée « entreprise » et attribués à une entreprise ou une associétation par l'IANA. Les schémas dits standards font donc généralement l'objet d'une RFC. Ceci permet de s'assurer d'une certaine cohérence quant aux données que l'on doit examiner.
Toutefois, le support du protocole dans les applications dépend étroitement des connaissances que peuvent en avoir les concepteurs et de la place qu'ils lui accorderont dans leur développement. Soit il s'agit de répondre à un besoin exprimé par les utilisateurs, soit il s'agit de s'inscrire dans la logique de l'application.
Tout dépend donc du support LDAP dont disposent Bongo, ejabberd et dotclear.

PS: je parle de SNMP entre parenthèses car les deux protocoles partagent beaucoup de concepts (et surtout les OID).

Pas plus que pour d'autres normes.
Le problème est que les éditeurs et développeurs d'applications connaissent très souvent bien asssez mal les protocoles comme LDAP, ce qui donne des supports très disparates. En général, il s'agit surtout d'une fonctionnalité, demandée par des clients qui disposent d'un AD, qui a donc été rajouté en plus.

\rm -rf users

Oui mais il a d'abord jeter l'opprobe sur tar, outil qui était (et est encore) utilisé pour gérer des archives notamment sur des lecteurs de bandes mais il n'y a que GNU tar pour permettre de compresser en même temps qu'on créé l'archive en question.
Si l'on suit l'importance des données, tar n'est pas à remettre en cause.
Et il y encore beaucoup de lecteurs de bandes magnétiques utilisées pour la sauvegarde, les disques dur ne les ont pas encore remplacés.

Ça l'air idiot comme ça mais il vaut mieux prévoir une procédure mensuelle de restauration d'un des systèmes gérés et de ses données (sur un serveur de secours, évidemment) afin de s'assurer que, le jour J, la restauration ne posera pas de problèmes majeures (genre, s'apercevoir que les données les plus « fraîches » datent de deux ans...).
Par contre, ton expérience semble surtout démontrer la négligence des personnes chargées des contrats d'hébergement : prévenir la veille, c'est beaucoup trop tard. Évidemment, si la date de fin de contrat était précisément le lendemain, c'est que vous aviez pris trop de temps pour vous préparer.
Par contre, ça n'explique pas pourquoi le loyer n'était plus payé depuis des mois. Parfois, l'informatique n'est pas qu'une question de technologies et il faut que tout le monde coopère et partage les informations (oui, un admin a besoin de savoir quand un contrat d'hébergement se termine, si, si).

Oui, enfin, l'option n'est disponible qu'avec la version d'Epiphany de Gnome 2.22...
Que ce soit présent dans le svn ne voulait pas non plus dire que c'était très stable. D'ailleurs, cette option n'est pas activée par défaut et Epiphany est alors compilé avec le support Gecko.
Cela dit, c'est une bonne nouvelle quand même parce qu'il y a certains bugs gênants (comme ne pas pouvoir retirer un certificat sous Epiphany).

N'oubliez pas qu'on peut utiliser SVK comme version décentralisée de SVN.
Ainsi, tous les arguments liés à la centralisation de SVN tombent à l'eau.

Même 20 minutes à pied, je suis pas aussi exigeant.

La plupart des distributions fournissent Evolution et e-d-s avec des paquets bien séparés. e-d-s est maintenant un projet à part bien qu'étroitement lié à Evolution et au projet Gnome.


http://freshmeat.net/projects/evolution-data-server/
http://packages.debian.org/fr/etch/evolution-data-server

Alors qu'attends-tu donc pour faire un rapport de bogues détaillé et expliquant comment le reproduire afin que le fameux plugin ne fasse pas partie de la version définitive ?

En même temps, le protocole LDAP n'interdit en aucune manière l'utilisation de schémas propriétaires, pour peu que l'entreprise a pris soin de s'enregistrer auprès de l'IANA (et dispose donc d'une branche réservée pour les définitions de ses OID), ce que semble confirmer la lecture de la documentation[1] d'AD à ce sujet.
Maintenant, je voulais surtout attirer l'attention sur le fait qu'AD ne se compose par uniquement d'un serveur LDAP mais dépend étroitement d'un certains d'autres services comme DNS (avec les extensions SRV) ou Kerberos.


[1]: http://www.microsoft.com/france/technet/produits/Win2000S/ad(...)

C'est pourtant facile à trouver.

Ce problème ne vient pas directement d'Evolution et ne remet pas en cause son utilisation générale mais entre un plugin et un service de Google (en beta).
Evolution est devenu très modulaire et il existe de nombreux modules qui ne posent aucun problème.

Non seulement parce que les versions dites stables ne sont pas à l'abri d'un bogue qui aurait échappé aux tests mais tout changement de versions requiert une prise de précautions quant à la protection des données.
En outre, tu parles de version beta, mais Google Calendar en est justement une et, à en lire certains commentaires, il semblerait que cette application ne soit pas innocente à ton sujet.

Et un Vendredi, qui plus est ! Alors que c'est totalement interdit par la Loi !
Aucun changement le Vendredi !

Ce n'est pas parce qu'un plugin a mal fonctionné qu'il faut tout jeter à l'eau.
As-tu également essayé avec un autre client de messagerie intégrant Google Calendar, pour comparer ?

Tu ne mentionnes pas SVN mais la question qui était posée et à laquelle tu réponds le mentionnait. En outre, la dernière phrase laisse penser que le « cherry picking » est l'apanage des systèmes distribués de gestions de versions alors que ce n'est pas le cas. Ensuite, entre changeset et revision, il n'y a globalement qu'une différence de noms.

Dans la mesure où epiphany utilise encore, par défaut, le même moteur que Firefox, installer epiphany impliquera d'installer firefox. Ils auraient donc toujours le choix.
Par contre, depuis la nouvelle version d'epiphany, il va devenir possible de choisir, à la compilation, entre Gecko et kHTML.

AD utilise pas mal de standards, donc LDAPv3.
Simplement, réduire AD a un simple annuaire LDAP est une erreur monumentale.

C'est fort dommage parce que le système de bookmarks par catégories d'Epiphany est assez innovant. En effet, je peux classer un même lien dans plusieurs catégories au lieu d'être coincé avec un système hiérarchique et trop rigide.
En outre, les extensions de Firefox expliquent aussi son succès mais les extensions pour Epiphany existent aussi et elles sont assez méconnues alors que les principales extensions sont là.
Même si je le déplore également, je comprends le choix de Firefox (son nom est quand même plus connu).