Démonstrations de NeXTSTEP

Éric Lévénez <usenet@levenez.com> wrote:

Bonsoir,

J'ai effectué 7 captures vidéos de NeXTSTEP pour montrer la dynamique de
ce système qui date de 20 ans...

Elles sont disponibles ici : <http://www.levenez.com/NeXTSTEP/#demos>

J'avais été fort étonné, il y a un paquet d'années de la réactivité de
l'OS des stations NeXT. C'était lors d'une Apple Expo, peut-être la
dernière à s'être tenue au CNIT. UN truc qui m'avait complètement bluffé
à l'époque (celle du système 6.0.x), c'était ce que permettait le
display Postscripte (pour l'affichage écran), entre autre, le "live
scroll", auquel nous sommes habitué maintenant : le défilement
synchronisé de l'ascenseur et du texte dans la fenêtre.

Egalement permis par le display postscript, une imprimante laser "toute
bête", et étrangement bon marché (comparativement aux Laser Apple qui
étaient des ordis à elles seules pour interpréter le postscript, et
également comparativement aux Stations NeXT)

J'ai l'impression que MAc OS X, pourtant hérité de NeXTSTEP n'avait pas
tout à fait la même réactivité lorsqu'il est sorti. Pourtant il y avait
un gouffre en terme de performance entre les NeXT que j'avais vu tourner
(à base de 68040), et les Macs du moment de la sortie de MAc OS X(pas
loin du GHz).

Je n'ai jamais bien compris.

--
PO.

Pour m'écrire : po_taubaty(arobas)yahoo(point)fr

Pierre-Olivier TAUBATY a écrit :

J'avais été fort étonné, il y a un paquet d'années de la réactivité de
l'OS des stations NeXT. C'était lors d'une Apple Expo, peut-être la
dernière à s'être tenue au CNIT. UN truc qui m'avait complètement bluffé
à l'époque (celle du système 6.0.x), c'était ce que permettait le
display Postscripte (pour l'affichage écran), entre autre, le "live
scroll", auquel nous sommes habitué maintenant : le défilement
synchronisé de l'ascenseur et du texte dans la fenêtre.

Oui, la réactivité était là, même avec un cpu à 25 MHz. On pouvait
déplacer les fenêtres avec leur contenu. Aucun rectangles blanc comme
sur Mac OS ou de contenu "fantôme" comme dans Windows.

Pour expliquer la rapidité du système, il y a aussi le fait que les
bibliothèques du système était plus petites et donc se chargeaient plus
rapidement. Pas besoin du prebinding pour contourner cela. Si l'on prend
Edit, il faisait 1,8 Mo en RAM et 5 Mo en Virtuel. Aujourd'hui TextEdit
fait 10 Mo et 2748 Mo en Virtuel. On voit là, par la mémoire virtuelle,
que TextEdit utilise des bibliothèques immensément plus grande et que
cela impacte directement le temps de lancement de l'application.

Egalement permis par le display postscript, une imprimante laser "toute
bête", et étrangement bon marché (comparativement aux Laser Apple qui
étaient des ordis à elles seules pour interpréter le postscript, et
également comparativement aux Stations NeXT)

Ce qui était étonnant était que la NeXTprinter, qui utilisait le même
moteur que les Canon et HP de l'époque, imprimait elle, en 400 ppp et
non en 300 ppp. L'impression de document complexe était aussi très rapide.

J'ai l'impression que MAc OS X, pourtant hérité de NeXTSTEP n'avait pas
tout à fait la même réactivité lorsqu'il est sorti. Pourtant il y avait
un gouffre en terme de performance entre les NeXT que j'avais vu tourner
(à base de 68040), et les Macs du moment de la sortie de MAc OS X(pas
loin du GHz).

Je n'ai jamais bien compris.

Quand je vois que le lancement de FrameMaker sous NeXTSTEP était très
rapide (instantané sur ma machine actuelle) alors que inDesign met près
de 10 secondes sur ma machine actuelle, on peut en effet se poser bien
des questions sur cette régression de l'informatique.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Éric Lévénez a écrit :

Pierre-Olivier TAUBATY a écrit :

J'avais été fort étonné, il y a un paquet d'années de la réactivité de
l'OS des stations NeXT. C'était lors d'une Apple Expo, peut-être la
dernière à s'être tenue au CNIT. UN truc qui m'avait complètement bluffé
à l'époque (celle du système 6.0.x), c'était ce que permettait le
display Postscripte (pour l'affichage écran), entre autre, le "live
scroll", auquel nous sommes habitué maintenant : le défilement
synchronisé de l'ascenseur et du texte dans la fenêtre.

Oui, la réactivité était là, même avec un cpu à 25 MHz. On pouvait
déplacer les fenêtres avec leur contenu. Aucun rectangles blanc comme
sur Mac OS ou de contenu "fantôme" comme dans Windows.

[couic]

J'ai l'impression que MAc OS X, pourtant hérité de NeXTSTEP n'avait pas
tout à fait la même réactivité lorsqu'il est sorti. Pourtant il y avait
un gouffre en terme de performance entre les NeXT que j'avais vu tourner
(à base de 68040), et les Macs du moment de la sortie de MAc OS X(pas
loin du GHz).

Je n'ai jamais bien compris.

Quand je vois que le lancement de FrameMaker sous NeXTSTEP était très
rapide (instantané sur ma machine actuelle) alors que inDesign met près
de 10 secondes sur ma machine actuelle, on peut en effet se poser bien
des questions sur cette régression de l'informatique.

A l'époque on se souciait du "packaging" du système (j'ai travaillé sur
un OS et des compilateurs). On faisait attention de "rassembler" le code
étroitement dépendant dans le même segment de mémoire (on essayait de
minimiser les branchements inter segment (qui pouvaient être
catastrophiques pour la gestion de la mémoire virtuelle car on ne
parlait pas de RAM en Go !
Si la machine n'était pas à segment mémoire, on prenait garde aux
algorithmes de pagination (j'ai connu une machine dans laquelle les
segments mémoire étaient eux-mêmes paginés)
Aujourd'hui, je crois que tout le monde se fiche du packaging et de
l'optimisation du code compte tenu des capacités mémoire et des disques
ainsi que de la fréquence d'horloge). Je dis "je crois" car je suis
retraité :-)
C'est évidemment une erreur car si on portait autant attention au
packaging qu'il y a 25 ans, avec les performances matérielles actuelles
on aurait des machines beaucoup plus réactives.
Il est, par exemple, absolument scandaleux que sur une machine à 3 GHz
on puisse voir un temps d'attente entre l'activation d'une application
et son affichage à l'écran. C'est une preuve soit de j'm'en foutisme,
soit de savoir "perdu"...

Wykaaa a écrit :

A l'époque on se souciait du "packaging" du système (j'ai travaillé sur
un OS et des compilateurs). On faisait attention de "rassembler" le code
étroitement dépendant dans le même segment de mémoire (on essayait de
minimiser les branchements inter segment (qui pouvaient être
catastrophiques pour la gestion de la mémoire virtuelle car on ne
parlait pas de RAM en Go !

Oui. Sous NeXTSTEP, la mémoire était gérée dans des zones. Ces zones
permettaient d'allouer de la mémoire contiguës en RAM pour accélérer le
travail de pagination (par opposition aux allocations mémoire
traditionnels où les espaces mémoires sont non prévisibles). Ces NXZone
étaient très utilisées. Maintenant les NSzone (d'OPENSTEP) sur Mac OS X
sont tombées dans l'oubli.

Aujourd'hui, je crois que tout le monde se fiche du packaging et de
l'optimisation du code compte tenu des capacités mémoire et des disques
ainsi que de la fréquence d'horloge). Je dis "je crois" car je suis
retraité :-)

Pour beaucoup de monde oui, c'est vrai. Mais il y a des exceptions. Par
exemple Google utilise des images qui contiennent tas de petites images
utilisées individuellement, comme dans
<http://www.google.fr/images/nav_logo7.png>. Ce genre d'astuce était
courant il y a 20 ans.

C'est évidemment une erreur car si on portait autant attention au
packaging qu'il y a 25 ans, avec les performances matérielles actuelles
on aurait des machines beaucoup plus réactives.

Beaucoup de programmeurs (Eh, les javanais, inutile de vous cacher!)
considère que si une application est lente, il suffit de changer de hard
ou d'attendre une nouvelle optimisation du compilateur. Et,
effectivement, souvent après quelques années, les anciens softs
deviennent utilisables sur les nouvelles machines...

Il est, par exemple, absolument scandaleux que sur une machine à 3 GHz
on puisse voir un temps d'attente entre l'activation d'une application
et son affichage à l'écran. C'est une preuve soit de j'm'en foutisme,
soit de savoir "perdu"...

10 seconde pour lancer un soft sur une machine à 3 GHz est en effet
inacceptable. Mais que faire d'autre que d'attendre ? Quand je vois que
FrameMaker se lance instantanément (j'ai rajouté en "Démo 8" sur mon
site cette vidéo pour le prouver) et que l'on ne peut pas lire le
panneau de lancement de l'application (sauf en faisant du pas à pas dans
la vidéo), il y a en effet de quoi s'interroger.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Éric Lévénez <usenet@levenez.com> wrote:

Quand je vois que le lancement de FrameMaker sous NeXTSTEP était très
rapide (instantané sur ma machine actuelle) alors que inDesign met près
de 10 secondes sur ma machine actuelle, on peut en effet se poser bien
des questions sur cette régression de l'informatique.

Je pense que beaucoup de programmes ne sont pas optimisés comme ils
l'étaient à l'époque dont on parle. On compte beaucoup maintenant sur la
"force brute" aka les GHz pour compenser.

De plus, les éditeurs, souvent en position de monopole, traînent à
réécrire des softs "monstrueux tels que Photoshop, si même jamais c'est
fait un jour.

SI l'on pouvait faire tourner un Word 5.1 ou un excel de la même époque,
sur nos machines actuelles, on risquerait d'être surpris. Pour être
honnête, malgré l'inflation de fonctionnalités apparues dans Excel
depuis cette époque, je l'utilise, pour mon cas personnel, quasiment de
la même manière qu'à l'époque. Un truc qui me fout dans une rage monstre
avec le dernier Excel, c'est qu'il lui faut entre 3 et 4 secondes pour
m'afficher le menu du tri des lignes à partir du moment ou je choisis
l'article de Menu. Et pourtant ma bécane n'est pas particulièrement
poussive.
--
PO.

Pour m'écrire : po_taubaty(arobas)yahoo(point)fr

Wykaaa <wykaaa@yahoo.fr> wrote:

Éric Lévénez a écrit :

> Quand je vois que le lancement de FrameMaker sous NeXTSTEP était très
> rapide (instantané sur ma machine actuelle) alors que inDesign met près
> de 10 secondes sur ma machine actuelle, on peut en effet se poser bien
> des questions sur cette régression de l'informatique.
>

A l'époque on se souciait du "packaging" du système (j'ai travaillé sur
un OS et des compilateurs). On faisait attention de "rassembler" le code
étroitement dépendant dans le même segment de mémoire (on essayait de
minimiser les branchements inter segment (qui pouvaient être
catastrophiques pour la gestion de la mémoire virtuelle car on ne
parlait pas de RAM en Go !
Si la machine n'était pas à segment mémoire, on prenait garde aux
algorithmes de pagination (j'ai connu une machine dans laquelle les
segments mémoire étaient eux-mêmes paginés)
Aujourd'hui, je crois que tout le monde se fiche du packaging et de
l'optimisation du code compte tenu des capacités mémoire et des disques
ainsi que de la fréquence d'horloge). Je dis "je crois" car je suis
retraité :-)
C'est évidemment une erreur car si on portait autant attention au
packaging qu'il y a 25 ans, avec les performances matérielles actuelles
on aurait des machines beaucoup plus réactives.
Il est, par exemple, absolument scandaleux que sur une machine à 3 GHz
on puisse voir un temps d'attente entre l'activation d'une application
et son affichage à l'écran. C'est une preuve soit de j'm'en foutisme,
soit de savoir "perdu"...

ah, ben j'avais fait ma réponse à Éric avant de lire la tienne. Je vois
que l'on a les mêmes points de vue ...

à se demander si maintenant on serait capable d'envoyer des gus sur la
Lune avec le même matos qu'à l'époque ... ça craint.
--
PO.

Pour m'écrire : po_taubaty(arobas)yahoo(point)fr

Éric Lévénez <usenet@levenez.com> wrote:

> C'est évidemment une erreur car si on portait autant attention au
> packaging qu'il y a 25 ans, avec les performances matérielles actuelles
> on aurait des machines beaucoup plus réactives.

Beaucoup de programmeurs (Eh, les javanais, inutile de vous cacher!)
considère que si une application est lente, il suffit de changer de hard
ou d'attendre une nouvelle optimisation du compilateur. Et,
effectivement, souvent après quelques années, les anciens softs
deviennent utilisables sur les nouvelles machines...

ah, ben c'est con, j'aurais du garder l'Encyclopédie Hachette Multimedia
2000. Elle était tellement lente sur mon G3/266 que j'ai filé le CD à un
copain PC iste (CD mixte). J'ai tellement ragé que j'avais téléphoné
chez Hachette, et on m'avait expliqué à l'époque qu'elle était
programmée en java. D'où, depuis une haine viscérale de ma part pour
tout ce qui concerne les javaniaiseries.
--
PO.

Pour m'écrire : po_taubaty(arobas)yahoo(point)fr

Pierre-Olivier TAUBATY a écrit :

Éric Lévénez <usenet@levenez.com> wrote:

C'est évidemment une erreur car si on portait autant attention au
packaging qu'il y a 25 ans, avec les performances matérielles actuelles
on aurait des machines beaucoup plus réactives.

Beaucoup de programmeurs (Eh, les javanais, inutile de vous cacher!)
considère que si une application est lente, il suffit de changer de hard
ou d'attendre une nouvelle optimisation du compilateur. Et,
effectivement, souvent après quelques années, les anciens softs
deviennent utilisables sur les nouvelles machines...

ah, ben c'est con, j'aurais du garder l'Encyclopédie Hachette Multimedia
2000. Elle était tellement lente sur mon G3/266 que j'ai filé le CD à un
copain PC iste (CD mixte). J'ai tellement ragé que j'avais téléphoné
chez Hachette, et on m'avait expliqué à l'époque qu'elle était
programmée en java. D'où, depuis une haine viscérale de ma part pour
tout ce qui concerne les javaniaiseries.

Il faut toujours se rappeler des proverbes suivants en informatique :

- Tout vient à point à qui sait attendre

- Patience et longueur de temps font plus que force ni que rage

Ceci dit, je ne suis pas certain que, si on programme correctement, Java
soit particulièrement lent. J'ai vu des programmes de calcul intensif
(simulation en mécanique des fluides) en Java qui vont presque aussi
vite que les mêmes en C++ compilé.

Pierre-Olivier TAUBATY a écrit :

Wykaaa <wykaaa@yahoo.fr> wrote:

Éric Lévénez a écrit :

Quand je vois que le lancement de FrameMaker sous NeXTSTEP était très
rapide (instantané sur ma machine actuelle) alors que inDesign met près
de 10 secondes sur ma machine actuelle, on peut en effet se poser bien
des questions sur cette régression de l'informatique.

A l'époque on se souciait du "packaging" du système (j'ai travaillé sur
un OS et des compilateurs). On faisait attention de "rassembler" le code
étroitement dépendant dans le même segment de mémoire (on essayait de
minimiser les branchements inter segment (qui pouvaient être
catastrophiques pour la gestion de la mémoire virtuelle car on ne
parlait pas de RAM en Go !
Si la machine n'était pas à segment mémoire, on prenait garde aux
algorithmes de pagination (j'ai connu une machine dans laquelle les
segments mémoire étaient eux-mêmes paginés)
Aujourd'hui, je crois que tout le monde se fiche du packaging et de
l'optimisation du code compte tenu des capacités mémoire et des disques
ainsi que de la fréquence d'horloge). Je dis "je crois" car je suis
retraité :-)
C'est évidemment une erreur car si on portait autant attention au
packaging qu'il y a 25 ans, avec les performances matérielles actuelles
on aurait des machines beaucoup plus réactives.
Il est, par exemple, absolument scandaleux que sur une machine à 3 GHz
on puisse voir un temps d'attente entre l'activation d'une application
et son affichage à l'écran. C'est une preuve soit de j'm'en foutisme,
soit de savoir "perdu"...

ah, ben j'avais fait ma réponse à Éric avant de lire la tienne. Je vois
que l'on a les mêmes points de vue ...

Les grands esprits se rencontrent :-)

à se demander si maintenant on serait capable d'envoyer des gus sur la
Lune avec le même matos qu'à l'époque ... ça craint.

C'est une vraie question et je crains que la réponse soit négative...

> à se demander si maintenant on serait capable d'envoyer des gus sur la
Lune avec le même matos qu'à l'époque ... ça craint.

Un peu de lecture :

<http://en.wikipedia.org/wiki/Apollo_Guidance_Computer>

et si tu veux t'amuser :

<http://www.ibiblio.org/apollo/>