Nicolas Noirbent a écrit 15 commentaires

Those who frequently install updates from security.debian.org won't have to update many packages

et pourtant j'ai beaucoup de paquets à installer à cause de cette publication

Sur debian.org:
Debian GNU/Linux provides more than a pure OS: it comes with over 25000 packages

Il faut savoir relativiser; une vingtaine de packages sur les 25000 disponibles finalement ce n'est pas grand chose :)

En sus du commentaire ci-dessus, je me permettrais de faire remarquer qu'un certain nombre de systèmes de fichiers modernes (dont ext3, XFS…) n'écrasent pas les données en place.

Ce qui signifie que « bêtement » réécrire des 0 par dessus le fichier cible ne détruira en aucun cas les données initiales sur la partition du disque dur sous-jacent; je n'évoque même pas les cas ou ladite partition est en réalité un volume LVM / une partition RAID.

On oublie très souvent la libc. C'est pas quelque chose de très visible, mais c'est pourtant indispensable...

Ça ressemble un peu à de l'auto-pub ça, venant du mainteneur Debian de ladite libc :)

Toute manière je me demande quel est l'avenir des FAI quand on vois se profiler les réseaux mesh, où alors j'ai rien compris, mais je veux bien qu'on m'explique.

Si on parle bien de la même chose, un "léger" problème au hasard : il traverse l'Atlantique ton réseau mesh ?

... Debian s'illustre avec ses outils de gestion de paquets à la pointe de la technologie :)

Et pourquoi pas AFS ?

http://en.wikipedia.org/wiki/OpenAFS
http://www.openafs.org/

Distribué, avec un client disponible pour UNIX, Windows et Mac OS X. Après c'est pas forcément évident à mettre en place, mais ça pourrait correspondre à tes besoins.

Tu peux donner plus d'info (un lien par exemple) pour que je ne redise pas cette connerie :-)

Un lien non pas vraiment, par contre:

# uname -a
Linux nnoirben 2.6.24-1-686 #1 SMP Mon Feb 11 14:37:45 UTC 2008 i686 GNU/Linux
# dpkg -l | grep linux-source
# module-assistant prepare
[...]
The following extra packages will be installed:
linux-headers-2.6.24-1-common linux-kbuild-2.6.24
The following NEW packages will be installed:
linux-headers-2.6.24-1-686 linux-headers-2.6.24-1-common linux-kbuild-2.6.24
[...]


Et il n'installe donc pas linux-source-2.6.24

Quand j'avais testé Debian (il y a longtemps certes), je devais installer kernel-source ou un truc dans ce style.

Ah bah du coup, ça fait déjà un bon bout de temps, vu que Debian a carrément changé de convetion pour les noms des paquets (de kernel-* vers linux-*, histoire d'être kernel-agnostic) depuis.

linux-headers ne permet pas de compiler un module.

Voir plus haut, le paquet linux-headers (qui est un paquet virtuel fourni par linux-headers-2.6.24 par exemple) suffit tout à fait pour compiler un module kernel sous Debian.

Comment on fait pour compiler un module sous Debian ?
Ben on installe tous les sources du noyau...

Ben non justement :/

Debian dispose d'un outil exprès pour ça, module-assistant, qui s'occupe de tout préparer lui même, outils de build, packages nécessaires etc. Et il ne télécharge que les en-têtes du noyau (paquet linux-headers-`uname -r`), jamais les sources complètes (en tout cas ça ne m'est jamais arrivé, mais tu as peut-être une expérience différente).

Ben non, APT me supprime des paquets qui ont besoin de faire du son, logique. Après sur un desktop, forcément ça en fait beaucoup, mais il ne me vire pas ImageMagick (lui).

Removing:
alsa-lib x86_64 1.0.15-1.fc8 installed 1.1 M
Removing for dependencies:
ImageMagick x86_64 6.3.5.9-1.fc8 installed 13 M


ImageMagick qui a une dépendance sur alsa-lib, l'exemple est assez cocasse du coup :)

Pour faire simple, soit les paquets A et B qui ont une dépendance commune envers le paquet C, j'installe d'abord A (et donc logiquement C) puis B (C étant déjà installé). Si je supprime A, je m'attends à ce que yum conserve C, mais là yum a un comportement stupide. A et C ayant été installé ensemble, yum va supprimer A, puis C et logiquement B puisque C va être supprimé.
Pas étonnant qu'avec ce comportement de merde, on fout le boxon sur sa Fedora.

Pas étonnant surtout que tout le monde prétende qu'APT soit mieux foutu que yum. Ce genre de comportement sur une opération de base c'est quand même du grand n'importe quoi, surtout pour ce qui est censé être le principal outil de gestion de paquets d'une distrib...

si un logiciel proprio permet de faire des économies (achat de licence plus cher mais gain en productivité meilleur qu'avec du libre par exemple), c'est nos impôts qui partiraient en fumée pour rien.

C'est une question de priorités d'un autre côté. Le gain financier n'est pas le seul intêret des logiciels libres, loin de là ; les avantages en termes techniques sont non-négligeables à terme : sécurité, possibilité d'auditer le code, d'initier un fork si besoin est, et donc indépendance d'un vendeur en particulier.

Donc même si ledit logiciel proprio pourrait paraître a priori plus intéressant sur le plan pécunier, il est très probable que favoriser l'équivalent libre se révèle une meilleure décision.

Mais tu es donc d'accord avec moi Qt n'est pas libre non plus puisqu'il impose des restrictions commerciales par l'application d'une double license

Non. La double licence de Trolltech te force à payer pour faire du code propriétaire avec QT, mais rien ne t'empêche de t'en mettre plein les fouilles en utilisant la version GPL de QT. Sauf que dans ce cas là, ton application doit être libre (logique).

Donc non, QT est tout à fait libre.

C'est fou comme linuxfr est mal frequente en fait.

Le jour ou RedHat se trouvera avec la meme quantite de softs qui dependent de sa plateforme et qu'il devra vivre avec et faire en sorte qu'ils continuent a tourner comme avant, les choses deviendront bien plus douloureuses.
L'ecosysteme Windows c'est une quantite de softs et de drivers gigantesque, et il faut que ca continue a tourner, si ca ne tourne plus, c'est un bug dans la plupart de cas.

La situation est un peu differente non ? Pour que ca "continue a tourner", tout ce que RedHat a a faire, c'est de recompiler les softs en question from source, merci le LL. Evidemment je fais l'impasse sur Oracle, et les eventuels problemes de compilation, mais ceux-ci sont rarement difficiles a resoudre sous Linux, qui est la principale plate-forme de dev pour les LL je pense.

Conclusion, ce sera sans doute plus facile pour RedHat que ca ne l'est aujourd'hui pour Microsoft...