[gull] Linux polyglotte: Slackware ou Unbuntu?

Marc SCHAEFER schaefer at alphanet.ch
Tue Aug 8 19:05:19 CEST 2006


On Thu, Aug 03, 2006 at 01:59:16PM +0200, Ludwin wrote:
> chose a partir d'un cd-rom defectueux, que l'installation se fait a
> moitie, tu te retrouves dans une situation compliqee. Si tu te procures un
> cd-rom non defectueux et que tu veux installer le truc une nouvelle fois,
> le system pourra te dire "impossible, deja installe". Tu essayes de
> desinstaller, mais ce n'est pas possible, parce que comme le paquet n'a
> pas ete reellement installe, il ne peut pas se desinstaller non plus. Non,

Etrange: le système de gestion de paquet que Debian utilise permet de
noter si un paquet a été installé correctement, partiellement, etc, et
les routines d'installation devraient être idem-potentes. Il y a aussi
des checksums où il faut.

Mais bon, il est de toute façon recommandé de tester son matériel (et le
CD-ROM). Il y a différents outils pour cela, y compris une vérification
intuitive depuis le menu de démarrage de l'installation d'Ubuntu.

> En plus, ce systeme d'update automatiques par le reseau, c'est c'est
> potentiellement dangereux. Tu dois, en root, autoriser un serveur a
> deposer des megas sur to disque dur, et pendant que cela se fait, si les
> donnees personnelles stockees sur ton disque dur sont lues par un tiers,
> tu ne t'en rendras pas compte.

Sans mises à jour par réseau, tu peux décider des mises à jour que tu
veux faire, en les déposant sur un serveur local ou sur un CD-ROM.

Bien sûr c'est un compromis coût/sécurité/sécurité. On préfère en général
laisser la distribution gérer la sécurité et l'administration pour se
concentrer sur le vrai travail. De plus, un package non mis à jour car la
sécurité est trop stricte peut être en lui-même un grave problème de
sécurité (on retrouve p.ex. ce problème dans des entreprises déployant
du GNU/Linux avec un firewall ISA peu coopératif, mais voir ntlmaps ou
squid).

Tout dépend de ce que tu fais, où et comment. Ce que tu définis comme
sécurité peut être un trou de sécurité pour quelqu'un d'autre.

> Mais tout le monde ne prendra pas ces precautions.

Oui, le système est conçu pour la majorité des gens qui veulent gagner
du temps et être à jour au niveau sécurité (ou fonctionnalité sur une
distribution unstable ou testing; ou avec des backports).

> La question n'est donc pas d'etre "un fan des tarballs".

On doit alors vérifier les signatures électroniques des packages sources,
voire dans des cas vraiment paranoïaques regarder les diff avec les sources
précédences -- je le faisais avec les patches kernel en 2.2, mais j'ai
dû abandonner en 2.4 et je ne parle même pas du 2.6!!.  Et on peut
totalement oublier cela avec des projets complexes comme KDE ou même
Emacs.

Sinon tu n'as pas plus d'assurance avec des tarballs sources que des
binaires.
 



More information about the gull mailing list