Re: Rép. : Re

Bonsoir,

Erwan DUROSELLE a écrit :
| Remarques de Sébastien Dinot
| 1. J'avais compris que la GPL empéchait justement de vendre le soft,

J'insiste, on peut parfaitement vendre un logiciel sous GNU GPL.

| En tout cas, je ne veux surtout pas déclencher une guerre sur les
| licences.

Je n'ai jamais pensé que cette idée vous avait effleuré. Mais entre
la méconnaissance et la maladresse des uns et la désinformation
volontaire des autres, les professionnels sont souvent inondés
d'informations fausses qui les rendent réticents au libre lorsqu'ils
ont tout à y gagner.

Mais il ne faut pas vous affoler, étant secrétaire de l'APRIL, il est
normal que je sois pointilleux sur ce point. (c;

| => Comment reformuleriez vous ce paragraphe ?

« PostgreSQL est disponible sous licence BSD. http://www.postgresql.org/licence.html

Contrairement à la licence GNU GPL, la licence BSD permet d'intégrer
le code dont elle régit les droits d'exploitation et de diffusion
dans une application propriétaire (elle n'est pas contaminante). »

| 3. Maintenance annuelle: J'insiste: Il n'y a pas de maintenance à
| payer à l'éditeur.

A ma connaissance, l'achat d'un SGBDR Oracle n'implique nullement pour
le client la souscription d'un contrat de maintenance.

A contrario, un client peu familier du libre optera plus facilement
pour PostgreSQL s'il sait qu'il peut souscrire un contrat de
maintenance auprès de Red-Hat. Si ce client n'a pas de service
technique compétent, un tel contrat peut même être une obligation de
fait.

| Je vais mettre "il n'y a pas de redevance annuelle à payer", pour
| qu'il n'y ait pas d'ambiguité.

Comme cela, c'est déjà un peu moins ambigu...

| Par contre, c'est vrai que je passe pas mal sous silence le fait
| qu'il faut quand même surveiller et administrer un peu pg. C'est
| parce qu''à mon sens, comparé à Oracle, il faut beaucoup moins de
| temps d'admin et surtout des compétences moins pointues.

N'étant pas administrateur mais développeur, je laisserai des
personnes plus compétentes que moi s'exprimer sur le sujet.

Mais, pour me référer moi aussi à mon expérience personnelle, j'ai pu
constater à plusieurs reprises que l'intervention d'un administrateur
qualifié sur PostgreSQL (au hasard, notre JPA) pouvait métamorphoser
les performances de notre SGBD.

| Qui plus est, le temps de maintenance nécessaire sera du temps
| "moins cher".

Je ne suis pas certain que JPA soit bon marché ! Qu'en dis-tu
Jean-Paul ? (c;

| A mon sens , SQL Server n'est pas très fiable: on a parfois des
| surprises avec des tables corrompues. Il faut alors faire un DBCC
| Checktable ou checkdb.

La robustesse des tables est de la responsabilité partagée du SGBD et
du système de fichiers sur lequel il enregistre les données. Si Oracle
peut apparaître en l'espèce plus fiable que SQL Server, c'est
probablement parce qu'il exploite son propre système de fichiers au
lieu des systèmes natifs sous MS-Windows qui ne sont pas journalisés.

| Quand à Oracle, le redémarrage après un arrêt brutal n'est pas
| toujours automatique: il faut souvent faire un recover.
|
| Dans les 2 cas, ce n'est pas grave, mais je crois que pg, lui,
| redémarre sans intervention aucune (à part évidemment un script de
| boot style pg_ctl ) et sans perte.

CQFD : « Ext3, ReiserFS et XFS rulez ! » ... et PostgreSQL aussi. (c:

| 5. Compatibilité SQL: J'essaie de faire passer l'idée que PostgreSQL
| est largement compatible avec SQL99, dans l'ensemble plus que les
| autres SGBD, mais,qu'il n'est pas "totalement" compatible.

Ce n'est pas le message que fait passer « Compatibilité très complète
avec les standards SQL 92 et 99 »

| => Avez vous une autre formulation à proposer? 'très bonne
| compatibilité'?

« PostgreSQL implémente d'ores et déjà la majeure partie des normes
SQL92 et SQL99 »

Sébastien

--
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !