• [^] # Re: Dans certaines entreprises

    Posté par . En réponse au journal Le comble du development en code fermé?. Évalué à 9.

    C'est bien pour cela que j'ai marqué : "tenter".
    On peut toujours tenter l'impression, si une imprimante accepte encore d'imprimer (certaines matricielles d'il y a 20 ans ont mal vieilli, et je ne parle pas des consommables sous vide que nous avions stocké).
    On peut aussi imaginer que le matériel électronique ne tienne pas le coup et refuse de fonctionner dans 10 ans.
    On va dire que ce genre de stockages et de précautions a pour objet de mettre le maximum de chances du côté du fournisseur du logiciel/matériel dans le cadre d'un contrat de garantie/support, et qu'on ne peut se prémunir contre tout, notamment le fait, par exemple, que les formats de données soient illisibles aujourd'hui, ou les protocoles réseaux (ou le matériel) soit incompatible.

    Mais là le propriétaire n'est pas forcément pire que le libre : avec le libre certes j'ai le code source, mais rien ne me garanti que je trouverais encore un compilateur capable de le compiler, un système d'exploitation capable de faire tourner le tout, ni même une machine compatible.

    Pour la documentation au format MS Word ou la compression au format Winzip, c'est clair que ce n'est pas forcément une bonne idée car c'est rajouter une "couche" d'abstraction avec un logiciel qui utilise un encodage propriétaire pour des données qui n'en valent pas forcément le besoin. Mais bon, en imaginant que ce soit un format libre qui soit demandé pour la documentation, qu'est ce qui me garanti qu'il soit encore lisible dans 10 ou 20 ans? De même, en supposant qu'on compresse/archive le tout au format .tar.gz?
    On a les codes sources des programmes qui permettent de lire/manipuler ces données, voire même la documentation du format, mais si on se place dans le cadre du deuxième paragraphe (à savoir la difficulté/l'impossibilité à/de les utiliser)?