Désolé coco on a déja fait pire : "opération espadon"
Le decor :
une espece de console surealiste avec 4 ecrans et pleins d'animations 3D bleus sur fond noir du meilleur effet.
La scene :
Travolta (un mechant terroriste) force le pauvre hero (Hugh Jackman en petit geni de l'informatique) a craquer une cle RSA (si si c'est marque dessus) avec un flingue sur la temp pendant que la splendide Hale Berry lui fait une fellation, juste histoire de prouver qu'il est le crack des crack ......
Un coup a reveiller des vocations d'informaticien.
Ah si un detail notable, un certain Linus se fait flinguer au debut du film.
La raison en est simple : ca fait longtemps que l'on sait modifier une image de façon non decelable.
En temps reel c'est plus dur, mais si je ne m'abuse les tribunes de la coupe du monde de foot de 98 (en France c'etait bien 98 ? ) etaient retransmise censurees en Arabie Saoudite en quasi temps reel.
Ca fait longtemps qu'on est loin des caviardages ridicules de l'epoque stalinienne.
Si recemment le montage de Kerry / Jane Fonda à une manif anti-vietnam qui etait un montage grossier a mis plusieurs semaines pour etre demonté, tu peux imaginer du travail pro sur des personnes ne pouvant pas protester de façon credible.
La situation est simple : aucune image n'est credible, aucune image n'est au dessus d'une alteration invisible.
Il suffit de voir les effets speciaux des films recents : on le les voit plus !
Ca n'est donc pas ce programme qui va changer cet etat de fait.
Le probleme etant que sont considéré comme brevetable les procédés incluant un élément non logiciel, utilisant ce biais sont déposés des brevets ou l'effet physique est la portion congrue mais protégeant le logiciel.
Il est possible(je l'ai vu passer) de considerer un systeme incluant un ordinateur et son logiciel et de proteger le tout.
Bien sur tu pourras utiliser ton logiciel, amoureusement realise avec tes mimines, quoique couvert par le brevet, tant que ca n'est pas sur un ordinateur.
(evidemment l'ordinateur sera sans doute decris comme "un systeme electronique de calcul et d'execution d'instructions preprogrammées" pour plus de .... hum .... clareté)
Je pense que la nocivité des brevets logiciels pour les particuliers, logiciels libres, et PME est relativement peut difficile a comprendre.
Mais ce que je voulais souligner c'est que ce discours de "non mais", sans doute délibéremment ambigu n'est pas l'apanage du MEDEF mais est une constante dans la phraséologie "pro brevet".
Le probleme est que aprés cet encourageant préambule, sans le formuler tel quel, le MEDEF defend l'idée de brevet logiciels.
Pas directement en tant que "breveter des programmes", mais en soulignant que les inventions de nature informatiques doivent etre protégées par des brevets, que les brevets du domaine n'ont pas de raison d'être plus nuisibles qu'ailleurs.
Il est a noter que cette position est trés similaire a celle de l'OEB qui se contente de considérer que "un effet technique" est produit dans un trés large éventail de conditions. Si large qu'on y passe des brevets logiciels sans les nommer comme tels explicitement.
Bref la position du MEDEF est peut explicite mais de ma lecture, tout a fait similaire à celle (critiquée à raison) de l'OEB.
En regardant le code, le plus pittoresque et que le SPAN de pub est imbriqué 10 fois dans lui même juste au cas ou .....
En exclusivité le merveilleux texte offert par le MEDEF : CLICK HERE to capitalize on a $5 billion a year industry with a home-based, no-inventory business opportunity. Low $65K investment. BudgetBlinds.com, over 600 franchises nationwide.
Excuse moi mais c'est juste une bete reprise de la definition du concept de brevet : un monopole temporaire délivré en vue de promouvoir l'innovation et le partage de la connaissance.
L'idée étant d'éviter la perte de l'info secrete d'une recette de fabrication à la disparition de son inventeur.
Maintenant que ca s'applique au domaine du logiciel est une autre affaire.
En ce concerne les inventions mises en oeuvre par logiciels, cela fait plus de 20 ans que kes offices de brevets ont développé une pratique interprétative des dispositions législatives sur le sujet. L'évolution des technologies nécessite aujourd'hui que la situation soit clarifiée pour éviter une conclusion préjudiciable à la sécurité dont les entreprises ont besoin pour développer et protéger leurs innovations. Les programmes d'ordinateurs en tant que tels relèvent de la protection par le droit d'auteur et ne peuvent être brevetés. ertaines décisions d'office de brevet ont pu jeter un doute sur ce point. Ce qui relève du brevet, c'est l'invention d'un nouveau procédé technique ou d'un produit industriel, même si leur mise en oeuvre fait appel à des moyens logiciels ou inclut un logiciel. En revanche, la protection par le brevet est et doit rester indépendante des modèles économiques sur lesquels repose la commercialisation des produits correspondants.
Le modèle dit "propriétaire" et le modèle dit "libre" sont compatibles avec la protection de l'innovation par le brevet. Certains économistes mettent par ailleurs en avant le risque que de trop nombreux brevets rendent excessivement onéreux les coûts de transaction associés au développemen de nouveaux systèmes informatiques. Le risque évoqué ici est la constitution de "maquis de brevets" comme on en connait dans d'autres domaines à forte composante brevet, comme lélectronique grand public ou les systèmes de télécommunication, des domaines où pourtant la concurrence est ouverte et vigoureuse. Les mécanismes régulateurs mis au point dans ces domaines à forte propension au brevet, accords de license croisée, pools de brevets et processus de normalisation ou les participants s'engagent à accorder des licenses à des conditions raisonnables et non-discriminatoires, ont fait la preuve de leur efficacité. Mais là comme ailleurs, il faut éviter les dérives vers une brevetabilité trop facilement admise et revenir vers une apréciation rigoureuse du caractère innovant des inventions présentées.
Comme clarification je trouve qu'on fait plus limpide ...
En tout cas si le libre est compatible avec les brevets, je peux dormir tranquille, c'est le MEDEF qui me le dit.
Il faut voir aussi que PHP est particulierement un contre exemple en matiere de genie logiciel : pas de conventions de nommages uniforme, operateurs de comparaisons aux effets de bord delirants, injection implicite de l'environnement et des parametres de CGI dans des varaibles globales (plus maintenant je sais, mais moult scripts utilisent encore cette fonction d'ou l'obligation fréquente de l'activer), options de l'interpreteur globales aux serveur ....
D'autre languages comme Python, Ruby, Perl, Scheme, Smalltalk ... (liste evidemment non exhaustive) ont un systeme de types flexible et n'ont pas les memes defauts.
Par contre ADA (ADA83), j'ai eu le "plaisir" de me le voir enseigner y'a quelques années. Ca comprenait plein de fonctions destinées à une bonne organisation des projets logiciels, les premiers templates, types avec contraintes, et pas mal de fonctions tres modernes.
Le language est un peut verbeux à mon gout (pas trés éloigné du Pascal de Delphi en fait), mais franchement ce qui etait insupportable etait la verbosité des messages et la lenteur du compilo.... (ok cette remarque s'applique au C++ et ses templates maintenant) .
Pour ce qui est d'UML, l'usage est plutot d'utiliser un stockage objet quand on modélise en objet (meme si ce stockage n'est qu'une couche de sérialisation par dessus un SGBDR). D'experience on rencontre d'ailleurs souvent des boucles avec des conditions complexes parcourant des listes d'objets pour faire des operations de reporting qui seraient triviales en attaquant directement la couche relationnelle.
Ma conclusion : vive l'hybridation.
Quand j'ai dis, malencontreusement "de l'odre de la dizaine", je pensais en fait "se compte en dizaines" comparé à la dizaine de milliers de tables d'un SAP.
Par contre j'ai évoqué une compta et le problème que tu poses est celui d'un ERP ( gestion de stocks, de RH, des caisses ...). Je peux t'assurer que ce genre de fonction ne sont pas dans un soft de compta de base (elles font l'objet de fort couteux modules d'extension).
Bref, comme je n'ai pas 3 mois devant moi et non plus qu'une connaissance correcte de la grande distrib je ne m'attaquerai pas à ton exemple.
Mais si tu te referes à ma remarque plus haut tu noteras que je postule que justement la complexité est inhérente à ce genre de problème qui croise une multitude de facteurs et pas à leur representation relationnelle.
Par contre je serai curieux (réellement, sans volonté polémique) de savoir comment ce genre de problème se résout en le modélisant par des graphes et quels outils tu peux utiliser pour passer du modèle à l'implémentation. Si c'est possible ca m'intéresse grandement.
Si je ne m'abuse LDAP, XML sont des modéles d'arbres, pas de graphes(non dégénérés) ou justement on introduit des ID un peut artificiels pour representer les relations transversales.
Dans les bases XMLnatives il y'a aussi Tamino de Software AG qui prétend à devenir pour le XML ce qu'Oracle est au relationnel.
De ma faible experience, SQLite et Ms Acces ont un point commun : toute la base est dans un seul fichier et ils sont prévus pour être utilisés par une appli à la fois (même si on peut y acceder de l'extérieur si on est pervers ou faineant).
Le SQL de MsAcces est un chouia particulier car il melange sa syntaxe à celle du Basic ce qui peut etre énervant (par exemple, le caractère de troncature est * et non %, les caractères de délimitation de nom de champs ou de table sont [ et ] au lieu de "...
Bref, SQLite est un peut plus orthodoxe.
Par contre MsAccess offre un moteur de gestion de formulaire, de rapports et un environnement de développement, alors que SQLite est concu pour s'intégrer dans des applis tierces.
A mon avis SQLite serai un trés bonne base pour construire un concurent d'Access (qui à ma connaissance n'existe pas dans le monde libre), mais n'est pas aujourd'hui tout à fait comparable.
Le mapping Merise/relationnel est bien connu et couremment pratiqué.
Bon de toute façon la popularité de Merise est en chute libre, ce qui n'est pas le cas des bases relationnelles.
Pour une application de compta même analytique, certe beaucoup de tables sont vites requises (mais de l'ordre de la dizaine plutot que les 10aines de millier de SAP).
Mon postulat est que dans le cadre d'une implémentation pratique avec les outils aujourd'hui couremment disponibles. Un SGBDR est un excellent outil, sans doute le meilleur dans la plupart des applis de gestion.
Je ne trouve pas que les SGBDO apportent d'ameliorations substancielles dans ce genre de contextes.
Et je ne connais pas d'outil permettant de modéliser une problématique en terme de graphes et de construire une appli autour.
Je n'affirme pas qu'un moteur relationnel soit la panacée, mais il faut bien admettre que c'est une solution qui à énormément progressé depuis les années 80 (y compris par l'absorbtion de techniques exogènes au relationnel : cubes de données, systèmes de types extensibles, traitement du plein texte...(je ne parlerai pas des fonctions d'arbres d'Oracle) ) et dont les implémentations offrent un souplesse que peut d'outils alternatifs offrent.
Enfin à peut de choses prét nous devons être du même avis.
J'ai un exemple simple, j'ai un client qui fait de la veille pour lequel on etudie un outil.
Il est intéressé à stocker les feeds d'info(Reuter par exemple) auquels il est abonné et quelques feeds RSS et des listes de brevets.
Il veut pouvoir taper dedans pour sortir: les articles écrits par le professeur bidule ou les entrées qui mentionnent le labo de bidulotique entre le 42 janvier et 54 fevrier, ou les articles donc les intervenants sont mentionnés dans des publications comportant le mot clé machinosetriphasée...
C'est un besoin qui dépasse le simple client RSS, mais avec la généralisation du format je ne serai pas surpris de voir pas mal de monde thésauriser les feeds pour retrouver des articles.
C'est sur on peut tout stocker en XML ou un format texte, mais pour de la recherche structurée c'est pas l'extase.
Pour le mail, il me semble que la popularité de l'annonce de GMail est la preuve que mon genre de mailomanie n'est pas si exceptionnel.
D'expérience, ces derniers mois, 20Mo c'est plutot le courrier de la semaine d'un utilisateur pas la totalité de ses archives de courriel.
En ce qui me concerne, j'indexe toutes les nuits le mail en tenant compte des infos structurées : FROM, TO, SUBJECT, MAIL-ID, MIME-PARTS ... Du coup je peux interroger la base pour sortir les emails avec un attachement en .PPT envoyés par machin (pour retrouver toutes les bonnes blagues qu'on m'a envoyé).
En cherchant le texte brut je perds la structuration. II y'a bien des outils pour chercher dans les mailbox mais c'est long et lent surtout quand tu recherches sur moult fichiers.
Bref mon bidule est un petit outil en ligne de commande d'un intéret tellement insignifiant que je suis le seul utilisateur, mais je m'en sers trés régulièrement et ca marche de façon simple, pas besoin de Google ou WinFS (ou BeFS) et c'est substanciellement plus rapide que la recherche depuis un client mail. Utiliser SQLite m'a permis de le faire en quelques heures de boulot au lieu de quelques jours si j'avais du coder les détails.
Pour la corruption de données, je pense surtout a celles dues à des bugs ou des problèmes de régression. J'en ai rencontré pas mal en particulier dans des softs "sur mesure" réalisés par des SSII aux contraintes de temps trop serrées mais aussi dans des grandes applications, censées être fiables.
L'idée de se baser sur une lib deja existante permet de déporter le problême : plus de monde qui rencontre les bugs implique plus de chance que ceux -ci soient corrigés sans avoir à le faire soit même, qui plus est qui dit upgrade du format dit outils de migration, ne pas avoir à les réaliser est un sacré gain de temps.
Si ce format est une BDD, dans pas mal de cas ca me parait avantageux.
Evidemment ca ne réponds pas à tous les besoins, mais même pour des quantités d'info moyennes l'économie de code complexe (recherches, tris, arbres, skip-list ou table de hashage) est une réduction considérable de risque de bugs. Je ne sais pas pour toi, mais personnellement, je trouve un rapport direct entre la quantité de code que j'écris et le nombre de bugs.
Pour les clowns, j'ai deja récupéré des projets sous-traités à la petite semaine, développés par des gars reconvertis informaticiens en 6 mois et qui avaient eu un cours de C with class pompeusement nommé C++ et qui n'avaient jamais entendu parler de namespace et encore moins de containeurs de la lib standard.
Alors évidemment, #include <algorithm> et utiliser des iterateurs c'est semble plus compliqué que de magouiller un truc bizarre avec une double liste chainée maison ( en plus une liste utilisée pour des pour des accés aléatoires) dans de telles conditions.
Bref du code moisi, c'est fréquent, et quand on utilise une librairie ad-hoc pour le boulot ca laisse moins d'opportunité de se tirer dans les pieds (enfin ca requiers 3 notions de SQL qui ne sont pas données à tous le monde mais tout de même ...).
Enfin au final je pense que nous sommes d'accord, ca n'est pas une solution universelle mais ca peut servir.
Je n'ai écrit ni newsreader ni client RSS, mais si j'imagine un usage un peut intensif du client RSS, ca va me permettre de faire des corrélations entre sources mais aussi de proposer à l'utilisateur de chercher dedans de façon tres evoluée.
Pour un client mail je vois tout de suite l'usage, j'ai personnellement plus de 2Gb de mail (je ne jette rien depuis 1997) et j'ai écris mon propre petit outil d'indexation (avec SQLLite il se trouve) pour chercher dedans plus simplement qu'avec aucun client mail que je connaisse. Rien de bien tordu mais ca marche et vite (le fichier de reference fait environ 15Mb).
"Lire et écrire un fichier n'est pas particulièrement compliqué, "; Il n'y qu'a voir avec quelle régularité un bon nombre d'applis corrompent leurs données, ou deviennent incapable de relire leur formats de fichiers entre deux versions. Faire une paire de routines de lecture écriture de fichier n'est pas bien compliqué, mais définir un bon format de fichier, le faire vivre et évoluer, ca n'a rien de simple. La dessus ajoute le fait que pour debugguer le tout il faudra sans doute ecrire ses propres outils d'exploration, génération d'exemples, mise à jour ..... bref ca devient vite compliqué.
Bien sur avec un format pur texte c'est plus simple, à condition d'avoir pensé au départ au multilinguisme, et à encoder les données purement binaire (son, images, échantillions de mesures) avant de les écrire (et évidemment faire attention à l'encodage entre librairies : chaines UTF-XX, ASCII, 8859-xx ?).
Au final si tant de monde adopte le XML et les librairies de lecture/écriture de ce format ca n'est pas sans bonnes raisons.
Pour ce qui est des fonctions de tri, oui il y'en a partout, mais il faut a chaque fois recoder les fonctions de comparaison, c'est à mes yeux plus complexe (surtout à maintenir) qu'une syntaxe dédiée à cet usage telle celle du SQL. Sans compter que moult programmeurs préferent réimplementer leur propres fonctions plutot que tenter d'utiliser les fonctions évoluées des bibliothèques (voir l'usage de la librairie standard C++ hors du cercle des experts de la norme).
SQLLite fournit un stockage relationnel, et les outils qui vont avec, je vois peut de problèmes provoqués par cela (mais je ne vais pas essayer de faire rentrer dedans des données qui ne s'y pretent pas).
La news est un chouia enthousiaste, mais je m'y joins pour inviter chaque programmeur qui ne soit pas trop "à cheval" sur la GPL à jeter un oeil à SQLite parceque c'est bien fichu et vraiment à connaitre pour LA fois ou ce sera peut être la réponse au problème du jour.
Compare la chienlie qu'est de travailler sur un DOM, ou en SAX avec document un peut complexe, ou d'utiliser des jolies requetes XML Query avec une pincée de XSL sur ce document, à la simplicité d'opérations en SQL (sauf les opérations de recherche plein texte, d'arborescences et de graphes qui sont en general l'objet d'extensions propriétaires plus ou moins élégantes).
A mes yeux le XML n'est pas plus souple à utiliser, ca ressemble bougrement à une base de donnée hyérachique(http://en.wikipedia.org/wiki/Hierarchical_database(...)) sur lesquelles les SGBDR ont été une innovation considérable. Croiser des infos en XML n'a rien de trivial.
Bref XML est bien sympa pour échanger des infos mais rarement pour les traiter.
"un SGBD peut être une bonne solution, mais c'est loin d'être pertinent dans toutes les applications. Voilà c'est mon avis sur cette publicité. " 100% d'accord !
Enfin n'oublions pas que SQLite ne s'inscrit pas en concurent de serveur de base de données, mais au contraire plutot comme une librairie à intégrer dans une application pour gérer ses données de façon rapide et flexible.
Le XML est par contre un excellent candidat aux fonctions d'import/export/sauvegarde/echanges reseaux ....
Tu as indeniablement raison : on trouve des arbres et des graphes partout.
Mais, tu admettras tout de meme que dire "rapport signal/bruit aux niveaux des tables tendant rapidement vers 0 ( un bon exemple est les 12 000 tables de SAP/V3 )" est de la mauvaise fois. SAP n'est pas une application simple ou rapidement concue. Pour modeliser ce que SAP tend à automatiser (soit à peut prés tout les proccessus d'une entreprise), il n'y sans doute pas de modele de représentation qui soit trivial, car le probleme est en soit (exagerement?) complexe.
Si les SGBR ne sont évidemment pas une sorte de panaçée universelle, ils offrent une solution pratique dans pas mal de cas. En particuliers dans tous les cas, généralement peut intéressants sur le plan de la recherche actuelle, mais forts courant dans une utilisation courante de l'informatique : quand un probleme se decompose bien en entites/relations.
Bref, il y'a malheureusement en informatique des modes et des cycles technologiques qui ne sont pas toujours rationnels, les meilleures solutions sont rarement pures (objet ou client/serveur ou relationnelles ou fonctionnelles ou centralisées ou scripts ou ....), même si le vendeur de chaque techno la vend comme telle.
Il faut faire avec, mais ca n'empeche pas SQLite d'être un bon petit outil bien pratique à connaitre.
Le probleme surgit quand avec ton format de fichier tu veux comparer deux "bidules" qu'a priori tu n'avais pas pensé à correller et qui, justement se trouvent coincés chacun au bout d'une joli structure arborescente.
L'avantage de SQLite, c'est que tu vas resoudre pas mal de problemes avec de "simples" requetes SQL et passer moins de temps sur les problemes de tris, retris, croisement et sauvegardes de fichiers...
Combien de temps perdu a reecrire des sauvegardes/chargements de fichiers (buggués bien sur) ?
Combien de quicksort ont été 100 fois réécris ?
Quand tu consideres qu'en plus SQLLite est plutot compact et rapide et fait des fichiers d'une taille assez raisonnable, ca le place tout betement comme un excellent outil dans la panoplie du programmeur, en particulier dans les applis interactives ou on a pas forcement envie d'imposer un backend SGBD à l'utilisateur.
[^] # Re: j'ai peur, pas vous ?
Posté par Christophe Renard . En réponse à la dépêche Une bibliothèque graphique de l'INRIA Sophia-Antipolis sous GPL. Évalué à 2.
http://www.cs.dartmouth.edu/~farid/publications/(...)
Des lectures intéressantes.
Par le bon vieux mecanisme de l'épé et du bouclier, je présume que ca n'est que transitoire.
To be continued ...
[^] # Re: Films nazes
Posté par Christophe Renard . En réponse au sondage Parmi ces films, le plus naze est. Évalué à 2.
cf :
http://www2.warnerbros.com/operationswordfish/ms/index.html(...)
[^] # Re: Films nazes
Posté par Christophe Renard . En réponse au sondage Parmi ces films, le plus naze est. Évalué à 3.
Le decor :
une espece de console surealiste avec 4 ecrans et pleins d'animations 3D bleus sur fond noir du meilleur effet.
La scene :
Travolta (un mechant terroriste) force le pauvre hero (Hugh Jackman en petit geni de l'informatique) a craquer une cle RSA (si si c'est marque dessus) avec un flingue sur la temp pendant que la splendide Hale Berry lui fait une fellation, juste histoire de prouver qu'il est le crack des crack ......
Un coup a reveiller des vocations d'informaticien.
Ah si un detail notable, un certain Linus se fait flinguer au debut du film.
[^] # Re: j'ai peur, pas vous ?
Posté par Christophe Renard . En réponse à la dépêche Une bibliothèque graphique de l'INRIA Sophia-Antipolis sous GPL. Évalué à 4.
En temps reel c'est plus dur, mais si je ne m'abuse les tribunes de la coupe du monde de foot de 98 (en France c'etait bien 98 ? ) etaient retransmise censurees en Arabie Saoudite en quasi temps reel.
Ca fait longtemps qu'on est loin des caviardages ridicules de l'epoque stalinienne.
Si recemment le montage de Kerry / Jane Fonda à une manif anti-vietnam qui etait un montage grossier a mis plusieurs semaines pour etre demonté, tu peux imaginer du travail pro sur des personnes ne pouvant pas protester de façon credible.
La situation est simple : aucune image n'est credible, aucune image n'est au dessus d'une alteration invisible.
Il suffit de voir les effets speciaux des films recents : on le les voit plus !
Ca n'est donc pas ce programme qui va changer cet etat de fait.
# Flash oui, mais surtout Tables
Posté par Christophe Renard . En réponse à la dépêche Résultats du concours Zopeur.org. Évalué à 8.
C'est pas terrible comme exemples de bonne utilisation je trouve.
Menfin
[^] # Re: Cette phrase ne compte pas ?
Posté par Christophe Renard . En réponse à la dépêche Le Medef prend position pour les brevets logiciels. Évalué à 3.
Le probleme etant que sont considéré comme brevetable les procédés incluant un élément non logiciel, utilisant ce biais sont déposés des brevets ou l'effet physique est la portion congrue mais protégeant le logiciel.
Il est possible(je l'ai vu passer) de considerer un systeme incluant un ordinateur et son logiciel et de proteger le tout.
Bien sur tu pourras utiliser ton logiciel, amoureusement realise avec tes mimines, quoique couvert par le brevet, tant que ca n'est pas sur un ordinateur.
(evidemment l'ordinateur sera sans doute decris comme "un systeme electronique de calcul et d'execution d'instructions preprogrammées" pour plus de .... hum .... clareté)
[^] # Re: Cette phrase ne compte pas ?
Posté par Christophe Renard . En réponse à la dépêche Le Medef prend position pour les brevets logiciels. Évalué à 3.
Mais ce que je voulais souligner c'est que ce discours de "non mais", sans doute délibéremment ambigu n'est pas l'apanage du MEDEF mais est une constante dans la phraséologie "pro brevet".
[^] # Re: Cette phrase ne compte pas ?
Posté par Christophe Renard . En réponse à la dépêche Le Medef prend position pour les brevets logiciels. Évalué à 3.
Pas directement en tant que "breveter des programmes", mais en soulignant que les inventions de nature informatiques doivent etre protégées par des brevets, que les brevets du domaine n'ont pas de raison d'être plus nuisibles qu'ailleurs.
Il est a noter que cette position est trés similaire a celle de l'OEB qui se contente de considérer que "un effet technique" est produit dans un trés large éventail de conditions. Si large qu'on y passe des brevets logiciels sans les nommer comme tels explicitement.
Bref la position du MEDEF est peut explicite mais de ma lecture, tout a fait similaire à celle (critiquée à raison) de l'OEB.
[^] # Re: Je ne lis pas la même chose que vous ...
Posté par Christophe Renard . En réponse à la dépêche Le Medef prend position pour les brevets logiciels. Évalué à 8.
OEB qui à tout de même laissé passer quelques 10 000 brevets logiciels ou affinitaires malgré une interdiction légale explicite.
C'est trés rassurant tout cela.
[^] # Re: Vous avez vu le code source de la page???
Posté par Christophe Renard . En réponse à la dépêche Le Medef prend position pour les brevets logiciels. Évalué à 4.
En exclusivité le merveilleux texte offert par le MEDEF :
CLICK HERE to capitalize on a $5 billion a year industry with a home-based, no-inventory business opportunity. Low $65K investment. BudgetBlinds.com, over 600 franchises nationwide.
Tout un programme !
ROFL
[^] # Re: Vous avez vu le code source de la page???
Posté par Christophe Renard . En réponse à la dépêche Le Medef prend position pour les brevets logiciels. Évalué à 6.
Et effectivement la page contient un merveilleux morceau de SPAM.
Tres drole je trouve.
[^] # Re: partie specifiquement sur les brevets logiciels :
Posté par Christophe Renard . En réponse à la dépêche Le Medef prend position pour les brevets logiciels. Évalué à 2.
désolé pour les fautes de frappes qui sont miennes aussi.
[^] # Re: C'est pas étonnant.
Posté par Christophe Renard . En réponse à la dépêche Le Medef prend position pour les brevets logiciels. Évalué à 5.
un monopole temporaire délivré en vue de promouvoir l'innovation et le partage de la connaissance.
L'idée étant d'éviter la perte de l'info secrete d'une recette de fabrication à la disparition de son inventeur.
Maintenant que ca s'applique au domaine du logiciel est une autre affaire.
# partie specifiquement sur les brevets logiciels :
Posté par Christophe Renard . En réponse à la dépêche Le Medef prend position pour les brevets logiciels. Évalué à 7.
Le modèle dit "propriétaire" et le modèle dit "libre" sont compatibles avec la protection de l'innovation par le brevet. Certains économistes mettent par ailleurs en avant le risque que de trop nombreux brevets rendent excessivement onéreux les coûts de transaction associés au développemen de nouveaux systèmes informatiques. Le risque évoqué ici est la constitution de "maquis de brevets" comme on en connait dans d'autres domaines à forte composante brevet, comme lélectronique grand public ou les systèmes de télécommunication, des domaines où pourtant la concurrence est ouverte et vigoureuse. Les mécanismes régulateurs mis au point dans ces domaines à forte propension au brevet, accords de license croisée, pools de brevets et processus de normalisation ou les participants s'engagent à accorder des licenses à des conditions raisonnables et non-discriminatoires, ont fait la preuve de leur efficacité. Mais là comme ailleurs, il faut éviter les dérives vers une brevetabilité trop facilement admise et revenir vers une apréciation rigoureuse du caractère innovant des inventions présentées.
Comme clarification je trouve qu'on fait plus limpide ...
En tout cas si le libre est compatible avec les brevets, je peux dormir tranquille, c'est le MEDEF qui me le dit.
[^] # Re: Humour ou facilité d'apprentissage ?
Posté par Christophe Renard . En réponse à la dépêche Être orateurs aux RMLL à 13 ans? Avec Ada, même ça c'est possible!. Évalué à 9.
D'autre languages comme Python, Ruby, Perl, Scheme, Smalltalk ... (liste evidemment non exhaustive) ont un systeme de types flexible et n'ont pas les memes defauts.
Par contre ADA (ADA83), j'ai eu le "plaisir" de me le voir enseigner y'a quelques années. Ca comprenait plein de fonctions destinées à une bonne organisation des projets logiciels, les premiers templates, types avec contraintes, et pas mal de fonctions tres modernes.
Le language est un peut verbeux à mon gout (pas trés éloigné du Pascal de Delphi en fait), mais franchement ce qui etait insupportable etait la verbosité des messages et la lenteur du compilo.... (ok cette remarque s'applique au C++ et ses templates maintenant) .
[^] # Re: explosion du trokilometre
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.
Postgresql pourrait faire l'affaire, mais pas de bol plein d'employés travaillent sur des portables sous Winxx dans leur coin.
SQLLite avec quelques fonctions de synchro "custom", ca marche bien.
[^] # Re: explosion du trokilometre
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.
Ma conclusion : vive l'hybridation.
Quand j'ai dis, malencontreusement "de l'odre de la dizaine", je pensais en fait "se compte en dizaines" comparé à la dizaine de milliers de tables d'un SAP.
Par contre j'ai évoqué une compta et le problème que tu poses est celui d'un ERP ( gestion de stocks, de RH, des caisses ...). Je peux t'assurer que ce genre de fonction ne sont pas dans un soft de compta de base (elles font l'objet de fort couteux modules d'extension).
Bref, comme je n'ai pas 3 mois devant moi et non plus qu'une connaissance correcte de la grande distrib je ne m'attaquerai pas à ton exemple.
Mais si tu te referes à ma remarque plus haut tu noteras que je postule que justement la complexité est inhérente à ce genre de problème qui croise une multitude de facteurs et pas à leur representation relationnelle.
Par contre je serai curieux (réellement, sans volonté polémique) de savoir comment ce genre de problème se résout en le modélisant par des graphes et quels outils tu peux utiliser pour passer du modèle à l'implémentation. Si c'est possible ca m'intéresse grandement.
Si je ne m'abuse LDAP, XML sont des modéles d'arbres, pas de graphes(non dégénérés) ou justement on introduit des ID un peut artificiels pour representer les relations transversales.
Dans les bases XMLnatives il y'a aussi Tamino de Software AG qui prétend à devenir pour le XML ce qu'Oracle est au relationnel.
Pour les graphes ?
[^] # Re: BerkeleyDB ?
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.
Pour le mode lib de MySQL .... interessant a voir.
En tout cas un des interets de SQLite c'est que c'est tout petit a linker.
[^] # Re: SQLite vs MS Access
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.
Le SQL de MsAcces est un chouia particulier car il melange sa syntaxe à celle du Basic ce qui peut etre énervant (par exemple, le caractère de troncature est * et non %, les caractères de délimitation de nom de champs ou de table sont [ et ] au lieu de "...
Bref, SQLite est un peut plus orthodoxe.
Par contre MsAccess offre un moteur de gestion de formulaire, de rapports et un environnement de développement, alors que SQLite est concu pour s'intégrer dans des applis tierces.
A mon avis SQLite serai un trés bonne base pour construire un concurent d'Access (qui à ma connaissance n'existe pas dans le monde libre), mais n'est pas aujourd'hui tout à fait comparable.
[^] # Re: explosion du trokilometre
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 3.
Bon de toute façon la popularité de Merise est en chute libre, ce qui n'est pas le cas des bases relationnelles.
Pour une application de compta même analytique, certe beaucoup de tables sont vites requises (mais de l'ordre de la dizaine plutot que les 10aines de millier de SAP).
Mon postulat est que dans le cadre d'une implémentation pratique avec les outils aujourd'hui couremment disponibles. Un SGBDR est un excellent outil, sans doute le meilleur dans la plupart des applis de gestion.
Je ne trouve pas que les SGBDO apportent d'ameliorations substancielles dans ce genre de contextes.
Et je ne connais pas d'outil permettant de modéliser une problématique en terme de graphes et de construire une appli autour.
Je n'affirme pas qu'un moteur relationnel soit la panacée, mais il faut bien admettre que c'est une solution qui à énormément progressé depuis les années 80 (y compris par l'absorbtion de techniques exogènes au relationnel : cubes de données, systèmes de types extensibles, traitement du plein texte...(je ne parlerai pas des fonctions d'arbres d'Oracle) ) et dont les implémentations offrent un souplesse que peut d'outils alternatifs offrent.
Enfin à peut de choses prét nous devons être du même avis.
[^] # Re: explosion du trokilometre
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 5.
Il est intéressé à stocker les feeds d'info(Reuter par exemple) auquels il est abonné et quelques feeds RSS et des listes de brevets.
Il veut pouvoir taper dedans pour sortir: les articles écrits par le professeur bidule ou les entrées qui mentionnent le labo de bidulotique entre le 42 janvier et 54 fevrier, ou les articles donc les intervenants sont mentionnés dans des publications comportant le mot clé machinosetriphasée...
C'est un besoin qui dépasse le simple client RSS, mais avec la généralisation du format je ne serai pas surpris de voir pas mal de monde thésauriser les feeds pour retrouver des articles.
C'est sur on peut tout stocker en XML ou un format texte, mais pour de la recherche structurée c'est pas l'extase.
Pour le mail, il me semble que la popularité de l'annonce de GMail est la preuve que mon genre de mailomanie n'est pas si exceptionnel.
D'expérience, ces derniers mois, 20Mo c'est plutot le courrier de la semaine d'un utilisateur pas la totalité de ses archives de courriel.
En ce qui me concerne, j'indexe toutes les nuits le mail en tenant compte des infos structurées : FROM, TO, SUBJECT, MAIL-ID, MIME-PARTS ... Du coup je peux interroger la base pour sortir les emails avec un attachement en .PPT envoyés par machin (pour retrouver toutes les bonnes blagues qu'on m'a envoyé).
En cherchant le texte brut je perds la structuration. II y'a bien des outils pour chercher dans les mailbox mais c'est long et lent surtout quand tu recherches sur moult fichiers.
Bref mon bidule est un petit outil en ligne de commande d'un intéret tellement insignifiant que je suis le seul utilisateur, mais je m'en sers trés régulièrement et ca marche de façon simple, pas besoin de Google ou WinFS (ou BeFS) et c'est substanciellement plus rapide que la recherche depuis un client mail. Utiliser SQLite m'a permis de le faire en quelques heures de boulot au lieu de quelques jours si j'avais du coder les détails.
Pour la corruption de données, je pense surtout a celles dues à des bugs ou des problèmes de régression. J'en ai rencontré pas mal en particulier dans des softs "sur mesure" réalisés par des SSII aux contraintes de temps trop serrées mais aussi dans des grandes applications, censées être fiables.
L'idée de se baser sur une lib deja existante permet de déporter le problême : plus de monde qui rencontre les bugs implique plus de chance que ceux -ci soient corrigés sans avoir à le faire soit même, qui plus est qui dit upgrade du format dit outils de migration, ne pas avoir à les réaliser est un sacré gain de temps.
Si ce format est une BDD, dans pas mal de cas ca me parait avantageux.
Evidemment ca ne réponds pas à tous les besoins, mais même pour des quantités d'info moyennes l'économie de code complexe (recherches, tris, arbres, skip-list ou table de hashage) est une réduction considérable de risque de bugs. Je ne sais pas pour toi, mais personnellement, je trouve un rapport direct entre la quantité de code que j'écris et le nombre de bugs.
Pour les clowns, j'ai deja récupéré des projets sous-traités à la petite semaine, développés par des gars reconvertis informaticiens en 6 mois et qui avaient eu un cours de C with class pompeusement nommé C++ et qui n'avaient jamais entendu parler de namespace et encore moins de containeurs de la lib standard.
Alors évidemment, #include <algorithm> et utiliser des iterateurs c'est semble plus compliqué que de magouiller un truc bizarre avec une double liste chainée maison ( en plus une liste utilisée pour des pour des accés aléatoires) dans de telles conditions.
Bref du code moisi, c'est fréquent, et quand on utilise une librairie ad-hoc pour le boulot ca laisse moins d'opportunité de se tirer dans les pieds (enfin ca requiers 3 notions de SQL qui ne sont pas données à tous le monde mais tout de même ...).
Enfin au final je pense que nous sommes d'accord, ca n'est pas une solution universelle mais ca peut servir.
[^] # Re: explosion du trokilometre
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 3.
Pour un client mail je vois tout de suite l'usage, j'ai personnellement plus de 2Gb de mail (je ne jette rien depuis 1997) et j'ai écris mon propre petit outil d'indexation (avec SQLLite il se trouve) pour chercher dedans plus simplement qu'avec aucun client mail que je connaisse. Rien de bien tordu mais ca marche et vite (le fichier de reference fait environ 15Mb).
"Lire et écrire un fichier n'est pas particulièrement compliqué, "; Il n'y qu'a voir avec quelle régularité un bon nombre d'applis corrompent leurs données, ou deviennent incapable de relire leur formats de fichiers entre deux versions. Faire une paire de routines de lecture écriture de fichier n'est pas bien compliqué, mais définir un bon format de fichier, le faire vivre et évoluer, ca n'a rien de simple. La dessus ajoute le fait que pour debugguer le tout il faudra sans doute ecrire ses propres outils d'exploration, génération d'exemples, mise à jour ..... bref ca devient vite compliqué.
Bien sur avec un format pur texte c'est plus simple, à condition d'avoir pensé au départ au multilinguisme, et à encoder les données purement binaire (son, images, échantillions de mesures) avant de les écrire (et évidemment faire attention à l'encodage entre librairies : chaines UTF-XX, ASCII, 8859-xx ?).
Au final si tant de monde adopte le XML et les librairies de lecture/écriture de ce format ca n'est pas sans bonnes raisons.
Pour ce qui est des fonctions de tri, oui il y'en a partout, mais il faut a chaque fois recoder les fonctions de comparaison, c'est à mes yeux plus complexe (surtout à maintenir) qu'une syntaxe dédiée à cet usage telle celle du SQL. Sans compter que moult programmeurs préferent réimplementer leur propres fonctions plutot que tenter d'utiliser les fonctions évoluées des bibliothèques (voir l'usage de la librairie standard C++ hors du cercle des experts de la norme).
SQLLite fournit un stockage relationnel, et les outils qui vont avec, je vois peut de problèmes provoqués par cela (mais je ne vais pas essayer de faire rentrer dedans des données qui ne s'y pretent pas).
La news est un chouia enthousiaste, mais je m'y joins pour inviter chaque programmeur qui ne soit pas trop "à cheval" sur la GPL à jeter un oeil à SQLite parceque c'est bien fichu et vraiment à connaitre pour LA fois ou ce sera peut être la réponse au problème du jour.
[^] # Re: pfff
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 4.
A mes yeux le XML n'est pas plus souple à utiliser, ca ressemble bougrement à une base de donnée hyérachique(http://en.wikipedia.org/wiki/Hierarchical_database(...)) sur lesquelles les SGBDR ont été une innovation considérable. Croiser des infos en XML n'a rien de trivial.
Bref XML est bien sympa pour échanger des infos mais rarement pour les traiter.
"un SGBD peut être une bonne solution, mais c'est loin d'être pertinent dans toutes les applications. Voilà c'est mon avis sur cette publicité. " 100% d'accord !
Enfin n'oublions pas que SQLite ne s'inscrit pas en concurent de serveur de base de données, mais au contraire plutot comme une librairie à intégrer dans une application pour gérer ses données de façon rapide et flexible.
Le XML est par contre un excellent candidat aux fonctions d'import/export/sauvegarde/echanges reseaux ....
[^] # Re: explosion du trokilometre
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 3.
Mais, tu admettras tout de meme que dire "rapport signal/bruit aux niveaux des tables tendant rapidement vers 0 ( un bon exemple est les 12 000 tables de SAP/V3 )" est de la mauvaise fois. SAP n'est pas une application simple ou rapidement concue. Pour modeliser ce que SAP tend à automatiser (soit à peut prés tout les proccessus d'une entreprise), il n'y sans doute pas de modele de représentation qui soit trivial, car le probleme est en soit (exagerement?) complexe.
Si les SGBR ne sont évidemment pas une sorte de panaçée universelle, ils offrent une solution pratique dans pas mal de cas. En particuliers dans tous les cas, généralement peut intéressants sur le plan de la recherche actuelle, mais forts courant dans une utilisation courante de l'informatique : quand un probleme se decompose bien en entites/relations.
Bref, il y'a malheureusement en informatique des modes et des cycles technologiques qui ne sont pas toujours rationnels, les meilleures solutions sont rarement pures (objet ou client/serveur ou relationnelles ou fonctionnelles ou centralisées ou scripts ou ....), même si le vendeur de chaque techno la vend comme telle.
Il faut faire avec, mais ca n'empeche pas SQLite d'être un bon petit outil bien pratique à connaitre.
[^] # Re: explosion du trokilometre
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 4.
L'avantage de SQLite, c'est que tu vas resoudre pas mal de problemes avec de "simples" requetes SQL et passer moins de temps sur les problemes de tris, retris, croisement et sauvegardes de fichiers...
Combien de temps perdu a reecrire des sauvegardes/chargements de fichiers (buggués bien sur) ?
Combien de quicksort ont été 100 fois réécris ?
Quand tu consideres qu'en plus SQLLite est plutot compact et rapide et fait des fichiers d'une taille assez raisonnable, ca le place tout betement comme un excellent outil dans la panoplie du programmeur, en particulier dans les applis interactives ou on a pas forcement envie d'imposer un backend SGBD à l'utilisateur.