Ce genre de logiciels a un temps de gestation bien plus lent que les logiciels traditionnels de part la complexité initialement requise. On pourrait prendre l'exemple de Salome qui est codé en utilisant Corba, ce choix a initialement été fait de part la nécessité de tout pouvoir faire en parallèle et en déporté simplement. A l'époque ou se projet a été commencé cela semblait une bonne idée, mais ça a malheureusement mis un frein à des contributions externe de part la complexité de corba.
Il faut bien voir que le nombre de soft que contient Salomé est impressionnant, il me semble que le gros problème vient du fait que ces softs sont fait par des scientifiques qui n'ont ni les connaissances ni l'envie d'apprendre à empaqueter leurs programmes pour différentes distributions (pour donner du grain à moudre à Zenitram). Il ne mettent pas forcément leurs softs à jour, car lorsqu'il fait le travail et qu'ils n'ont pas motivations scientifiques pour le faire évoluer alors ils ne le feront pas. Il devient du coup très difficile de faire cohabiter toutes les version des différentes lib dans le gestionnaire de programme. Il est donc souvent décidé de compiler en local. Je te rappel qu'il y a également des standard pour qu'un dépot soit accepter et je pense qu'ils s'en contrefichent. La solution de l'équipe de CAELinux est donc de prendre une distribution à jour, de se frapper tout le travail de compilation et de générer une "distribution" ou tout marchera "out of the box". Cette tactique me semble pertinente car ce sont les distributions (et le noyau) qui gères les évolutions de matériels et de softs standards.
Je ne pense donc pas qu'il faille réellement prendre ça au sens d'une distribution, mais plutôt au sens d'une compilation de logiciels sur une distribution déjà existante.
Le débat de la complexité de faire des logiciels pour linux a déjà souvent été abordé ici et je n'ai pas vu de solution simple. Celle-ci l'est pour le développeur et pour l'utilisateur qui accepte la contrainte de devoir installer un système pour ces applications. Je pense donc que c'est un compromis qui fait avancer les choses.
[^] # Re: pourquoi ?
Posté par freejeff . En réponse à la dépêche CAElinux 2010 et Salome-meca 2010. Évalué à 9.
Il faut bien voir que le nombre de soft que contient Salomé est impressionnant, il me semble que le gros problème vient du fait que ces softs sont fait par des scientifiques qui n'ont ni les connaissances ni l'envie d'apprendre à empaqueter leurs programmes pour différentes distributions (pour donner du grain à moudre à Zenitram). Il ne mettent pas forcément leurs softs à jour, car lorsqu'il fait le travail et qu'ils n'ont pas motivations scientifiques pour le faire évoluer alors ils ne le feront pas. Il devient du coup très difficile de faire cohabiter toutes les version des différentes lib dans le gestionnaire de programme. Il est donc souvent décidé de compiler en local. Je te rappel qu'il y a également des standard pour qu'un dépot soit accepter et je pense qu'ils s'en contrefichent. La solution de l'équipe de CAELinux est donc de prendre une distribution à jour, de se frapper tout le travail de compilation et de générer une "distribution" ou tout marchera "out of the box". Cette tactique me semble pertinente car ce sont les distributions (et le noyau) qui gères les évolutions de matériels et de softs standards.
Je ne pense donc pas qu'il faille réellement prendre ça au sens d'une distribution, mais plutôt au sens d'une compilation de logiciels sur une distribution déjà existante.
Le débat de la complexité de faire des logiciels pour linux a déjà souvent été abordé ici et je n'ai pas vu de solution simple. Celle-ci l'est pour le développeur et pour l'utilisateur qui accepte la contrainte de devoir installer un système pour ces applications. Je pense donc que c'est un compromis qui fait avancer les choses.