Posté par 007 .
En réponse au journal FUD de Sun.
Évalué à 2.
> RedHat modifie manifestement pas mal de trucs de base (compilo, glibc, emplacement d'en-têtes, structure des en-têtes, etc.)
FUD. C'est vrai pour RHEL. Et encore...
Le plus souvent les incompatibilités sont des modifications qui se retrouvent en upstream quelques semaines ou mois plus tard. Par exemple NPTL.
Par contre, il y a un "truc" que certains n'ont pas remarqué. /usr/include/linux de RedHat ou Fedora n'est pas un lien vers /usr/src/linux/include/linux (ou /lib/modules/2.x..../build/include/linux ).
C'est le paquet glibc-kernheaders qui est la pour avoir plus d'indépendance avec les modifications rapides des entêtes de Linux.
C'est une "feature" et aussi une source d'emmerdement. Si problème :
$ cd /usr/include
$ mv linux linux.orig
$ ln -s /usr/src/linux/include/linux
OU
$ ln -s /lib/modules/2.x.../build/include/linux
Même pour FC2 (Linux 2.6) c'est encore principalement les entêtes de Linux 2.4.
C'est pas dramatique car il faut normalement utiliser /lib/modules/2.[version]/build/include/linux ou /usr/src/linux-[version] pour les programmes qui dépendent du noyau. Les bon paquets/projets (par exemple alsa de freshrpms) font ça. Le répertoire /lib/modules/2.[version]/build/ qui n'existe que dans RedHat depuis un moment est plus ou moins prévus pour être en standard dans 2.6.x a venir.
C'est un peu expliqué ici : http://lwn.net/Articles/80250/(...)
> glibc
Très peu de modification car c'est principalement RedHat qui maintient la glibc...
Pourquoi ? Car il n'est pas nécessaire de faire des backports de la branche de développement :-)
> RedHat n'est pas un Linux de base, on peut le considérer comme un fork.
Si c'était un fork on verrait moins de "<-------@redhat.com>" dans les changelog de Linux.
> Exemple : le pilote des cartes wireless à base de puces RT2400, dont il fallait modifier trois #include avant qu'il ne compile correctement.
Installes un kernel vanilla dans ce cas.
Si la distribution ne marche pas avec un kernel vanilla (bien configuré !), tu peux faire un rapport de bug sur http://bugzilla.redhat.com/(...) . Il sera pris en compte (si ce n'est pas un bug du kernel :-)).
[^] # Re: FUD de Sun
Posté par 007 . En réponse au journal FUD de Sun. Évalué à 2.
FUD. C'est vrai pour RHEL. Et encore...
Le plus souvent les incompatibilités sont des modifications qui se retrouvent en upstream quelques semaines ou mois plus tard. Par exemple NPTL.
Par contre, il y a un "truc" que certains n'ont pas remarqué. /usr/include/linux de RedHat ou Fedora n'est pas un lien vers /usr/src/linux/include/linux (ou /lib/modules/2.x..../build/include/linux ).
C'est le paquet glibc-kernheaders qui est la pour avoir plus d'indépendance avec les modifications rapides des entêtes de Linux.
C'est une "feature" et aussi une source d'emmerdement. Si problème :
$ cd /usr/include
$ mv linux linux.orig
$ ln -s /usr/src/linux/include/linux
OU
$ ln -s /lib/modules/2.x.../build/include/linux
Même pour FC2 (Linux 2.6) c'est encore principalement les entêtes de Linux 2.4.
C'est pas dramatique car il faut normalement utiliser /lib/modules/2.[version]/build/include/linux ou /usr/src/linux-[version] pour les programmes qui dépendent du noyau. Les bon paquets/projets (par exemple alsa de freshrpms) font ça. Le répertoire /lib/modules/2.[version]/build/ qui n'existe que dans RedHat depuis un moment est plus ou moins prévus pour être en standard dans 2.6.x a venir.
C'est un peu expliqué ici :
http://lwn.net/Articles/80250/(...)
> glibc
Très peu de modification car c'est principalement RedHat qui maintient la glibc...
Pour le kernel, la FC2 est très peut patchée :
http://lwn.net/Articles/80290/(...)
Pourquoi ? Car il n'est pas nécessaire de faire des backports de la branche de développement :-)
> RedHat n'est pas un Linux de base, on peut le considérer comme un fork.
Si c'était un fork on verrait moins de "<-------@redhat.com>" dans les changelog de Linux.
> Exemple : le pilote des cartes wireless à base de puces RT2400, dont il fallait modifier trois #include avant qu'il ne compile correctement.
Installes un kernel vanilla dans ce cas.
Si la distribution ne marche pas avec un kernel vanilla (bien configuré !), tu peux faire un rapport de bug sur http://bugzilla.redhat.com/(...) . Il sera pris en compte (si ce n'est pas un bug du kernel :-)).