Autor: Arkadiusz Podgorski (wodzu_at_softomat.com.pl)
Data: Wed 14 Oct 1998 - 15:52:18 MET DST
Adam Płaszczyca <_555_at_irc.pl> wrote:
: Polecam patent z MAC-a. Tam komp nie odda dyskietki. Stacja jest
: lockowana tak samo jak może byc programowo zalockowany CD-ROM.
: Co więcej, naciśnięcie przycisku Eject powoduje tylko informację dla
: systemu, ze ktoś chce wyjąć dyskietkę. Wtedy jakiś demon mógłby wymieść
: cache'a na dyskietkę odmontować ją, odlockowac stację i wyrzucić nośnik.
: Ale cóż - PC powstał wtdy, kiedy nikomu się nie śniło o unixie na nim
to jeszcze lepiej jest rozwiazane w sunach - tam nie ma przycisku wysuwania
dyskietki. zeby ja wyjac, trzeba zrobic to programowo. :) wtedy nie ma
problemu z syncem nosnika.
:> praktycznie nie wychodzi z cache'a - dlatego wykonuja sie blyskawicznie.
:> tak, jakby byly to polecenia powloki.
: Tak samo jak w OS/2.. CMD zna podstawy, reszta jest zewnętrzna. Ls i
: inne też ;)
tak, ale chodzilo o to, czy warto robic programiki realizujace tylko sekwencje
operacji podstawowych... :))
:> dopuszczalnych ustawien karty dokonuje sie po uruchomieniu systemu - nie ma
:> koniecznosci zadnych restartow. i mozna to zrobic zdalnie.
: wyświetlania. Kłopot w tym, że sam WPS siedzi o wiele mocniej w systemie
: niż X-server w unixie.
no i o to wlasnie sie rozbil problem :) ze engine graficzny jest fragmentem
systemu, a nie jego klientem, jak x-windows. chociaz dzieki temu jest np.
szybszy, czego trudno nie zauwazyc.
:> ciebie uslugi sa realizowane przez programy (demony) pracujace (uruchamiane)
:> *po* inicjacji jadra - mozna zmieniac ich konfiguracje i restartowac je (nie
:> zawsze jest potrzebny restart demona - niektore obsluguja rozkazy odczytania
:> konfiguracji ponownie) dowolna ilosc razy.
: A myślisz, że w OS/2 ni? Tez jest odpowiednik kill -HUP, tyle, że nie
: jest jawnie w systemie dany userowi :-)
wlasnie - nie jest dany jawnie. a fajnie by bylo, gdyby byl. to sa takie niby
tylko drobiazgi, ale z nich sklada sie zycie.
:> kernel w linuksie obsluguje _sprzet_, a nie uslugi. rekompilacja jest
:> potrzebna, jezeli cos zmieniasz w bebechach. i to tez nie zawsze - z reguly
:> wystarczy zaladowac wlasciwy modul i po sprawie. uslugi swiadczone sa przez
:> programy, ktore czescia systemu jako takiego nie sa. bardziej sa po prostu
:> czescia dystrybucji. kazdy z nich jest dla systemu zwyklym programem. a ze
:> swiadczy na rzecz innych programow jakies uslugi? jego problem :)
: Identycznie jest w OS/2. Restart jest zwykle wymuszany niepotrzebnie,
: poniewaz komuś nie chciało się wykonac dynamicznej wymiany zmiennych
: systemowych. Jest to dość skomplikowane zadanie, co wynika z innej
: konstrukcji systemu. OS/2 uruchamia proces nie przez shell. To shell
: każe systemowi odpalić proces i dlatego nie przejmuje on ustawień danej
: sesji (a raczej może nie przejąć). Ale dzięki temu po wykrzaczeniu się
: usługi nie ląduje się w shellu (co dość dobrze zabezpiecza przed
: hackerami).
no coz, na lenistwo programistow nie ma lekarstwa, niestety. znam to z
autopsji... :)
:> wlasnie to uwazam za _wielka_ zalete un*x-ow - dobrze zrealizowana
:> warstwowosc systemu. jest kernel, ktory za pomoca modulow sterownikow korzysta
:> ze sprzetu. programy maja dostep do wszystkiego za pomoca kernela, a uslugi
:> swiadcza zwykle programy. czegos takiego nie ma *wcale* w windows (tam zwyklym
:> programem mozesz grzebac po dysku - makabra) i nie do konca jest w os/2 (co ma
:> adres ip karty sieciowej do systemu?).
: Nic nie ma. To się w locie ifconfigiem zmienia.
: A że ludzie restartują system zamiast wklepać c:\mtpn\bin\setup.cmd
: czyli skrypt który robi ifconfigi i dodaje routing (tak, tak, route
: add....) to juz ich sprawa.
chyba zly przyklad wybralem. nie chcialo mi sie zastanawiac nad lepszym i teraz
mam ;)) sorry, ale ostatnio uzeralem sie z instalacja sterownikow do novella
w windzie - musialy chodzic na odi, bo inaczej klient progressa nie umial sie
podlaczyc do serwera. odi musialo byc dosowe, na vlm. co dwa klikniecia, to
restart - to dlatego pomyslalem o sprawach sieciowych. krew mnie zalewala :))
: OS/2 jest tak samo systemem wielowarstwowym jak Unix. Co więcej, do
: obsługi urządzeń I/O nie jest potrzebny kernel. Ba, nawet pierwszy ring
: też nie. Dopiero na drugim są DLL-e które komunikują się ze sprzętem.
: Jedynie niskopoziomowe sterowniki musza byc załadowane w czasie startu
: systemu. Restartty sa raczej efektem dopisania ścieżek dostępu i
: niechęcią do podmiany zmiennych systemowych.
z tym sie zgadzam - warstwowosc dostepu do sprzetu jest w os/2 bardzo dobrze
rozwiazana. ale, niestety, nie ma tej "dyscypliny" w pisaniu sterownikow, ktora
na programiscie wymusilaby pisanie ich tak, aby mozna je bylo restartowac bez
ruszania reszty systemu. a to konczy sie koniecznoscia restartu systemu. i co
po wspanialych mozliwosciach, jak z nich nie mozna skorzystac?
:> natomiast os/2 ma niezaprzeczalnie dwie wielkie zalety: ea (ale to, jak
:> wczesniej napisalem wymusiloby zmiane systemu plikow ext2 w linuxie) i wps -
:> najlepszy GUI, jaki widzialem.
: Ea wcale nie kłóci się z ext2!!! Sam miałem ext2 na OS/2 i jakoś ea się
: zapisywały :-)
ja _mam_ ext2 na os/2 - one sie zapisuja, zgoda. ale tak, jak na partycjach
fat. wystarczy uruchomic linuxa i mozna je popsuc. bo nie sa integralna
czescia *filesystemu*, tylko dodatkiem zapisywanym w pliku.
:> naprawde bylbym szczesliwy, gdyby kiedys te dwa systemy zostaly zintegrowane
:> w jeden - laczacy najlepsze cechy obu.
: Hm.. to wcale nie jest takie niemożliwe. Właściwie OS/2 mógłby być
: wieloużytkownikowy. Jedynie HPFS musiałby nieco więcej danych
: przechować.
hpfs ma jedna wade: za maly cache dysku. ograniczony od gory do 2mb. to
smiesznie malo dla wielouzytkownikowej maszyny. poza tym to ciagle przerzucanie
danych na dysku. nie badzmy ortodoksyjni, moze warto pomyslec o nowym
filesystemie?
:> ps. mysle, ze EOT.
: E, tam.. taka fajna dyskusja :-)))
no to co? *unix/2 project*? :))
-- # *sig. under construction* #%#--#####+####+#######x############++=## nie moge dojsc, jak oni uzywaja wielkich liter. moze maja inny typ klawiatury? #"####%%#####+##=###%### _wodzu_at_softomat.com.pl_ ##%####**###||######
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:18:33 MET DST