[gull] Il faut reconnaitre que la Wikipedia est drole

[Marc SCHAEFER]

On Mon, Sep 26, 2005 at 09:36:31PM +1000, Frederic Schutz wrote:
> Ah, une occasion de rebondir dans une discussion sur les logiciels libres...
> 
> > PS: j'émets une réserve par rapport à Wikipedia: la technologie (PHP/MySQL[*]).
> 
> Qu'est-ce qui te gene le plus dans ces technologies ? Ou, en d'autres
> termes, vois-tu des problemes concrets dans Wikipedia a cause de ces
> technologies ?

La majorité[*] des logiciels développés en PHP sont mal conçus, et le
langage incorpore des mécanismes censés corriger des faiblesses des
programmeurs (magic_quote, register_globals, etc) qui posent plus de
problèmes qu'ils n'en résolvent. Aussi, PHP a une fâcheuse tendance à
reprendre de bons concepts d'autres langages en les sabotant légèrement.

On peut certes faire du bon code dans tous les langages, mais PHP repose
sur de mauvaises bases.

MySQL est une base de données non générale, qui n'implémente pas tout ce
à quoi on pourrait s'attendre après avoir compris les fondements des
systèmes de gestion de bases de données. Même si ses dernières versions
vont dans la bonne direction, ce n'est pas encore un système
qui permet de véritables développement corrects SGBD. Et pire, il donne
l'illusion à ses utilisateurs de les offrir.

Il y a certes des cas où une base de données non générale peut suffire,
mais alors il y a d'autres choix que MySQL (p.ex. DBM, voire SQL-DBM).

> raison) pour etre plus rapide que p.ex. PostgreSQL. Et Wikipedia n'a
> surement aucun besoin des fonctionalites qui manquent a MySQL.

Justement, c'est souvent parce qu'on n'a que MySQL qu'on ne voit pas les
fonctionnalités qui pourraient être utilisées déjà dans le design de
l'application.

Il est évident que le portage d'une application limitée à MySQL sur
PostgreSQL ne donnera pas forcément de meilleurs résultats. Il est
évident qu'une application écrite avec un véritable SGDB en vue ne
fonctionnera jamais sur MySQL (ou du moins dans les 2-3 prochaines
années).

Le seul cas où une base de données hyper-simple peut être employée c'est
lorsqu'une couche intermédiaire (moniteur transactionnel, etc) sort de
la base de données les fonctionnalités SGBD correspondantes. C'est
l'approche parfois prise par les développements en Java, pour deux
raisons: 1. la performance/scalability  2. le fait que les développeurs
Java aiment bien maîtriser leur monde, et donc tout réimplémenter en
Java [*].

> Je ne sais pas ce qu'il en est pour la fiabilite; je me souviens qu'il
> y avait besoin de restaurer toute la base de donnees a un moment, mais
> je ne sais pas si MySQL en etait responsable.

Dans mon expérience pratique jusqu'ici, MySQL m'est apparu comme ayant
plus de problèmes de fiabilité que PostgreSQL. Mais il faut bien dire
que depuis 2-3 ans je n'ai plus véritablement utilisé MySQL, il se peut
que la situation se soit améliorée.

Au niveau de la licence, par contre, j'ai toujours regretté que
PostgreSQL soit en licence BSD, alors que MySQL est en GPL. Mais bon,
comme MySQL a une licence duale (une propriétaire), on retrouve les
mêmes problèmes avec PostgreSQL et MySQL au niveau pratique: les deux
existent également sous forme de versions propriétaires avec `plus' de
fonctionnalités.

A ce sujet, Digium Asterisk est aussi dual-licensed (GPL ou
propriétaire), ce qui a permis à Intel d'intégrer leurs composants
propriétaires, mais uniquement dans la version propriétaire (aussi
appelée Pro). Cela a été possible car tous les patches des contributeurs
ont été reversés à Digium.  Un Allemand qui développe du support pour
des cartes BRI a explicitement mis sous GPL uniquement ses patches, et
donc ils ne seront jamais intégrés.

La situation du kernel Linux est très différente (copyright à chaque
auteur, en GPL) donc une licence duale est impossible. Mais bon, Linux
est finalement (le kernel) qu'une partie infime d'un système GNU/Linux,
facilement changeable [*] -- au moins sur les serveurs.

Rien d'encourageant à ces licences duales ou non GPL. [*] Elles ne
forcent plus les propriétaires à revoir leurs pratiques.

[*] troll