Kedves stpmod! (44,45)
Kár hogy kiragadtad a mondatot. Így más kontextusba kerülvén már értelmet nyer. Neked kéne az egész bekezdést egybe értelmezned.
Egyébként igen furán írsz. Nem bírom értelmezni írásodat. Kérlek minden mondatot írj le, ne csak minden 3-at! ..és szinonimákat is használhatnál köszi.
Kedves NevemTeve! (42)
Mit jelent az "objektumokat hivogatnék" kifejezés? Vezérlésátadást? Metódushívást? Felfogható ilyennek is. Pontosabban üzenetek küldésére kéne gondolni. Meg a helyzet kapcsán kialakuló szituációkra. Pld: megvárom az érkezését, párhuzamosan futok vele és később bevárom. Ez utóbbinál ugyebár új (feldolgozási) szál indítása történik, eddig nem megszokott módszer szerint. Egyébként ennek a boncolgatását későbbre halasztanám.
Kedves Szindbad76! (32)
Teljesen egyet értek veled. És a 33-ban is igazad van. Hogy kiegészítselek és Nadamhu (0)-ra is válaszoljak, ennek az az oka, hogy egységesen és mindent egyformán szeretnénk kezelni. Mondhatnám úgy, hogy a minden file szemlélet hátránya (talán). Tehát minden, ilyen szemléletbe nem illő alkatrész-t ilyenné próbálunk tenni. Ezt pedig legkönnyebben ASM-ben lehet elkövetni.
Az OO szemléletben minden alkatrész lehetne saját maga, nem kéne uniformisba, uniformisra húzni őket. Csak hát ezzel gondok vannak, mert minden objektum más és más, ezért máshogy, másféle képen kéne kezelni őket. Nos erre nincs meg az igazi koncepció. Hogyan tud egy OS gazdálkodni az olyan elemekkel, amiket nem ismer. Mert én úgy veszem észre, hogy a gazdálkodósdi összeolvad, pontosabban nem különül el rendesen a kezeléstől. Ezt bonyolítja a belső/külső nézetek keveredése. (hát valami ilyesmi.) Szerintem itt az a baj az OS-al, hogy rugalmatlan, nem képes elfogadni valami ujjat, nem képes befogadni számára még ismeretlen eszközöket, szóval rugalmatlan. Persze, hogy nem képes, mert nem mondták meg neki azt, hogyan is tegye (ezt).
Mert nem ilyen szemlélettel lettek kifejlesztve. Mert minden kis programocska (ASM driverek, a kernel, stb) az eszközt kapásból használatba veszi, és semmi rendszerezettség nincs ebben. Hát akkor tegyük rugalmassá az OS-t, ehhez mélyebbre kell ásni, egészen a hardverig, egészen a filozófiába. Itt ŐS princípiumokra van szükség, erre építkezve jussunk hozzá az illeszkedő eszköz kezeléséhez. Szükséges leírásokhoz, majd építsük fel belőle a driver-ét.
Eddig az OS-volt az, ami elrejtette a hardvert. Most, - hogy olvasom a gondjaitokat - ezt a szintet lejjebb kéne vinni. Mivel az OS egy bonyolult dolog, ezért egyszerűbb elemekre, az objektumokra lehet letolni. Vagyis az OS-t is objektumokból kéne felépíteni, és felkészíteni az eltérő tulajdonságú elemek kezelésére. Kérdés: Az absztrakciós feladat letolható-e az objektumok szintjére? Válasz: igen. Indoklás. Az objektumok encaptulation-ja és a kommunikációja. A fekete-doboz szemléletet alkalmazva, először meg kéne határozni azt, hogy mi kellene az OS-nak, milyen információk alapján tudna Ő dönteni, és menedzselni, és rugalmasan viselkedni. Ezek az adatok és leírók üzenetekben érkeznek, ezért feltehetem a kérdést úgy is, hogy Milyen üzenetekre van szüksége az Os-nak? , hogy menedzselni és illeszteni is tudjon. A menedzseléshez szüksége üzenetek, leírók nagyon jól meghatározhatóak, mondattervekbe, típus definíciókban. Viszont az illesztési adatok már nem. És én itt vagyok elakadva.
Nadamhu (29)
Igen, IGEN! Pontosan. Egy kicsit gondoljatok csak bele. Kérnék példákat is. Kellenek, fontosak ezek a részletek!
(31) Nos. Minek is az a futtató környezet? ;-)
Kedves NevemTeve! (14) Kiegészités.
mi maradna meg a gép kikapcsolása után? Hát az objektum leirata. A nem (élő) funkcionáló objektum csak leirat, neki nincsenek metódusai, csak leírói erről is meg arról is, pld a metódusáról, a tárolás szerkezetéről. Persze e tervezési folyamat még koránt sem ért véget. Mert lehet hogy hibáztam, és nem látok még mindent. Pld azt a folyamatot, amikor a hely nevű ősobjektumból hogyan származtatom le a file-t. Még nem látom azt a sort, hogy az öröklések során milyen metódusokkal fog bővülni, milyenekkel bővülhet, amiknek van (a természetben) végrehajtható változata. A mostani elemek példájával élve az egyik első objektum az SCSI műveletek elvégzésére képes funkciógarnitúra.
Kedves NevemTeve! (14)
1. JPEG
Hogy vág ez az operációs rendszerek témaköréhez? Ez az a példa, amit a (1)-ben kértél. Vegyünk valami konkrétumot; milyen lenne az objektumorientált "ls" parancs? Te kérted. Bár a (15)-ban nadamhu megcáfol, és megerősít.
(17) Akkor próbáljuk meg lépésenként.
lennének-e file-ok vagy sem? Nem és igen. A hagyományos értelemben véve nincs, mert az OO szerint tároló objektum, és mint ilyen persze, hogy létezik neki neve(), Open(), Read(), Write() ,Close() vagy ami jól esik neki. De nem biztos, hogy ezek és csak ezek, mert miért ne lehetne neki egy ReadRecord(123) metósusa? Amennyiben a tároló objektum ismeri a belső szerkezetét akkor rendelkezhet ilyen metódussal is.
Nadamhu (9)
miért nem lehet ezt egészen az oprendszer szintjére levinni. Le lehet vinni, sőt lejjebb is, egészen a hardver szintre.
Fileok és programok helyett objektumokban kellene gondolkodni. Ez egy nagyon fontos dolog. Gyakorlatilag még nem ez az uralkodó. El kéne gondolkodni a minden file mintájára (analogiájára) a minden objektum jogosságán, fontosságán. (mind ahogy a 10-ben is megemlíted.) Ez egy nagyon érdekes és nagyonis irányító elv. Ennek következménye, hogy nincsenek külön adatok és programok. Mert minden művelet (cselekvés)-nek van adat jellegű leírója és minden adat képes cselekedni valamit (pld hozzá adhatok egy hasonló típusút.)
k = new KÉP();
(most megjelenik egy lista, hogy melyik programmal akarom majd editálni...) Szerintem meg nem. Nem az jelenik meg, hogy melyik programmal, hanem az, hogy az objektumm mire képes, ő maga mit tud cselekedni. Valami más esemény hatására jelenne meg az a lista (amit te mondtál)... ami őrült hosszú lenne, és nem győznél válogatni, és itt valamilyen rangsorolás kellene (pld gyakoriság, vagy az, hogy hány objektumnál van alapértelmezettnek beállítva ez az objektum.).
oprendsyer szinten van-e értelme az OO szemléletet alkalmazni, és ha igen, akkor hogyan. VAN. A hogyan, még kidolgozás alatt.
Kedves Muster Mark!
Na de egy olyan oprendszer, aminél az objektumok alatt már asm van... :Na de egy olyan oprendszer, aminél az objektumok alatt már a HARDVER van...
Igen a lassúság is érv. Bár szerintem az üzenetek lassúsága és nem az objektumoké.
Kedves nadamhu!
Szerintetek ez azért maradt így mert ez koncepcionálisan olyan jó, vagy megszokásból? Szerintem megszokásból. Nincs átalakító erő, ami errefelé terelné a dolgokat.
Hülyeség lenne egy olyan Oprendszer, ahol csak classok és objektumok vannak?: Nem, sőt kifejezetten jó. Én is egy ilyet szeretnék.
A CORBA vagy a COM nem pont ilyen mahinacios rendszer? mintha pont azt csinalna, amiket a tobbi hozzaszolasban irtal. Pontosan! Az én kérdésem az, hogy az egy valid eképzelés-e, hogy egy ilyen COM, vagy CORBA jellegů rendszer belefészkeli magát az oprendszer belsejébe, és ezáltal ez az eddigi leghatékonyabb OO framework lehetne.
Ott lenne akarhany azonosithatatlan valami es kesz. Ha viszont van olyan azonositoja, amit az azonositasra hasznalsz, miert nem illeti meg ezt a kozhasznu "nev" nev? ;-) Ilyen értelemben van neve, mert meg lehet találni egy fastruktúrában egy sztring alapján. Viszont esetleg többféleképpen is meg lehet találni, ezért nem egy neve van, hanem több. (Mint a Unixos link.) De késôbb rájöttem, hogy ez valóban nem kardinális kérdés, és belementem, hogy legyen olyan neve ezekenek a fileoknak/objektumoknak, akár mint eddig.
En meg azt nem ertem, hogy hol a nagy kulonbseg. Az egységes szemléletmód, egységes szintaktika sokat jelentene. Többek között egy egységes dokumentációt. A rendszer gyorsabb megismerését. Az egységesség, és az objektumok kerneleben kezelése performance elônyökhöz is vezethetne. (Pl. nem szerializál a rendszer, csak ha végképp muszály, stb...)
A filetípusok öröklési hierarchiája nagyon fontos. Hiába mondod, hogy nincs különbség: az eddigi oprendszereken valahogy nem lehet megoldani ilyeneket:
"Hogyan listázod ki a 10 oldalnál nagyobb dokumentumokat"
Mivel a rendszer nem gondolkodik öröklôdésben, a fejlesztôk sem gondolkodnak abban, hogy a Documentum az olyan valami, ami valahány oldalas. A kép az olyan valami, aminek van vizszintes és függôleges mérete, és ezt változtatni lehet.
Pontosabban igen (mert az OO programozás elterjedt), de túl elszigetelten. Tehát lényegében egy az oprendszer által sugallt egységesség, mindeki által elfogadott objektum-hierarchia elônyös lehet.
Ezt kifejtened, mert nem ertem mire gondolsz. Ha a Java virtual machine és futtatókörnyezet kifejezetten a kernelben lenne, és optimalizálna olyan dolgokat, amiket eddig azért nem lehet, mert nem minden Oprendszeren můködne jól, akkor nyilván gyorsabb lenne.
>Úgyhogy mostantól egy új fogalomról: machinációs rendszerrol beszélek.:)
A CORBA vagy a COM nem pont ilyen mahinacios rendszer? mintha pont azt csinalna, amiket a tobbi hozzaszolasban irtal.
Ja, es itt van mar jo sok ideje. :)
>a fileoknak nincsen neve
Ravasz elkepzeles. Az objektumoknak szvsz dukal identity, state es behavior. A "csak hivatkozunk ra" jo az identitynek, de mielott hivatkoznal ra is meg kell talalni, es a fajloknal a nev a "passziv modban" hasznalt azonosito. Ha ilyen nincs, akkor a fajlod nem toltheti be a hagyomanyos szerepeit. vagy te mast ertesz fajl es nev alatt.
Namost nincs neve, de megtalálhatom a levelezésemben, vagy a kedvenc képeim között. A kedvenc képeim között lehet persze valami neve, vagy tartozhat hozzá megjegyzés, de ez nem a 'file neve'.
Hoyg talalod meg a kedvenceid kozott vagy a elvelezesedben? Ott lenne akarhany azonosithatatlan valami es kesz. Ha viszont van olyan azonositoja, amit az azonositasra hasznalsz, miert nem illeti meg ezt a kozhasznu "nev" nev? ;-)
>Nem hiszek abban, hogy a 'fileok', a 'processzek' a mai formájukban természetes
En meg azt nem ertem, hogy hol a nagy kulonbseg. Kell egy file, es valahol azt mondod hogy CreateFile, masutt create, masutt CoCreateInstance, vagy new File. Aztan kapsz vissza egy dolgot, ami 'handle' vagy 'interface pointer' vagy 'object id'. De ezekkel tok azonos modon dolgozol. Remelem egy programozonak aki ugyis absztrakt modon lat nem egy lenyges szempont, hogy a parameterek milyen sorrendben vannak.
A hatterben meg tok ugyanaz tortenik. Ill. ha valakinek nem tetszik az interface kinezete, nygodtan irhat maganak egy wrappert ami a kedvere valo. Sokszor ez meg elszlelheto runtime koltseggel sem jar.
A JAVA pl. valóban a platformfüggetlenség miatt félkarú óriás, ahogy Szindbad is mondta. Ha az OO a kernelben lenne, akkor sokkal hatékonyabb lenne egy JAVA program, és sokkal többre lenne képes.
Ezt kifejtened, mert nem ertem mire gondolsz.
>Hogyan listázod ki a 10 oldalnál nagyobb dokumentumokat? (Document, TextDocument, WordDocument)?
Volt itt egy topik valami 'minden adatbazis' szeru cimmel, ami ehhez hasonlo problemarol szolt, talan erdemes atolvasni.
A C fordítónem kezel fileokat, csak objektumokat manipulál.
A kernel dönt el, ha valakit muszály szerializálni. Ennek az okat lehet egy shutdown, vagy mert az objektumot/fileot el akarjuk küldeni a szomszéd gépre.
Az UnixObject-nek sem, (nemhogy a CCompilernek!) arról sincs fogalma, hogy hova szeiralizálódik, ezt a kernel dönti el.
Gondolom a kernelben valamilyen adatbuffereket használnék, és oda szerializálnám ki akiket muszály, mert eltérô címtartománybó hivatkoznak rá. Shutdown-kor, meg amikor elfogyott a memória, meg a lehetô leghardverközelibb módon tolná ki a kernel az adatot a Wincehterre. De ez szigorúan nem látszik az alkalmazásfejlesztô szemszögébôl.
Nekem egy kicsit úgy tůnik, hogy nem is velem vitázol, hanem az egész OO szemlélettel.
Amikrôl én beszélek (szerializáció) elég hasonlóan můködnek egy csomó OO frameworkben. (pl. EJB-k)
Félreértesz, nem azt kérdeztem, hogy milyen szintaxissal kell hívni a C-fordítót, hanem azt, hogy a C-fordító a futása során milyen rendszerhívásokkal kezeli a file-okat (természetesen ideértve az #include-dal beemelt file-okat is)
Mivel a szerializálás tényleg csak a legszükségesebb esetben megy végbe, egyes esetekben 'performance' növekedés is várható. (Azzal együtt, hogy a mai oprendszerek is cachelik a fileokat a memóriában. Itt nemhogy nem íródik ki fölöslegesen a cucc, de még csak nem is szerializálódik. Ha egy objektumot processzhatáron (címtartományon) túl kell elérni, akkor persze a szerializálás elkerülhetetlen. Ezért szimpatikusabb nekem, hogy egy user által végzett můveletek lehetôség szerint egy 'processzben', egy címtartományban legyenek.)
A helloworld.c egy TextDocument típusú objektum/file. (A TextDocument is nyilván az Object-bôl származik.)
a CCompiler egy osztály. Azon lehet filózni, hogy kell-e példántosítani, vagy csak statikus metódusai legyenek. Ha példányosítjuk, akkor a példány egy C Fordító példány lesz, ami esetleg konfigurációs paramétereket tárol.
Tehát:
class TextDocument;
...
TextDocument helloworld = Mycomputer.get('/src/helloworld.c')
CCompiler cc = new CCompiler(); // ez az objektum fizikailag egy c fordító konfigurációs filenak felelne meg...
class UnixObject; // még nem tudjuk, hogy ezen az oprendszeren lesz e object file, mindenesetre ez egy cross compilálás lesz, és linuxos .o file-ot generál.
Lehetne egy kicsit konkrétabban? Mondjuk én vagyok a C-compiler, aszondták nekem, hogy a helloworld.c-ből csináljam meg a hellowold.o-t. Milyen műveleteket használhatok a file-kezelésre?
mondjuk vannak file-ok (végülis névvel vagy anélkül?) Nem kardinális kérdés, hogy van-e neve. Viszont a gondolatkísérlet kedvéért az lesz a legszerencsésebb, ha minél kevesebbet változtatunk a jelenlegi rendszerekhez képest:
Legyen akkor neve.
Jó, ugyan szeritnem objektumokról van szó, nevezhetjük fileoknak is ôket.
Ellenőrzésképpen a régi, korszerűtlen rendszerek az alábbi műveleteket tudják: megnyitás/ létrehozás/ bezárás/ írás/ olvasás/ pozícionálás/ zárolás... Ezzel szemközt itt hogy lenne? stpmod-tól kellene megkérdezni, ô mondta, hogy ilyen már létezik.
én csak a saját ötleteimet tudom mondani:
Az OO lényege, hogy azt, hogy milyen můveletet tudsz végezni valamivel, az osztály maga deklarálja, publikus metódusok formájában.
Mivel minden osztály (file típus) az 'Object' osztályból származik, ezért valószínůleg az Object tartalmaz be/ki szerilaizáló metódusokat.
read(DataStream d);
write(DataStream d);
Ha valaki új file típust (class-ot) talál ki, akkor ezeket implementálni kell, plusz definiálhat új publikus metódusokat.
Egyenlőre a szakma ezeket a fogalmakat használja és ebben a te egyetnemértésed nem számít. vs.
Amiről beszélsz tehát, már létezik.
Hmmm. Még önmagával sem túl konzisztens a kioktatása, kedves Horger Antal tanár úr.:)
Frappánsan, ha már nyelvújításról beszél, mindjárt fel is hozta az egyelőre szó újítását.
Szakmailag nem tudok a hozzászólással mit kezdeni, mert a kioktatáson kívül semmilyen érv nem volt benne. Ez így elég fantáziátlan. A szakma meg nekem nem te vagy, hiába nyilatkozol a szakma nevében.
Hol is tartunk? No nézzük újra: mondjuk vannak file-ok (végülis névvel vagy anélkül?), milyen műveleteket lehet velük végzeni? Ellenőrzésképpen a régi, korszerűtlen rendszerek az alábbi műveleteket tudják: megnyitás/ létrehozás/ bezárás/ írás/ olvasás/ pozícionálás/ zárolás... Ezzel szemközt itt hogy lenne?
Ezzel nem értek egyet.
Nem hiszek abban, hogy a 'fileok', a 'processzek' a mai formájukban természetes, vagy a hardver miatt szükségszerů fogalmak lennének, amiknél soha nem lehet találni jobbat.
Egyenlőre a szakma ezeket a fogalmakat használja és ebben a te egyetnemértésed nem számít. Persze a villáskulcsra is kitalálhatunk valami új szót, de akkor ne új módszerekről beszéljünk, hanem nyelvújításról.
Szerintem az objektum, ahogy azt a JAVA kezeli legalább olyan fundamentális építôelem lehet(ne), mint a file, vagy a processz. A standard input, standard output, meg a command line paraméterezés meg nem is versenyezhet mondjuk egy OO metódushívás kifejezôerejével.
Egyelôre nincs OO alapú oprendszer, de nem lennék meglepve, ha 10 év múlva csak az az oprendszer maradna fennt, amelyik OO alapú.
Létezik manapság is objektum orientált oprendszer, igaz nem a PC-k szegényes világában. Meglepetésedre közlöm, hogy ezen oprendszer nem íratja ki a "metórusok hívását" a júzerrel. Sima parancsokkal kommunikál, és az interpreter az, ami ezen parancsok illetve paramétereik alapján elvégzi az objektumokkal a megfelelő műveleteket. Amiről beszélsz tehát, már létezik. Ezen operációs szisztéma "kernel" szinten nem csak az objektumokat támogatja, hanem mikrokód szinten DB2 adatbázismotorra lett ráépítve. Ergo eléggé hihetetlen sebességgel kezeli nem csak a file-okat, hanem a komplex adatbázisműveleteket is. Magyarán "kernel szint" alatt már adatbázisokról beszélünk.
A multiplatformossag nem az egyszeru vegfelhasznalo erdekeit szolgalja, hanem a feljesztest finanszirozo szervezetet.
Ez sajnos így nem igaz. A multiplatform a jövő zenéje - mert vannak akik a szabványokat a saját érdekeik okán felrúgják - ugyanis lassan a retyó is hálózatba lesz kötve, tudnia kell kommunikálni más eszközökkel, és nem lehet azt csinálni egy biznyos fejlettségi fok után, hogy lesz a windózos júzereknek wc interfésze, a linuxos júzereknek egy másik wc interfésze, de ezekből is lesznek alverziók, mert lesz aki nokia telefont és lesz aki erikszon telefont használ, melyek okán újabb alverziókat kell írni, hiszen az én riasztóm DSC, a tiéd meg valami más márka és a TV-nk, a kazánunk a külső időjárási körülményeket érzékelő alrendszerünk, a fűnyírónk, a porszívónk is mind más-más gyártó más-más processzorát és programját használja. A JAVA lenne a megoldás, és minden hw gyártó - ma már nem a számítógépet jelenti a hw - csak a szabványos JAVA VM megírásával járul hozzá ahhoz, hogy te a bóklászós bevásárló otthon összeköthessed, és adott esetben még egyéni elképzelésed alapján akár programozzad is a kacatokat, amiért pénzt adsz.
Tetszik vagy sem, ezek ma már külön-külön mind elérhető rendszerek automata és kommunikációkész verzióban, csak még hiába dugdosnád össze őket, mert minden gyártónak van saját busz szabványa, kommunikációs protokollja és a többi, és a többi. Gondold tovább !
Metódushívást. Egy metódus maga döntené el, hogy indít - e saját threadet.
pl.
Kep k = ...
k.edit();
indítana threadet, mert egy grafikus képszerkesztônek kell egy saját thread, a shellben meg vissszetérne azonnal a hívásból.
Bizony, az egy shellbôl, egy user által indított cuccok egy címtartományban lennének.
Na, hogy az osztályok le ne fagyasszák egymást az tényleg egy jó kérdés.
Amiket erre ki lehet találni:
- Válogassa meg mindenki, hogy mely osztályokban bízik. (Ma sem linkelsz be a programodba megbízhatatlan könyvtárakat.)
- A lefagyások elkerülhetôk ha JAVA szerů virtuális gépet használunk, csak itt sebességgondok lehetnek.
- Opcionálisan mégiscsak lehetne processzt indítani thread helyett. De nem ez lenne a default, és valószínůleg csak nem megbízható osztályba híváskor csinálnánk ilyet.
Mit jelent az "objektumokat hivogatnék" kifejezés? Vezérlésátadást? Metódushívást? Közös címtartományban? És hogyan történne a job-management (tudod Control+Z, fg, bg, kill), ha már egyszer átadtuk a vezérlést egy programnak, amely, ne adj isten, lefagyott?
(BTW: tudod mi a különbség a process és a thread között? A threadek is processzek, csak éppen közös címtartományban futnak, ezért módjuk van tönkretenni egymás adatait - ezért független programokat _nem_szabad_ így futtatni).
Amúgy lehet neve is.
Rájöttem, ami a lényeges különbség kettônk között, hogy én öröklôdést is orrba szájba használnék, és nem használnék processzeket egy shell scriptben minden parancs kiadásához, csak sima objektumokat hívogatnák. (Legfeljebb néha külön threadet csinálna magának.)
BTW2: sikerült már kitalálni, hogy lesz-e a file-oknak neve vagy sem?
Sikerült. Kernel szinten nem kell nekik 'név'.
Aztán persze tervezhetünk olyan objektum hierarchiát, hogy bejárhassuk ôket.
Tervezhetünk fastruktúrákat, amik végül levélként objektum instanceokra mutatnak, de ezeket úgy fogd fel, hogy egyenrangú linkek. Magának az objektumnak nem kell név. Nem kell kitüntetett link.
Pl.:
Collection myComputer;
...
Kep k = myComputer.getData("kepek/szepek/enyime.jpg");
1. Nincs öröklés. Ha ezt esszenciálisnak tekinted, akkor igazad van.
2. Ennek nincs köze az operációs rendszer... az OS számára nem léteznek állományformátumok (kép, dokumentum stb), ezért nem is foglalkozik velük.
opendir-konstruktor
readdir-metódus
closedir-destruktor
DIR *-objektumreferencia Akkor most én kérdezek:
Hol az öröklôdés?
Hogyan lehet megváltoztatni egy kép méretét, a formátumától függetlenül? (Kép, JpgKép, BmpKép)
Hogyan listázod ki a 10 oldalnál nagyobb dokumentumokat? (Document, TextDocument, WordDocument)?
Merthogy ezek nem elsôsorban fileok, ezek képek és objektumok.
Hát kérem tisztelettel: a file az adattárolás egysége a háttértárolón (tehát akkor is létezik, amikor a számítógép ki van kapcsolva), arról ismerszik meg hogy van neve, jellemzői, adattartalma. Példa: tárolom a gépemen az összes RFC-t, és hirtelen szeretném megnézni a 1116-ost. Nem teszek mást, mint keresek egy /usr/share/doc/rfc/rfc1116.txt nevű file-t.
A procesz a számítógép hasznos működése; azaz a felhasználó kiszolgálására szolgáló tevékenysége. A kernel feladata a processzek indítása, leállítása, az erőforrások (pl CPU) elosztása közöttük, kommunikáció biztosítása a proceszek között. Ja és persze (a harver segítségével) el kell szeparálnia egymástól a processzeket, hiszen azok különböző felhasználókhoz tartoz(hat)nak, semmi szükség arra, hogy egy rosszindulatú processz mások adatait meglássa vagy elrontsa...
BTW1: meg tudod már magyarázni, hogy mitől nem oorientált a POSIX-kernel?
BTW2: sikerült már kitalálni, hogy lesz-e a file-oknak neve vagy sem?
