[gull] x86_64

[Marc SCHAEFER]

On Thu, Jun 01, 2006 at 09:21:55AM +0200, Daniel Cordey wrote:
> Il s'agit des binaires de KDE 3.5.2 pour la SuSE 10.0, a partir du site 
> www.kde.org. Je ne vais pas m'amuser a tourner KDE en chroot :-)

Il y a des exemples où des personnes lancent leur client WWW dans un
autre serveur virtuel VLS, de manière à éviter d'être compromis. Cette
séparation de privilège (local/Internet/travail/jeu) a un sens, et je ne
serais pas surpris de la découvrir en standard dans certaines
distributions bientôt.

En attendant, on peut aussi créer des utilisateurs différents pour les
différentes activités et créer les wrappers appropriés.

Evidemment, pour tout KDE, c'est un peu excessif, mais alors, finalement, la
question ne devrait-elle pas être: pourquoi vouloir une version de KDE
différente de celle supportée par sa distribution, et donc se créer
finalement du travail important et finalement inutile ?  Les
`améliorations' en valent-elles vraiment la peine (en dehors d'un test
simple).

> Il faut reconnaitre qu'en dehors de KDE, il y a les drivers/modules 
> proprietaires du kernel et la malheureuse application Flash... Ce sont les 
> seuls binaires dont les sources ne sont pas disponible que j'utilise et qui, 
> a mon avis, justifient pleinement leur emploi.

Jusqu'ici j'ai eu peine à trouvé un emploi de Macromedia Flash qui était
réellement justifié. Cela existe certainement, mais je ne l'ai pas
encore rencontré.

Pour les pilotes propriétaires du kernel, c'est également assez rare
d'en avoir véritablement besoin, en particulier dans un serveur.

> (ex: Oracle). Lorsque l'on a pas le choix, il faut au moins rester vigilant.

- s'abonner à la liste d'annonce de sécurité du produit
- s'abonner à une liste d'annonce de sécurité générale (on ne peut faire
  p.ex. confiance à Oracle pour publier ou sécuriser, cf bug-traq)
- rester vigilant par rapport aux bibliothèques partagées éventuellement
  apportées par le logiciel pour son usage propre (elles ne seront pas
  mises à jour par la distribution)
- ne pas hésiter à contacter le vendeur si un soupçon apparaît (p.ex.
  annonce de sécurité sur SSL, pas de dépendance à une bibliothèque
  dynamique SSL visible dans les différents exécutables du logiciel,
  mais le logiciel offre une couche SSL (donc compilée statiquement et
  vulnérable))

tout cela a bien sûr un coût, c'est le coût du logiciel propriétaire.

dans certains cas, on aura avantage à tourner en chroot ou VLS de
manière à assurer les bonnes versions de bibliothèques partagées exigées
par le support du logiciel si LD_PRELOAD ou LD_LIBRARY_PATH ne suffisent pas
et que le support du logiciel (la hotline) insiste pour des versions
particulières, comme dans le cas de logiciel propriétaire sur plateforme
propriétaire.