Ayrton a écrit 251 commentaires

C'est le desktop pour entreprise et c'est pas nouveau. RedHat en avait parlé il y a plusieurs mois (mi 2003 peut-être). Par contre le desktop pour les particuliers n'est pas prêt selon RedHat. Ça reste ouvert car RedHat a dit que s'ils fesaient un desktop pour particulier, ile achèteraient des licenses mp3 par exemple.
On n'est pas encore là...
Ce qui est vrai une année, n'est pas forcément vrai l'année suivante...

> Meme la nouvelle fedora n'est toujours pas a la hauteur de la mdk.

Fedora c'est le même créneau que Red Hat Linux. C'est pour appâter le petit décideur pressé d'eau vive.

Mandrake, c'est un autre registre.

Là je dis respect.
Je dis "Rentrez femmes et enfants !".
"Attention artillerie lourde !".

Avec Mandrake tu peux prendre le grand large.
Aller en haute mer et défier le triangle des bermudes.
Avec le câlibles d'une Mandrake tu vas à la pêche aux gros[1] comme le thon.
Sinon je dis fausse donne.

[1] décideurs

pssiii.... pssiiii.... ça fait plus de 20 minutes. J'crois qu'on peut arrêter.

> cela se discute de savoir si ca teinte la distribution debian :-)

Il est uniquement exécuté par le périphérique. Donc ça ne "teinte" que le périphérique. C'est comme si tu dirais que de mettre un firmwire sur un serveur apache pour le distribuer, "teintait" apache. Dans ce cas, comme pour Linux (ou Debian), Apache est utilise pour transporter le firmware et c'est tout.

> Il faut lire le post en entier

C'est ce que j'ai dit.

> si j'ai bien compris

Je ne crois pas :-)

> est que la présence d'un module GPL qui charge un firmware dans un modem ne teinte pas le kernel, puisqu'il est GPL

C'est ce que dit Linus.

> car la présence ou non d'un fichier de data chargé dans le modem ne saurait tainté le kernel au sens justement ou Torvalds l'entends

Tu as raté un truc.

Giuliano Colla s'étonne qu'un module avec un firmware binaire soit GPL et qu'un module avec du binaire exécuté par le noyau ne soit pas GPL. Il a parlé trop vite et pas remarqué que les drivers soft-modem sous Linux ont un fichier binaire qui s'exécute dans le noyau Linux.

Torvalds, dit que les drivers type Linuxant "pollue" le noyau car il y a des fichiers objets qui s'exécutent dans le noyau. Ce qui n'a rien a voir avec un firmware téléchargé par le noyau sur un périphérique (le firmware est exécuté sur le périphérique et non dans le noyau).

> Alors en attendant une éventuelle solution GPL, il ne faut pas trancher à la hâche un tel problème dont la solution n'est pas si évidente : il faut rester pragmatique, et c'est ce qu'à fait Linus et probablement d'autres développeurs.

Je ne comprend pas où tu veux en venir. Le compromis a été trouvé et accepté.
Il passe par MODULE_LICENSE, EXPORT_SYMBOL, EXPORT_SYMBOL_GPL etc.

Là, Linuxant viole clairement ce compromis et pour des raisons mineurs (warnings avec "taints kernel" qui perturbent l'utilisateur).

Puisque la news parle de GPL et de driver, voilà la réponse de Linus Torvalds dans le thread lorsqu'un mec s'est aventuré à troller sur les firmwares binaires dans le noyau qui viole la GPL :
http://marc.theaimsgroup.com/?l=linux-kernel&m=108327433126226&(...)

À lire. Ça évitera d'autres trolls ici.

Comme ça troll encore et encore sur les firmwares, voilà une réponse d'un Linus Torvalds qui s'est levé du pied gauche :
http://marc.theaimsgroup.com/?l=linux-kernel&m=108327433126226&(...)
You are not the first (and sadly, you likely won't be the last) person to
equate binary kernel modules with binary firmware. And I tell you that
such a comparison is ABSOLUTE CRAPOLA. There's a damn big difference
between running firmware on another chip behind a PCI bus, and linking
into the kernel directly.

And if you don't see that difference, then you are either terminally
stupid, or you have some ulterior reason to claim that they are the same
case even though they clearly are NOT.

Tout le monde devrait lire le mail en entier. Surtout Debian.

> il semblerait que la mauvaise foi est évidente

J'aime bien la réponse de Rusty Russell (le mainteneur de modutils etc) à Marc Boucher.
http://marc.theaimsgroup.com/?l=linux-kernel&m=108310787213125&(...)
On Wed, 2004-04-28 at 02:58, Marc Boucher wrote:
> Actually, we also have no desire nor purpose to prevent tainting. The purpose
> of the workaround is to avoid repetitive warning messages generated when
> multiple modules belonging to a single logical "driver" are loaded (even when
> a module is only probed but not used due to the hardware not being present).

You lied about the license, rather than submit a one-line change to
kernel/module.c.

This shows a lack of integrity that I find personally repulsive.


Name: Only Print Taint Message Once
Status: Trivial

Only print the tainted message the first time. Its purpose is to warn
users that we can't support them, not to fill their logs.

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff \
--minimal .22310-linux-2.6.6-rc2-bk5/kernel/module.c \
.22310-linux-2.6.6-rc2-bk5.updated/kernel/module.c
--- .22310-linux-2.6.6-rc2-bk5/kernel/module.c 2004-04-22 08:04:00.000000000 +1000
+++ .22310-linux-2.6.6-rc2-bk5.updated/kernel/module.c 2004-04-28 09:03:31.000000000 \
+1000 @@ -1131,7 +1131,7 @@ static void set_license(struct module *m
license = "unspecified";

mod->license_gplok = license_is_gpl_compatible(license);
- if (!mod->license_gplok) {
+ if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) {
printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
mod->name, license);
tainted |= TAINT_PROPRIETARY_MODULE;

Faut être sans ambiguïté :
C'est scandaleux !

Par pragmatisme Linus tolère des modules proprio. Linuxant devrait en être heureux.
Faire croire que c'est du GPL alors qu'il y a une partie proprio est SCANDALEUX.

> J'espère qu'elle est plus stable que la 1.91

Évidemment qu'elle est plus stable. La 1.91 était bonne mais avec plein de petit problème (principalement lié à SeLinux). La 1.90 était horrible.
La 1.92 marche comme un charme ici. Il reste quelques bugs assez génant. Pas de sauvegarde du mixer alsa, pas de configuration de la sourie en mode texte, etc...
Pas difficile à corriger.

> J'ai voulu upgrader ma Core 1 en 1.91

Il ne faut pas faire ça ! Le mode mise à jour n'est absolument pas pris en compte pour les test X.
Quelqu'un qui connait bien Linux peut faire une mise à jour (depuis les CD ou avec yum) mais il y a toujours des corrections à faire à la main.

Faut compiler avec -O0 et/ou -fno-inline .

Difficile. gcc boostrap.
Ce qui va arriver, c'est que icc va compiler gcc-stage1 puis gcc-stage1 va compiler tout gcc. Puis les 15 % de mieux, tu peux rêver.

> break my_class::my_method() ne marche toujours pas

Faut virer "()"

Ça semble déjà fait (j'utilise pas cette fonctionnalité) :
/etc/rc.d/rc.sysinit

# Boot time profiles. Yes, this should be somewhere else.

if [ -x /usr/sbin/system-config-network-cmd ]; then

  if strstr "$cmdline" netprofile= ; then

    for arg in $cmdline ; do

        if [ "${arg##netprofile=}" != "${arg}" ]; then

            /usr/sbin/system-config-network-cmd --profile ${arg##netprofile=}

        fi

    done

  fi

fi

Il faut utiliser "netprofile=<profile>" dans les parablèmes de boot.

> Ecrire un compilateur ne lui sert qu'à montrer ses CPUs sous un meilleur jour (notamment tests SPEC CPU).

Merci d'aller dans mon sens.

> Le resultat, c'est que des tas de projet vont passer du temps a corriger les problemes de compilation lie a gcc 3.4

Et généralement il vont aussi découvrir des conneries dans leur code.
J'était sur http://lwn.net/Articles/79560/(...) et j'ai trouvé ça dans gcc 3.4 :


gcc 3.4 supports a "warn_unused_result" attribute on functions; the compiler will complain when code calls a function marked with this attribute and fails to check the return value. The Red Hat kernel applies that attribute to a few functions (copy_from_user(), pci_enable_device(), etc.) to trap places where the proper checks are not made. Various functions which use too much kernel stack space have been fixed up.


Une très très grosse partie de FC2 compile avec gcc 3.4 (ce n'est pas le compilateur par défaut). A chaque foi qu'il y a un nouveau compilateur il faut 6 mois pour que l'essentiel soit porté (il reste toujours deux ou trois mal maintenu...).

Tu veux quoi ? Plus d'évolution ?
GNU/Linux a la chance d'être orienté source. Ça permet d'évoluer vite.
Profitons-en.
Si on était empétré dans les problèmes de compatibilité comme les OS proprio, GNU/Linux serait probablement un échec.

De plus tu peux toujours installer plusieurs version de gcc en parallèle. Donc je ne comprend pas ta remarque.

Je suis d'accord avec toi. C'est le *principe* de respecter les standards qu'il faut retenir. Après, au cas par cas, on respecte ou non les standards. Mais ne pas respecter les standards gratuitement, sans bonnes raisons, est nul.

> Quel est l'interet d'un standard si difficile a implementer que personne ne peut le faire avant 10 ans ?

Ça fait une roadmap pour les 10 ans à venir :-)
Mozilla a mis combien de temps pour respecter les standards ?
Mozilla serait aussi bon si le projet devait aussi faire le travail réalisé par le w3c ?
De plus, qui participe pour faire les standards ? Pour w3c c'est mozilla, etc. Bref ceux qui réalisent des navigateurs et/ou utilisent le web.

> Sauf que les messieurs du standards, parce qu'ils s'ennuient et pour justifier leur salaire, ils continuent a faire evoluer le standard.

Là tu abuses. Il faut toujours un standard d'avance si le standard actuellement utilisé n'est pas satisfesant. Regarde le "merdier" des débuts d'html car il n'y avait pas de standard en avance. Des navigateurs incompatibles, des normes qui sortent à l'arrache pour remettre de l'ordre (html 3.2 et 4).
Maintenant que le w3c a repris de l'avance, tout le monde bossent dans la même direction.
De plus des nouveaux standards qui remplacent l'ancien il n'y en a pas tous les jours (regardes pour le C/C++ et SQL et compte le nombre de standard ANSI par exemple et divise par le nombre d'année).
Enfin, les nouveaux standards font toujours très attentions à la compatibilité. C'est plus rarement le cas des initiatives isolées.

Freedesktop travail pour faire des standards et éviter le bordel et la guerre entre Gnome et KDE.

Les standards c'est bien.

Ça n'enlève rien au principe de respecter les standards.
Si tu fais du spécifique icc ou gcc, tu auras encore plus de problème.
Il faut que les compilateur s'alignent. Je préfère qu'il s'alignent sur des standards que le :
- "nivellement pas le bas pour que ça passe partout"
- ou "je code gcc comme un porc car je veux qu'il supporte les saloperies de Visual C".

> gcc est plus que correct, mais il n'est pas le meilleur à tous points de vue.

C'est peut-être pas le meilleur pour les performances mais globalement c'est le meilleur (avis personnel)
Puis ces trucs d'optimisations c'est "fatiguant". On promet le pérou et quand on voit la différence entre une Gentoo et une autre distribution, on constate que le pérou est encore très loin... Et aussi lorsque le cpu est utilisé intensivement (sauf pour des cas particuliers qui ne consernent que 0.01 % des utilisateurs).

Il y a plein de cluster Linux vendu avec gcc. Ce n'est pas un hazard.
Si icc écrasait gcc en performance, Intel aurait fait un bench avec une distribution complètement compilée avec icc pour montrer comme icc rox à mort. Peut-être qu'Intel aurait aussi forké une distribution avec la seule particularité d'utiliser icc.

> beaucoup de temps processeur, par ex. oggenc, mencoder

J'aimerais bien voir un bench de mencoder, qui est optimisé aux petits oignons, compilé avec gcc et icc.
Déjà il faut que ça compile avec icc, ce qui n'est pas sûre.
Puis l'écart en faveur d'icc (si cet écart existe) sera très faible. Pas de quoi lacher un amour de logiciel libre comme gcc.

Lorsque j'utilise gdb, j'ai pour habitude de compiler avec "-O0 -g2". C'est peut-être plus nécessaire mais ça marche bien.

Si 20 lignes de "code parfaitement banal de C" suffissent pour générer du code incorrect, que GNU/Linux marche alors qu'il faut compiler des dizaines de millions de lignes de code est un véritable exploit.
Les utilisateurs de Gentoo apprécirons ta remarque.

> genere un code 15% plus performant en moyenne

Tu veux dire que si je compile mon GNU avec icpc mon système va tourner 15 % vite en moyenne ?
Fichtre !

J'y crois pas.

> Sinon, je note l'objectivite habituelle des linuxiens de base qui ont moinsse a tout va mon commentaire.

Rappel de ton post :
>> Sinon, le but d'etre compatible standard pour etre compatible standard, c'est bof.
>> Pis le standard C++, c'est quand meme une horreur.

Et

>> Comme gcc est le seul compilateur aussi respectueux des standards, si tu ecris du code au poil pour gcc, j'ai peur que ce soit une garantie de peter sur d'autres compilateurs.

Remplaçons gcc par mozilla et compilateur par navigateur pour voir ce que ça donne :
Comme mozilla est le seul navigateur aussi respectueux des standards, si tu ecris du code au poil pour mozilla, j'ai peur que ce soit une garantie de peter sur d'autres navigateurs.

Le moinsage ne me surprend pas.

> gdb est une bouse.

Utilise les debuggeurs des unix commerciaux (quand il n'utilise pas déjà gdb). La bousse aura soudain un parfum de rose.

Pour moi gdb est la rolls des debuggeurs et ddd est une bonne interface graphique.
Si gdb déconne sur ta distribution, fait un rapport de bug.

UTF-8 est un codage particulier d'UCS-4 (unicode).
Tous les caractères d'UTF existent dans UTF-8. Si tu préfères, UTF-8 couvre UTF-32.

man utf-8 :
Tous les 2^31 caractères de l’UCS peuvent être encodés en utilisant UTF-8.

2 millards de caractère dans utf-8.
Pour info, un caractère dans utf-8 peut-être codé avec 1 à 6 octets. UCS-4 c'est toujours 4 octets.