Autor: Tomasz Kloczko (kloczek_at_rudy.mif.pg.gda.pl)
Data: Wed 26 Jun 1996 - 13:23:46 MET DST
Czescz!
Bedzie troche dlugo.
Gregorio Kus (Grego_at_RMnet.IT) wrote:
[..]
: >Np. jezeli ktos uzywa win, zeby odpalic program terminalowy to punkty 1-3
: >mozna od razu pominac, a przeciez to tez jest "typowe zastosowanie".
: a g... prawda
: jesli bowiem odpalam program terminalowy, to odpale sobie rownoczesnie
: jakis edytor, do ktorego jestem przyzwyczajony, zeby w nim pisac i przerzucac
: tekst przez clipboard, moge odpalic tez jakis Off-line reader, nie widze tez
: dlaczego musialbym zamykac to nad czym do tej pory pracowalem, aby tylko
: sprawdzic czy przyszedl mail na ktory czekam, itd itp etc.
Szczeze mowiac nie wiem przeciw czemu protestujesz. Czy chodzi Ci o to ze
odpalanie programu terminalowego nie jest typowym zastosowaniem (jednym z
wielu mozliwych) czy tez o cos innego.
Moze chciale powiedziec, ze polaczenie terminalowe moze sluzyc w zasadzie
tylko do cztania poczty?
Troche zapewne prowokujace pytanie, ale wybacz nie wiem co chciales
powiedziec.
: Po prostu - jak sie juz ma ten multitasking
: (nawet taki twutwu-win-tasking)
: to sie go zaczyna predzej czy pozniej wykorzystywac
: i wtedy wlasnie okazuje sie ze 386dx/40Mhz+32MB RAM, jest maszyna o wiele
: szybsza (nie obliczeniowo, bo to dla niewielu ma znaczenie, lecz w tym
: co istotne - w czasie reakcji na polecenia uzytkownika)
: niz pentium 160MHz + 8MB RAM.
: I tym bardziej dotyczy to prawdziwego multitaskingu, zwlaszcza gdy sie
: korzysta z internetu (nie z emailu przez jakas bramke BBSowa, tylko przez
: slip czy ppp) bo sama obsluga tcp/ip dociaza system niezle. W typowych
: zastosowaniach (z uporem powtarzam to sformuowanie w/g Ciebie bezsensowne)
: doinstalowanie tcp/ip obciaza maszynke z 8MB RAM na tyle, ze nie jest tego
: w stanie wynagrodzic dodatkowy simm z 4MB, trzeba przeskoczyc na 16 zeby
: odzyskac poprzedni komfort pracy. (sprawdzone doswiadczalnie, niejednokrotnie,
: zarowno pod WARPem jak i pod w95, jedyny wyjatek to Linux
: ale i to pod warunkiem ze sie nie uzywa Xow)
Jak sie ma 386/40 z 8MB RAM to mozna na tym zrobic poprostu o wiele wiecej
niz pod win-swinstwem i nawet pod Warp-em (ktorego przynajmniej toleruje).
Siedze przed SGI Indy, ale polaczenie terminalowe mam otwaryte na maszynke,
ktorej parametry przytocze: 386DX/40Mhz 8MB RAM, 160MB HD. Przez dlugi czas
ta maszynka miala wylacznie 4MB, potem 5MB. Przez caly czas obsluguje (robi
to z powodzeniem juz od ponad dwoch lat) prawie cala poczte studencka na naszym
wydziale (>=95% ruchu na naszym wydziale jaki wnosza studenci z tytulu
poczty). I to wszystko chodzi na tym jedynym wyjatku - Linux-ie. Przy 8MB w
porywach jest ten komputerek w stanie obsluzyc do 4-5 osob jednoczesnie
(jesli chodzi o czytanie poczty, news-ow).
Co do multitaskingu lub lub uzywajac polskiego slowa - wielozadaniowosci, to
mam dosc radykalne poglady i twierdze, ze jest lub go nie ma. W przypadku
win* (3.*, 95, NT) twierdze, ze go poprostu nie ma. Przykladow sytuacji,
ktorych osoba pracujaca pod NT nie zaobserwoje nigdy pod Linux-em moznaby
mnozyc bez liku. Od braku pelnej separacji zasobow poprzez ochrone tychze, a
takze na utrzymaniu ich integralnosci konczac. Wszystkie te wlasnosci
charakteryzuja posrednio system wielozadaniowy, bo inaczej to praca z
czym takim "wielozadaniowym" traci masochizmem.
Zeby nie bylo nie domowien. Brak poprawnie dzialajacej separacji zasobow
itd. pod NT z moich obserwacji nie wynika z bledow (bugs) w systemie tylko z
ogona jaki sie ciagnie od poczatku historii z dos-em. W zwiazku z tymze
ogonem twierdze, ze przysle zmiany w win* bede polegac nadal na zmianach na
poziomie miedzymordzia graficznego (vide NT 4.0) bac innych nie wnikajacych
gleboko w sama architekture systemu. Zmiany na poziomie samej architektury
bylyby konieczne jezeli Win* mialoby byc przynajmniej tak dobre w
podstawowych funkcjach systemowych takich jak ochrona, separacja i
utrzymanie integralnosci zasobow udostepnianych przez system.
Wszystkim chcacym zobaczyc na czym polega roznica miedzy win*, a jakim
kolwiek U*nix-em polecam lektore artykulu w ostatniego Net Word. Chodzi mi o
artykol opisujacy kolejnego potwora rodem z M$ - Exchange server.
Ta kobyla byla testowana na win NT 3.51 srv, pentek 100Mhz, 48MB RAM, 4GB HD
na scsi. Instalowalo sie to ok. 15 min z CD z czego wnosze ze na dysku
powinno to zajac do 300MB (jest to gorna granica i rzeczywisty rozmiar
moze byc nawet o rzad mniejszy). Autor artykolu nie podal ile to
zajmuje.
Szacunkowe 300MB wynika z: 15min=900s -> 900s x 600kb (zalozylem ze jest to
CDx4)=540MB, i zakladam ze transmisja z dysku trwala ok polowe czasu, co w
przyblizeniu daje gorna granice 300MB.
A co to robi? W skrocie jest to odpowiednik sendmail-a + majordomo + kilka
skryptow, ktore czasem administratorzy U* uzywaja do analizy logow +
niektore aspekty isnienia quota filesystems.
Nawet jezeli Ex Srv ma tylko 30 MB (a ma napewno wiecej) to i tak bedzie to
o okolo 5-7 razy wiecej w stosunku do tego co zajmuja narzedzia U*, nie
mowiac juz o tym ze zestaw U* ma szersze niz opisywane w tym artykule
zastosowania. Nie mowiac juz o tym, ze jek juz wyzej opisalem to samo moze
robic 386DX/40Mhz z 8MB ram i pracujacym Linux-em, a na potrzeby malej
firemki majacej wyjscie na swiat mozna jeszcze z tego zrobic router.
Juz z samego faktu, ze jest to nowosc i nie ma porownania co do stopnia
wytestowania Ex Srv w stosunku do narzedzi U*. Nigdy nikomu nie polecilbym
stosowania tego do obslugi poczty GDZIEKOLWIEK.
Podstawowa wada tej kobyly moim zdaniem jest to, ze w celu osiagniecia
odpowiedniej efektywnosci w wypelnianiu funkcji musi toto miec w sobie
zaszyte pewne funkcje, ktore normalnie zapewnia OS, a ktorych w
win NT zapewne nie ma.
Jezeli M$ bedzie dalej robil narzedzia, ktore beda mialy tak
wybojale wymagania przy tak malym zestawie funkcji, to sam sobie bedzie
za kazdym razem wbijal gwozdz do trumny. Czego M$ szczeze zycze.
Pozdrawiam
kloczek
-----------------------------------------------------------
"Ludzie nie maja problemow, tylko sobie sami je stwarzaja"
-----------------------------------------------------------
Tomasz K/loczko, student, PG FTiMS | e-mail : kloczek_at_rudy.mif.pg.gda.pl
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:46:25 MET DST