Voici un certain nombre de cas qui me disent que cela pose problème :
outils pour récupérer/manipuler en click a click des paramètres/réglages de la nouvelle carte trucmuche avec drivers proprio dans le kernel (au choix gadget HP sur cartes mères, overcloking/température sur nvidia, carte wifi ...) => J'aurais beau installé la partie user space en binaire si j'ai pas les drivers binaires je suis mal. Et l'on revient au fait qu'il fait résoudre les problèmes des blobs dans le kernel, et que cela ne marcherait peut être pas sur BSD x86 avec compatibilité binaire (qui est aussi un système libre), voire sur linux sparc64.... Donc la distribution de binaire pour ce secteur sera toujours moins intéressante que l'accès aux specs du hardware. (Cela coûtera en plus plus cher aux éditeurs).
Autres choses, imaginons une IHM de haut niveau. Comme il faut compiler tout en static, le binaire va réintégrer les librairies genre gtk, expat, sdl, ... non seulement la taille des install va exploser, mais quid des interactions (pour une appli qt par exemple) entre le nouveau desktop (KDE) et le binaire avec ses anciennes librairies. N'y a t'il pas des risques de devoir régler son système sur les applis binaires ? Du genre j'ai une appli métier qui utilise tel mécanisme donc je peux plus upgrader mon serveur qui est en DMZ. En tant que sysadmin, je serais pas chaud.
Pour les serveurs, (oracle par exemple) imaginons, c'est bien beau d'avoir les binaires, mais le sysadmin veut aussi une standardisation des emplacement de réglages (/etc/), des fichiers de log/pid, des scripts de démarrage, qu'en sera-t'il. Le démarrage sur un BSD (compatible binaire linux) qui se fait à la slackware, n'est pas le même que dans une RH ou une debian. De même pour la gestion des droits, il est parfois sain de créer un utilisateur local, avec toutes les contraintes et conventions par système, ça sent l'usiine à gaz.
Et que se passe-t'il quand une librairie (dont on on ne sait pas qu'elle est intégrée si le binaire est strippé) souffre d'une vulnérabilité ? On ne remet plus à jour une librairie, mais n applications ? En plus comment peut on faire confiance à des éditeurs propriétaires pour bien vouloir jouer le jeu de la transparence nécessaire à la sécu, alors qu'il livre la forme la plus obfuscated possible du code, c'est à dire un binaire ?
Ca va faire exploser le besoin en maintenance sur les serveurs (chic du boulot). Et déjà qu'on peut ne pas avoir confiance dans des logiciels même quand on a les sources, alors avec du binaire, faut être sacrément confiant. Vous vous sentez installer un logiciel sous forme binaire de gestion de DVD-rom fourni par sony vous ?
Le choix le plus simple, le plus efficace serait quand même que les éditeurs comprennent que leur métier c'est le service et pas la vente de logiciels en boîte, et se mettent à faire du logiciel libre, et continuent à faire du service payant. Peut être même que ce serait plus rentable si on regarde les économies d'échelle
# ça peut pas marcher ?
Posté par Jul (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 3.
outils pour récupérer/manipuler en click a click des paramètres/réglages de la nouvelle carte trucmuche avec drivers proprio dans le kernel (au choix gadget HP sur cartes mères, overcloking/température sur nvidia, carte wifi ...) => J'aurais beau installé la partie user space en binaire si j'ai pas les drivers binaires je suis mal. Et l'on revient au fait qu'il fait résoudre les problèmes des blobs dans le kernel, et que cela ne marcherait peut être pas sur BSD x86 avec compatibilité binaire (qui est aussi un système libre), voire sur linux sparc64.... Donc la distribution de binaire pour ce secteur sera toujours moins intéressante que l'accès aux specs du hardware. (Cela coûtera en plus plus cher aux éditeurs).
Autres choses, imaginons une IHM de haut niveau. Comme il faut compiler tout en static, le binaire va réintégrer les librairies genre gtk, expat, sdl, ... non seulement la taille des install va exploser, mais quid des interactions (pour une appli qt par exemple) entre le nouveau desktop (KDE) et le binaire avec ses anciennes librairies. N'y a t'il pas des risques de devoir régler son système sur les applis binaires ? Du genre j'ai une appli métier qui utilise tel mécanisme donc je peux plus upgrader mon serveur qui est en DMZ. En tant que sysadmin, je serais pas chaud.
Pour les serveurs, (oracle par exemple) imaginons, c'est bien beau d'avoir les binaires, mais le sysadmin veut aussi une standardisation des emplacement de réglages (/etc/), des fichiers de log/pid, des scripts de démarrage, qu'en sera-t'il. Le démarrage sur un BSD (compatible binaire linux) qui se fait à la slackware, n'est pas le même que dans une RH ou une debian. De même pour la gestion des droits, il est parfois sain de créer un utilisateur local, avec toutes les contraintes et conventions par système, ça sent l'usiine à gaz.
Et que se passe-t'il quand une librairie (dont on on ne sait pas qu'elle est intégrée si le binaire est strippé) souffre d'une vulnérabilité ? On ne remet plus à jour une librairie, mais n applications ? En plus comment peut on faire confiance à des éditeurs propriétaires pour bien vouloir jouer le jeu de la transparence nécessaire à la sécu, alors qu'il livre la forme la plus obfuscated possible du code, c'est à dire un binaire ?
Ca va faire exploser le besoin en maintenance sur les serveurs (chic du boulot). Et déjà qu'on peut ne pas avoir confiance dans des logiciels même quand on a les sources, alors avec du binaire, faut être sacrément confiant. Vous vous sentez installer un logiciel sous forme binaire de gestion de DVD-rom fourni par sony vous ?
Le choix le plus simple, le plus efficace serait quand même que les éditeurs comprennent que leur métier c'est le service et pas la vente de logiciels en boîte, et se mettent à faire du logiciel libre, et continuent à faire du service payant. Peut être même que ce serait plus rentable si on regarde les économies d'échelle