marc jeweilige bismark a écrit 16 commentaires

Je vote pour une nouvelle arch 64bit RISC, PowerPC, sans BIOS pourri mais du openfirmware, sans disquette, sans RS232 ni port // mais de l'USB, du firewire et de l'ethernet en standard.

D'autres partisans ?

Ok, l'interface de blender est ésotérique mais je pense que pour un logiciel de 3D une interface bizarre mais puissante se justifie. Ce n'est pas comme un logiciel de traitement de texte ou de gravage de cds que tu utilises de temps en temps pour faire un petit truc, écrire une lettre, faire un backup simple.
On n'utilise pas blender un quart d'heure chaque mois, juste pour faire le rendu d'un cube simple sans fioritures. Un dessin 3d c'est plusieurs heures de travail en prise direct avec le soft, voir plusieurs jours. La 3d est un monde bien différent de la 2d des interfaces graphiques normaux (QT, gnome, MFC) et justifie tout à fait une autre aproche avec interface spécialisé.

Le truc qu'il te faut c'est du java. Pas de buffer overflow ni de double free (mais ça veux pas dire qu'il n'y a plus de bug).

Et le libre n'est pas vraiment en retard de ce côté avec tomcat, cocoon, jboss, netbean, etc.

Mais bon, au niveau perf, ça vaut pas le C.

A mon avis les critères de fiabilités pour la conception de la Xbox ne sont pas les mêmes que pour des serveurs. Au niveau dissipation thermique, fiabilité de l'alim, des composants ça doit être autre chose.

C'est comme comparer une perceuse intermarché avec perceuse industriel.

Si j'était Adobe je me posserais des questions. Si vos clients utilise vos produits sur un autre OS avec VMWare, c'est peut-être bientôt plus vos clients. En plus c'est pas des hackers barbus, c'est Dreamworks, 150+350 postes, avec supports, plugins etc.

Je sais pas de quels filtres tu parle parce qu'en son temps j'avais testé tout mes documents Office avec OpenOffice.org 638 et StarOffice 6.0 beta. Résultat: aucune différence, tout ce qui n'est pas passé dans l'un ne passait pas dans l'autre. Deplus j'ai fait des rapports de bugs et à la version 641 tout mes documents passaient la conversion.

Je me demande si c'est pas l'argument "c'est cher donc c'est mieux" qui te fais dire ça. Si c'est le cas je commence à comprendre pourquoi Sun vend StarOffice.

Sur le même sujet j'ai trouvé un résumé du kernel cousin de septembre 2000 qui parle de façon très détaillée des posix threads, de design, etc. :

http://kt.zork.net/kernel-traffic/kt20000911_84.html#1(...)

Sun hoped to make other than improvements to how Linux handles common computing processes known as threads, changes Sun hopes will make Linux work better on high-end servers with many processors.

Ca ressemble a une implementation des threads à la Solaris dans linux, contribué pas Sun.

Les threads sous linux sont implémentés comme des processus lourds qui partage la même mémoire. C'est pourquoi on voit plusieurs lignes pour un programme avec ps, par exemple pour java ou OpenOffice.org. Une autre solution est d'implémenter toutes les threads dans le processus de l'application. C'est je crois la façon de fonctionner de l'ancienne lib gnu pour les thread.

Solaris utilise je crois la voie médianne, plusieurs processus qui exécute plusieurs thread chacun. Ce serait intéressant de voir ça implémenté pour linux.

Oui je vois ce que tu veux dire. Mais je crois que ce que tu appelles "architecture" n'est pas le concept qu'on comprend par exemple pour "architecture Sparc, powerpc, i386, ...". Ce dont tu parles est plutôt la réalisation de cette architecture, la configuration, le nombres d'unités de calcul, la longueur du pipe, les forces et les faiblesse du CPU.

Car si j'ai bien compris les compileurs actuels pour CISC ne font pas qu'optimiser les instructions mais les produisent de façon à ce que le microcode dans lequel elles vont être traduites par le CPU soit performant. Parce que ces processeurs exécutent le microcode d'une façon assez proche de celui des RISC. Le problème est que l'architecture "interne", style RISC, change d'une version à l'autre (PIII-> P4 p. ex.).

Je me demande si on a ce problème d'une version à l'autre d'un RISC, par exemple du POWER3 au POWER4 d'IBM.

mais bien que ça reste du x86

Justement c'est plus du i386. Sur une distrib compilée pour Hammer 64 ça sera bien plus rapide en raison du plus grand nombres de registres, du 64 bit, etc. C'est comme le passage 286 -> 386.

Il faut espérer que Debian sorte une version pour le Hammer...

Il se lance nettement plus vite que la 641c

J'ai toujours pensé que les impressions sur les nouveaux soft est faussé par l'effet "c'est nouveau donc c'est mieux".

Alors j'ai fait un petit test:
Debian woody, Athlon 756Mhz.
OOo lancé puis fermé de suite, résultat après 2-3 lancements pour remplir le cache.

641c:
real 0m15.736s
user 0m8.920s
sys 0m0.290s

1.0.0:
real 0m15.352s
user 0m8.750s
sys 0m0.280s

C'est bien ce que je pensais.

openoffice n'est pas près de rentrer dans debian car:

- sa compilation est compliquée, demande tcsh, n'est pas fait avec automake/autobuild, utilise dmake et non gmake, demande un bootstrap, etc. Un logiciel peut avoir une procédure de compilation bizarre mais la c'est presque trop.

- OOo utilise plein de lib standard qui sont dans debian, mais les compile pour lui tout seul et les inclues dans LD_LIBRARY_PATH au démarrage. C'est de nouveau pas propre.

- OOo est un gros bloc et la philosophie debian c'est plutôt chaque soft son paquet, comme avec kde. Donc il faudrait séparer le tableur, l'éditeur de texte, de graphiques, etc.

tiré de http://alienor.fr/~pierre/echo-linux/articles/intro-X/introX.html(...)

début de X: 1983
première version publique, X10: 1985
X11R1: février 1987
X11R6: mai 1994

le site annonce la X11R7 pour décembre 96 :)

Je suppose que de X11R1 à R6 la compatibilité binaire est conservée mais pas de X10 à X11.
Donc X a été testé 4 ans avec 11 versions avant d'arrivé à la version "binairement compatible" que nous utilisons aujourd'hui.

mes 2 cents

J'ai lu en quelquepart que les modéros de bugtraq indiquaient qu'il fallait d'abord communiquer le bug à l'auteur en lui donnant un délai raisonnable pour corriger la faille. Ensuite, le délai dépassé on pouvait publier sur bugtraq.

Confirmation ?

Ca dépend tout du type de calcul à effectuer. Si c'est un calcul limité par la vitesse de calcul des processeurs, un cluster c'est ok. Si c'est un calcul limité par les entrées sorties et la communication entre les threads/processus, le cluster qui a moins de débit et de plus gros délais est largué.

Sans compter qu'on sait pas combien de linux se cachait dans les 38% d'unix de 2000.