007 a écrit 2187 commentaires

> toujours lié à des dll windows donc

Il y a le même "problème" avec execshield. C'est un "faux" problème car execsheild peut-être désactivé par programme :
# execstack -q /usr/bin/mplayer
X /usr/bin/mplayer

Pour un programme "normal" :
# execstack /bin/ls
- /bin/ls

execshield peut aussi être désactivé lors de la phase de link mais j'ai oublié comment. Normalement au build de mplayer c'est fait automatiquement.

# grep "Connect time" /var/log/messages
Jun 21 11:37:08 me pppd[711]: Connect time 7757.8 minutes.

Soit : 129 heures (plus de 5 jours).

J'ai un autre "Connect time" à 66h. J'ai déjà remarqué ça plusieurs fois.
Mais parfois c'est nettement moins de 24h...
tele2 en 1024.

Il y a toujours la doc Red Hat :
RHL 9 en français :
http://europe.redhat.com/documentation/(...)

RHEL 3 en anglais :
http://www.redhat.com/docs/manuals/enterprise/(...)

C'est pas totalement à jours par rapport à Fedore Core 2 mais c'est ok pour 97 % des infos.

> Que feriez-vous à ma place ?

A ta place, je posterai ça sur les forums. Il y en a un pour Mandrake sur linuxfr :
http://linuxfr.org/forums/14/(...)

Merci de votre attention.

> C'etait a cause de la licence de Yast que la distro n'etait pas libre, tu ne vas quand meme pas dire le contraire !

J'ai dit le contraire ? Dans mon post au début j'ai parlé de yast ?

Vu que tu es si véhément envers Yast/SuSE, fais de même avec Mandrake CS. Histoire d'être cohérent.

> Et c'est ca que les defenseurs du libre critiquaient dans Suse

Ils ont raisons (les défenseurs du libre).

> D'ou la comparaison que tu faisais avec Mandrake n'etait pas justifiee.

????
J'ai comparé la licence de Yast avec quoi dans Mandrake ?
Je comparais la "volonté" de limiter la disponibilité de la version gratuite pour faire du pognon. La comparaison portait sur ça.
Et notes bien que la disponibilité gratuitement des isos (ce qui concerne la news) n'est pas lié à la licence de yast puisqu'il n'y avait pas d'iso gratuite pour SuSE 9.1 au début alors que Yast a toujours été sous GPL pour SuSE 9.1.
Si on critique cette "volonté" de SuSE alors il faut aussi critiquer les volontées de Mandrake (et RedHat pour te faire plaisir, mais maintenant il y a Fedora qui est 100 % free et gratuite (les isos aussi et dès la sortie)) de limité la disponibilité de la version gratuite pour "forcer" les abonnements au club ou l'achat de boîte.

Histoire d'être cohérent tu devrais aimer une news Mandrake qui anonce la disponibilité gratuite des isos avec : "La distribution Mandrake tant critiquée pour ne pas mettre à disposition à la communauté les ISO de sa distribution fétiche dès sa sortie vient en effet de mettre à disposition de tout le monde les ISO."

Oui ? non ?

Ben moi je ne serait pas d'accord avec cette formulation. Ni pour Mandrake ni pour Suse.

> Chose que Suse ne faisait pas a cause de Yast.

Ce que tu refuses de comprendre, c'est que ce n'est pas à cause de yast. Yast est (ou était) le moyen pour diminuer la diffusion gratuite de la distribution. Tu comprends la nuance. SuSE peut modifier quand il veut la licence de Yast (d'ailleur ils l'ont fait). SuSE ne subit pas la licence de Yast !

C'est comme si tu me disais que les sources de Windows ne sont pas dispo à cause de la licence de Windows. Si les sources de Windows ne sont pas dispos, c'est parceque MS ne veut pas ! C'est tout. La licence est le moyen pour interdire la diffusion des sources.

Si Linux est diffusé avec les sources c'est parce que Linus le veut. La GPL (la licence) est le moyen pour garantir que les sources sont là.

> Le CD est un peu depassé

Ben 99 % des équipements hifi des ménages est dépassé par le CD.
Pour exploiter correctement le format CD il faut des enceintes à au moins 400 € l'unitée... C'est pas donné, or ici on trouve que le CD sont trop chers.
De plus si la qualité c'est si important que ça, la dernière chose à faire, c'est de convertir en mp3 ou vorbis.

> En comparaison de RedHat

T'as aussi Fedora. Et dans ce cas, pour 32 bit et 64 bits, c'est gratuit.
Mais une Fedora n'est pas une RHEL et tout ne peut pas être gratuit.

> La licence de Yast interdisait la redistribution contre argent ce qui ne la rendait pas libre : pas de CDs dans les revues ou par correspondance.

Ok, je comprend. Quand tu disais "iso non-dispo à cause de la licence yast" je croyais que tu disais "isos non-dispo chez suse à cause de la licence yast".

> Je te ferais remarquer que c'est toi qui a attaque Mandrake

Ben si t'es parano...

> il faut que tu tapes sur Mandrake avec des arguments fallacieux.

Expliques. Si tu vois une attaque contre Mandrake, j'allucine.
Si tu le demandes, je te fais une attaque contre Mandrake (le distributeur). Mais si tu insistes uniquement !

J'en reviens au début du thread qui portait sur :
- "La distribution tant critiquée pour ne pas mettre à disposition à la communauté les ISOs de sa distribution fétiche"

C'est pas la distribution qu'il faut critiquer mais le distributeur qui a (avait) choisi de ne pas distribuer gratuitement les ISOs. De plus, pour moi ce n'est pas réellement critiquable. Comme tu le dis, il ne faut pas confondre libre et gratuit. Ce qui était critiquable, était l'ancienne licence de Yast. Et encore... Si SuSE ne veut pas faire de logiciel libre, c'est ses oignons. C'est à l'utilisateur de bien choisir sa distribution et de ne pas prendre de distribution avec du proprio s'il n'en veut pas. Notes que la nouvelle licence Yast ne résoud pas le problème si SuSE (ou Novell) ne veut pas distribuer gratuitement les isos. SuSE pouvais mettre à disposition les isos gratuitement avec l'ancienne licence Yast. Notes aussi que RedHat avec RHEL n'a pas de problème de licences qui empêche la redistribution gratuitement des isos. Mais les isos ne sont pas disponibles. Par contre si tu as des isos RHEL sans contrat de maintenance (minimum 1 an) tu peux les redistribuer gratuitement (où au coût des frais de port). RedHat (le distributeur) n'a pas l'intention de distribuer gratuitement RHEL pour des raisons de business. Pour ça il passe par un système un peu compliqué de contrat de maintenance. SuSE passait (aussi) par la licence Yast, Mandrake ne met pas à disposition les isos durant un certain temps, la CS n'est pas dispo, les powerpack ont des logiciels proprios de partenaire etc...
Ce n'est pas la distribution qui faut "dénoncer" mais la politique commerciale du distributeur. De plus, pour moi (et je le répète) ce n'est pas critiquable.
Par contre, je ne me priverais pas d'informer l'utilisateur final que tellle ou telle distribution est plus ou moins proprio :-)

> il y a meme des outils pour creer les isos soi-meme a partir d'un miroir FTP.

Que tu ne peux pas revendre pour des raisons évidentes de protection de marque. Sinon ça veut dire que tout le monde peut profiter de la notoriété de MandrakeLinux pour distribuer sa propre distribution sous le nom de MandrakeLinux.
Si demain je m'amuse à refaire les isos d'une MandrakeLinux avec les sources ou binaires de MandrakeLinux, je me fais attaquer. Ce qui est bien normal.

Et toi, tu es soulagé maintenant ?

> ils bloquaient leur redistribution en mettant un installeur non libre. Le fait que les isos n'etaient pas disponibles n'etaient qu'une consequence de cela.

Tu te mets le doigt dans l'oeil et il faudrait de renseigner un peu. L'ancienne licence de Yast n'interdit pas la distribution de Yast (et surtout par SuSE).

> Mandrake par contre a toujours ete 100% libre

Comme il en a toujours été avec Debian, Gentoo, RedHat/Fedora, Slackware, etc...

> je précise que j'ai compiler ce kernel comme un 2.4.x

Si tu as recopié un fichier .config d'un 2.4 pour compiler un 2.6, il est normal que ça ne marche pas.

> "lorsque la TVA est passée jadis de 33% à 18,6%, les prix payés par le consommateur, eux, n'ont baissé que de 8%".

Le passage de 33% à 18,6% de taxe fait diminuer le prix de 10,8 % au-lieu de 8 % réalisé.
Par exemple, pour un disque à 100 F avec 33 % de taxe, le prix est passé à 92 F au-lieu de 89,2 F prévu lors du passage à 18,6 % de taxe. 2 F 80 d'écart.
C'est pas le scandale de la décennie et il faut savoir si la baisse de seulement 8 % tient compte de l'inflation...

Pour fedora c'est ici :
http://linuxfr.org/forums/30/(...)

> Si tes dates sont stockées sous forme classique (2004-06-31 19:53:21)

Marche pas avec le passage heure d'été/hiver. Il faut un "truc" supplémentaire. Par exemple stocker les heures en GMT. Puis c'est a toi de prendre en compte les locales. C'est lourd. PostgreSQL fait ça tout seul. De plus tu ne peux pas faire de différence de date avec SQLite (par exemple).

> Si tu lis la news et les liens tu verras que justement depuis cette version il y a un typage simple mis en oeuvre pour distinguer int/float/text/blob

Faut aller lire le site. Il n'y a pas de vrai typage. Les données restent stockées en string.
Vas lire le site attentivement.

> Quelqu'un peut me rappeler en quoi un SGBD doit fournir des fonctions de traitement de date pour avoir le droit d'être un "système de gestion de base de données" ?

Stocker des données et ne pas pouvoir faire de traitement (par exemple soustraction) n'est "pas top".

> la news ne comparent avec MySQL et pgSQL.

De la news :
Offre des performances supérieures à PostgreSQL et même MySQL pour beaucoup de types de requêtes communes

> n'est probablement pas fait pour avoir une super grosse concurrence, maintenant est-ce grave ?

Non.

C'est vrai que ces petites phrases assassines sont pénibles alors que SuSE est un très gros contributeur.

C'est le dlfp touch, on aime bien taper sur les plus gros contributeurs et on est tout gentil pour les petits qui ne contribuent pas ou presque pas.

C'est comme ça.


La distribution tant critiquée pour ne pas mettre à disposition à la communauté les ISOs de sa distribution fétiche

Encore un truc stupide. Ce point chez SuSE pouvait être vu comme regrettable mais pas critiquable d'un peu de vu utilisateur ou par rapport à la distribution. Pour Mandrake les iso official sont disponibles en download gratuitement beaucoup de semaines après la sortie de la distribution. Ça justifie un "La distribution tant critiquée pour ne pas mettre à disposition à la communauté les ISOs de sa distribution fétiche" pour Mandrake ?
Évidemment que non.

vient en effet de mettre à disposition de tout le monde les ISOs de la version personnelle.

C'est le CD1 qui est dispo et pas tous les CD.

> ces mêmes données stockées sous forme relationnelle dans un fichier de données SQLite, seront accédées beaucoup plus rapidement

Ça dépend. Pour une recherche ET si tu as le bon index alors peut-être (il faut beaucoup de données). Pour récupérer toute la liste, c'est beaucoup moins sûr.
Je dis ça de façon général et pas par rapport à XML.
J'ai déjà constaté que pour des petites tables un index n'apporte rien en recherche et est pénalisant lors des mises à jour/ajout/suppression.

La "forme relationnelle" a un sens avec plus d'une table :-)

Comme je m'intéresse à SQLite, j'ai trouvé ceci :
http://www.sqlite.org/faq.html#q2(...)
What datatypes does SQLite support?

SQLite is typeless. All data is stored as null-terminated strings.

Comme faire des comparaisons de date ou des calculs sur des dates ?
Comment est supporté les locales pour les dates (heure été/hiver :p) ou les chiffres ?

Ce n'est pas une critique de SQLite. Ça montre que SQLite n'est pas un équivalent d'un "vrai" SGBD.

> http://www.sqlite.org/cvstrac/wiki?p=UnsupportedSql(...)

Beaucoup de choses marquées spécifiques à Oracle existent dans PostgreSQL.

> mais vous foncez tout de suite critiquer sqlite

Personne ne dit que SQLite est nul. Le problème est de comparer SQLite avec MySQL ou PostgreSQL. SQLite n'a rien à voir avec MySQL et encore moins avec PostgreSQL.

Ce qui est critiqué c'est le FUD de la news.
Exemple :
Disons en deux mots qu'il a tout d'un grand

C'est du foutage de gueule.

Implémente la plus grande partie de la norme SQL92, dont les triggers et les transactions
Et pas de language embarqué...
Voir :
http://www.sqlite.org/omitted.html(...)
Et aussi :
http://www.sqlite.org/cvstrac/wiki?p=UnsupportedSql(...)

Et j'ai bien l'impression que c'est pas complet.
Implémenter une caractéristique de SQL92 peut-être extrêment dure (par exemple les sous-requêtes et de façon complète). Pour affirmer que la plus grande partie de la norme SQL92 est implémentée il ne suffit pas d'avoir SELECT, INSERT, DELETE et UPDATE ou d'avoir plus de 50 % des mots clés de supportés.

- Supporte les transactions avec toutes les propriétés d'atomicité, de consistence, d'isolation et de durabilité (ACID)

Pour une table ! Le contexte de transaction peut-être très complexe. Juste pour exemple, je te conseil de lire (ce n'est pas long) :
http://www.postgresql.org/docs/7.4/static/mvcc.html(...)

Offre des performances supérieures à PostgreSQL et même MySQL pour beaucoup de types de requêtes communes

Mais quelle surprise ! Cette comparaison est stupide. Tout est réalisé sur une seul table et jamais avec plusieurs client à la foi. Comment ça ce comporte sur une machine smp ? Mistère...

Si j'étais aussi "bête" je ferait bien un comparatif/bench entre PostgreSQL et SQLite. Il y aurait plein de "failed" pour SQLite et dans quelque cas SQLite serait plus rapide. Mais ce serait stupide.

Bref, j'ai pas envis d'en discuter longtemps. SQLite n'a presque rien d'un grand. C'est un petit et il le fait très bien. Il n'est pas conçu pour être un grand.
Il faut le comparer à Berkeley DB (qui a les transactions sur une table (ACID) prend peu de place mémoire et est aussi extrèment rapide). btw Berkeley DB a aussi un mode serveur.

On compare un ananas avec une patate seulement parce que ça se mange. Ça me gonffle. L'ananas ce n'est pas terrible avec une côte de boeuf grillé et la tarte aux patates j'aime pas ça. NB: Je bouffe des ananas et des patates.

Pour finir positivement, SQLite me plait beaucoup et nul doute que j'y penserais si je travail sur un projet qui "cadre" avec ce pour quoi il a été fait.

> > we are already dealing with a 100GB database.

Ça c'est sans le moindre intérêt. Ça montre seulement que lors du développement ils ont fait attention. Berkeley DB en fait autant.

> De toute façon mon propos n'était pas de jouer les vendeurs de benchmarks de SGBD

Faut pas laisser croire que SQLite est dans la cour des "grands" avec ou sans benchmarks.

- Implémente la plus grande partie de la norme SQL92, dont les triggers et les transactions

Sur plusieurs tables à la fois les transactions ?
Peut-on ouvrir plusieurs transactions en écriture à la fois sur la même table (genre réservation de billets d'avion par plusieurs personnes à la fois)?
Dans la norme SQL92 supporte-il la majorité des types ou qu'un ensemble très limité comme "INTEGER, REAL, TEXT et BLOB" ? Il y a les types decimal ou numeric à précision arbitraire ?
Il y a les sous-requêtes ? Il y a la clause "HAVING" ?

- Offre des performances supérieures à PostgreSQL et même MySQL pour beaucoup de types de requêtes communes

C'est suffisament vague pour que tu ne le prouves pas...

2. Offrir à l'utilisateur un niveau illimité d'annuler/refaire

Berkeley DB qui supporte aussi les transactions fait ça sans "artifice". Parce que avec les triggers n'importe quel gestionnaire peut faire ça.
btw, Berkeley DB supporte aussi les backups à chaud avec une simplicité désarmente. Il suffit de copier les fichiers. C'est tout.

J'ai rien contre SQLite. Mais la pub avec des arguments "tendancieux" sur dlfp m'énerve beaucoup. J'ai l'impression de les publicitaires MS n'aurait pas fait mieux que toi.

> Ce qui est absolument mortel avec SQLite c'est qu'il ne peut évidemment _jamais_ planter vu qu'il n'y a pas de serveur.

Mieux vaux lire ça qu'être aveugle.
Aucun programme ne peut avoir la prétention de ne _jamais_ planter.

Et le "vu qu'il n'y a pas de serveur" je ne vois pas que qu'il fait ici.

> Berkeley DB.

Ya aussi metakit :
http://www.equi4.com/metakit.html(...)

C'est peut-être l'occasion de faire une news avec "fantastique" "comparable à Oracle met en plus rapide" etc...

Pour info Berkeley DB est le backend de rpm, evolution et subversion. J'en oublier évidement beaucoup beaucoup beaucoup.

Surtout qu'il y a un forum pour ça :
http://linuxfr.org/forums/15/(...)