Szerintem a Midori != Windows 8. Windows 8 egy merõben más, de nem managed rendszer lesz.
Gondoljatok csak bele egy Crysis 2 szintû játék hogy fog azon futni a jövõben. A játékfejlesztés elég erõs ipar és egy ilyen managed rendszeren megpecsételõdne az egész, már ami a windows-t illeti. .NET-es fejlesztõként tudom, hogy vannak buktatói a managed rendszernek, ami nem teszi alkamassá profi szintû rendszerközeli programok futtatására, ez sajnos tény. ;) A Vista C# graf felülete alatt is full natív DirectX támogatás van azért gyors, de Doom4-et nem írnék rá.
> adatszerkezetbõl adatszerkezetbe mutató adat elérési ideje korlátos, ha az elemek száma is korlátos.
Na, hat nagyjabol ezt probalom neked elmagyarazni. Ha pedig ezek az eltero adatszerkezetek egyetlen kozos grafba vannak szervezve akkor annak az egyes pontjai koze vektorok irhatok fel melyeken keresztul a leghosszabb ut determinalhato. (tovabbra is veges adatszerkezetekrol beszelunk)
> Determinisztikus esetekre PLC-t használnak
Altalanositas. Hol? Ipari kornyezetben lehet, de ennek semmi koze a temankhoz.
> RTTI mûködése a fordító kezében van. Minden típushoz hozzárendel egy bizonyos Typeid rekordot, melyben a típus sorszáma szerepel néhány más adat mellet. Ezt az értéket hasonlítja össze a beazonosítani kívánt típus azonosítójával.
A tipusindexeles alapveto dolog.
> sõt, léteznek advanced keresési technikák, ahol többezer adat közül max. 8-10 összehasonlításból megmondható a típusról, hogy megfelelõ -e.
Ez szinten nem ujdonsag.
> Aztán a VMT-t meg jó is hogy nem írtad le. Mert amit te mondasz, az nem virtuális metódus lesz, hanem static osztály-tagfüggvény
Ha tovabbra is kenyszerszeruen egy altalad valasztott konkret hagyomanyos nyelvi fordito, netan binaris targykod architektura sajatossagait alkalmazod altalanositasban.
> mihelyst átadod az objektumod egy másik osztálynak, máris buktad az osztálytagfüggvény címét.
Es itt tovabbra sincs kiemelve, hogy mindez a hagyomanyos operacios rendszereknel megszokasbol alkalmazott redundans osztaly/objektum nyilvantartas problemaibol adodik.
Vegyel alapul egy terminalszervert ahol - mondjuk a gyakorlati pelda kedveert - 100 user van bejelentkezve es mindegyik 2 peldany Firefox-ot futtat. Az processzenkent (ures bongeszoket feltetelezve) nagyjabol 70MB, 200x70MB az 14GB-nyi lefoglalt memoria 200 redundans adattal ami 14GB helyett 70MB-tal is felirhato lenne ha van a hatterben egy kozos adatszerkezetbe szervezett egyszeru, kulturalt memoriahozzaferes-kezelesi strategia. Ha a merevlemezen rendelkezik egy futtathato binaris futtatasanak jogosultsagaval egy adott felhasznalo, akkor evidens, hogy ugyanannak a memoriaba mar korabban betoltott peldanyahoz is kell hogy jogosultsaga legyen, (!!) ha csupan az egyes felhasznalok altal folytatott tevekenyseg van kulon memoriateruleten kezelve es szeparalva. Ugyanezzel a modszerrel logikailag barmilyen eroforras megoszthato konkurrens peldanyok es felhasznalok kozott, csupan konfiguralas kerdese.
> elõször is [b[biztos, hogy ezzel még nem lesz típusbiztos a címtartomány kezelésed.
Mivel?
> A típusbiztosság megköveteli, hogy a forrás és a cél típusa megfeleltethetõ legyen egymásnak
Igen, ezt jelenti az amit irtam: "Realtime tipusazonositas."
> közös protokolokról nekem az usb jut eszembe. ott egy halom deszkriptor létezik, aminek a kitöltögetése a -közös protokol miatt- jókora erõforrást visz el.
Es mekkora eroforrast visz el ha pont-pont kozti kapcsolatokra tucatnyi protokollt hasznalunk, netan egyikbol a masikba atjarunk?
Melyik eroforrastakarekosabb? Egy jol atgondolt azonos protokollon keresztul barmilyen digitalis/digitalizalt adat tovabbitasa, vagy tucatnyi protokollt megirni, karbantartani, memoriaban tartani, egyidoben futtatni es netan egyikbol a masikba konvertalgatni?
> Na persze, és így lesz egy multitask operációs rendszerbõl multi threaded single task. Ami nagyjából semmit nem ér, mert ad egy nagy pofont az adatbiztonságnak, a szálbiztonságnak
He?? Tobbek kozott eppen ezt hivatott garantalni azaltal, hogy a kozos protokollok (ertsd: kozos atjarasi pontok) miatt nem kell bloatware-eket karbantartani, nem kell 25-szor ellenorizni egy felhasznalo jogosultsagat ugyanahhoz az eroforrashoz, mert minden felhasznalo tevekenysege ugyanazon a grafon megy keresztul. Ha mar az elso lepesnel elakad a masodik kriteriumot meg sem kell vizsgalni. Es ez igaz barmely szituaciora, legyen az az eroforras akar egy memoriaterulet, egy tetszoleges periferia, egy hattertaron tarolt adat, vagy mittomen egy ugyviteli szoftver altal tarolt adatbazisrekord.
> De hogy OS-t nem írtál még sem embedded sem PC környezetben az biztos.
En nem igy emlekszem.
> Tudod már miért akadt el az OO alapú Linux fejlesztése ?
"1. Miert nem hasznaljak RTOS-ek alatt a OO nyelveket?
Nem-determinisztikus egy-egy fuggveny lefutasa."
Visszacsatolt rendszerekben SEMMI sem determinisztikus, mert az egész egy nagy állapotgép. Determinisztikus esetekre PLC-t használnak, abban pedig biztosan nem lehet visszacsatolt hálózat, ezzel küszöbölve ki az illegális állapotokat (így nem lesz pl. a stop gombból fordulatszám növelés pl. marógépen).
"2. Miert nem determinisztikus?
Mert szinte ismetlodoen adatszerkezeteken keresztul kell elernie mutatokat melyek eleresi ideje bizonytalan. (proceduralis paradigmat kovetve is vannak ilyen esetek, de a hangsuly szinten a gyakorisagon van)"
adatszerkezetbõl adatszerkezetbe mutató adat elérési ideje korlátos, ha az elemek száma is korlátos. Az elérési idõt csak a programozó határozza meg, legyen az akár VMT, vagy egy sima adattábla, esetleg közvetlen fügvényhívás azáltal, hogy milyen technikát alkalmaz.
"3. Melyek ezek az esetek?
Realtime tipusazonositas. (VMT-t szandekosan nem irom ide mivel futasidoben nem kell foglalkozni az osztalykonzisztenciaval ha a targykodban a metoduscimet tarolod. Ez kizarolag a forditasi idot befolyasolja)"
RTTI mûködése a fordító kezében van. Minden típushoz hozzárendel egy bizonyos Typeid rekordot, melyben a típus sorszáma szerepel néhány más adat mellet. Ezt az értéket hasonlítja össze a beazonosítani kívánt típus azonosítójával. Ez viszont erõsen korlátos futásidejû, C++ esetében 1-2% sebességcsökkenést okoz. sõt, léteznek advanced keresési technikák, ahol többezer adat közül max. 8-10 összehasonlításból megmondható a típusról, hogy megfelelõ -e. ha pedig typeid(typespecifier) futásidejét nézzük, akkor annak ideje nagyjából egy órajelciklus, mert ez kb egy define-al egyenértékû mûvelet. Aztán a VMT-t meg jó is hogy nem írtad le. Mert amit te mondasz, az nem virtuális metódus lesz, hanem static osztály-tagfüggvény, aminek ténylegesen címet tesz bele minden tisztességes C++ fordító az álmoskönyvek szerint is. Virtual tagokra viszont ez nem érvényes, mert ott a VMT tagot az indexe fogja azonosítani (hasonképp mint ahogy egy DLL export függvényeit is azonosítják). Ezen index adat alapján lesz a tagfüggvény megkeresve és meghívva. Mindezt általában cachelik a fordítók a sebesség optimalizálás céljából (amig az objektum-mutató azonos típusra mutat, addig nem is szoktak új VMT keresést indítani). Persze lehet ezt is tárgykódban értelmezni, de sokkal rugalmatlanabbá válik a rendszer, ráadásul a VMT kérdése itt sincs megkerülve: mihelyst átadod az objektumod egy másik osztálynak, máris buktad az osztálytagfüggvény címét. A miértre válasz az öröklõdés polimorf mechanizmusa. Ha egy osztálytagföüggvényt felülírunk, akkor annak indexe a régi osztály indexét örökli, de a leszármazottban a régi osztály metódusai még léteznek - mindössze az indexük íródik át (avagy egyes fordítókban egy külön pointer mutat a szülõ osztály VMT-jére!).
"4. Miert van erre szukseg?
Hogy garantaljuk a tipusbisztos cimtartomany kezelest."
elõször is [b[biztos, hogy ezzel még nem lesz típusbiztos a címtartomány kezelésed. A típusbiztosság megköveteli, hogy a forrás és a cél típusa megfeleltethetõ legyen egymásnak. pl. a C++ eredetileg ilyennek indult, de aztán a C-bõl átjött hozadék miatt már nem lett az.
"5. Lehetseges ezt maskent garantalni?
Igen, lehetseges, ha az adatszerkezetek kozti atjarhatosagot kozos protokollokra helyezzuk. Ha autentikus adatszerkezeteket alkalmazunk melyek kozos protokollba (pl. kozos graf adatszerkezetektol fuggetlenul) szervezhetoek akkor globalisan, a teljes rendszerben tetszoleges adat eleresehez szukseges legrosszabb eleresi ido mindig determinalhatova valik. (Az most mas kerdes, hogy sokszor nem csak a legrosszabb eset, hanem ennel joval tobb informacio is determinalhato)"
közös protokolokról nekem az usb jut eszembe. ott egy halom deszkriptor létezik, aminek a kitöltögetése a -közös protokol miatt- jókora erõforrást visz el. Vajon a közös protokolok nem visznek el erõforrásokat úgy, mint pl. egy VMT kezelés ? Ezen felül az autentikus adatszerkezetek által garantált adatelérési idõvel pedig csak óvatosan. Ha nekem olyan az adatom, aminek a kinyerése az adatszerkezetbõl NP teljes problémát vet fel, akkor a garantálhatóságot dobhatod a kukába.
"Egyebkent a fenti modszerrel az OO alkalmazasokat jellemzo nagy memoriahasznalat is radikalisan csokken ha elunk is a kedvezo lehetosegekkel es eleve ugy epitjuk fel az OS-t, hogy a redundans memoriahasznalatokat mersekelje. (Ugye ha a problemat gyokereiben kezeljuk, varhato hogy mas problemaktol is szabadulunk, amelyeket talan korabban altalanosan el is fogadtunk mellektermekkent es igy mar nem is foglalkoztunk veluk)"
Na persze, és így lesz egy multitask operációs rendszerbõl multi threaded single task. Ami nagyjából semmit nem ér, mert ad egy nagy pofont az adatbiztonságnak, a szálbiztonságnak, a "közös lónak túros a háta" elvnek, de cserébe garantáltan felvet jópár deadlock problémát, illetve egy halom olyan dolgot, amit még az ellenségemnek és t. családjának sem kívánnék.
Ebbõl nekem kb. az jön le, hogy lehet olvasott vagy, sokat foglalkoztál vele. De hogy OS-t nem írtál még sem embedded sem PC környezetben az biztos. Amúgy csípem a humorod, legalább értelmesen beszélgetsz:-) Tudod már miért akadt el az OO alapú Linux fejlesztése ? :-))
üdv.
> pl. a virtuális metódusok hívásakor. ezen függvények hívása biztosan lassabb lesz. Emiatt nem is alkalmazzák embedded cuccokban RTOS-ek alatt.
Nem. Rossz a megkozelites. Csak a felszinig messz el a problema okozojanak keresesekor, majd egy felvalasszal felbe is hagyod a keresest. :-) MINDIG vezesd vegig lepesrol-lepesre visszafele a valaszt egy adott kerdesre es megtalalod az okozojat a gyokereknel (mely okozo rend szerint mashol is problemakat okoz).
Peldaul, hogyan jutunk el az aktualis problema okozojahoz:
1. Miert nem hasznaljak RTOS-ek alatt a OO nyelveket?
Nem-determinisztikus egy-egy fuggveny lefutasa.
2. Miert nem determinisztikus?
Mert szinte ismetlodoen adatszerkezeteken keresztul kell elernie mutatokat melyek eleresi ideje bizonytalan. (proceduralis paradigmat kovetve is vannak ilyen esetek, de a hangsuly szinten a gyakorisagon van)
3. Melyek ezek az esetek?
Realtime tipusazonositas. (VMT-t szandekosan nem irom ide mivel futasidoben nem kell foglalkozni az osztalykonzisztenciaval ha a targykodban a metoduscimet tarolod. Ez kizarolag a forditasi idot befolyasolja)
4. Miert van erre szukseg?
Hogy garantaljuk a tipusbisztos cimtartomany kezelest.
5. Lehetseges ezt maskent garantalni?
Igen, lehetseges, ha az adatszerkezetek kozti atjarhatosagot kozos protokollokra helyezzuk. Ha autentikus adatszerkezeteket alkalmazunk melyek kozos protokollba (pl. kozos graf adatszerkezetektol fuggetlenul) szervezhetoek akkor globalisan, a teljes rendszerben tetszoleges adat eleresehez szukseges legrosszabb eleresi ido mindig determinalhatova valik. (Az most mas kerdes, hogy sokszor nem csak a legrosszabb eset, hanem ennel joval tobb informacio is determinalhato)
Egyebkent a fenti modszerrel az OO alkalmazasokat jellemzo nagy memoriahasznalat is radikalisan csokken ha elunk is a kedvezo lehetosegekkel es eleve ugy epitjuk fel az OS-t, hogy a redundans memoriahasznalatokat mersekelje. (Ugye ha a problemat gyokereiben kezeljuk, varhato hogy mas problemaktol is szabadulunk, amelyeket talan korabban altalanosan el is fogadtunk mellektermekkent es igy mar nem is foglalkoztunk veluk)
Ez érdekes. Hogy mikor keresünk a VMT-ben ? pl. a virtuális metódusok hívásakor. ezen függvények hívása biztosan lassabb lesz. Emiatt nem is alkalmazzák embedded cuccokban RTOS-ek alatt. Inkább C és asm.
> mégpedig: ha egy osztályalapú OS-t veszel alapul, biztosan nem kerülheted el a VMT alkalmazását
Meg mindig elbeszelunk egymas mellett. Elismetlem megegyszer: szo sincs a VMT megszunteteserol. Meg csak utalast sem tettem erre. Es kerem, hogy ezuttal tenyleg legyen vilagos.
Az idezetemben ezert vastagitottam ki a "folyamatosan" szot, mert a kezdetektol fogva a VMT-ben valo kereses gyakorisagara (es modjaira) utalok.
Most azt, hogy hogyan oldottam meg adatszerkezeteken keresztul az ilyen jellegu problemakat azt minimum egy hetes eloadas sorozaton keresztul tudnam levezetni neked. Nem apro konstrukcios ujitasokrol van itt szo (az en esetemben), hanem teljesen uj nyelvi leiro rendszerrol, teljesen uj eroforras kezelesrol, teljesen uj generacios forditoprogramrol. Meg forraskod sincs a hagyomanyos "szoveges fajl" ertelembe veve es megcsak a fogalom, hogy "fajl" sem letezik.
Egy sokdimenzios csomoponti adatbazis van ahol a programozo/felhasznalo szemszogebol nincsen protokolbeli kulonbseg egy "konyvtar" mint gyujtoeszkoz, "fajl" mint taroloeszkoz, "port" vagy "halozat" mint I/O eszkoz, vagy akar felhasznalo, process, stb mert mindegyikuket transzparensen azonos protokollon keresztul eri el. Ami megkulonbozteti oket az a rajuk valo hivatkozas (nev, azonosito, stb).
Ez a kialakitas termeszetenel fogva olyan teljesen uj lehetosegeket hoz amelyeket ha egyuttesen alkalmazunk akkor ujra kell alkotnunk a szamitastechnikarol, informatikarol eddig tanultakat es teljesen maskent kell megkozelitenunk reszproblemakat.
mégpedig: ha egy osztályalapú OS-t veszel alapul, biztosan nem kerülheted el a VMT alkalmazását, ami viszont minden egyes függvényhíváskor lassít egy picit. Talán többet mint egy szimpla "rep movsd". Ráadásul ez esetben is van egy probléma: nem tudod, és nem is tudhatod, hogy az adott OS fordításakor milyen címre linkelõdik egy-egy metódus. Vagyis csak úgy, ha létrehozol egy -a metódusra mutató- adatterületet. aminek értékét átadod a megfelelõ helyeken. Viszont még mindig van ezzel egy probléma. Ez pedig a méret, mert ha mindenkinek átadod ezt, akkor õk is tárolni fogják azt valahol, ami az erõforrások felesleges elfecsérléséhez vezet. Vagy mégjobb, átadunk egy mutatót, ahol ezen metódusok le vannak írva. És ezzel már gyak. létrehoztuk a VMT-t egy valamilyen osztályra. Aztán sebességbeli gondok is vannak. mert pl egy MOV ebx, [ebp+16*4] call ebx sokkal lassabb mint egy
call directcall
hívás. Nem beszélve az objektumpointerek kezelésérõl, mert ott is akadnak gondok. emiatt az OO az embedded cuccokban nem véletlen nem kapaszkodott meg. Ha nem lenne sebességbeli gond, már régen abban írnák az oprenccerek zömét.
Apropó, tudod, hogy végül miért akadt el az OO-ban írt linux?
> Avagy bármiféle interfészt, esetleg absztakt osztály leszármazottat (többszörös öröklõdés esetén) ?
Es most ahogy latom, hogy itt alapfogalmakban levo hianyossagok is felszinre kerultek, ugyanis a VMT lenyege - mint Virtualis Metodus Tabla - a neveben is hordozza, hogy az a virtualis metodusok cimterenek es egyeb kiegeszito adatainak gyujtemenye, nem pedig a polimorfizmus feltetele. A kettonek egyebkent semmi koze egymashoz.
A VMT-ben kizarolag a virtualis metoduskenk, netan virtualis property-kent definialt elemek tarolodnak. Normalisan megirt forditoprogramok a VMT-t letre sem hozzak olyan osztalyoknal ahol virtualis elemek nincsenek definialva. Az oka pedig amiert a VMT-re szukseg van, hogy amikor egy leszarmaztatott osztalybol letrehozott objektumon belul egy felul nem irott metodusunk egy virtualis metodusara hivatkozik, azt tudnia kell, hogy az uj osztalyban nem lett-e veletlenul felulirva az ominozus virtualis metodus. Ha igen, akkor az ososztaly metodusanak a leszarmaztatott osztaly felulirt metodusara kell hivatkoznia, hiszen pont ez a virtualis elemek lenyege.
A polimorfizmus pedig az orokolt valtozok, property-k, metodusok es egyeb osztalyokba foglalt elemekre valo hivatkozas a leszarmaztatott osztalyokbol azonos neven. Ennek pedig az egvilagon semmi koze a VMT-hez.
> Kiröhögöm a vakbelem, pont te beszélsz kultúráról, aki még az ékezetet sem ismeri és (idézlek!) "bisztos" a dolgában.... LoL
Ekezet ismerete nem gond, meglete mar annal is inkabb. Ha Magyarorszagtol tavol elsz es nem all rendelkezesedre magyar nyelvu ekezetes billentyuzet, nem ismered a magyar billentyuzetkiosztast mert talan nincs is ra szukseged a hetkoznapi eletben meg nem a kultura hianyat jelenti, csupan azt, hogy a rendelkezesre allo lehetosegeid korlatozottak.
A kozvetlen hangnemedbol feltetelezem, hogy Te egy magasan kvalifikalt szakmernok vagy aki annak idejen az egyetemen megtanulta, hogy a tanulas egyik legjobb eszkoze a kommunikacio mas szakemberekkel es annak a levezetese erzelmi kicsapongasok nelkuli pusztan muszaki alapokon. Abban is egeszen biztos vagyok, hogy az egyetemen elhangzott az is, hogy annyi tisztelettel kozelits meg masokat, mint amennyit viszont elvarsz magad is, tovabba abban is biztos vagyok, hogy ezek tettleges cafolataval - mint irasaid kulturalis minosegevel - nem hagynad, hogy masok hite meginogjon az altalanos muveltseged irant.
> Basszuskulcs, a többalakúságot hogy realizálod ?
Tovabbra is meggyozodesem, hogy egy kulturalisan erett, kutatoi figyelemmel rendelkezo kollegaval beszelgetek aki minden mondatot korultekintessel ertelmez.
Ime egy korabban elhangzott mondatom amire a fenti valaszod erkezett: "miert van ra szukseg, hogy a VMT-ben, stb folyamatosan keresgelj?"
Itt pedig a tobbi: ...ezeknek a problemaja egyetlen gyokerben keresendo es ez nem maga az OO paradigma, hanem ezeknek a jelenlegi megvalositasaba. (adatszerkezetkeben, kodgeneralasban, eroforraskezelesben es azoknak az EGYUTTES hatekony alkalmazasaban). A hagyomanyos operacios rendszereknel erre meglehetosen korlatozott lehetosegek allnak rendelkezesre.
> Avagy bármiféle interfészt, esetleg absztakt osztály leszármazottat (többszörös öröklõdés esetén) ?
> Tudod, hogy hogy mûködik egy OO nyelv natív megvalósítása?
A Singularity-hez hasonlo elven mukodo sajat operacios rendszeren es annak az OO forditojan dolgozom lassan otodik eve. Eleg valoszinu, hogy tudom mirol beszelek. (az oldalt majd befejezem ha lesz idom)
> -Akkor mesélj róla, mert az én emlékeimben a VMT tábla kezelése igencsak lassító tényezõ!
Eleg szamonkeroen hangzik, de azert valaszolok. Azt nem art tudni, hogy a VMT mellett sok mas minden is lassito tenyezo (pl. valos ideju tipusosszehasonlitas) melyek mindegyike valamilyen adatszerkezetben valo keresesen alapszik. Megforditanam a kerdest: miert van ra szukseg, hogy a VMT-ben, stb folyamatosan keresgelj?
En nem fogalmaznek hasonlo hangnemben, de gondolom tudod, hogy ezeknek a problemaja egyetlen gyokerben keresendo es ez nem maga az OO paradigma, hanem ezeknek a jelenlegi megvalositasaba. (adatszerkezetkeben, kodgeneralasban, eroforraskezelesben es azoknak az EGYUTTES hatekony alkalmazasaban). A hagyomanyos operacios rendszereknel erre meglehetosen korlatozott lehetosegek allnak rendelkezesre.
Nem hiszem, hogy a csak ertek szerinti atadas alatt teljes strukturak/objektuom masolasat ertenek. Ha, igen akkor felejtos a rendszer.
Kozos heap nem jelent biztonsagi problemat, mivel nem keletkezhet olyan nativ kod ami iletektelen dolgot muvelne. (Egy viszonylag kis resz foglalkozik azzal, hogy ez igy legyen, azt elvileg egyszeru ellenorizni, hogy jo -e)
"Magyarul, van egy visszamaradott tomeghiszteria ami ott kezdodik, hogy valaki egyszer azt mondta, hogy: "objektumorientalt nyelvben orultseg kernelt irni, mert a teljes rendszer lassu lesz". Az mar mas kerdes, hogy azota a hardware arak jelentosen csokkentek es a nyelvek is alkalmasak, a lenyeg a birkaoszton. Szemelyes meggyozodesem es tapasztalatom, hogy napjainkban aki ilyet allit az vagy nem tudja, hogy egy operacios rendszer hogy mukodik, vagy nem programozott meg objektumorientalt nyelvben vagy ha igen akkor az egesz emberiseg halas lenne ha abbahagyna."
Hmmm... ez egy baromság... Tudod, hogy hogy mûködik egy OO nyelv natív megvalósítása? -Akkor mesélj róla, mert az én emlékeimben a VMT tábla kezelése igencsak lassító tényezõ! (és akkor nem beszéltünk egy halom más dologról, ami ugyancsak lassít) Embedded cuccokban nem véletlen nem nyerõ az OO az OS írkálásra. Max GUI, de ott sem mindig.
Hát én végigrágtam magam a teljes technikai doksin, de nem hiszem, hogy jobb lesz, mint bármelyik másik OS-ük... Ilyen kitételek vannak benne, pl: "nem kell figyelni a gép teljesítményére, mert az úgyis nagy", meghogy "nincs cím szerinti átadás, csak érték szerinti, mivel ez megold minden problémát". Ezenkívül minden dinamikusan foglalt memória (bármelyik taské is) ugyanabba a heap-be kerül, ennyit a biztonságról.
Ettõl függetlenül azért vannak benne jó ötletek, de aligha mondanám, hogy eredetiek. Inkább csak amolyan meshup féle. Majd meglássuk.
Valoban, ha teljesen kozos laptablat hasznal minden akkor teljes TLB-t soha nem kell ervenyteleniteni.
En nem vagyok oda microkernelkert, legtobb IPC sokkal koltsegesebb, mint egy sima fuggveny hivas. Monolitoknal nincs ilyen problema :)
Egy process, ha var valamire akkor (es tudjok, hogy 1 usecnel (joval) tobbet kene varnia) akkor is bekovetkezik a task valtas (pl. nanosleep(),(blocking) read()). sched_yield() -el explicite is lemondhat process az idoszeleterol.
"Érdekes lesz, hogy ha közvetlen a Windows 7 *elõtt?* után majd megjelenik ez a Midori. :P"
Van egy meglevo platformjuk, ezt tamogatni kell valahogy. A midori egy uj kernel, ami azt jelenti, hogy fogjak a jelenlegi win32-es/win64-es alrendszert es atirjak, hogy winnt kernel helyett a midori-n fusson. Ezt barki megteheti, a wine-os csapat peldaul linux ala irta at. Innentol a gep jo resze midori alatt fut, de a programok a windows alrendszer alatt. Igy futott anno winnt4-en os/2-es program, winxp-n linux-os es linuxon win32-es. De a win16-os rendszer tamogatasat is hasonloan oldottak meg, ez az alrendszer tunik most el a vistaval.
Meg az is lehet, hogy a win7-et mar a midori kernellel hozzak ki, bar eleg nagy ervagas lenne a cegnek az osszes driver ujboli ujrairatasa a hardvergyartokkal. Valoszinubb, hogy a miniwin fele megoldast valasztjak, ahol van egy hypervisor, van egy fo kernel es van egy par kompatibilitasi kernel. A kompatibilitasi kernelekbe mehetnek a regi driver-ek es a regi win32/win64-es alkalmazasok. A fo kernelbe kerul a .net-es rendszer es programok, tovabba a gui kodjanak nagy resze es az uj driver-ek. A cpu es a memoria kezelese, tovabba a kommunikacio pedig a hypervisor feladata.
"Minden procesznek van egy sajat lap tablazata (vannak kozos lapok). A hardver (MMU) kezeli ezt. Ha new/malloc (brk(), anonimous mmap()) foglalsz memoriat akkor rendszerint meg nem lesz a te processede a lap. Amikor eloszor fer hozza a process az eleteben, akkor kivetel keletkezik, es kernel neki adja azt a lapot, onantol kezdve kernel nem szol bele mit csinal vele (nincs buntetes)."
Ez a regi windows-ok mukodese volt. A midori eseteben epp az a jo, hogy egyetlen szemetgyujtos allocatator kezeli az egesz cimteret. Igy elofordulhat az is, hogy egy fizikai lapon tobb eltero folyamat adati vannak vegyesen. Maga a nyelv a biztonsagos, ezert becsuletesen soha nem fognak a folyamatok egymas adataihoz erni. Az uzenetkuldes (rendszerhivas) mindossze annyibol all, hogy az egyik folyamat atadja a kernelnek az adatterulet leirojat, amit az odaad a masiknak. Igy az adatokhoz hozza sem kellett erni, es megis sikerult a folyamatok kozotti kommunikacio.
"Task valtaskor rendszerint kiurul a TLB, kernel -> user mod valtaskor ill. vissza valtaskor nem,"
Process valtaskor. Szoftveres task valtaskor nem (pl. thread valtas). Mikrokernelek eseten a kernel jo resze is tobb masik process-ekben van, tehat neha egy rendszerhivas alatt tobb tucatszor is process-t kell valtani.
"usec alatt van egy mai processoron az ujboli kitoltese (nem kell teljesen kitolteni (Hardware vegzi), akar ns-ekrol is beszelhetnenk), kb. ms-onkent van task valtas-rol dontes (szervernel gyakran ritkabban (10ms)), (minden hoszabb I/O -ra valo varakozaskor is, ugye nincs sok ertelme azt a processt futatni ami adatok hinyaban all)."
A fenti pelda egy jatek eseten max. 100 task valtas/sec-t tesz lehetove. Igy egy jatek, ami a kernel-t hivja, ami a grafikuskartya driver-et hivja, ami a grafikat rajzolja, max. 25 hivast tudna megtenni masodpercenkent ha mikrokernelt hasznalnank. Mivel egyetlen kep kirajzolasahoz tobb mint 25 hivas kell, ezert az egesz rendszer hasznalhatatlan lenne ha a grafikus drivert kiszednenk a kernelbol es sajat process-t kapna. Ha viszont megnoveljuk a taszkvaltasok szamat, mondjuk 100-szorosara, akkor az elpazarolt ido is megno. A tlb toltesek jo resze pl. nem cache-bol jon, sot a mai x86-osok amugy is eleg lassan kezelik a process valtast. (a taszkvalto utasitasok eseten ez tobb ezer orajel/utasitas szokott lenni)
A midori nem az egyetlen jo megoldas. Ha a cpu kezelne rendesen az egy cimterbe telepitett tobb folyamatot, tehat tamogatna a fine grained protection-t, akkor is meg lehetne oldani a problemat (nagy asszociativ tabla kell csak hozza). Viszont az egyszeru es olcso, de gyors es nagy mennyisegu processzorok fele mozdul el a vilag. Arrol nem beszelve, hogy a singularity/midori eseten az os nagyobbik resze (meg a driver-ek is) teljesen platformfuggetlenek, tehat barmilyen cpu-n kepesek futni, fuggetlenul annak hardveres kepessegeitol. Vedett kod eseten akar egy lapkezeloegyseg (paging) nelkuli cpu is kepes virtualis memoriat hasznalni. (csak a szemetgyujto vezerlo fejlecebe kell tenni egy 'kilapozva xy helyre' jelzobitet) Igy egy objektum (programkod+adatok) tetszolegesen mozgathato a halozaton barmerre, mivel nincs adott hardverhez kotve. (kerulhet diszkre vagy egy tavoli gepre is) A rendszer vedelme addig tart, amig a memoriahaz kozvetlenul senki (egy programozo sem) sem ferhet hozza csak a kernel objektumkezeloje. Ha gep vedett modon kepes futtatni az alap kernelt (pl. beleegettek a bios-ba) es a par szaz soros kodban nincs biztonsagi res, akkor onnantol sokkal biztonsagosabba valik mint a jelenlegi windows-ok.
Azért ez érdekes, ugye nem sokára jön a Windows 7 eközben pedig még valami Midori-n is dolgoznak *gõzerõvel*. Oké, de ha a Windows 7 is valami gagyi lesz azért mert nem fektetnek bele annyi *energiát* akkor ez egyenlõ a Vistával. Sokan maradnak a Windows XP-nél és fognak is maradni. Bár azért kíváncsi vagyok mit változtatnak a Windows 7-be. Érdekes lesz, hogy ha közvetlen a Windows 7 *elõtt?* után majd megjelenik ez a Midori. :P
elõbb a Visztát kéne egy kicsit kifényesíteniük és kiadni egy legalább olyan megbízható és jó operációs rendszert, mint a vLite Vista, amit pofátlanul egy horvát diáknak kellett third person megírnia...Nekem most konkrétan egy P2-300-as géprõl fut 256 mega ramról , egy CDrõl települt 2 gigát foglal egy 5 gigás partición és tûrhetõ sebességû (igaz f*ssá van tvíkelve), de fut egy másik gépemen is Virtuális Gépben egy 1.8-as P4-en ahol 384 ramból 256-ot kapott a Virtuálgép és ott meg aztán jól eldöcög.. szal Viszta ide Viszta oda , sok értelme nincsen ..
Eddig egy jó Windowst sikerült írnia a Microsoftnak ez a Win2000 és ezt még egy kicsit feltuningolták így lett az XP , ezért én (is) csak 2000/XP-nek szokom hívni... Visztának nincsen igazán nagy átütõ fícsöre amiért érdemes lenne vele szívni...
Csak (unsafe mentes) CLI kodot fogad rendszer. Nem tudsz gonosz (native) binarist hasznlani, ahol hibazhatsz, vagy gonosz kodot irhatsz.
Milyen kernel space - user space mapelesrol beszelsz, ILYEN NINCS. Minden procesznek van egy sajat lap tablazata (vannak kozos lapok). A hardver (MMU) kezeli ezt. Ha new/malloc (brk(), anonimous mmap()) foglalsz memoriat akkor rendszerint meg nem lesz a te processede a lap. Amikor eloszor fer hozza a process az eleteben, akkor kivetel keletkezik, es kernel neki adja azt a lapot, onantol kezdve kernel nem szol bele mit csinal vele (nincs buntetes).
Task valtaskor rendszerint kiurul a TLB, kernel -> user mod valtaskor ill. vissza valtaskor nem, usec alatt van egy mai processoron az ujboli kitoltese (nem kell teljesen kitolteni (Hardware vegzi), akar ns-ekrol is beszelhetnenk), kb. ms-onkent van task valtas-rol dontes (szervernel gyakran ritkabban (10ms)), (minden hoszabb I/O -ra valo varakozaskor is, ugye nincs sok ertelme azt a processt futatni ami adatok hinyaban all).
Tessék. Itt a válasz egy másik cikkre: http://www.sg.hu/cikkek/61221 Egyenértékû, mi? Hulladék MS
Akkor hogy meg egy kicsit bonyolultabba tegyuk a vilagot: Hogyan lehet megoldani, hogy a singularity/midori rendszer alatt fussanak a regi win32-es programok?
A kernel, es az uj os osszes eleme egy folyamatban fut. Minden regi folyamat elindithato egy kulon dedikalt cimterben. Az illesztest egy win32 api-t emulalo dll vegzi, ami hagyomanyos modon linkelodik a regi programokhoz, viszont a modern kernel fele mar uzenetekkel kommunikal. Hasonloan mukodik a wine is. Igy lehetoseg van sebessegcsokkenes nelkul kidobni a winnt kerneleket, kompatibilitasi celbol megtartva a win16/win32/win64 api-kat. Tehat egy kis hack-elessel a singularity/midori alatt is futhat egy win32-es program. Csak a drivereket es az os alatt dolgozo programokat (pl. shell extension-oket, viruskeresoket) kell kidobni. Ha a kernel alatt ott lesz egy hypervisor, akkor az szinte 100%-ban kepes atvenni a mikrokernel alapfunkcioit (cpu es memoriakezeles), tehat maga az os mar tenyleg tisztan managed kodban futhat. A jelenleg is fejlesztes alatt allo java os-ek pl. pont igy mukodnek. (lasd: google android)
Atyaúristen! szinte tapintható a hatalmas tudás itt a fórumon:DD
A Singularity csak egy fejlesztõi projekt, kutatási célból lett kifejlesztve. Kereskedelmi operációs rendszer nem lesz belõle.
A Midori az nem a Singularity, a Midori a Singularity projekt tanulságaira építve lett kifejlesztve.
Úristen, ti ezen a földön éltek? XD
Eloszor is szoftveres process szetvalasztas megoldhato akar basic-ben is, de barmilyen a boundary check-et nyelvi szinten tamogato nyelvnel.
Masodszor az intel cpu-k eseten a process valtas nagyon lassu, mivel sokaig tart a kernel-user valtas es minden valtaskor kiurul a tlb. Ezt ki lehet vedeni egy jobb architekturaval, pl. tagged tlb-vel es gyors syscall-okkal. Viszont ezek tamogatasa reszben hardvert igenyel, reszben nagyon sok munkat. A garbage collector-os os-ek nem szeretik a szettagolt cimtereket. Sokkal konyebb megirni oket egy nagy lapos virtualis cimterben. Lehetseges mashogy is, mivel a singularity tamogatja a szeparalt cimtereket, csak nem kotelezo a hasznalatuk. Azok a process-ek amik egy cimterbe kerulnek, sokkal konnyebben tudnak uzneteket valtani, mivel nem szukseges sem masolni, sem map-pelni a ket cimter kozott. Ez megoldja a mikrokernelek sebessegproblemajat.
"halmozza az amugy is tulterhelt buszt."
JAV: halmozza az amugy is tulterhelt buszra eso I/O keresek szamat.
1. > Boundary check nem OO feature
Kerdes: akkor miert nem BC extension-t hasznalnak k/u-space helyett?
OO-rol mint tipusbisztos nyelvrol volt szo osztalyokba szervezett vedett metodusokkal nem pedig kiragadott bovitmenyrol proceduralis nyelvek compiler-eihez.
Ha az utobbit hasznalod kernel/user-space helyett meg mindig nem garantalt, hogy megoldottal egy lehetseges "invalid access"-t csupan csokkentetted a kockazatat, valamint az tobabbra sem garantalt, hogy egy elore definialt abstract buffer implementaciod-at ha ki akarsz egesziteni vagy fuggvenyeit "felulirni" nem fogsz olyan viselkedesebe beleavatkozni ami a szandekodon kivul szamlalok/mutatok elcsuszasat eredmenyezi. Ha OO-ban egy kulturaltan megirt es a lathatosagi jogokkal esszeruen szervezett metodusrendszerrel implementalod ilyen szoba sem johet.
> 2. Te azt emelted ki, hogy az OO eszkozok tobb memoriat hasznalnak, ami gyakran igaz...
Itt van, hogy mit emeltem ki: "Helyette viszont meg fog jelenni egy masik hatasfokvezteseg, de egy alaposan atgondolt es odafigyelessel elkeszitett objektumorientalt OS-nel a legrosszabb esetben is az 5%-ot nem haladhatja meg!
(Nehogy folytasd a multkori write-onlyt mert itt hagylak. :) )
3. Ha 4k lapokrol beszelunk, 32 bites rendszerrol. Akkor az elso eleres mondjuk 3x tovabb tart, de 1024 eleresre leosztva mar ez nem is latszik.
Ja hat mondjuk egy fuggvenynel, egy processnel es tobbnyire azonos cimtartomanyokra hivatkozva nem pedig tobbezer processznel szanaszejjel tordelve a memoriaban. Es ugye igyekezni kell ezeket elsosorban mind lokalisan a CPU-ban cachelni mert ha tartosan memoriabol olvasgatod a cache tartalmat az tovabb halmozza az amugy is tulterhelt buszt.
Ne komolytalankodjunk legyszi, meg mindig a kernelspace es userspace mappelesnel tartunk terheles alatt es meg mindig ezek buszterheleserol van szo nem pedig "uresjaraton" ciklusszamlalasrol.
Es ujbol kiemelnem: nem az orajel ciklusszam szamit kiragadott fuggvenyeknel szintetikus mikrotesztekkel (mert az olyan lenne mint az univerzum modellezese ket hidrogenatommal) hanem a halmozodott I/O terheles plussz halmozodott mutexek plussz ciklusszam plussz a maradek es mindez eles kornyezetben valodi feladatoknal.
Hmmm. Mikor jövünk már rá végre, hogy az ilyen cégektõl nem érdemes csodát várni? Majd megvesznek valamit, és eladják MS fejlesztésként, szokás szerint. Aki kicsit is belelát a nagy "szoftverfejlesztõ" cégek mûködésébe, meg fog erõsíteni benne, hogy szinte mindent külsõsökkel csináltatnak. Hogy miért, azt nem tudom, valami managerlogika lehet. Egy közgázt végzett kolléga igazán felhomályosíthatna...
1. Boundary check nem OO feature Belepesi pontok megadasa sem OO feature pl. az OO -elotti ADA nyelv is tudott ilyeneket.
2. Te azt emelted ki, hogy az OO eszkozok tobb memoriat hasznalnak, ami gyakran igaz,de nem minidig C++ -nal nagyon minimalis tobblet meg virtualis osztalyok hasznalatakor is. (Tudom hibrid)
3. A lapozas bunetetese minimalis, es NEM OS fuggo. Ha pl. SWAP-et akarsz hasznalni akkor eleg nehez dolgod van nelkule, es meg lassabb lenne. Egy lap elso elerese tovabb tart, mint siman fizikalis memoriat cimezni, leven 3-4 tablazatott kell MMU-nak megnezni, aztan azt ugye cacheli az TLB -ben. Ha 4k lapokrol beszelunk, 32 bites rendszerrol. Akkor az elso eleres mondjuk 3x tovabb tart, de 1024 eleresre leosztva mar ez nem is latszik. Boven 1% alatt lesz. Utanna meg benne lesz (egy jo darabig) a TLB -ben. Es nem mondanam, hogy kernel memoriajat mmapolod ki, Linearaddrest kepzed Physical addressre, ez a lekepzo tabla minden processnel mas lehet.
Memoria foglalas termesztesen ido, de ez elkerulhetetlen.
4. hasonlitsd ossze sysenter/sysexit vs. call/ret utasitasok orajel ciklus szamat.
Úristen a topik képtõl hirtelen megilyedtem hogy a Kóka már ide is beszivárgott !!
> 1. OO nyelv nem csoda szer a gonosz ellen es nem az OO miatt sporhato ki kern/user space.
Hat miert? :)
> 2. nem feltetlen nagy egy OO pradigmat tamogato nyelven irt program memoria igenye, nem kell C#/Java -bol kiindulni.
Komplex szoftverekrol volt szo altalanossagban es OO-rol. Nem indultam ki semmilyen konkret nyelvbol es ha jobban elolvasod amit irtam, pont azt emeltem ki amit cafolni akarsz.
> Baromsag.
1. Mert? 2. Kultura?
> Ha minden aron lassunak akarod beallitani...
Itt alj! Meg mielott elkanyarodnank a lenyegrol. Nem akarok semmit beallitani semminek. Tapasztalatok megosztasarol volt szo nem pedig lelkes rajongasrol. Amiket ott leirtam azokat javareszt magam is kiprobaltam. Ha gondod van vele, akkor fejtsd ki, hogy miert.
> ... akkor, probalkozz egy mezi fuggveny hivas es egy rendszerhivas idejenk osszehasonlitasaval.
Gondolom ezt SMP multitasking mellett, kis blokkmeretnel magas CPU es I/O overhead-nel kepzelted el. Ha igen, akkor az a szazalektartomany nagyjabol valosagot mutatja.
Az a fickó nem kiköpött mása Bill Gatesnek? Tán a fia?!
"Az objektumorientalt nyelvek csak kesobb jelentek meg amelyek megoldast nyujthattak volna a problemaa, de a hardware - es kulonosen a memoria - arak azok tovabbra is az egekben voltak."
1. OO nyelv nem csoda szer a gonosz ellen es nem az OO miatt sporhato ki kern/user space.
2. nem feltetlen nagy egy OO pradigmat tamogato nyelven irt program memoria igenye, nem kell C#/Java -bol kiindulni.
"Az utobbiaknak a kernelspacebol mappelt memoria all a rendelkezesere.
Miert vastagitottam ki? Azert mert ez onmagaban kepes 20-40%-os hatasfokveszteseget okozni."
Baromsag.
Ha minden aron lassunak akarod beallitani a szokvanyos modelt akkor, probalkozz egy mezi fuggveny hivas es egy rendszerhivas idejenk osszehasonlitasaval.
ps: A google altal kifejlesztett android is hasonlo a technikara epul, csak ok egy java varianst hasznaltak es tobb nativ c-s kod van az os-ben, mert kernelnek linuxot hasznaltak es nem irtak hozza egy uj mikrokerneles os-t.
"A rendszergarázda férjen hozzá a rendszerhez konzolokon és beállító paneleken keresztül. De ne buherálja meg file szinten... Ugyanez a programokra is legyen igaz."
Ezt lenne hivatott a hypervisor es a digitalis alairas biztositani. A problema, hogy innentol ha valaki lement egy csaladi kepet, akkor csak addig ferhet hozza amig a kepet keszito programhoz/hardverhez van ervenyes elofizetese. Ha ez lejar, akkor onnantol az ember a sajat adataihoz sem ferhet hozza. Az xbox360 mar ilyen hardvert es hypervisort hasznal. Aki szeretne, hogy miutan a gepe kap egy virust, utanna mar csak a microsoft ceges kulcsaval lehetne hozzaferni az adatokhoz, az mar az uj windows-ban is talalkozhat ezzel a fejlesztessel. Bonuszkent a kod kiszuri az illegalis programokat (pl. open source szoftverek) es a licensz nelkuli multimedias tartalmakat. (pl. letoltott filmek, mp3-ak) Biztos, hogy jo ez nekunk?
"Még rengeteg dolog van természetesen, remélem, a projekt tagjai informatikusok és elõször azt tervezik meg, hogy mit is akarnak megcsinálni, mielõtt elkezdik lekódolni..."
Alapvetoen regi kernel hackerekrol van szo, szoval ertenek hozza. Az alapotlet csak annyi, hogy kis binaris kernel nativ koddal es egy sajat biztonsagos programnyelv, ami nyelvi szinten biztositja, hogy ne lehessen megkerulni a szoftveres vedelmet. Igy nem kell hardveres vedelem es ezert egy nagy cimterben (process-ben) fut minden program. Ennek eredmenyekent a kommunikacio nagyon gyors a folyamatok kozott, ezert egy programot fel lehet epiteni tobb kisebb logikailag szeparalt darabbol is. Ilyen volt a xerox alto es az amigaos is. Az egyetlen ujitas az, hogy a java mintajara maga a programnyelv adja a vedelmet. (nincsennek benne mutatok es minden memoriahozzaferes szoftveresen ellenorzesre kerul) Ez a microsoft fele javaos, amit hivhatnanak akar c# os-nek vagy .net os-nek is.
"Most akkor meg azt mondják cirka 2 év után, hogy hát akkor Vista kuka, és ugorjunk neki egy harmadik változatnak?"
Nem azt mondják. Azt mondják, hogy miközben a kereskedelmi vonal fejlesztése zajlik a megszokott módon, és nem kell aggódni jön a Win7, addig a szürkeállományt ráirányítják egy kisérleti projectre. Egy új megközelítésre az oprendszerek terén. Nem kell aggódni, nem lesz midori a gépeken Win8 elõtt :)
A rendszergarázda férjen hozzá a rendszerhez konzolokon és beállító paneleken keresztül. De ne buherálja meg file szinten... Ugyanez a programokra is legyen igaz.
Megjegyzem, az asztali kiépítésben kevés processzormagot támogató Win leginkább üzletpolitikai döntés, vegyél Windows Server Datacenter Editiont, és az támogat több tucat magot. De igen, ez fontos irány, s mégfontosabb lenne, ha a kedves alkalmazásfejlesztõk is felkészítenék a programjaikat a többprocesszoros környezetre. Tavasszal voltam a Visual Studio 2008 bejelentõ konferenciáján, állófogadás, zsírdudorokat rezgetõ lányok, valósidejû Guitar Hero(t) fejlesztés, meg felhasználói élmény fokozás, meg forgó eszköztár (O.T.: a management eszköztárat ilyen forgó felületen is el lehet érni.. márha sikerül valamit eltalálni rajta:XD) az volt, csak arra az alapvetõ koncepcióbeli váltásra nem sikerült fél szót sem szentelni, hogy emberek, ébresztõ, a számítógépekben mostmár nem egy processzormag van, s ezt az MS fejlesztõeszköz szinten az alábbiakkal támogatja.. Persze nem állítom, hogy nem kínálnak frappáns eszközöket erre a feladatra, csak én fontosabbnak éreztem volna ennek a kidomborítását a vackok helyett. (LINQ fontos, a WPF néhány komponense is meglehetõsen hatékonynak tûnt, mielõtt még valaki leszedi a fejemet.)
Az OS v. egy program könyvtárába pl. még a rendszergarázda se tudjon belépni, annak a teljes karbantartása az installer feladata...
Ezt komolyan gondoltad??? A rendszergazda jobb helyeken az isten, nehogy már ne férhessen hozzá a rendszerhez. Bár ez ilyen MS szokás a Vistában is jelen van.
A Windows alaposan megérett a cserére. A Midori-ban több dologra érdemes lenne koncentráni: - X db CPU támogatása - nem, 2, nem 4, nem 8, hanem elsõ körben mondjuk 1024 db. - Teljesen elkülöníteni a következõ dolgokat: -- OS -- Driverek -- Programok -- Felhasználói adatok Ezeket mind külön könyvtárban kell tárolni, egymást csak engedéllyel lássák, írni csak engedéllyel írhassanak, stb. így nem lenne gond pl. egy uninstall. Az OS v. egy program könyvtárába pl. még a rendszergarázda se tudjon belépni, annak a teljes karbantartása az installer feladata...
Még rengeteg dolog van természetesen, remélem, a projekt tagjai informatikusok és elõször azt tervezik meg, hogy mit is akarnak megcsinálni, mielõtt elkezdik lekódolni...
Az alapvetõen új vezérlõeszköz koncepcionális irányát errefelé látom, persze kompakt kivitelben:
mennyi ideig szoktál gépezni? Én van amikor folyamatosan 4-5 órát. Próbáld meg addig nyújtogatni a karod. Kíváncsi vagyok elfárad-e. (Jah és általában végig netezek, szal "a nem használod végig az egeret" nálam nem ellenérv. Többet használom mint a billentyût)
Vagy lesz ilyen trio mint anno cirka 10 éve, hogy Win98, 2000, XP.
98-at nagyon sokáig használtak mert megszerették az emberek, estünkben ez az XP, aztán 2000-ret a fanatikusok, és akik nem tartottak a driver és update gondoktól...esetünkben ez a Vista....és XP-t meg azok akik tudták mit hoz a jövõ, és igazuk is lett...ez most aaa Midori?
Igen. Múltkor egy másik cikkben írtad elég hosszan, hogy a Vista egy új alapot kapott, végülis az XP-t kivágták a fenébe és nekiugrottak egy új oprendszer írásának...ez a Vista.
Most akkor meg azt mondják cirka 2 év után, hogy hát akkor Vista kuka, és ugorjunk neki egy harmadik változatnak?
Egy kicsit attól félek, hogy habár szerintem a Singularity egy nagyon jó koncepció háziszámítógépes felhasználás szintjén. De lehet, hogy nagygépes sokfelhasználós hálózatos rendszernél meg a mmonolit, vagy max modul rendszerû kernelre épülõ OS lenne jobb. Emléxem az Amiga milyen könnyen indult, meg kicsi erõforrás igénye volt, de aztán ahogy romlott a progik minõsége úgy fagyott minden 10 percben, mionnyuk nem lassította adolgokat, legalább is a Win/DOS-hoz képest mert az még rosszabb volt és igazából a memória védelem hiánya volt az oka, amit azért a késõbbi változatoknál kiküszöböltek.
Na szal amitõl viszont igazán félek az az, hogy a M$ urai úgy gondolják, hogy mivel a Win segítségével kerültek magas pozíciókba, így egyszerûen befékeznek minden új kezdeményezésnek, mert féltik a kis zsíros állásukat.
Na bakter ezér szeretek fórumozni, rögtön jött 1-2 hsz, amik évtizedes homályokat oszlattak az agyamban!;)))
Köszi!;)
lehet nem nagyon használtál érintõképernyõt, de minden nehézkesebben kezelhetõ mint az egér.. lehet hogy nagyobb szabadságot nyújtanak, de pl egy kesztyû: órákon át nem tudod a kezed a levegõben tartani és mutogatni a semmibe, mert fárasztó, még akkor is ha rambótól örökölted a bicepszed. érintõképernyõ: nagyon látványos, iszonyat interaktív, csak úgyanúgy leszakad az ember keze, plusz saját tapasztalat, hogy nap végére olvashatatlanságig összepiszkolódik. úgyhogy amikor olyan volt elõttem, akkor is csak nagy ritkán használtam. a pda-kon nagyon jó, mert úgysem azon írnám a több tíz oldalas doksikat, de a jó öreg egeret én még nem temetném.
A merõben új dolog alatt egyértelmûen a Windows kidobását kell érteni. Ami elavult, az az ablakkezelés például.
Olyan megérzésem van, hogy a Singularity OS mellé egy új beviteli eszközt is kapunk. Az egér már sok tekintetben elavultnak minõsül, a különbözõ kutatóintézetek pedig szépen csendben fejlesztgetik például a kesztyût, amely képes mozdulatokat, gesztikulációt értelmezni. Például egyetlen mozdulattal kinagyíthatunk ablakokat, könnyen lehet zoomolni a két mutatóujjat közelítve/távolítva (kép, böngészõ betûméret). Emlékezzünk csak a Minority Report (Különvélemény) ide vonatkozó képkockáira.
A jövõ hardware elemeit pedig úgy tudom elképzelni, hogy minden eszköz képes saját maga futtatni a drivereit és csak input/output paraméterekkel rendelkezik az OS felé, meg egy verziólekérdezéssel. Megmondja a minimális, gyorsan futó alap kernelnek hogy õ miféle eszköz, milyen beviteli és kimeneti paraméterekkel rendelkezik és milyen gyakorisággal vár frissítést a paraméterekre. Mellé még egy plusz kommunikációs port kell a softwarenek, amelyen képes a saját driverét OS-tõl függetlenül frissíteni. Mennyivel könnyebb lenne az életünk...
Midori ... zõd ... lol ... érdekes névválasztás. Mindenesetre jó lenne többet tudni róla mert ez eddig édeskevés.
A programokat nem eldugja, logikusan rendezi, amit ha ismer az ember, nagyon hasznos dolog a win bárhova káosz és mindent beleszarni a registrybe megoldás helyett. Firefox kilépések anyám gépén mennek linuxon, amikor 10 tap van megnyitva... de a gépben 128mb ram van, én gépemen linuxon még nem lépett ki firefox, viszont vindózon nem az volt a legstabilabb böngészõm :D
Nyitott vagyok az újítások felé :) A hírbõl viszont két dolog jött le: - még nagyon távol van - még a microsoftnál is keresik ennek az új iránynak a helyét..
"Érdekes, amikor megvettem annakidején az Amigáról szóló 1-2 könyvemet, akkor valahogy zéró ismerettel is el tudtam mûködtetni a gépet, pedig akkor még net sem nagyon volt, ahol a felmerülõ kérdéseknek utána tudtam volna nézni, mert nem is kellett."
Azert az amiga az egyseges hardverevel kozelebb alt egy mai konzolhoz. Viszont tenyleg jobban volt kitalalva. Egy hardvervedelem nelkuli realtime mikrokernel volt az os alatt. A midori is pont ilyen, csak a programozasi nyelvet csereltek le bcpl-rol sing#-ra. A bcpl a c elodje volt, kifejezetten kernelirasra optimalizalva. A sing# a c# egy valtozata kifejezetten kernelirasra optimalizalva. A softveres process vedelem es a user modu driverek/rendszerszolgaltatasok is jellemzoi ennek az architekturanak.
A midoriaban az egyik ujitas az, hogy a vedelmet egy objektumorientalt nyelv segitsegevel valositja meg, ugy mint annak idejen a xerox alto gepek, ahol egy kis binaris mikrokernel folott ult egy biztonsagos nyelv, a smalltalk, amiben az operacios rendszer felso szintu komponenseit irtak. (pl. ablakozo, filerendszer, halozati stack) Mindezt egy 8 magos smt-s cpu-n. Ez a forradalmi 1972-es technologia jelentheti a jovot. Szerintem egy kicsit le vagyunk maradva...
Nos ez jól hangzik. Kíváncsian várom, mi lesz belõle. Jó lenne már túllépni ezen az "egy szoftwer mindenek felett" szemléleten. A politikusok ezt elõre menekülésnek mondják. Azaz, ha már sokan utálnak, akkor egy kis csoportunk csináljon valami forradalmian újat, így a párt visszaszerzi a tömegek bizalmát.
Rigidusnak köszönöm az érthetõ hsz.-ét a memóriacímzésrõl. Nem gondolkodtál még el egy könyv írásáról az oprendszerek mûködésérõl?
na ennek a felét se értettem, de elhiszem 8).
akárhogy is, bár nem pártolom az ms-t, de ha csinálnak nekem vmi csicsamentes, kicsi, gyors vindózt, én megsimogatom pista bácsi kopasz fejét...
Urak, mielott tuz ala veszitek egymast az elkovetkezendo 100-150 HSZ-ben:
A Singularity egy teljesen alapoktol ujratervezett es irt operacios rendszer. Nem alacsonyszintu nyelveket hasznalnak a kernel irasara, hanem a C# egy subsetjet, a Sing#-ot ami egy fejlett objektumorientalt nyelv es kimondottan rendszerszoftverek irasara fejlesztettek ki.
A mai operacios rendszerek a memoriat alapvetoen ket fo egysegre osztjak. UNIX-os korokben ezt hivjak kernelspace-nek es userspace-nek. Ez nem valami feature, hanem egy 60-as 70-es evekben alkototott modszer, hogy fizikailag elszeparalja a rendszerszoftvereket a felhasznaloi szoftverektol igy a teljes rendszer hibaturese es biztonsagossaga novelheto.
Az objektumorientalt nyelvek csak kesobb jelentek meg amelyek megoldast nyujthattak volna a problemaa, de a hardware - es kulonosen a memoria - arak azok tovabbra is az egekben voltak. Az objektumorientalt nyelvek - feladattol fuggoen - altalaban tobb rendszereroforrast emesztenek fel, viszont toredeke energiaval lehet fejleszteni, karbantartani oket, nem beszelve a kodujrahasznalhatosagra gazdagabb lehetosegek vannak, igy komplex szoftvereknel a teljes kodmeret toredekere csokkentheto. Ebbol termeszetesen az is kovetkezik, hogy hibalehetoseg is es a karbantartashoz szukseges fejlesztoi garda is csokken.
Azota az objektumorientalt nyelvek is messze jobbak mint akkoriban, ill. a hardware arak is elerhetobb aron vannak, viszont az emberi tenyezo a legnagyobb problema. Ahogy a szamitogepek elterjedtek ugy kialakult a "sok birka egy helyen" hatas. Na ez egy erdekes jelenseg, mert amikor ez koma eleri az embereket, onnettol kezdve nem kepesek az orruknal tovabb latni, csak habozas nelkul mennek a tomeg utan. Olyankor ha valaki megszolal, hogy "emberek, aljunk mar meg egy kicsit gondoljuk vegig ezt ujra" akkor a nagyjabol a 80 szazalek heves kopkodesbe kezd. (tobbek kozott ezert egtem ki es mondhatnam az undor elfog a mai "szamitastechnikatol" vagy "informatikatol")
Magyarul, van egy visszamaradott tomeghiszteria ami ott kezdodik, hogy valaki egyszer azt mondta, hogy: "objektumorientalt nyelvben orultseg kernelt irni, mert a teljes rendszer lassu lesz". Az mar mas kerdes, hogy azota a hardware arak jelentosen csokkentek es a nyelvek is alkalmasak, a lenyeg a birkaoszton. Szemelyes meggyozodesem es tapasztalatom, hogy napjainkban aki ilyet allit az vagy nem tudja, hogy egy operacios rendszer hogy mukodik, vagy nem programozott meg objektumorientalt nyelvben vagy ha igen akkor az egesz emberiseg halas lenne ha abbahagyna.
Es akkor vissza a singularity-re. A hagyomanyos operacios rendszereknel a kernelspace alatt allokalt memoria kozvetlenul irhato a kernel altal, ehhez a felhasznaloi programok nem ferhetnek hozza. Az utobbiaknak a kernelspacebol mappelt memoria all a rendelkezesere.
Miert vastagitottam ki? Azert mert ez onmagaban kepes 20-40%-os hatasfokveszteseget okozni. Ha ugyanezt az operacios rendszert objektumorientaltan keszitjuk el es az egyes szoftverkomponenseket hozzaferesi jogosultsagok szerint az osztalyokba/objektumokba valo szervezes altal izolaljuk el egymastol akkor ez a hatasfokveszteseg megszunik.
Helyette viszont meg fog jelenni egy masik hatasfokvezteseg, de egy alaposan atgondolt es odafigyelessel elkeszitett objektumorientalt OS-nel a legrosszabb esetben is az 5%-ot nem haladhatja meg!
A puffertulcsordulasi problemakat pedig azert szunteti meg, mert az objektumorientalt nyelveknel a memoria allokalas es cimkezeles transzparensen tortenik. Magyarul: nem a programozonak kell puffer-eket cimezgetni meg a szamlalojukat, mutatojukat szinkronban tartani, hanem egyreszt a nyelv tipusbisztos, masreszt pedig annak a programkonyvtarai mar tartalmazzak ezeket es konnyeden, bisztonsagosan felulirhatok is, ha valamilyen specialis viselkedesre akarjak azt birni (pl.: bizonyos elemek szurese a pufferbol, dinamikus meretezes, stb). Ezert van az, hogy nem fordulhat elo, hogy valamelyik puffer mutatoja tulcsordul es ilyenkor olyan cimtartomanyra mutathat ami mar egy masik program altal le van foglalva es akar mas jogosultsaggal fut.
A nemi szervemet mertem volna feltenni tétnek, hogy a szádból ma el fog hangzani a "nevetséges" szó... Nagyon unalmas, és sablon szöveg . Egy saját gondolatod volt már?
Meglátjuk, minden esetre én lennék a legboldogabb ha megszabadulnánk ettõl a Windows dologtól...
Engem a pingvinezéssel kapcsolatban csak az zavar, hogy sajna annál sokkal nagyobb tudás kell a Linux optimális mûködtetéséhez, mint amivel én rendelkezem. Mondjuk úgy sokkal több annál, mint ami egy dúrván 150 oldalas használati utasításban összefoglalható.
Érdekes, amikor megvettem annakidején az Amigáról szóló 1-2 könyvemet, akkor valahogy zéró ismerettel is el tudtam mûködtetni a gépet, pedig akkor még net sem nagyon volt, ahol a felmerülõ kérdéseknek utána tudtam volna nézni, mert nem is kellett. Hát azóta ennyivel hülyébb lettem!;)))
Már megint új alapok? Nekem nem tetszik ez az új alapok dolog valahogy :) Ja és duke: Remélem, adja majd az ég, hogy nem Linux-alapú rendszerük lesz. Habár elég szimpatikus a pingvin és szemben a Winnel még szeretni is lehet, azért ne õ irányítsa már a rendszeremet. Hát mi az, hogy ha nincs elég lemezterület, nem is enged be? Mi az, hogy szerkesztgetni kell fájlokat, ha be akarok állítani egy csicsát? Mi az, hogy a programjaimat valahova eldugva rakja el, és csinál magának vagy 20 rendszermappát a gyökérre? És egyáltalán mik azok a Firefox kilépések netezéskor?
Hát ha megnézed valamelyik linket, akkor látod, hogy ez egy mikrokerneles OS-rõl van szó, a Linux meg alapvetõen nem olyan.
Szerintem ez egy jó koncepció, skálázható, gyors, könnyen az eltérõ hardverekhez alakítható OS-t lehet csinálni, vagy is nagyjából az ellentétét annak ami ma a Win-t jellemzi.
Ráadásul saját fejlesztés, szal végre valamit letesz a M$ az asztalra. Mondjuk talán csak az a ciki, hogy ilyen OS-t ezelött 25 ávvel már megalkottak.
Na ez ami nevetséges... a UNIX nem a Multics alapjaira épült, hanem a Multics hiányosagaiból tanult. És néhány apróságon kívül amely a régi korlátolt hardverbõl ered, nem hinném, hogy jobban meglehet csinálni. A modern OS-ek nem javíthatnak rajta csak bõvíthetik olyan dolgokkal amelyek akkor nem léteztek még. A többi hülye duma.
Ez nagyon érdekes lesz ha tényleg így lesz. Lehet kukázni minden eddigi programot, drivert. (?)
helyesírást minek? értelmezõ kéziszótárt inkább :/
"miszerint a teljes Windows-koncepciót félreteszik, megvizsgálva, hogyan is festene egy ilyen új platform. "
Valojaban a microsoft semmi mast nem csinal,mint midori neven kiad egy sajat Linux disztribúciot.Mert belatak vegre,hogy keptelenek egy mukodo oprendszert irni,pedig mar jo ideje probalkoznak.Osszeszedik majd a vilaghalon talalhato ingyenes linux programokat,es nagy penzert eladjak majd a hulyeknek,akik beveszik,hogy tenyleg egy szuper uj oprendszerrol van szo.
Informatika és tudomány
meg mindig a kernelspace es userspace mappelesnel tartunk terheles alatt es meg mindig ezek buszterheleserol van szo nem pedig "uresjaraton" ciklusszamlalasrol.
. Egy saját gondolatod volt már? 
Habár elég szimpatikus a pingvin és szemben a Winnel még szeretni is lehet, azért ne õ irányítsa már a rendszeremet. Hát mi az, hogy ha nincs elég lemezterület, nem is enged be? Mi az, hogy szerkesztgetni kell fájlokat, ha be akarok állítani egy csicsát? Mi az, hogy a programjaimat valahova eldugva rakja el, és csinál magának vagy 20 rendszermappát a gyökérre? És egyáltalán mik azok a Firefox kilépések netezéskor?
