bobert a écrit 604 commentaires

...que l'offre importante de logiciels libres utilisables sur la plate-forme de Microsoft revient régulièrement dans leur argumentaire. Par exemple dans cet article:

Enfin, nous pensons que Windows est une plate-forme idéale pour réaliser des projets open source, dès qu?on ne s?intéresse pas aux couches basses du système d?exploitation. D?ailleurs, sur les 82k projets sur SourceForge, 30.000 sont indépendants de la plateforme et 20K ciblent la plateforme Windows

Tout ça me conforte dans l'idée que, mis à part des créneaux stratégiques comme les suites bureautiques, c'est absolument contre-productif sur le long terme de miser sur des développements portables sous Windows.

1. Microsoft ne peut que s'en féliciter, et on voit bien dans cet article qu'il ne s'en prive pas

2. Du côté des utilisateurs de Windows potentiellement portés vers le libre, on peut se faire une idée du résultat sur le site framasoft, dont les commentaires sont je pense bien représentatifs. C'est assez édifiant : il y a eu depuis peu des articles spécifiques à Linux, ou de découverte de ce système, qui ont provoqué une véritable levée de boucliers de la part d'une partie des utilisateurs, avec des arguments du genre (je résume, donc je déforme): "on est là pour parler de logiciels libres, pas de Linux" ou "J'ai installé Openoffice et Mozilla sur ma machine et j'en suis très content, merci Framasoft, ça m'a rien coûté. Mais je vois vraiment aucun intérêt à passer à Linux, j'ai déjà sous Windows tout ce dont j'ai besoin".

Je suis convaincu que l'idée d'amener des utilisateurs vers les logiciels libres en leur proposant des portages sur Windows est naïve et vaine.

Je vous rappelle que, tant qu'il n'y aura pas une masse critique de consommateurs qui enverront un courrier d'injures aux constructeurs de matériel, de périphériques, de jeux, etc, pour leur dire "j'ai acheté votre dernier Trucmuche, qui ne fonctionne pas sous Linux Mandrake, c'est inadmissible", on restera dans la situation qu'on connaît.

Un utilisateur de Microsoft Windows qui installe Mozilla et OpenOffice.org, c'est très bien, tant mieux pour lui, mais ça ne fait pas fondamentalement avancer le schmilblick ; ça conduit même à une situation bien plus perverse sur le long terme, à mon humble avis. Que je partage.

Valable, comme idée.

Exact, j'attends beaucoup de gnome-storage, je supporte plus d'avoir à stocker des informations de même nature dans des hiérarchies différentes (une pour les mails, une pour les fichiers, une pour les notes...).

Enfin, j'en étais déjà là il y a deux ans (http://linuxfr.org/comments/137786,1.html(...))... tout ça nous rajeunit pas...

pourquoi ne pas implémenter le FS comme une base de données, au lieu d'avoir un FS traditionnel et une base de données qui doivent rester synchronisés ?

J'ai l'impression que le monde des LL a fait une réaction épidermique à la base de registres de Windows. Depuis, on a traîné dans la boue ceux qui proposaient une interface unifiée de stockage de données de configuration dans des bases de données-fichier (ça va pas, non ? Tout doit prendre la forme de fichiers "plats", qu'on puisse modifier à la main!).

Alors une base de données comme système de données, tu n'y penses même pas !! (Enfin pour ma part j'attends ça avec impatience...)

print ' ; '.join(fichier.lignes[0]) Mais enfin là ça ressemble un peu beaucoup à du csv... on est revenu à notre point de départ ! Si tu veux faire un minimum de traitement de tes données, il faut bien que tu en aies une connaissance a priori, donc il faut savoir quelle information est écrite dans telle ou telle colonne de ta feuille de calcul, et donc dans tel ou tel élément de ta liste... La conclusion de l'histoire c'est qu'il va bien te falloir à un moment décider quoi faire de taListe[0], taListe[1], taListe[2] et taListe[3], individuellement. Vu ce que tu comptes faire, tu pourras pas y couper...

Sauf que moi je veux afficher les listes intégralement, et pas un élément à la fois...

   print "Salle %d / Classe %s / %d / %s" % fichier.lignes[0]

Ah, la programmation... que d'efforts !!

>>> liste = ['117', 'CE2 A', '0', 'Ext\xe9rieur']

>>> liste[3]

'Ext\xe9rieur'

>>> print "%s"%liste[3]

Extérieur

>>>

Ne pas confondre évaluation et affichage via la fonction print...

* Une page dédiée donne une liste non-exhaustive des applications utilisant SQLite: http://www.sqlite.org/cvstrac/wiki?p=SqliteUsers(...)

* Je ne programme pas trop en C, mais il y a au moins une application écrite en C mettant en oeuvre SQLite, et dont j'ai examiné les sources, c'est CVStrac, du même auteur (http://www.hwaci.com/sw/cvstrac/(...)). Très bien écrite, tu y trouveras ton bonheur.

* Pour ce que tu veux faire, peut-être pourrait-tu envisager un langage de plus haut niveau que le C, histoire de pas réinventer la roue. Pour une application comme celle que tu décris, l'idéal est de développer rapidement un code maintenable, les performances brutes sont un critère secondaire. Pour ça, un langage de choix est python, que je te recommande chaudement.

En python, la biblopthèque d'accès à SQLite s'appelle PySQLite (http://pysqlite.sourceforge.net/(...)). Ne te focalise pas sur l'aspect austère de la page d'accueil, télécharge l'archive : tu peux mettre en oeuvre PySQLite en 5min chrono ; il n'a vraiment pas de quoi s'en priver !!

Essaie, et dis-moi ce que tu en penses...

Salut,
s'agit-il d'une application à usage personnel, ou d'un site communautaire ?
Dans le second cas, il semblerait que ça existe déjà: http://www.bedetheque.com/(...)
Dans le premier, peut-être l'auteur dudit site accepterait-il de publier les sources ?

[...] concurent d'Access (qui à ma connaissance n'existe pas dans le monde libre) [...]

Il y a bien Kexi [1],[2], mais on est effectivement encore loin du compte..

[1] http://www.koffice.org/kexi/(...)
[2] http://www.kexi-project.org/(...)

Il y a le très sympathique xplanet [1]. À l'origine dérivé de xearth, il était prévu pour calculer à intervalles régulier des images de rendu de la Terre, mais il peut maintenant représenter toutes les planètes ainsi que les satellites majeurs du système solaire.

Ses possibilités sont très larges, donc tout le monde peut le configurer comme il veut.

Pour ma part, je demande à xplanet:
- de représenter la Terre en projection orthogonale
- en générant une image à partir:
1. d'une carte de la Terre, sans nuages, en "vraies" couleurs
2. d'une carte de la Terre de nuit, avec des lumières des concentrations
urbaines
3. d'une carte de perturbations atmosphériques, générée toutes les 3 heures et que je récupère à intervalles régulier grâce à un petit script en python [2]

Tout ça peut s'utiliser comme un fond d'écran animé, même avec KDE [3].

Le résultat est vraiment passionnant, je trouve, moi je m'en lasse pas. À titre d'exemple, voilà une copie d'écran sur internet qui ressemble à peu près à ce que j'ai [4]... pas mal, non ?

eu'l Bob

---

[1] http://xplanet.sourceforge.net/(...)
[2] http://www.ephemeral.org/doodads/download_clouds.py(...)
[3] Pour KDE: Configurer le bureau -> Fond d'écran -> Options avancées -> Modifier, et taper une commande du style

xplanet -radius 60 -projection orthographic -config /home/ngirard/.xplanet/default --geometry %xx%y --num_times 1 --output %f.jpg && mv %f.jpg %f

[4] (Image png, 1152x864) http://buru.ag0ny.com/shot/xplanet.png(...)

Pour la bureautique, il manquait clairement un Access-like dans les suites du type Open Office [...]

Pour une intégration complète, on n'y est pas encore... mais il est déjà parfaitement possible de gérer des données stockées dans une base SQLite via Openoffice.org, à la Access. Voir le document suivant, rédigé par Yves Chaufour de l'équipe francophone de doc de OOo:

Yves Chaufour (Mai 2004) - "Comment utiliser une base de données SQLite avec OOo" - http://fr.openoffice.org/Documentation/How-to/Bdd/08SQLite.pdf(...)

* Une liste de canaux RSS dédiés à Python: http://lowlife.jp/cgi-bin/moin.cgi/PythonProgrammersWeblog(...) , ainsi qu'une page générée automatiquement à partir de ces susdits canaux RSS: http://mechanicalcat.net/pyblagg.html(...)

* Et les séries très connues des "Why I love Python", très bien pour découvrir ou faire découvrir les aspects de ce langage qui le rendent si sympathique à ses utilisateurs:

- celui de Bruce Eckel (en ppt zippé, beurk): http://64.78.49.204/pub/eckel/LovePython.zip(...)

- ceux de Kent S Johnson, "Why I love Python" numéros 1, 2 et 3:
http://www.pycs.net/users/0000323/weblog/2004/04/23.html(...)
http://www.pycs.net/users/0000323/weblog/2004/04/29.html(...)
http://www.pycs.net/users/0000323/weblog/2004/05/28.html(...)

eu'l Bob

deux mecs qui, en 2004, continuent de développer un N-ieme lecteur de news en C pseudo-objet, franchement...

Non mais je rêve...
À part les Jacky et leur bagnole, je vois pas avec quoi comparer une telle arrogance et une telle mauvaise foi...
Donc les développeurs de Gnome, de Pan, etc, ne valent rien, ah bon. Heureusement qu'on a encore des vrais mecs comme toi pour coder en C++, c'est vrai.

c'est toi qui dit que Pan est le meilleur newsreader sous Linux

C'est certainement un des plus riches ; peut-être un des plus populaires ; ça n'est pas moi qui le dis, c'est Freshmeat:
http://freshmeat.net/browse/39/?filter=&orderby=rating_DESC(...)

la probabilité que leur code C soit devenu tellement spaghetti qu'ils n'arrrivent plus à l'etendre ou le maintenir et non-negligeable.

Ben tu vois, la meilleure façon de voir que ça n'est pas le cas, au lieu de faire des suppositions gratuites, c'est de regarder le code source de Pan. Vas-y, te gêne pas pour leur donner des conseils. Mais peut-être ne t'abaisses-tu pas à regarder du "C pseudo-objet"...

Après, y a pas que moi qui trouve que c'est de l'over-engineering, y a lui aussi [lien vers une discussion sur le stockage des mails]

Ton lien ne concerne pas du tout la problématique des lecteurs de news, mais l'indexation d'e-mails ; c'est absolument en-dehors du contexte.

Un lecteur de news tel que Pan, ça ne fait pas que permettre d'écrire et de scorer des messages. Il se doit de

- gérer des connexions multiples à des serveurs multiples
- stocker / afficher des attachements binaires, les décoder en reconnaissant les formats d'encodages les plus récents (yenc par exemple)
- repérer dans plusieurs messages des dizaines ou des centaines d'attachements binaires qui sont autant de parties d'un binaire unique (fichier ogg, archive rar, etc), et proposer un affichage & un traitement homogène de ces sous-parties
- reconnaître que plusieurs centaines ou milliers de messages portent un attachement binaire qui est incomplet
- tenir la volumétrie de certains newsgroups, sur certains serveurs, qui peuvent contenir plus d'un million de messages

L'utilisation de SQLite ouvrirait la voie à de nouvelles fonctionnalités très utiles pour beaucoup d'utilisateurs:
- gérer de manière unique des messages postés dans plusieurs groupes de discussion ; si la RFC prévoit un identifiant unique pour chaque message, dans la pratique les serveurs n'en tiennent pas compte, i.e. un client de news ne peut pas la plupart du temps demander à un serveur de récupérer le message ayant tel identifiant
- gérer plusieurs serveurs de news de manière transparente pour l'utilisateur ; bien souvent l'abonnement à un provider de news donne accès à un certain nombre de serveurs aux caractéristiques différentes (bande passante maximum, nombre de connexions simultanées, volume maximum de téléchargement autorisé par jour, rétention des messages de 5, 10, 15 jours, disponibilité ou non de tel ou tel groupe de discussion). L'idée serait donc de laisser l'utilisateur récupérer les messages de son choix, sans qu'il ait manuellement à gérer le choix des serveurs / groupes de discussion

s'appelle disc-cover. C'est un script perl qui fait un boulot admirable. L'essayer, c'est l'adopter.

Le programme utilise en entrée:
- un cd audio inséré dans ton lecteur
- ou bien un fichier de données cddb, en provenance par exemple de http://www.freedb.org(...)
- si nécessaire, une image jpeg ou png

Il utilise ensuite LaTeX pour générer une jaquette de très bonne qualité.
On peut utiliser plusieurs formats de jaquettes (cd normal, cd "slim", etc.)


* La page sur Freshmeat: http://freshmeat.net/projects/disc-cover/(...)
* La page principale: http://homepages.cwi.nl/~jvhemert/disc-cover.html(...)
* Sous Mandrake, une fois la source de paquetages "contrib" correctement configurée, on l'installe d'un coup de

urpmi disc-cover
* Un exemple (peut-être pas très sexy, mieux vaut l'essayer directement):
http://homepages.cwi.nl/~jvhemert/disc-cover/screenshot.jpg(...)

* Une page de "démo" qui permet de l'utiliser directement sans avoir à l'installer: http://freshmeat.net/redir/disc-cover/1929/url_demo/index.cgi(...)

Alors, quoi ? Que demander de mieux ;)

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

Oh la la... alors quand tu entends dire d'une petite bagnole qu'elle a tout d'une grande, tu vas crier au FUD parce qu'on a osé fairela comparaison avec ta grosse caisse avec ses 6 cylindres en Vrac ??


> 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. [...]

Merci pour l'adverbe, tout cela est très constructif.

Comme déjà dit, je ne me situais pas dans le contexte des applications client-serveur (encore que je serais ravi d'avoir une petite causerie là-dessus)

Il s'agissais simplement de considérer des applications indépendante sur un poste linux, par exemple de bureautique ; dans ce contexte, il y a des logiciels qui utilisent déjà des SGBD en mode client-serveur comme Postgres et MySQL, pour gérer leurs données ; je parle des tonnes d'outils de gestion de collection de mp3, de gestionnaires / créateurs d'albums photo (e.g. Zoph, Atomic Photo Album), de bookmarks, de notes, etc.

Pour toutes ces applications, ça a bien un sens de se demander, "tiens, et si au lieu de mettre en branle postgresql pour gérer mes 2 Mo de données, j'utilisais tout connement SQLite ?"

Et avant de chipoter sur ce que propose / ne propose pas SQLite, fais simplement la part des besoins des applications sus-citées. Ont-elles besoin d'un PL/SQL de la mort ? Ont-elles besoin d'un SGBD qui tourne en mode serveur, dont la mise en place échoit à l'utilisateur final ?

Si j'étais aussi "bête"

Mais non, tu as raison, c'est bien toi le plus intelligent. C'est un plaisir que de mener une conversation avec un être suprême comme toi.

Pour un lecteur news, un client RSS, ou un gestionaire d'album photo, c'est de l'over-engineering de débutant.

Débutant... hum... c'est pas la prétention qui t'étouffe... mais je ferai rien pour te contredire, si tu as besoin de te persuader que tu as la plus grosse ou fait plusieurs projets que quelqu'un dont tu ne connais rien.

Alors prenons simplement l'exemple d'un lecteur de news, ok ? Quel est le lecteur de news le plus riche ou un des plus aboutis sous linux ? Pan [1].
Les développeurs principaux, Chris Kerr et Duncan, ont commencé comme tout le monde par utiliser des formats de stockage "maison" dans de simples fichiers, pour toutes les données, relatives aux serveurs de news, aux liste de groupes, aux listes de groupes abonnés, aux listes d'en-têtes, aux corps de messages. Mais ils sont arrivés aux limites de ce mode de stockage, et sont précisément en train de tout réécrire...en utilisant SQLite.

Tiens, je te laisse leur adresse, histoire que tu ailles aussi les traiter de débutants:

Duncan <1i5t5 dot duncan at cox dot net>
Charles Kerr <charles at rebelbase dot com>


[1] http://pan.rebelbase.com/(...)

Bon, passons sur l'orthographe et l'absence totale de respect de la netiquette, visiblement ici ça passe bien d'écrire "vas-y, sors un peu ta quéquette, qu'on sache si tu as le droit d'écrire des choses pareils" à quelqu'un qu'on ne connaît pas. Soit.

Prenons un projet libre lambda. Le développeur de lambda a choisi comme format de stockage
- le XML, parce que ça fait hype et qu'il y a des tas d'API pour grignoter du XML, alors pourquoi s'emmerder, hein ?
- tout ça compressé via gzip

Bon, et mettons qu'un utilisateur de lambda arrive à 1000 enregistrements, ou unités d'informations pour le logiciel lambda. Ça, c'est du quotidien, c'est le cas par exemple de mes bookmarks sous Konqueror, j'en ai plus d'un millier, stockés bien évidemment comme il se doit dans un bon gros fichier xml.

Or ce que je prétends quand j'écris "Sans rien faire, il y a des chances que SQLite soit plus rapide que vous pour [...]", c'est tout bêtement que ces mêmes données stockées sous forme relationnelle dans un fichier de données SQLite, seront accédées beaucoup plus rapidement, à la louche je dirais de 100 à 1000 fois plus vite.

Avant d'y aller de ton petit commentaire méprisant, réfléchis-y juste 5 minutes ; relis l'article de Spolsky sur le B-A-BA du traitement de données XML / relationnel, que j'ai cité plus haut.

Moi j'y pense à chaque fois que konqueror mouline pour ajouter un bookmark, tout ça parce que le format choisi (XBEL) est un format d'échange et pas de stockage

Les extraits que tu donnes décrivent le comportement des versions 2.x de SQLite. Pour la version 3.0, cf. mon résumé, ou:

SQLite version 3.0 allows one process to begin writing the database while other processes continue to read. The writer must still obtain an exclusive lock on the database for a brief interval in order to commit its changes, but the exclusive lock is no longer required for the entire write operation. A more detailed [1] report on the locking behavior of SQLite version 3.0 is available separately.

[1] File Locking And Concurrency In SQLite Version 3
http://www.sqlite.org/lockingv3.html(...)


Voir aussi les deux extensions client-serveur que j'ai citées.

Bref, pas de quoi "revenir sur terre", comme tu dis si gentiment.

C'est intéressant, je ne connaissais pas ; mais si je lis bien la doc:

You register an undo operation by specifying the object that is changing (or the owner of that object), along with a method to invoke to revert its state, and the arguments for that method.

Cette API ne fait donc que déplacer le problème : pour annuler le résultat d'une fonction f qui assure un certain traitement, il faut se cogner l'écriture de la fonction inverse f^{-1} et la passer à l'API...

Au contraire, en utilisant SQLite, l'annulation ne nécessite pas de coder de fonction inverse, elle se fait simplement en exploitant les propriétés du modèle relationnel.

Franchement faut arrêter de délirer, un SGBD peut être une bonne solution, mais c'est loin d'être pertinent dans toutes les applications

Parfait, alors sur le fond on est d'accord. Je proposais simplement à tout développeur de regarder sérieusement SQLite, pas d'en faire sont Saint Graal.

Sur la forme de la réponse, classique sur linuxfr, qui consiste à balancer une réponse méprisante à son petit camarade et à réfléchir après, je te propose cette lecture enrichissante [1] qui discute entre autres des performances du traitement de données stockées sous forme relationnelle et sous forme de XML, juste histoire de se mettre d'accord sur ce dont on parle.

Méfie-toi, l'auteur est un ancien de chez Microsoft, donc c'est sûrement un autre gogo qui ne sait pas coder (ahem...)

[1] Joel Spolsky (2001) Back to Basics
http://www.joelonsoftware.com/articles/fog0000000319.html(...)

donc, si c'est si simple

Bien sûr que ça n'est pas aussi simple, j'ai volontairement grossi le trait mais tout ça reste valable pour l'écrasante majorité des applications présentes sur un poste de bureau sous Linux.

Mon discours s'adressait aux développeurs de logiciels de tous les jours, de clients RSS, de lecteurs de news, de générateurs d'albums photo, de montage vidéo, de tableurs, etc. Pour tous ces usages l'emploi de SQLite pour la gestion de la persistance de ses données est très pertinent, je le maintiens.

Inversement, je veux bien que tu me cites une seule application d'une distribution Mandrake (au hasard) qui ait potentiellement affaire à une fermeture transitive sur un arbre de 10 000 noeuds puis sur un graphe ( non fortement connexe ) contenant des cycles du meme nombre de noeuds... Honnêtement, c'est un peu pousser mémé dans les orties, non ?

le relationnel n'est pas une panacée, et ces 5 questions expose certains points faibles theoriques et pratiques du model

Ouais mais il s'agit pas de discuter de théorie et des faiblesses du modèle relationnel. Les utilisateurs de centaines de milliers d'applications client-serveur se disent pas tous les jours "ah merde, mes données sont stockées dans un SGBD relationnel, dont le modèle a des points faibles, quelle angoisse !!"

Mon propos était de proposer la puissance et la souplesse d'un SGBDR embarqué pour gérer les données d'une bête application autonome de tous les jours. Grâce à SQLite ça n'est pas réservé au client-serveur !

La question qui mérite d'être posée, c'est, plutôt que de réinventer la roue, un format de stockage de données, du code pour assurer la lecture / l'écriture / le traitement de ces données, pourquoi ne pas utiliser SQLite ? Pour les types d'applications que j'ai citées, on a tout à y gagner.

Et puisque tu sembles si bien connaître le modèle relationnel, pourquoi ne pas m'aider à défendre ce point de vue pour ce genre d'applications ?

Tu veux nourrir le troll ou lancer un débat constructif ?

SQLite peut être intéressant sur les toutes petites bases (2 ou 3 tables, quelques milliers d'enregistrement) MAIS que ça ne tient plus du tout la route pour les très grosses applications [...]

Ah bon ? Qu'est-ce que tu en sais, personnellement ? Tu as des tests à l'appui ?

Au hasard, extrait de la mailing-list SQLite du 25 Janvier 2003:

> A 32-bit primary key limits the number of entries in a single table
> to 2^32. But each such entry must be at least 24 bytes in size so
> we are already dealing with a 100GB database. And you can have
> multiple tables. So I don't think this is really a problem.

Ça laisse tout de même de quoi voir venir, hmm ?

De toute façon mon propos n'était pas de jouer les vendeurs de benchmarks de SGBD, on sait tous que ça ne rime à rien.

Il s'agit simplement de proposer à un développeur de logiciel libre (pas à une compagnie d'assurance hein, un gars qui code un client de courrier, un lecteur de news, un outil de dessin, que sais-je, la plupart des applications qu'on peut trouver sur un poste de bureau sous Linux), que ça peut être très judicieux d'utiliser SQLite pour assurer la persistance de ses données, point barre.

Et dans ce contexte, ça n'a aucun intérêt de faire la course aux gigaoctets ou aux millions de transactions par seconde, c'est pas le débat. Mais par contre, SQLite gère très bien une volumétrie beaucoup plus importante que ce que tu imagines.

... quelqu'un pourrait-il me dire si Yum et les outils d'administration sont codés en perl, ou en python ?

Decouvert la semaine derniere : je devais finir (enfin, commencer plutot ;-) une serie de presentations pour le lendemain ; j'emprunte le portable d'un collegue, sous Red Hat 9.1 je crois. Pour me detendre, je demarre xmms et je veux lire quelques mp3.

Et la j'ai la grosse surprise de voir s'afficher un message du genre:

"due to licensing/patent problems, support for mpeg 1/2/3 has been removed. Red Hat"


Ca m'en a donne des sueurs froides... depuis quand un vendeur de distributions de logiciel libres trouve-t-il normal de se poser en flic et de decider de ce que les utilisateurs peuvent ou ne peuvent pas faire ??? C'est encore possible de considerer par defaut les gens comme des adultes responsables ou bien on doit deja s'habituer au meilleur des mondes possibles, ou on sera pris en charge a 100 % ??? Plus besoin de partir a la recherche du bonheur, on le fait a votre place !!! Du pain, des jeux, un suppo et au lit !!!

Sans deconner, ca me fait gerber, y'a pas d'autre mot