Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

NeXTSTEP sur VMware

39 réponses
Avatar
Eric Levenez
Pour info, NeXTSTEP marche bien sur VMware Fusion tournant sur Mac OS X sur
un Macintosh Intel. Et je dois dire qu'il marche nettement mieux que sur feu
VirtualPC sur Macintosh PPC : sans parler de la vitesse ou des drivers
VMware adaptés à NeXTSTEP, il s'agit surtout du bug sur le coprocesseur
mathématique des PPC mal émulé par Virtual PC qui perturbait Display
PostScript, fortement optimisé pour les processeurs Intel.

Ma nouvelle page sur VMware :

<http://www.levenez.com/NeXTSTEP/VMware.html>

Pour info mon ancienne page sur VirtualPC :

<http://www.levenez.com/NeXTSTEP/VirtualPC.html>

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

10 réponses

1 2 3 4
Avatar
Eric Levenez
Le 23/02/08 10:36, dans
,
« OdarR » a écrit :

On 22 fév, 21:03, Eric Levenez wrote:
Ma nouvelle page sur VMware :

<http://www.levenez.com/NeXTSTEP/VMware.html>


C'est beau, et est empreint d'un peu de nostalgie...

Limite en RAM, taille de partition, floppy...


Oui, mais je suis toujours stupéfait de ce que NeXT a réussi à faire avec un
CPU à 25 MHz et 8 Mo de Ram il y a 20 ans. Aujourd'hui avec une machine 1000
fois plus puissante (en CPU, RAM, disque...) je ne fais guère plus qu'à
l'époque. Mais je dois dire que c'est mieux maintenant, quand même :-)

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


Avatar
pas.de.spam
Eric Levenez wrote:

Le 23/02/08 10:36, dans
,

On 22 fév, 21:03, Eric Levenez wrote:
Ma nouvelle page sur VMware :

<http://www.levenez.com/NeXTSTEP/VMware.html>


C'est beau, et est empreint d'un peu de nostalgie...

Limite en RAM, taille de partition, floppy...


Oui, mais je suis toujours stupéfait de ce que NeXT a réussi à faire avec un
CPU à 25 MHz et 8 Mo de Ram il y a 20 ans. Aujourd'hui avec une machine 1000
fois plus puissante (en CPU, RAM, disque...) je ne fais guère plus qu'à
l'époque. Mais je dois dire que c'est mieux maintenant, quand même :-)


Je pense qu'en fait il faut distinguer les applications de l'époque et
les applications d'aujourd'hui.

C'est sûr que pour un tableur, un traitement de texte, un navigateur
internet (en mettant à part toutes les javaniaiseries et autres
flashouillages), enfin bref tout ce qui se faisait à l'époque, on n'a
pas vraiment changé grand chose. D'autant que le Display Postscript des
NeXT était une véritable "tuerie" à l'époque. C'est là que j'ai
découvert que le "Live Scroll" existait : c'est à dire le texte qui
défile à l'écran lorsque l'on bouge un ascenseur. C'est maintenant chose
courante, mais à l'époque, ce n'était pas le cas, et c'est resté ainsi
pendant très longtemps chez Apple.

Après, il y a toutes les autres applications et utilisations que l'on
fait maintenant d'un ordi, l'encodage MP3, L'encodage vidéo, le
traitement des images avec Photoshop, la 3D, autant d'applications qui
n'étaient même pas imaginables à l'époque.

Les stations et Cube NeXT de l'époque étient des monstres de puissances.
De plus, l'optimisation n'était pas un vain mot : aujourd'hui, on se
repose sur la puissance de la machine pour éviter une optimisation qui
d'après certains développeurs (sujet développé ici plusieurs fois)
coûterait trop cher par rapport à ce qu'elle rapporterait.

J'ai lu ici ou là que la nouvelle mouture de la Suite Office 2008 pour
Mac était au moins aussi lente, si ce n'est plus lente en natif sur les
nouvelles Machines , que la précédente version qui passait par Rosetta.

J'ai pu tester hier sur un Mac PRo gonflé à 6 Go de RAM, que déjà rien
que j'ouverture était vraiment plus lente que sur ma machine (on compare
donc du natif PPC chez moi, versus du natif Intel sur le Mac Pro).
N'ayant pas de gros fichiers, je n'ai pas vraiment pu faire de tests,
mais l'impression que ça m'a laissé était un brin amère.
--
PO.

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



Avatar
Eric Levenez
Le 23/02/08 13:04, dans <1icrtdg.sroi5f1xpsbd5N%,
« Pierre-Olivier TAUBATY » a écrit :

Eric Levenez wrote:

Le 23/02/08 10:36, dans
,

On 22 fév, 21:03, Eric Levenez wrote:
Ma nouvelle page sur VMware :

<http://www.levenez.com/NeXTSTEP/VMware.html>


C'est beau, et est empreint d'un peu de nostalgie...

Limite en RAM, taille de partition, floppy...


Oui, mais je suis toujours stupéfait de ce que NeXT a réussi à faire avec un
CPU à 25 MHz et 8 Mo de Ram il y a 20 ans. Aujourd'hui avec une machine 1000
fois plus puissante (en CPU, RAM, disque...) je ne fais guère plus qu'à
l'époque. Mais je dois dire que c'est mieux maintenant, quand même :-)


Je pense qu'en fait il faut distinguer les applications de l'époque et
les applications d'aujourd'hui.


Oui, bien sûr.

C'est sûr que pour un tableur, un traitement de texte, un navigateur
internet (en mettant à part toutes les javaniaiseries et autres
flashouillages), enfin bref tout ce qui se faisait à l'époque, on n'a
pas vraiment changé grand chose. D'autant que le Display Postscript des
NeXT était une véritable "tuerie" à l'époque. C'est là que j'ai
découvert que le "Live Scroll" existait : c'est à dire le texte qui
défile à l'écran lorsque l'on bouge un ascenseur. C'est maintenant chose
courante, mais à l'époque, ce n'était pas le cas, et c'est resté ainsi
pendant très longtemps chez Apple.


Oui, Display Postscript était très rapide. En plus du "Live Scroll" il y
avait aussi la gestion des déplacements des fenêtres. À l'époque quand on
déplaçait une fenêtre sur un autre système, il y avait toujours des zones
blanches et un attente avant que le blanc soit redessiné. Rien de tel sur
NeXTSTEP. L'effet "gomme" des fenêtres non plus.

Après, il y a toutes les autres applications et utilisations que l'on
fait maintenant d'un ordi, l'encodage MP3, L'encodage vidéo, le
traitement des images avec Photoshop, la 3D, autant d'applications qui
n'étaient même pas imaginables à l'époque.


Photoshop je ne pense pas, mais Adobe Illustrator était dispo sur NeXTSTEP
et permettait la modification directe qui n'existait pas sur Mac grâce à
Display PostScript. Il y avait aussi des softs comme Mathematica...

Pour le MP3, je crois que les NeXTstations n'étaient pas assez rapides, même
avec le DSP de traitement du son qu'elles embarquaient.

Mais pour la vidéo et le son il y avaient des cartes matériels pour
augmenter la puissance de la machine comme la NeXTdimension.

Les stations et Cube NeXT de l'époque étient des monstres de puissances.
De plus, l'optimisation n'était pas un vain mot : aujourd'hui, on se
repose sur la puissance de la machine pour éviter une optimisation qui
d'après certains développeurs (sujet développé ici plusieurs fois)
coûterait trop cher par rapport à ce qu'elle rapporterait.


C'est sûr qu'aujourd'hui les programmeurs qui commencent par Java sont
pourris et ne connaissent pas ce mot "optimisation". Quand on parlait de
kilo, ils parlent de mégas ou même gigas.

J'ai lu ici ou là que la nouvelle mouture de la Suite Office 2008 pour
Mac était au moins aussi lente, si ce n'est plus lente en natif sur les
nouvelles Machines , que la précédente version qui passait par Rosetta.


Je confirme. Le lancement des applications Office est horriblement long :
entre 4 et 6 secondes pour afficher une page vierge. FrameMaker sur NeXTSTEP
se lance de façon instantané (pas mesurable).

J'ai pu tester hier sur un Mac PRo gonflé à 6 Go de RAM, que déjà rien
que j'ouverture était vraiment plus lente que sur ma machine (on compare
donc du natif PPC chez moi, versus du natif Intel sur le Mac Pro).
N'ayant pas de gros fichiers, je n'ai pas vraiment pu faire de tests,
mais l'impression que ça m'a laissé était un brin amère.


Oui, les softs Microsoft ou Adobe ont toujours de gros problèmes de
lancement.

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




Avatar
filh
Eric Levenez wrote:


Les stations et Cube NeXT de l'époque étient des monstres de puissances.
De plus, l'optimisation n'était pas un vain mot : aujourd'hui, on se
repose sur la puissance de la machine pour éviter une optimisation qui
d'après certains développeurs (sujet développé ici plusieurs fois)
coûterait trop cher par rapport à ce qu'elle rapporterait.


C'est sûr qu'aujourd'hui les programmeurs qui commencent par Java sont
pourris et ne connaissent pas ce mot "optimisation". Quand on parlait de
kilo, ils parlent de mégas ou même gigas.



Well... on peut aussi considérer que des optimisations qui reposent sur
des hacks immondes non portables...

Le temps des géniaux programmeurs qui faisaient du code, certe rapide
mais non gérable est - heureusement - passé :)

FiLH

--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org


Avatar
sebastienmarty
FiLH wrote:

Eric Levenez wrote:


Les stations et Cube NeXT de l'époque étient des monstres de puissances.
De plus, l'optimisation n'était pas un vain mot : aujourd'hui, on se
repose sur la puissance de la machine pour éviter une optimisation qui
d'après certains développeurs (sujet développé ici plusieurs fois)
coûterait trop cher par rapport à ce qu'elle rapporterait.


C'est sûr qu'aujourd'hui les programmeurs qui commencent par Java sont
pourris et ne connaissent pas ce mot "optimisation". Quand on parlait de
kilo, ils parlent de mégas ou même gigas.



Well... on peut aussi considérer que des optimisations qui reposent sur
des hacks immondes non portables...

Le temps des géniaux programmeurs qui faisaient du code, certe rapide
mais non gérable est - heureusement - passé :)


Il y aurait sans doute un juste milieu à trouver... Mais encore
faudrait-il s'en donner la peine.

--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)



Avatar
Eric Levenez
Le 23/02/08 14:37, dans <1icrpxc.10r65zn198xvwaN%,
« SbM » a écrit :

FiLH wrote:

Eric Levenez wrote:

C'est sûr qu'aujourd'hui les programmeurs qui commencent par Java sont
pourris et ne connaissent pas ce mot "optimisation". Quand on parlait de
kilo, ils parlent de mégas ou même gigas.


Well... on peut aussi considérer que des optimisations qui reposent sur
des hacks immondes non portables...

Le temps des géniaux programmeurs qui faisaient du code, certe rapide
mais non gérable est - heureusement - passé :)


Il y aurait sans doute un juste milieu à trouver... Mais encore
faudrait-il s'en donner la peine.


Oui, l'optimisation n'est pas trouver des "hacks immondes" ou écrire en
assembleur, c'est d'abord et principalement réfléchir. Ensuite cela consiste
à trouver la bonne architecture logicielle et trouver les bons algorithmes.
Et là ces nouveaux programmeurs ne savent que faire du couper/coller de
codes écrits par d'autres du même niveau...

Enfin bon on s'éloigne du sujet :-)

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



Avatar
filh
Eric Levenez wrote:

Le 23/02/08 14:37, dans <1icrpxc.10r65zn198xvwaN%,

FiLH wrote:

Eric Levenez wrote:

C'est sûr qu'aujourd'hui les programmeurs qui commencent par Java sont
pourris et ne connaissent pas ce mot "optimisation". Quand on parlait de
kilo, ils parlent de mégas ou même gigas.


Well... on peut aussi considérer que des optimisations qui reposent sur
des hacks immondes non portables...

Le temps des géniaux programmeurs qui faisaient du code, certe rapide
mais non gérable est - heureusement - passé :)


Il y aurait sans doute un juste milieu à trouver... Mais encore
faudrait-il s'en donner la peine.


Oui, l'optimisation n'est pas trouver des "hacks immondes" ou écrire en
assembleur, c'est d'abord et principalement réfléchir. Ensuite cela consiste
à trouver la bonne architecture logicielle et trouver les bons algorithmes.


Là c'est pas de l'optimisation hein... :) Toi qui aime jouer sur les
mots exacts.

Et là ces nouveaux programmeurs ne savent que faire du couper/coller de
codes écrits par d'autres du même niveau...


T'as raison « c'était mieux avant » (c) (tm) (r)..

FiLH

--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org




Avatar
Nina Popravka
On Sat, 23 Feb 2008 15:58:24 +0100, (FiLH) wrote:

T'as raison « c'était mieux avant » (c) (tm) (r)..


Non, "c'était mieux aaaaaaaaaaaaaaaavant" (c) (tm) (r)
--
Nina

Avatar
filh
Erwan David wrote:

(FiLH) écrivait :


Well... on peut aussi considérer que des optimisations qui reposent sur
des hacks immondes non portables...


On peut optiliser ET être portable. Je programme de l'embarqué, là on
est bien obligé


Well portable dans l'embarqué ? (1)
Optimisé en place oui là je veux bien.



Le temps des géniaux programmeurs qui faisaient du code, certe rapide
mais non gérable est - heureusement - passé :)


20 ms pour faire les 6 échanges nécessaires à l'ouverture d'un portillon
du métro par une carte Navigo? Il ne s'agit pas de trainer, ni d'un côté
ni de l'autre.


Oui, mais c'est pas prévu pour pouvoir embarquer un plugin video...un
jour :)

FiLH

1 : la portabilité c'est... ARM ou ARM non ?


--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org


Avatar
pas.de.spam
FiLH wrote:

Eric Levenez wrote:

Le 23/02/08 14:37, dans <1icrpxc.10r65zn198xvwaN%,

FiLH wrote:

Eric Levenez wrote:

C'est sûr qu'aujourd'hui les programmeurs qui commencent par Java sont
pourris et ne connaissent pas ce mot "optimisation". Quand on parlait de
kilo, ils parlent de mégas ou même gigas.


Well... on peut aussi considérer que des optimisations qui reposent sur
des hacks immondes non portables...

Le temps des géniaux programmeurs qui faisaient du code, certe rapide
mais non gérable est - heureusement - passé :)


Il y aurait sans doute un juste milieu à trouver... Mais encore
faudrait-il s'en donner la peine.


Oui, l'optimisation n'est pas trouver des "hacks immondes" ou écrire en
assembleur, c'est d'abord et principalement réfléchir. Ensuite cela consiste
à trouver la bonne architecture logicielle et trouver les bons algorithmes.


Là c'est pas de l'optimisation hein... :) Toi qui aime jouer sur les
mots exacts.


bien sûr que si ! Il y a toujours plusieurs manières d'obtenir la même
chose, et une bonne réflexion à la base est déjà de l'optimisation.
L'optimisation n'est pas à posteriori, mais déjà en amont du codage, et
pendant le codage lui-même. Il n'y a quà voir tous les programmes qui ne
tirent pas partie de l'architecture multi processeurs, notamment une
bonne partie des jeux. Sans aller plus loin que chez Apple, j'ai vu
tourner hier un Mac Pro avec Compressor, et bien il n'utilisait que 2
coeurs sur 8, et encore pas toujours les 2 en même temps. Et cela même
alors qu'il avait une suite de fichiers à compresser. Je n'ai pas
compris pourquoi.



Et là ces nouveaux programmeurs ne savent que faire du couper/coller de
codes écrits par d'autres du même niveau...


T'as raison « c'était mieux avant » (c) (tm) (r)..


Tout n'était pas mieux avant, mais certaines choses si !ou du moins
certaines façons de faire.

--
PO.

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





1 2 3 4