matiasf a écrit 1969 commentaires

Avant d'utiliser des RISC, j'étais "impressionné" par ces cpu et ce que l'on lisait dans la presse spécialisée.
Puis j'ai bossé sur des stations de travail alpha hppa sparc. Ben mon pc personnel était toujours plus rapide. Sauf une fois. Mais c'était un "monstre" ( 8 cpu alpha , 16 Go ). Réellement impressionnante cette bécane, mais hors de prix...

J'ai une anecdote marrante. Je développe un intranet pour HP sur hppa avec php. J'ai des performances lamentables. Je suis remis logiquement en cause et j'explique que mes développements sur Linux/i86 n'ont pas ce problème. On organise des benchmarcks. J'ai plusieurs machines dont une station de travail haut de game d'hp ( 1 cpu 1Ghz ) et un pc avec un celeron 500 Mhz. Le celeron est 40 % plus performant ... Le site tourne maintenant sur un PC :-)

Alors pour moi, même si j'entend souvent que le x86 est tout pourri, je suis toujours bluffé par ces performances et encore plus par son rapport performance/prix.

> J'ai dit, et je maintiens, que le x86 est un boulet dans l'industrie du processeur.
C'est un petit boulet. Le i386 est fort correct et il est sortie il y a 12, 15 ans. Je sais plus.

Le mode réel du i386 est un boulet (16 bits). Mais il représente presque rien dans les nouveaux cpu ( 1 % maxi ). A part Grub, Lilo et autre truc en début de boot, il n'y a plus de programme qui utilise le mode réel du x86.

> Vois pas le rapport.

Je veux dire que le portage vers une architecture 64 bits est déjà fait pour la grande majorité des applis.

Exemple :

[f.matias@one tmp]$ rpm2cpio ftp://ftp.free.fr/mirrors/ftp.redhat.com/redhat/linux/rawhide/x86_(...) | cpio -iv -m -d
./usr/bin/gunzip
./usr/bin/gzexe
./usr/bin/gzip
[...]
[f.matias@one tmp]$ file bin/gzip
bin/gzip: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped
[f.matias@one tmp]$ bin/gzip
bash: bin/gzip: cannot execute binary file
[f.matias@one tmp]$

Idem pour postgresql-server (je les ai pas tous fait...). Il y a même le répertoire /usr/lib64/ pour ses librairies.

> (ISA = Instruction Set Architecture)

Je ne te comprend pas bien car je ne suis pas hyper pointu en cpu. L'Athlon peut déjà utiliser des instructions de 64 bits. D'ailleur je ne vois pas en quoi c'est un avantage. Faut un plus gros cache.

http://moules.powa.free.fr/dlfp_score.php?comment_nb=183315(...)

Tourjours pas de cabale ?

> Si seul le noyau est en 64 bits, l'intérêt est relativement limité pour l'instant.

Ya beaucoup d'applis qui tournent nativement en 64 bits sur Alpha, Sparc, ia64 etc...
Je pense que c'est du 64 bits.

Le 13/03/2003 à 18:32 :
http://www.woof.lu/board/(...)

17:22 dacabale< matiasf
17:23 17:22:24 matiasf (XPs: 28) [url] [url] [url] [url] [url]

Je vous salue pas les Gros Cons.

Autant pour moi. j'avais posé la question à l'annonce de la sortie mais pas de réponse. Je fais une fixation sur les sources et les licenses.

RedHat ne remet pas en cause l'existence à la RedHat Linux "classique". Par contre, le côté "chiant" de la "classique" c'est qu'il n'y a qu'un an de support. Mais rien empêche une sociétés ou un organisme de prolonger le support pour ces distribes.

> Est-ce que la redhat AS a aussi un cycle de sortie long ?

Même chose pour AS/ES/WS. La AS est sortie en mai 2002. Le cycle est de 12 à 18 mois. Le support est au minimum de 5 ans :
http://www.redhat.com/apps/support/errata/rhlas_errata_policy.html(...)

Tient, ça a augmenté. C'était de 3 ans il y a quelques mois.

> Et si je comprends bien, il y a les mêmes tests sur les différentes distrib Redhat, la seule chose qui change vraiment

Pas vraiment :
http://www.redhat.com/whitepapers/rhel/ASESWSOverViewPdf.pdf(...)

Donne les différences entre les Redhat enterprise à la RedHat classique.

> Est-ce que la tranformation d'une ES par nos petites mains avec des paquets de la SA annule les éventuels contrats de support ?

Je ne serait pas étonné que la ES soit déjà une SA. La différence étant le support. Donc ...

> faire ce genre de chose.

Quoi plus précisement ?
Avoir trouvé un modèle économique qui marche bien et réinvestir pratiquement tout dans le free software. Réinvestissement qui profite à toutes les distribes.

> A propos de Mandrake, quelqu'un peut me dire où je peux lire la license, et où sont les sources et errata ?

Je parle de la version Corporate Server.

Si RedHat fait comme pour la SA, il y aura des sources dispos sur leur serveur. Si les sources sur leur serveurs ne sont actuellement pas dispo, je pense que c'est temporaire. D'ailleur il y aura une "download" edition et seront obligés de fournir aussi les sources en download (GPL). Donc tout le monde pourra expertiser les diffirences pour voir comment sont implémenter les différences entre la SA, ES et WS.

Enfin, pour l'instant, comme on ne sait pas grand chose. Cette limitation est peut-être uniquement pour le support. Pour le support, je pense qu'il vont faire comme pour la SA. Ils fourniront les sources. De plus d'après la license, rien empêche de faire un forck de la SA/ES/WS par une autre société et fournir du support.

On est très très loin de Microsoft.

> Bref, pour ceux qui souhaitent rester libre, il reste heureusement beaucoup de distributions (Mandrake, Debian, Gentoo, Slackware, etc).

A propos de Mandrake, quelqu'un peut me dire où je peux lire la license, et où sont les sources et errata ?

> Et est-ce que ALSA utilise beaucoup plus de ressources (CPU, memoire et batteries) ?

Pas à ma connaissance.

> mais pour quelqu'un chez qui OSS marche bien

Si tout va bien, qu'il n'y a pas de problème et que toutes tes demandes sont exhaussées : aucun.

Alsa pour Redhat, c'est ici :
http://freshrpms.net/docs/alsa/(...)

Ya aussi plein d'autres bonnes choses.

> Des procedures/ fonctions de moins de 40 instructions (instructions, pas lignes). Si c'est trop gros, tu decoupes.

Bof. Si c'est une fonction fleuve sans imbrication, je vois pas pourquoi spliter la fonction. Des paramètres plus pertinants doivent être utilisés dont le nombre de variables locales utilisées, le nombre d'imbrication, la complexiter etc...

Personnellement, avoir une fonction qui est appelée uniquement une fonction n'améliore pas forcément la lecture. Je préfère une longue fonction fleuve. Si plusieurs actions sont réalisés, mettre un "gros" commentaire. Par exemple :
/*
* Stockage des informations récupérées
*/

et non

// enregistrement

Cà c'est une boucle infinie. De plus dans la récursivité il faut une condition de fin. Sinon core dump...

Pour avoir un explication sur la récursivité, relire cette phrase et mettre une cacahuète de coté. Si ça vous soule :
* Manger une cacahuète, revenir à *. Arrèter tout si plus de cacahuète.

> Mais c'est quand meme vachement utile quand tu dois parcourir un arbre.

On peut tout faire avec les boucles. Mais la récurcivité rend parfois, voir souvent, les choses plus propres et lisibles. Mais ça coûtes des appels de fonctions supplémentaires et de la place sur la pile.

L'interêt de ce "truc" est qu'il fonction sur gecko. Qui lui est disponible partout. Ce n'est donc pas dépendant de la plate-forme. C'est un peu comme java.

> En effet pour ma part lorsque je code quelque chose, je m'arrange pour que ce soit aussi beau que possible.

Beau? C'est pas mon soucis. Mon soucis numéro 1 est la lisibilité, la clarté, la simplicité (sans être simpliste !).

La "beauté" d'un fichier source peut-être trompeuse. Un source peut-être beau car bien commenté, avec de solides conventions, etc... bien que la conception soit naze. Lorsque l'on fait un programme, il y a l'expression de besoin du client, et les choix techniques, de conceptes utilisés pour répondre à ce besoin. Pour moi un bon code permet de rapidement comprendre la solution, les conceptes retenuent pour répondre au besoin. En C, les fichiers .h et la séparation claire des outils/conceptes utilisés est primordiale. Les fichiers .h et la définition des structures de données en disent beaucoup plus sur l'"élégance" d'un programme que les fichiers .c, l'indentation, etc...

> j'ai pense tout simplement que c'etait parce que le nouveau Nautilus etait ecrit en GTK2 et Mozilla toujours en GTK1. Quelqu'un peut confirmer?

C'est le problème. Il est domage qu'ils n'aient trouvé une solution. Par exemple on peut faire cohabiter php3 et php4 en modules dans apache (faire un configure --enable-versionning pour php3 et php4). Gtk 2 était une grosse réécriture de gtk1. Ce problème ne se reproduira pas avant longtemps.

Ce qui fait aussi la vitesse globale d'une base de donnée, c'est aussi ces fonctionnalités. Si, par exemple, pour le contrôle d'intégrité tu doit tout coder en php, ton appli va en prendre un coup en terme de performance. il y a aussi les locks de table qu'il ne faut pas oublier de virer sinon, ... plus de service ... Sans parler des risques d'erreur en programmant ...

Idem pour xemacs. Le file selector est moche mais efficace. Le plus moche et le plus efficace reste bash :-)

> je ne sais pas pour 2

Je n'ai pas nautilus et je suis sous Gnome 2.

J'ai bien aimé. C'est un court métrage "fun", satirique. L'analogie avec Hitler est lourde quand même. Notes que tous les utilisateurs sont tous pris pour des pigeons. Par contre certains bouffent de la merde (c'est de l'humour à la Michel Muller).
J'ai passé un bon moment. Merci.

flux : http://www.tv-radio.com/station/public_senat/public_senat-150k.ram(...)