On 2015-09-12 21:02, AK wrote:
> No nie znalem.
> RAM byl z gumy (os go wirtualizowal)

RAM nie był z gumy. Wirtualna przestrzeń adresowa byla z gumy. Wrzucana
na nie-gumowy bęben. Zonk.

> 1. Jaki znow beben ? :)

Taka szybka pamięc masowa. Jeden kiedyś ogladałem w jakims muzeum.
Niektore rozwiązania miały ciekawe cechy, implementowano na nich prawie
całe procesory (minuteman).

> 2. Owszem, wydajnosc "siadala", ale program dalej dzialal, a nie
> "zamazywal stosem sie/dane" czy inne rzeczy znane z C/C++/PC-ta :)

Nic takiego nie zachodzi na PC podczas normalnej pracy. Każdy procesor
może przekręcić przestrzeń adresową i zamazać dane, ale to jest cecha
systemów ze stałym rozmiarem adresu. Trudno tu się doszukować wielkich
problemów. A i tak jeśli coś się takiego stanie to uszkodzi proces a nie
system. W teorii, ale bardzo czesto praktyce. No chyba że tym "systemem"
jest MSDOS.

>> Naprawde nie widzisz problemu że twoje dane lądują na urzadzeniu które
>> jest setki razy wolniejsze bo się nie mieści w ram?
> To byla sprawa systemu , co nie znaczy ze nie bylo tego swiadomosci
> i nie projektowalo sie tak aby jak najmnej trafialy, a niektore
> algorytmy byly
> az do tego stworzone (np. taki simplex z generacja kolum przy np. metodach
> rozkroju, czy metody podzialu i ograniczen, itp itd), aby trafialy
> "madrze".

Czyli hacking. Musiałeś mieć "specjalnie" zmodyfikowany algorytm z
powodu ograniczeń sprzetowych, z wiedza o sprzecie. Hacking.

>> PS. Każdy duzy współczesny OS potrafi to samo, czyli dac pełna
>> przestrzeń adresową dla procesu magicznie swapując ją w tle. Gdzie tu
>> jakaś zaleta mainframe?
> 1. wirtualizacja calych systemow operacyjncych (np VM na IMB360/370)
> OK. Nareszcie sa VMWare i VirtualBox, ale troche to twralo :)

Nie trwalo. Nikomu nie było potrzebne na biurku. PC jest przeznaczony na
biurka do oglądania facebooka.

> 2. hibernate/restore dowolnego joba/zadania/programu.
> Tego nie masz na PC nawet dzis.
> (mowie tylko o maiframes starych - wspolczesnych nie znam)

Mam. Na Linuxie jest kilka projektów potrafiących:
a) zrobić save-restore procesu
b) przemigrować proces na inna maszynę

Tylko że nie znam sensownego zastosowania poza oblczeniami na klastrach
bo to jest ogólnie problem kłopotliwy z definicji bez wzgledu na
implementację.

> 3. fault tolerant

Problem w tym że mało to kogo już obchodzi. Infrastruktura google
pracuje na chińskim złomie i maitenance polega na wyrzucaniu na smietnik
kolejnych maszyn. Natomiast jesli jedna maszyna wymaga wysokiej
niezawodności to bardzo możliwe że coś jest popsute w projekcie.

>> Obecnie niczym. Procesy na x86 w win i lin są separowane w sposób
>> doskonały.
> "Teraz" "obecnie", "od pieciu lat". Zgadza sie, ale Odra to miala w latach
> siedemdziesiatych i miala od poczatku (tak jak zaprojektowano).

A PC nie zaprojektowano. Albo inaczej: zaprojektowano go używając tych
samych technik co ZX-Spectrum. Chcesz postawić teze: Odra była lepiej
zaprojektowana niż PC. Zgoda. Z kim się kłucisz?

Amiga (razem z Sinclair QL) miala w 1985 preemptive multitasking jako
pierwszy komputer domowy. Czy to oznacza że powinna być traktowana na
równi z Odra jako innowacyjna? Nikt o niej juz nie pamięta.

> Troche szacunku do tamtej mysli informatycznej.

Mam do niej ogromny szacunek.

> PC-ty dorobily sie tego po wielu latach (ok 15stu od zaistnienia), a
> wczesniej
> "krolowal" slawetny tryb "real mode" i klopoty z A20 (enhanced, extended
> memory,high memory i rozne inne prowizorki + slawetne modele pamieci
> procesora x86).

O którym to A20 już wspomnialem. Nie uwazam PC za dobre komputery.
Dziadostwo zawsze wygrywa.