Discussion :

[esperanto]

Mais ce n'est pas pour autant qu'on devient contributeur de la solution : le projet est généralement géré par une équipe plus ou moins réduire, qui ne voit pas forcément d'un bon œil les patchs de chacun.

Étant moi-même confronté à ce problème (des nouvelles fonctionnalités pour lesquelles l'équipe originale traîne des pieds pour intégrer mes patches malgré l'insistance des utilisateurs) je pourrai difficilement te contredire sur ce point.
Reste que le fork est une possibilité qui n'existe pas avec le logiciel propriétaire. Quand un projet libre est au bord du gouffre, on le sauve en le forkant, voir le cas de X.org par exemple. Évidemment ça suscite toujours l'ire des responsables du projet initial, mais à un moment, ils ne peuvent pas continuer de mépriser les nouvelles fonctionnalités du fork et venir s'étonner que les utilisateurs qui réclament ces fonctionnalités (surtout que dans notre cas, j'ai offert d'aider à leur portage sur la dernière version) finissent par le préférer à l'original.

Donc si demain une personne décide de mettre en place une super solution qui permet de faire de la haute dispo sous PostgreSQL, mais qui casse en contre-partie certaines autres chose, alors ce n'est pas pour autant que PostgreSQL saura faire de la haute dispo du jour au lendemain.

Dans un tel cas, il se peut que les deux forks continuent leur vie de façon indépendante, parce qu'ils ne visent pas le même public (les logiciels libres ne se font pas concurrence au sens commercial du terme). En plus on a un bon exemple avec MySQL car si tout le monde a entendu parler de MariaDB, moins de gens connaissent l'autre fork Drizzle qui a choisi d'abandonner certaines fonctions pour se concentrer sur d'autres comme la performance brute. Et les sociétés qui assurent le support de MariaDB acceptent généralement de faire la même chose avec le fork.

[esperanto]

le terme "utiliser un index" ne veut pas dire qu'il tire profit de la puissance de l'index en recherche.[...]
Comme vous n'avez pas analysé correctement l'usage de l'index, dans le plan d'exécution, [B]vous n'avez pas remarqué qu'il n'utilisait pas un seek, mais un scan…

Certes après vérification je vois que le EXPLAIN me dit "Bitmap Index Scan", ce que je n'avais pas remarqué. Oui mais...

Reprenons mes trois requêtes:

1. la requête "select count(*) from test where distance(x,y) < 0.1" n'utilise pas l'index et répond en 430 ms.
2. la requête "select count(*) from test where x > -0.1 and x < 0.1 and y > 0.1 and y < 0.1" utilise l'index et répond en 79 ms
3. et là ça devient intéressant, la requête "select count(*) from test where x > -0.1 and x < 0.1 and y > 0.1 and y < 0.1 and distance(x,y) < 0.1" utilise l'index et répond en 109 ms!!!

Pour la première requête la commande EXPLAIN dit "Seq Scan on test". Or ici TEST désigne la table et non l'index. Donc j'avais raison de dire que l'index n'était pas utilisé.
Pour la troisième requête, la commande EXPLAIN dit " Bitmap Index Scan on test_x_y_idx". Alors certes c'est un scan mais de l'index (test_x_y_idx), pas de la table.

Et puis au fond moi ce qui m'intéresse c'est le résultat: à moins que les meilleures performances de la troisième requête n'aient rien à voir avec l'utilisation de l'index, ce qui reste à prouver, reste que tu as étalé ta science pour rien - depuis le début tu nous dis qu'un index multi-colonnes est inefficace pour les recherches spatiales (sauf si c'est sous Oracle ou SQL Server, évidemment...) et là mon test semble montrer que même si ça impose de modifier un peu les requêtes, en cherchant un peu on peut quand même tirer profit de l'index. Encore une fois, à moins que tu voies une autre explication à la différence de performances.

Encore une fois, votre méconnaissance lié à votre enfermement dans le monde PostgreSQL, ne vous permet pas de déciller vos yeux !

Celle-là c'est vraiment la meilleure. J'ai cité ici pas mal d'autres moteurs SQL que j'utilise régulièrement. J'ai cité ça et là l'utilisation de moteurs non-SQL comme Tamino, et je n'ai pas parlé d'un serveur qu'on avait développé à usage interne qui indexait du XML mais stockait tout dans Oracle. Je devrais aussi parler de mon utilisation régulière d'Apache Lucene, qui n'est pas un moteur de bases de données mais uniquement d'indexation. Mais évidemment comme je n'ai cité ni Oracle ni SQL Server (parce que dans tous les projets que j'ai faits utilisant ces serveurs je devais passer par un DBA qui cachait jusqu'au nom des tables pour être sûr de nous faire passer par des vues) et que toi tu ne connais que ces deux-là et un peu PostgreSQL, au final effectivement PostgreSQL est le seul que nous connaissions tous les deux.

Il existe des techniques d'indexation, permettant d'indexer TOUTES les colonnes des tables, et elles sont d'une redoutable efficacité.

mais efficaces pour quelles requêtes? Est-ce que ces indexes auront ou non le même problème que celui que tu décris ici?

Je veux bien te croire mais aurais-tu des exemples de requêtes que tu fais avec ces index là?

Bien sûr que oui…

Et donc? Il t'a peut-être échappé que derrière la forme rhétorique de la question, on attendait un peu plus comme réponse que oui ou non. J'attends donc toujours de voir à quel type de requête un index couvrant toutes les colonnes d'une table, ou tous les champs d'une colonne XML, est mieux adapté qu'un index ne couvrant que certains champs. Et c'est une vraie question, pas une affirmation que ça n'existe pas.

De la même façon que tu ne peut à l'avance savoir comment vont être utilisées les données relationnelles d'une base et donc sans arrêt réagir à créer des index en fonction des requêtes pratiquées, tu ne peut savoir à l'avance comment va être utiliser le XML stocké.

Quand on conçoit la structure des données en même temps que les applications qui vont l'utiliser, bien sûr que si. Évidemment ça échappe à un DBA qui part du principe que les développeurs ne connaissent rien aux données et donc que le DBA doit tout faire pour eux, mais il va ensuite se plaindre qu'on lui demande trop de travail...

[SQLpro]

... Ainsi, pour une PME, ou grosse boîte qui a un projet non critique, il est parfaitement possible d'utiliser SQL Server Express, par exemple, dont les limites sont suffisamment larges pour pouvoir soutenir la comparaison avec des offres gratuites de MySQL ou PostgreSQL dans la plupart des cas.
L'avantage de rendre du SQL Server, c'est qu'on bénéficie du support de Microsoft, y compris avec la version Express. Ainsi, on a tous les correctifs "au plus tôt" qu'ils soient de sécurité ou qualité. On a aussi la garantie d'avoir tout les outils pour changer de version de façon quasi transparente, etc.

Je ne dirais pas cela, car la version Express est limité à :

• un cache de 1 Go
• des bases de 10 Go (donc au plus 320 To...)

Mais la limite du cache, va vite peser sur les perf...

En revanche tu as la version Web, qui est très intéressante (quelques dizaines d'euros par mois)...

A +

[SQLpro]

Et la notion d'Index " plaçant " ( CLUSTER en anglais ) alors ... Comme dans Db2 for z/OS par exemple ?

Pour information, cette notion s’appelle index cluster dans MS SQL Server et c'est ce SGBDR qui l'a popularisé car par défaut pour toute table dotée d'une clef primaire, depuis l'origine Sybase du produit (1983...).

C'est natif dans le moteur et le moteur relationnel de MS SQL Server est optimisé pour cela.

A +

[StringBuilder]

Sinon, pour recentrer le sujet initial, y'a quand même un truc qui me turlupine depuis le début avec ce topic : soit j'ai mal lu, soit à aucun endroit il n'est indiqué comment a été produit le graph.
Qu'est-ce qui a été compté exactement ?

En effet, autant le nombre d'utilisations de la version payante est assez simple à déterminer, autant celui des version gratuites... comment dire...

On parle de versions "docker".

Bon nombre de développeur disposent de plusieurs versions docker sur leur propre poste de développement. Vu la vitesse à laquelle ça s'installe, on a tendance à les bèner quand on n'en a plus besoin, quitte à les retélécharger 3 jours après.
A ce moment, si on compare le nombre de licences payées par rapport au nombre de téléchargements des versions gratuites, les chiffres sont complètement biaisés : à mon avis, plus de 80% des téléchargements n'aboutissent pas à des utilisations à proprement parler. Ça va généralement êtres des tests, des machines de dev, etc.

[SQLpro]

...depuis le début tu nous dis qu'un index multi-colonnes est inefficace pour les recherches spatiales (sauf si c'est sous Oracle ou SQL Server, évidemment...)

Vous me faite dire des choses que je n'ai pas dit ! Je n'ai jamais dit que Oracle ou SQL Server serait efficace pour ce genre d'approche. Aucun SGBDR ne peut, pour un index rowstore bicolonne, être performant en recherche spatiale. C'est une autre technique qui est utilisé, dont nous avons parlé à savoir la tesselation, ou pavage via des grilles.... Même PostGreSQL utilise des index spatiaux avec des QuadTree et bien évidemment pas un index bicolonne du genre (X, Y) !....

et là mon test semble montrer que même si ça impose de modifier un peu les requêtes, en cherchant un peu on peut quand même tirer profit de l'index. Encore une fois, à moins que tu voies une autre explication à la différence de performances.

Non ! Votre test ne montre rien du tout en matière d'opération de recherche d'index. Il montre simplement que l'on peut lire toutes les entrées d'un index légèrement plus rapidement par balayage que de lires toutes les données de la table par le même procédé de balayage, puisque la table comporte souvent plus de colonnes que l'index !
De plus vous n'allez pas demander à l'éditeur de la solution de réécrire ses requêtes parce que vous êtes sur un SGBDR limité ! Il va vous rire au nez et passé au client suivant, ou vous dire, comme je l'ai vu faire... "Vous auriez du prendre la solution Oracle !"

Celle-là c'est vraiment la meilleure. J'ai cité ici pas mal d'autres moteurs SQL que j'utilise régulièrement. J'ai cité ça et là l'utilisation de moteurs non-SQL comme Tamino,...

Certes, mais avez vous décortiqué et compris leur fonctionnement ? Visiblement vu le genre d'affirmation éminemment fausses que vous distillez, vous n'êtes pas allé très loin dans la compréhension des ces outils !

...au final effectivement PostgreSQL est le seul que nous connaissions tous les deux.

À la grande différence que je suis un expert SQL Server, mais bien que je connaisse intimement le fonctionnement de PostGreSQL (y compris dans son stockage interne, et les bugs que j'y ai relevé) je ne me prétends pas expert... Qui dit expert dit expérience; et je connais et pratique SQL Server depuis 1995 avec plusieurs milliers de missions dont 10 % d'audits alors que le business PostGreSQL ne représente que 2 à 3 % de mon activité....

Et donc? Il t'a peut-être échappé que derrière la forme rhétorique de la question, on attendait un peu plus comme réponse que oui ou non. J'attends donc toujours de voir à quel type de requête un index couvrant toutes les colonnes d'une table, ou tous les champs d'une colonne XML, est mieux adapté qu'un index ne couvrant que certains champs. Et c'est une vraie question, pas une affirmation que ça n'existe pas.

La démonstration vous a été donné ici. Commencez par apprendre à lire !
https://www.developpez.net/forums/d2.../#post11349241

En plus je vois que tu as créé un index CLUSTERED, j'ai un vague souvenir de les avoir vus à la fac à l'époque où le produit s'appelait encore Sybase et bénéficiait donc du travail d'une société spécialisée dans les bases de données, là où Microsoft fait un peu de tout et surtout n'importe quoi.

Audiard disait "les cons, ça ose tout, c'est même a ça qu'on les reconnais...". Dire que Microsoft fait surtout n'importe quoi est à la limite de la diffamation. C'est en tout cas de la fake news ! Je laisse aux autres le soin de vous juger ! Mais affirmer que MS fait n'importe quoi alors que Sybase est mort, racheté à vil prix par SAP, tandis que la plupart des clients de Sybase sont passés sous SQL Server pour tout un tas de raisons, prouve que vos dires sont justes des âneries !

Et dans mon souvenir, ces indexes imposent que la table soit elle-même triée par rapport à l'index, ce qui doit certainement rendre les écritures très coûteuses (parce que dans tous les cas, la présence d'un index alourdit les écritures - c'est bien pour ça qu'il m'arrive de ne pas indexer du tout quand je sais qu'une colonne sera seulement affichée, jamais recherchée - mais là, à moins que tu sois certain que les données seront insérées dans l'ordre, le coût doit être vraiment très élevé!). Et avant que tu ne viennes encore dire que je n'ai rien compris, ça semble cohérent avec ce que tu as écrit ici...

Encore une fois vous affirmez des âneries sans aucune preuve ni jugeote ! Pourquoi le coût d'une insertion dans une table organisée en cluster serait-il plus important et même comme vous l'affirmez sottement "très couteuse" ???
Un index cluster c'est la table. Il n'y a donc qu'une seule structure de données à alimenter. Donc le coût de l'insertion brute est le même que pour une table en heap. En revanche il y a un extra overhead lié :

• d'une part au "tri" de l'index
• d'autre part à la structure de navigation

... mais MS (comme Sybase par le passé) recommande de ne pas créer des index clustered sur tout et n'importe quoi. Les règles sont les suivantes :

• l'index clustered devrait être UNIQUE et NOT NULL
• la clef d'index devrait être la plus petite possible (ne pas dépasser la longueur du mot du processeurs soit 64 bits)
• la clef de l'index devrait être invariante (ne pas faire l'objet d'UPDATEs).
• les valeurs de al clef devrait être monotone

Toutes ces conditions sont respectées lorsque l'index clustered est créé sur une clef primaire de type entier auto incrémenté.
Les mesures de performances montre que l'insertion dans une telle structure est plus rapide que dans une table en heap, tout simplement parce que dans une table en heap, le système passe sont temps à scanner la table à la recherche d'un emplacement pour stocker la ligne alors que dans une table organisée en index clustered avec un auto incrément monotone il sait à l'avance ou placer la ligne !
Par conséquence le temps perdu dans l'extra overhead du fait du cluster est largement inférieur à un scan à la recherche d'un slot de ligne....

Encore une fois toutes ces considérations sont expliquées dans mon livre sur SQL qui consacre aux index un chapitre entier...

Quand on conçoit la structure des données en même temps que les applications qui vont l'utiliser, bien sûr que si. Évidemment ça échappe à un DBA qui part du principe que les développeurs ne connaissent rien aux données et donc que le DBA doit tout faire pour eux, mais il va ensuite se plaindre qu'on lui demande trop de travail...

C'est une erreur flagrante que de modéliser les données par rapport à un traitement. On modélise une base de données pour les données qu'elle doit recevoir et qui vont être utilisées par les applicatifs. La nuance est importante. En effet une base contient beaucoup de données et tout un historique. Les règles de gestion évoluent dans le temps et donc les traitements sont constamment modifiés. Si vous avez fait une adhérence des données très importante à la demande initiale, les demandes suivantes deviendront de plus en plus compliquées à satisfaire et de moins en moins performantes (d’où le respect à la lettre des formes normales...). En revanche si vous avez modélisé les données pour ce qu'elles sont (en général, les données n'ont pas attendue l'informatique pour exister à l'état naturel...)

À lire dans l'ouvrage de mon collègue Christian Soutou que j'ai annoté :



A +

[Invité]

Audiard disait "les cons, ça ose tout, c'est même a ça qu'on les reconnais..." Je laisse aux autres le soin de vous juger !

Heu... faudrait peut-être se calmer. Déjà c'est un forum d'informatique pas la Cour d'assises. Et ensuite, même si vous étiez vraiment le Albert Einstein du SGBD, ça ne serait tout de même pas une raison pour être insultant et méprisant.

[StringBuilder]

En même temps, il y a des limites aux âneries qu'on peut dire.

A l'époque de SQL Server 7.0 (qui pourtant était très largement mieux que le 6.5 qui était un fork de Sybase) je veux bien qu'on puisse dire que Microsoft faisait n'importe quoi et s'occupait de ce qui ne le regardait pas...
Mais dès la version 2000 chaque ligne a été réécrite, et SQL Server est arrivé à tenir la comparaison avec Oracle 8i, ce qui à la base était inespéré pour Microsoft, et depuis 2005, où presque tout à de nouveau été réécrit (donc à l'époque, oui, Microsoft tâtonnait un peu, on peut l'admettre) SQL Server est devenu leader en termes de performance, de montée en charge et de fonctionnalités.
Et depuis cette date, le produit ne cesse de s'améliorer.

Donc depuis plus de 15 ans, Microsoft produit un excellent outil, si ce n'est le meilleur... alors qu'ils étaient partis d'un ramassis de pas grand chose... Dire exactement le contraire relève juste de l'intégrisme religieux.
Qu'on puisse reprocher certaines choses à SQL Server, c'est une chose, taxer Microsoft de faire n'importe quoi en est une autre.
Oracle, depuis 10 ans, oui, fait n'importe quoi : leur SGBD évolue au compte goutte et devient au fil des versions de plus en plus merdique. L'époque où ils étaient leader est très lointaine.

[Luc Orient]

... Un index cluster c'est la table. Il n'y a donc qu'une seule structure de données à alimenter.

Ben non ... Enfin, plus exactement ça dépend ... En SQL Server oui, en DB2 for z/OS non ... L'index, cluster ou pas d'ailleurs, est une structure de données distincte de la table ...

[jpouly]

Pour en revenir à des choses plus sérieuses :

Pourquoi personne ne paie pour un logiciel de base de données open source ?

ben parce qu"il y a Oracle / Microsoft et leurs forces de ventes (), et que pour 99 % des gens, 99 % des informaticiens et 100 % des décideurs, l'open source == gratuit.

Le reste, c'est de la masturbation intellectuelle, voir de la querelle de cours de récréation (a.k.a. mon OS est plus beau que le tiens, mon mac est meilleur que ton pc, mon atari fait mieux les calculs que ton amiga, mon cpc est plus fantastique que ton c64, ...).

[SQLpro]

On est d'accord.

Ben non... Vous affirmez encore une fois n'importe quoi...... Je vous cite :

Pour faire court, l'index est utilisé si et seulement si au moins la première colonne est utilisée, et ensuite si la deuxième, la troisième... apparaît dans la requête.

Hé non !!!! Vous dites :

l'index est utilisé si et seulement si au moins la première colonne est utilisée

Ceci est faux... L'index sera utilisé par l'optimiseur si il juge moins couteux d’accéder à cet index que de passer par la table.
Par exemple pour une table de personnes comportant de multiples colonnes et un grand nombre de lignes, et un index sur le nom,
une requête du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM persone WHERE nom BETWEEN 'L' AND 'N'

a peut de chance de prendre l'index ni en scan (balayage) ni en seek (recherche)
En revanche cette requête utilisera un scan :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT nom FROM MaTable WHERE Nom <> 'MARTIN'

Et celle-ci un seek :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT nom FROM persone WHERE nom BETWEEN 'L' AND 'N'

Avec plusieurs colonnes, ça se complique. Si la jonction des prédicat est faite avec AND et la rechercher est vectorielle alors, il se peut que l'index soit utilisé en recherche... Encore une fois, toute ceci est expliqué dans mon livre sur le langage SQL...

A +

[SQLpro]

Bonjour,

afin de satisfaire l'incrédulité de notre amie sodium et d'autres, voici un extraits des tests auxquels je me livre dans le cadre d'une étude générale de portabilité de Microsoft SQL Server vers PostgreSQL :
https://www.developpez.net/forums/d2.../#post11357084

Merci de poster vos remarques dans cette nouvelle enfilade afin d'éviter de polluer l'enfilade présente pour ne pas faire trop dériver le sujet initial.

A +

[yahiko]

Merci de bien vouloir vous en tenir à des critiques sur les idées, les faits, les concepts et de proscrire les attaques à la personne.

[Invité]

Quand une personne possède la signature la plus prétentieuse de l'histoire du web, multiplie les arguments d'autorité, met en avant ses articles, ses bouquins pour au final prouver qu'elle n'est pas plus compétente qu'un amateur sachant utiliser Google, ça mérite un minimum de moquerie. On dirait un personnage de Molière

En attendant, je réitère ce que j'ai dit en début de topic :

Quand tu arrives à un rapport 1 pour 300k de performances sur deux technologies concurrentes avec un degré de maturité équivalent, c'est que soit tu es le messie qui a vu la lumière et le reste du monde est complètement stupide de ne pas l'avoir adoptée, soit tu ne sais te servir que l'une des deux et tu es totalement incompétent sur l'autre. Et je ne sais pas pourquoi mais mon instinct va plutôt en direction de la seconde possibilité

[tatayo]

Bonjour,
Ce serait cool de recentrer la discussion sur la question originale : Pourquoi personne (sous entendu parmi ceux qui en utilisent) ne PAIE pour un SGBD open source ?
Car le débat entre un développeur qui ne sait pas qu'il peut mettre des index ailleurs que sur un clavier (non, pas là…) et un DBA qui ne sait pas qu'on peut relier 2 tables autrement qu'avec une contrainte (à part si c'est pour accueillir la belle mère*1), ce n'est pas la question ici. Ok, je ne sais pas s'il y a une autre discussion, mais rien n'empêche d'en créer une.
Le débat entre "mon 103SP kité va plus vite que le tien" et "c'est normal, t'as pas lâché les freins", ce n'est pas la question ici. Il y a d'autres discussions pour cela.
Le débat "plat préparé" et "fait maison", ce n'est pas le débat ici. Il me semble qu'il y a déjà (au moins) une discussion ailleurs.

Et pour les débat d'écolier ("t'es nul", "nan c'est toi qu'es nul", "tu sais même pas régler un carbu", "et toi tu sais même pas remplacer les segments"*2, etc...), autant les renvoyer dans les cours de récré

En fait la discussion était intéressante au début, mais maintenant, bof bof.

Sur ce (petit) coup de gueule qui me défoule bien, je retourne dans ma cuisine m'occuper de mes pains au lait.

Tatayo.
*1 non, ce n'est pas du vécu (quoi que)
*2 là oui, ça sent le vécu

[MaitrePylos]

Le débat entre "mon 103SP kité va plus vite que le tien" et "c'est normal, t'as pas lâché les freins", ce n'est pas la question ici. Il y a d'autres discussions pour cela.

Oui, mais tu as un carbu de 21 Dellorto et un pot Polinni ? sinon même pas la peine de discuter hein*



* Putain viens de me prendre 30 ans dans la gueule pfffffff

[marc.collin]

il doit en avoir un minimum qui paie, autrement ces bases de données ne se développerait pas aussi rapidement, il n'y aurait pas tout un éco système autour.

Le marché est différent selon la taille de l'entreprise.

L'accent est mis sur le service depuis un bon moment au lieu des licences.

Combien pour de la formation?
Combien paye pour du support?
Combien payer pour une offre avec plus de fonctionnalité?

Un assemblage de brique pour arriver à un produit avec une certaine valeur ajouté, le plus rapidement possible avec le moins de coût possible... l'entreprise ne sait même pas si le produit qui sera mis en ligne aura du succès...

Les offres opensources se sont diversifié et sembler combler la majeur partie des besoins de bien des entreprises

Est-ce que le temps où les entreprises utilisaient des produits surdimensionné pour leur besoins est révolue?

non je ne crois pas, le lobbying est encore très fort... mais il y a une prise de conscience

des passages d'oracle, ms sql server à du mariadb, postgres et des bd nosql j'en vois beaucoup plus souvent qu'il y a 15 ans

[SQLpro]

… des passages d'oracle, ms sql server à du mariadb, postgres et des bd nosql j'en vois beaucoup plus souvent qu'il y a 15 ans

C'est logique, vu que le marché des données est en pleine expansion et de manière quasi exponentielle. Tous les SGBDR sont gagnant, avec un bémol aujourd'hui sur Oracle, non pas à cause du produit lui même, mais plus de ses pratiques commerciales….

A +

[SQLpro]

A relier avec la problématique de financiarisation de l'open-souce :
https://www.developpez.com/actu/2984...-le-decouvrir/

A +

[StringBuilder]

C'est assez incroyable comme histoire.
Mais j'ai envie de relativiser tout de même en rappelant que dans de nombreuses boîtes, des pans entiers de projets reposent sur une personne aussi, et que la disparition de cette dernière, c'est la disparition de cette partie du produit aussi.
Même pire, si on dépend d'un produit (MS-DOS par exemple) et que l'entreprise qui détient le code décide de l'arrêter, il n'y a aucun moyen d'obtenir le code source pour espérer au moins pouvoir maintenir la compatibilité ascendance, comprendre pourquoi certaines choses ne fonctionnent pas, etc.

Donc ce qui me gêne le plus à ce jour, c'est que les codes sources des logiciels ne soient pas, comme le sont les brevets, soumis à un organisme capable de fournir une copie lorsque :
- le produit devient libre de droit en raison de son ancienneté
- le gérant du produit disparaît et personne n'a racheté le produit pour le maintenir (ou à décidé de ne plus le distribuer)