ptit_tux a écrit 1268 commentaires

Perdre moins c'est gagné plus. C'est nouveau.

A force de gagner plus en perdant moins ils vont pas faire long feu.

Certe, c'est pas cool. Mais ces scripts sont sous GPL ?

Tu peux donner plus de précision sur les problèmes de licences car je comprends pas bien. Merci.

NB: je connais mal gentoo.

Je sais que RedHat a fait quelques essais. Finalement c'est pas terrible et ne justifie pas le coût en maintenance. Il y a 4 paquets qui sont optimisés sous RedHat : kernel, glibc, openssl et mod_ssl.

Pour RH9, en phase beta quelqu'un avait fait un script pour recompiler tous les paquets en i686 et les gains était pas terrible selon lui.

> J'en suis a ma 5 ou 6eme version de glibc avec la gentoo

Ben le problème, c'est pas rpm. C'est gentoo qui fournit des mise à jours de glibc qui marchent comme Mandrake/RedHat/etc fournissent des mise à jours de glibc qui marchent. Si tu fais une mise à jours d'une glibc suite à un errata, il n'y a pas de problème. rpm (ou deb) n'a rien a voir là dedans.
De plus les utilisateurs de cooker ou rawhide peuvent te garantir qu'ils ont fait des tones de mise à jour de libc sans problème.

> bien sur le force faisant tout exploser

Ce qui prouve que la dépendance n'est pas là pour rien et qu'elle existe réellement ! C'est pas une invention de rpm !

Maintenant installes la dernière version de glibc (depuis le cvs) et regarde si ça marche sous Gentoo. C'est à dire fait ça sans le travail en amont de gentoo. Ou mieux, fait un downgrade. Passage de glibc 2.2 à 2.0.

> Les dependances a la RH/Mandrake c'est bien, mais bonjour l'enfer pour changer de version de glibc ...

Système rpm ou non, les dépendances existent. Remplace gtk+ v1.2 par gtk+ v2 et tu verras que les applis qui utilisent gtk+ v1.2 ne marchent plus. C'est valable pour gentoo, RH, Mandrake, Slack, Debian, etc...

Puis si tu veux pas que rpm contrôle les dépendances, mais l'alias suivant dans ton compte root :
alias rpm="rpm --nodeps"

> Le parallele est bien la: tu peux merder a l'install de n'importe quelle distribs...

T'es lourd. Si tu merdes avec une RedHat, l'installeur refuse de faire l'installation (0 paquets d'installé). C'est compris ?

> tu installes (mal) un boot loader

C'est le seul point faible à ma connaissance. Tu peux installer le boot loader sur une partition sans que le MBR ne chaine dessus. De même tu peux installer le boot loader sur un disque non reconnu par le bios. Mais c'est des éléments que ne peut pas contrôler l'installeur.

> tu partitionnes (mal)

Sous Redhat => NON. Le système de fichier est contrôlé et la place disque aussi. Essai de mettre /boot sur une partition raid0 et c'est => NON, aucune installation.

Pourquoi ça t'embête que je dise ça ?

> T'aimes pas le commerce ?
> Elle est pas libre, leur distro ?

Où "vois"-tu ça ?

> mais, par rapport à l'année derniére, ils ont perdus moins donc gagnés plus

???
Comment gagné plus alors que globalement tu perds de l'argent ?

> et ?

Et rien. Mais certains croient que Gentoo c'est comme Debian. C'est pas le cas.

> il est un peu naze ton troll, ca fait vraiment le gamin qui repporte à la maitresse ...

Pourquoi, t'as honte de ça ?

> Je vois pas franchement la difference

C'est lorsque tu installes ta gentoo que tu compiles un kernel pour supporter la partition root ? Fait comment la gentoo ? elle met tout dans un ramfs (gcc, kernel-source, etc...) ?

> Le concept de la Gentoo ( que se devrait de suivre pas mal de "distribs")

Heu non merci pour moi. Les nuits à recompiler pour gagner 5%...

> C'est un peu, je trouve, dans le meme genre d'idee non ?

Non. Je dis que sous RedHat, l'installation est refusé s'il estime que la becane ne peut pas booter après. Ça n'a rien à voir. J'ai jamais dit que RedHat d'interdisait de supprimer tes partitions. Si tu supprimes tes partitions, anaconda (l'installeur de redhat) te permet d'installer la distribution ? NON.

Pour info, même si le site gentoo se termine par .org , c'est une boîte commerciale qui fait/dirige la distribution.

Je et Olivier parlons de l'installation. Une fois installé, le root peut faire toutes les conneries qu'il veut.

On aime ou on n'aime pas mais sous Redhat, l'installation sera refusée si le système de fichier ne permet pas de booter.

Tous les charmes de la Gentoo en une phrase...

Heu... Pourquoi tu m'"engueules" alors qu'on est d'accord ?

Bug connu.

> SCO est mort

SCO n'est pas mort, il nous fait chié encore.

> Le prix élevé donne l'impression qu'ils ont de très bonne raison de gagner le procès.

Ben mois je crois que c'est le contraire. Comme leur magouille ne va pas durer longtemps, ils essaient de récupérer le plus de pognon rapidement.

SuSE soutient l'initiative de RedHat :
http://www.suse.com/us/company/press/press_releases/archive03/sco_r(...)

Les mots sont assez dures :
We applaud their efforts to restrict the rhetoric of the SCO group -- and the FUD they are trying to instill

SuSE annoncera prochainement ce qu'il font faire pour appuier l'initiative de RedHat :
and will determine quickly what actions SuSE can take to support Red Hat in their efforts.

C'est l'utilisation de GNU/Linux et non Linux pour nommer son système son cheval de bataille. Puis RMS utilise Linux. Pardon GNU/Linux.

J'en sait rien. Mais comme en plus il n'y a pas que toi qui va lire ce post...
Disons que c'est un complément.

Tu utilises un noyau sans module ?

Le Slack touch.
Moins t'en demande, et moins t'as de problème.

Et non, ce ne sont pas les premiers :
http://www.redhat.com/about/presscenter/2003/press_coe.html(...)

Si la bsd n'est pas couverte, c'est parce que le BSD protège mal les sources et surtout les sociétés qui font du logiciel libre.

Imagines si Linux était sous BSD. IBM (ou un autre) reprend Linux, l'améliore et ne rediffuse pas les sources. Si Redhat fait du BSD, c'est comme s'il donnait du code sans contre-partie. D'ailleur Microsoft adore la licence BSD et déteste la licence GPL.

C'est dans l'article zdnet :

"This came as a surprise to us," IBM said Monday in a statement. "We have not had a chance to talk with Red Hat about this yet. So we have no comment at this time."

Pour SCO, dire quelles sont les lignes de code qui posent problème n'a aucun intérêt.
En effet, dans ce cas, en 1 semaine maximum, les lignes incriminées seraient remplacées et SCO n'aurait plus rien a exiger.