Discussion :

[yahiko]

Les résultats sont corrects sous Windows et pas sous Linux.
Nous pouvons en conclure que Windows est plus fiable que Linux.

[Steinvikel]

...ou que le code est plus fiable sous Windows.
le code, ou bien le framework, ou bien le compilateur, ou bien...

[SQLpro]

Cet article montre deux problèmes hélas aujourd'hui très courants :

1) le libre est bien souvent moins contrôlé que les produits d'éditeur et cela pour une raison simple. La vente engage la responsabilité de l'éditeur qui fait payer sa prestation, son objet, son bien... Et l'engagement de responsabilité implique des dommages et intérêts conséquents en cas de vice caché, et ici c'est bien d'un vice caché qu'il s'agit dans le cas de Python.
Or dans le libre, il n'y a pas de contrat commercial, donc pas de responsable, donc pas d'indemnisation possible.
Chez les éditeurs, cette problématique oblige à passer de nombreuses batteries de tests afin d'éviter de se retrouver pénalisé en cas de faute.... Dans le libre la pression étant inexistante, les bugs sont nombreux et les tests bâclés (lorsqu'il y en a !).... Il n'est qu'a voir le nombre incroyable, de bugs qui persistent dans MySQL/MariaDB (par exemple le fameux GROUP BY qui donne des résultats faux et jamais corrigé depuis l'origine) pour s'en convaincre...

2) le développement est devenu au fil du temps de moins en moins fiable car les projets sont de plus en plus "urgent".... Autrefois on faisait un cahier des charges, on montait un projet avec un planning, des étapes de validation et des batteries de tests. Maintenant on développe à l'arrache en mode "quick and dirty" la plupart confondant méthode agile et bousculade !
par conséquent, là aussi les avant test, POC et autre garde fous n'existent plus et les tests finaux ne sont jamais réalisés. Il résulte de tout ceci des gâchis monstrueux qui, peut être, un jour, conduiront à une vision un peu plus réaliste, un peu plus élitiste et sans doute moins prolétaire du développement informatique, qui s'apparent plus, aujourd'hui à du pissage de code qu'à de la réflexion !

A +

[wiztricks]

Salut,

1) le libre est bien souvent moins contrôlé que les produits d'éditeur[

Avant d'utiliser en production un logiciel libre, on prend quelques précautions comme de savoir ce qu'en font ses utilisateurs. On peut aussi regarder dans la buglist les problèmes soumis et les réponses apportées. Et comme on a les sources regarder un peu les cas d'utilisation qui ont été testé.
Après ben on teste (même pour les logiciels produits par les éditeurs) que çà produit les résultats attendu dans les cas d'utilisation qu'on souhaite.

Et s'il y a plein de bugs et que la communauté des utilisateurs râle ben on utilisera autre chose.

Libre = gratuit mais il y a un autre travail à faire

Et l'engagement de responsabilité implique des dommages et intérêts conséquents en cas de vice caché, et ici c'est bien d'un vice caché qu'il s'agit dans le cas de Python.

Le problème est dans le code qui a été écrit avec Python et non dans Python.

Quand un chercheur ajoute une étape de traitement qui permet de sortir la fréquence des molécules qu'il réalise pour valider une étude... Il doit publier son code pour que d'autres puisse reproduire ses résultats.
Après si d'autres chercheurs réutilisent ce code pour leurs traitements, on n'est pas dans la production logicielle mais dans les échanges normaux d'une communauté scientifique.

Or dans le libre, il n'y a pas de contrat commercial, donc pas de responsable, donc pas d'indemnisation possible.

La plupart des logiciels libres qui ont pignon sur rue peuvent être utilisés librement ou avec un contrat commercial.

2) le développement est devenu au fil du temps de moins en moins fiable car les projets sont de plus en plus "urgent"....

Si le client veut de la daube pas cher, on lui livre de la daube pas cher et pleine de bugs. Et si les commerciaux des SSII se couchent devant le client pour faire du chiffre plutôt que d'assumer leur rôle de conseil et dire au client qu'il faut mettre un peu les moyens en fonction la criticité de l'application pour sa production....
Sûr qu'avant on avait des techniciens tant du côté entreprise que développeurs, aujourd'hui un commercial rencontre le directeur des achats et çà discute pépète.

Mais c'est pas un problème de logiciel libre/éditeur, c'est juste des organisations et des patrons qui ont oublié qu'ils n'y a pas que des objectifs financiers...

* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

Ah ces mecs du Sud, toujours dans l’exagération

- W

[yahiko]

Cet article montre deux problèmes hélas aujourd'hui très courants :

1) le libre est bien souvent moins contrôlé que les produits d'éditeur et cela pour une raison simple. La vente engage la responsabilité de l'éditeur qui fait payer sa prestation, son objet, son bien... Et l'engagement de responsabilité implique des dommages et intérêts conséquents en cas de vice caché, et ici c'est bien d'un vice caché qu'il s'agit dans le cas de Python.
Or dans le libre, il n'y a pas de contrat commercial, donc pas de responsable, donc pas d'indemnisation possible.
Chez les éditeurs, cette problématique oblige à passer de nombreuses batteries de tests afin d'éviter de se retrouver pénalisé en cas de faute.... Dans le libre la pression étant inexistante, les bugs sont nombreux et les tests bâclés (lorsqu'il y en a !).... Il n'est qu'a voir le nombre incroyable, de bugs qui persistent dans MySQL/MariaDB (par exemple le fameux GROUP BY qui donne des résultats faux et jamais corrigé depuis l'origine) pour s'en convaincre...

Et il y aura toujours des pékins pour dire que c'est normal qu'il y ait des bugs car c'est du libre, tout en étant sévères à l'extrême lorsque des logiciels propriétaires comportent des failles. Et ce sont ces mêmes personnes qui promeuvent l'usage du libre en entreprise et dans le milieu pro. Bref...

2) le développement est devenu au fil du temps de moins en moins fiable car les projets sont de plus en plus "urgent".... Autrefois on faisait un cahier des charges, on montait un projet avec un planning, des étapes de validation et des batteries de tests. Maintenant on développe à l'arrache en mode "quick and dirty" la plupart confondant méthode agile et bousculade !
par conséquent, là aussi les avant test, POC et autre garde fous n'existent plus et les tests finaux ne sont jamais réalisés. Il résulte de tout ceci des gâchis monstrueux qui, peut être, un jour, conduiront à une vision un peu plus réaliste, un peu plus élitiste et sans doute moins prolétaire du développement informatique, qui s'apparent plus, aujourd'hui à du pissage de code qu'à de la réflexion !

Il est vrai que l'Agile est parfois/souvent un prétexte pour ne pas s'enquiquiner (pour rester poli) à trop réfléchir et formaliser en amont et à traiter les sujets à vas-y comme je te pousse.
Il y a un article à rédiger sur la face sombre des méthodes dites Agile.

[jean12]

Très bel exemple d'humilité et de collaboration! On reconnait ainsi de vrais scientifiques.

[maz57]

Bonjour tout le monde,

Voici le lien du code source original de la publication : https://www.nature.com/articles/nprot.2014.042#s1

[laurent_ott]

Tout cela me rappelle une anecdote où des résultats en chimie avaient été faussés parce que l'on utilisait des conteneurs en plastique au lieu de conteneurs en verre.
À qui la faute ?