Portál AbcLinuxu, 19. prosince 2025 23:17
Jako studentská zábava fajnPřipomíná mi to jeden projekt. Nějakej finskej studentík, jak on se jmenoval…
:D přesně to mě napadlo :)
4.8.2009 19:00
Marek Bernát | skóre: 17
| blog: Arcadia
Nie som linuxový kunsthistorik, ale nebolo to tak, že pred linuxom nič podobné nebolo (poriadny free operačný systém)? Dnes už ten poriadny OS máme a hoci nemám nič proti novým prístupom, to práve naopak (mikrojádra, objektovél/funkcionálne kernely, ... len pekne sem s nimi), tak začína byť celkom zrejmé, že linux je asi nedostižný (čo asi týka OS podporujúci všemožný hardvér a pod.).
Nebo možná HelenOS vznikl dřív než Minix 3?
Prvni radky kodu HelenOSu byly napsany v roce 2001 a prvni oficialni release byl v roce 2006. Jak je na tom Minix 3 nevim.
A vůbec: jestli tohle čte nějaký z lidí od HelenOSu, mohl by osvětlit, co mají s Minixem 3 společného, v čem se liší a tak?
Trunk verze nemaji spolecneho nic, az na to, ze jsou obe zalozene na mikrojadru. Lehke srovnani viz reakce na predchozi prispevek. V Networking branchi jsme si pujcili dva ovladace sitovek z Minixu, ale zrejme je budeme muset napsat znovu.
m světem. Z toho, co jsem tak letmo pochytil na titulní stránce HelenOSu, mám sice dojem, že by vývojáři možná udělali líp, kdyby se přidali k Minixu, ale třeba jdou na matfyzu trochu jinou cestou, kdoví.
To by byl ale krok zpatky, alespon z pohledu kernelu.
Ten Minixovy (Minix3) jeste nedavno nedokazal vyuzit virtualni pamet (stabilni verze to stale neumi), nema podporu SMP, v podstate bezi jen na 32-bit x86 a naslo by se toho jeste vic. HelenOS naproti tomu ma docela dobre rozvinuty microkernel, virtualni pamet mel jiz pred 0.2.0 (coz je rok 2006), SMP podporuje asi od roku 2002 a bezi "skoro" na vsem.
V userspacu ma Minix3 vyhodu, protoze je do urcite miry kompatibilni s POSIXem a tudiz nema takovy problem s nedostatkem aplikaci.
4.8.2009 21:39
Marek Bernát | skóre: 17
| blog: Arcadia
staré struktury je třeba opouštět a hledat nové cesty
Súhlas. Ale OS bez aplikácií, to musí byť ťažké :-/
Pro to není od roku 2001 (?) ještě ani jedna aplikace? Co takhle systém dostat víc do povědomí tím, že se aspoň jedna napíše. Berte to jako názor laika, možná to nejde ... Třeba textová kalkulačka, kvůli které to aspoň bude stát za to rozjet v tom Virtualboxu. Rychlá instalace z jiného OS a boot z usbčka n. FDD by nebyl od věci. Třeba může každý výsledek od 1 do milónu okomentovat nějakým vtipným komentářem - statistickým údajem. Komentáře vám budou psát a dodávat fanoušci, tak zjistíte, kolik jich máte.
No ale vzdyt my mame nekolik malo aplikaci. Zkuste treba /app/tetris.
Nicmene psani aplikaci neni momentalne nas nejvetsi problem ani priorita.
5.8.2009 16:22
Marek Bernát | skóre: 17
| blog: Arcadia
Ja to určite neskôr vyskúšam
To je pochopiteľné a ja vám držím palce, nech je z toho nový a lepší linux Len problém je, že je to začarovaný kruh: aby išiel vývoj rýchlejšie dopredu, systém sa musí dostať do povedomia používateľov a programátorov. A bez aplikácií sa to stane asi dosť ťažko. Ten fínsky študentík to v tomto ohľade mal strašne jednoduché a byť Vami, tak ma to trochu štve A keď sme pritom (neviem, či sa to tu niekde riešilo, ak áno, poprosím link na komentár), je veľmi veľký problém pridať nejaký translačnú vrstvu *nixových systémových volaní do tých HelenOSových? Prípadne (a lepšie), je realizovateľné napísanie kompilátoru, ktorý bude využívať vašu libc a pomocou ktorého by sa dali skompilovať bežné *nixové programy (samozrejme okrem tých, ktoré explicitne volajú kernel mimo libc, tam asi nič iné ako úplný prepis programu nie je alternatíva)?
Tak treba ten tetris je "trochu" prizbusobeny BSD tetris, ktery si muzete nainstalovat treba v Linuxu. Z toho je videt, ze do urcite miry se aplikace portovat daji. Nas souborovy system trochu pripomina POSIX, takze by to zas nemuselo byt tak tezke. Horsi je, ze neimplementujeme treba signaly.
Teoreticky by bylo mozne mit nekolik verzi libc (~personalit) a POSIXove aplikace linkovat s POSIXovou libc a nativni HelenOS aplikace s nativni libc atp. Ale to jsou zatim jen rane uvahy.
Tady někdo poobědval vtipné kaše, že?
Text takového rozsahu by v tvém případě jistě vyšel jako článek...
Ne. Článek musí mít nějakou minimální délku.
...také ne pro mrzké zisky jako někteří jiní zde.
Mohu vědět, kdo tu píše pro mrzké zisky?
Jinak k věci: k čemu to jako bude dobré?
Muzete to treba pouzit jako operacni system Pridame vim, a muzete to pouzivat treba k editaci a uchovavani textovych dokumentu na platforme dle vaseho vyberu. Pridame networking a muzete to pripojit k siti a provozovat na tom nejaky jednoduchy web server. Nebo si naprogramujete tu killer aplikaci sam a strcite to do cerne krabicky a treba to i nekomu prodate...
Jako studentská zábava fajn,
Proc zrovna jako studentska? Vyvoj HelenOSu je urcite zajimavy i pro ty, co uz studenty nejsou (a treba ani nikdy nebyli).
ale existuje nějaký reálný pádný důvod (bude to dřív než Hurd, má to extrémní výkonový potenciál,...), proč to používat?
Bude to drive ci pozdeji, uvidime. Samozrejme ze to ma extremni vykonovy potencial - napr. kdyz pustite nekolik paralelnich /app/tester loop1, tak to za chvili extremne roztoci vetraky na plny vykon. Spis bych ale hledal jine duvody, proc se HelenOSem zabyvat - treba jestli ma citelny a srozumitelny kod, jestli ma zajimavy design a jestli je stabilni a zda ho kazda chybka slozi na kolena.
Muzete to treba pouzit jako operacni system
Skvělé! Jenom teda operační systém, na němž nejsou aplikace, je obvykle dost naprd operační systém.
Proc zrovna jako studentska? Vyvoj HelenOSu je urcite zajimavy i pro ty, co uz studenty nejsou (a treba ani nikdy nebyli).
Jasné. Já akorát na webu četl, že je to vyvíjeno na UK.
...treba jestli ma citelny a srozumitelny kod, jestli ma zajimavy design...
Ha! To mě napoprvé nenapadlo, dobrý nápad. Beru.
Na vete "Cílem projektu HelenOS je vytvořit plně použitelný OS." sme sa s kolegami tiez celkom dobre pobavili. A hned nasledujuca veta "HelenOS je charakteristický dobrou přenositelností (beží na sedmi různých architekturách) a podporou více procesorů (SMP)." je tiez hodna obdivu. Vskutku zaujimavy OS; este par rokov vyvoja a dobehne aj Hurd.
Jsem rád, že jste se pobavili. My se s kolegy v práci taky rádi pobavíme . Když prof. Tanenbaum psal MINIX, jeho cílem bylo vytvořit učební pomůcku. Když Microsoft psal Singularity, chtěli si ověřit princip operačního systému napsaného v managed kódu, nechtěli ho prodávat. Cílem Open Kernel labs je dodávat OKL4 jako mikrokernel, nikoli jako operační systém. Takže ta věta říká dvě věci: chceme, aby to bylo reálně použitelné (to, ač vás to možná překvapí, není vždy cílem) a druhá je, že to má být kompletní operační systém (to taky není zřejmé). Navíc už se našlo pár lidí, kteří si mysleli, že HelenOS je Linuxová distribuce.
Co se týká přenositelnosti, většina hoby operačních systémů běží pouze na Intelu (vč. MINIXu a Hurdu) a SMP také nepodporují (protože jsou to vesměs výtvory jednoho autora, pro kterého něco takového byl příliš velký luxus. Mám na mysli systémy jako MINIX, Haiku, Syllable, Visopsys, SPAD, QNX Neutrino a další... S Linuxem nebo BSD se nechceme a ani nepotřebujeme srovnávat (zatím )
Dohonit Hurd v počtu podporovaných aplikací bude poměrně obtížné, vzhledem k tomu, že HelenOS není UNIX-like systém a nelze tak na něm spouštět UNIXové aplikace bez úprav. Na druhou stranu Hurd by se musel hodně snažit, kdyby chtěl HelenOS honit co do počtu podporovaných platforem. Kromě toho Hurd se v posledních letech téměř nevyvíjí a chybý mu jasný směr, takže jakýkoliv operační systém, který se vyvýjí ho musí zákonitě dřív či později předhonit.
neskutecna arogance od cloveka ktery nic podobneho nikdy nedokazal (predpokladam)
proc vlastne vyvijite dalsi OS, ktery je jiny nez ostatni?Ne že bych měl s HelenOSem něco společného, ale odpověď se přímo nabízí: protože můžou! Proč Microsoft vyvíjí Singularity/Midori (a přetáhl na to člověka od Coyotosu)? Proč se Andy Tanenbaum rozhodl udělat z Minixu 3 reálně použitelný systém a dostal na jeho vývoj grant? Protože bez výzkumu bychom byli pořád na stromech. Jedna věc je vývoj a výzkum operačních systémů, programovacích jazyků, algoritmů, a tak dále a tak dále, tady jste sakra přestřelil, druhá věc je tisíc a jeden přehrávač mp3 nebo podobné tic tac toe projekty, tam si občas sám klepu na hlavu, o co komu vlastně jde. No nic, knížka volá
4.8.2009 21:56
Marek Bernát | skóre: 17
| blog: Arcadia
bychom byli pořád na stromech.
Alebo dokonca na orientovaných cyklických grafoch. Bŕŕ.
Tedy zprava o dalsim ziliontem OS, jehoz vyvoj mozna ani nebude trvat dele nez vyexpiruje domena projektu...me tyhle zpravy frustruji. Autori budou bezpochyby odbornici, ale nebylo by lepsi, kdyby se pripojili k existujicim projektum nez plytvali sve drahocene sily na dalsi variantu varianty OS?
Doba trvani projektu - od roku 2001 - by Vam mohla napovedet, ze s nejvetsi pravdepodobnosti s jeho vyvojem jeste jen tak neskoncime. Stejne tak soucasny trend, kdy se nam pomalu ale jiste dari ziskavat nove vyvojare (a to nejen z MFF UK), vypovida o tom, ze jsme spise na vzestupu nez-li na ceste opacnym smerem.
Ackoliv jiste prehanite, k tomu ziliontemu OS bych rad dodal, ze HelenOS ma nekolik vlastnosti, ktere napr. u mikrokernelovych OSu jen tak nenajdete: velice slusnou podporu procesoru sparc64 (ze vsech OSu je lepsi uz jen Solaris, Linux a OpenBSD) nebo dynamicke linkovani (zatim v jedne z nasich branchi).
Navic, kdyz pisete servery pro mickrokernelovy OS, tak zjistite, ze to neni vubec zadna sranda a v duchu se proklinate, ze misto mikrokernelu nebastlite nejakou monolitickou rychlokvasku, kterych je opravdu spousta. To znamena, ze pri teto cinnosti narazite na problemy, ktere nemaji obecne zname/prijate reseni a razem se stavate prukopnikem. My jsme na toto narazili napr. pri navrhovani a implementaci VFS a celeho systemu souboru.
ten duvod je velice jednoduchy. Pri delani editoru nebo OS neni treba mit inzenyrsky cit. Neni potreba se zabyvat s interfacemi (modularitou), Jenom par lidi ma ten talent neco takoveho uhodnout a pote take implementovat.
Vyrobci os a nebo editoru takove problemy nemaji. Interface si stanovi sami a nemusi se nikomu zodpovidat. A prave chybejici schopnost myslet modularne zabranuje tomu, aby se vsichni tio lide spojili a delali na jednom projektu. Kazdy vidi ty sve interface a nastavi je ve svem projektu tak chybne, ze nikdo nemuze pomahat, aniz by byl seznamen s tim 'celkovym'.
Linux, bsd a vsechny tyto podobne systemy se mohly vubec alespon trochu rozvinout, protoze Thompson, Ritchie a Pike ty interface navrhli tak, jak to ma byt. A ti dnesni se maji alespon neceho drzet. Ale jakmile se to dostalo do desktopu a narostl pocet vyvojaru a tim automaticky pocet tech, kteri na tu 'modularitu' nemaji, nastavji problemy A tito lide dnes sedi jiz na dulezitych mistech , kde dokonce rozhoduji a vysledky vidime - posledni hit byl ten nesmysl s tim mono do debianu, aby se mohl nastartovat nejaky pitomoucky program, ktery to potrebuje.
5.8.2009 00:52
Marek Bernát | skóre: 17
| blog: Arcadia
Toto je samozrejme tak dementný príspevok, že skoro ani nemá zmysel reagovať. Pri OS netreba mať cit? Vy poznáte niekoho schopného navrhnúť poriadny kernel? Takých ľudí je sakra málo. A Váš príklad s *NIXom je tiež mimo: je to jeden veľký a dnes už archaický bordel a kernel môže vyzerať niekoľkonásobné lepšie (*NIX "architektúra" spočíva na monolitickom prístupe + moduly a všetko sa to prasí tam. Preto v posledných rokoch v Linuxe začali objavovať Ameriku a zistili, že kopa vecí sa dá presunúť do userspacu (napr. FUSE, ale nie len)). Ak to porovnáte s čistotou mikrojadra, tak je to asi niekde inde Sám sa v týchto veciach veľmi nevyznám a klaniam sa pánom v Bell Labs a ďalším, za to, čo tu máme, ale vývoj rozhodne nezastal pred 50 rokmi
Pokud vim to nekritizoval ale slusne se ptal, diky tomu ze se tento clovek zeptal, jsem se od skutecnych odborniku dozvedel pro mne velice zajimave informace. Tak uz sakra VSICHNI PRESTANTE S TIM ODSUZOVANIM!
Byl jednou jeden programátor sloužící na dvoře válečníka Wu. Ten se jednou programátora zeptal: "Co je jednodušší navrhnout, účetní program, nebo operační systém?" "Operační systém", odpověděl programátor. Válečník se velmi podivil. "Účetní program je nepochybně triviální ve srovnání se složitostí operačního systému", řekl. "To ne", odpověděl programátor, "když se navrhuje účetní program, programátor funguje jako prostředník mezi lidmi s rozdílnými názory na to, jak má program fungovat, jak mají vypadat výstupy a jakým daňovým zákonům má program odpovídat. Naprotitomu operační systém není omezen vnější podobou. Při jeho návrhu se programátor snaží nalézt nejjednodušší harmonii mezi strojem a představami. Proto je jednodušší navrhnou operační systém." Válečník přikývnul a usmál se: "To je všechno hezké, ale co je jednodušší odladit?" Na to programátor neodpověděl.
Jedna se o cca 30 syscallu, z nichz velka cast je HelenOS specific IPC a zbytek slouzi pro ovladani adresoveho prostoru ulohy, vytvareni threadu a novych tasku, a podobne veci. Z toho je videt, ze jadro toho samo o sobe zas az tak moc neposkytuje a veskera buisness logic je tedy implementovana pomoci serverovych tasku jako je napr. VFS. S temito tasky se potom komunikuje prave pomoci onech IPC syscallu.
Pokud jde o rozhrani nabizene nasi libc, tak ta je do velke miry specificka (napr. funkce pro praci s UTF8 a UTF32). Cast libc je wrapper kolem sluzeb nabizenych VFS serverem a do urcite miry se podoba souborove casti standardu POSIX, ale slovo kompatibilita je v tomto pripade prilis silne.
Na jadro mame kernelove testy, ktere se daji pustit z kconsole pomoci test * (musi byt ale v jadre zakompilovany). Na userspace mame program zvany tester (/app/tester), ktery proveruje funkcionalitu ruznych casti systemu z pohledu uzivatelske ulohy. Nicmene to, zda system vubec nabootuje a zda se v nem daji uspesne provozovat operace se soubory je take docela dobrym ukazatelem stability
Tak jsem se seznámil s telefonním IPC, pročetl kód připojující kořenový systém (od initu přes libc až do serveru vfs) a musím říct, že to je fakt makačka.
Zatímco monolitické jádro zavolá aplikace jednou z mnoha služeb a pak si jádro věc celou ukutí samo, tak tady aplikace zavolá knihovní funkci a ta se pak skrze jádro dohaduje se serverem jak bába na tržišti (opcode, velikost argumentu, obsah argumentu). Jakou to má proboha režii? Vždyť se na každý ipc_data_* musí dvakrát přepínat kontext (aplikace → jádro → server) a to se děje pro každý argument služby serveru dvakrát (velikost a data). Už chápu, proč v tak rané fázi umíte SMP :D
Mimochodem zkusil jsem cat /dev/con0 a všechny console se zasekly. Tak jsem chtěl zabít cat z jaderné konzole, jenže ve výpisu úloh ani vláken nebyl (navíc jsem nezjistil, jak pozastavit scrollování). Jenže příkaz kill nějak není. Asi bych si to musel přes ipc domluvit s jádrem (po nastudování zdrojáků). Je to tak?
Zatímco monolitické jádro zavolá aplikace jednou z mnoha služeb a pak si jádro věc celou ukutí samo, tak tady aplikace zavolá knihovní funkci a ta se pak skrze jádro dohaduje se serverem jak bába na tržišti (opcode, velikost argumentu, obsah argumentu). Jakou to má proboha režii? Vždyť se na každý ipc_data_* musí dvakrát přepínat kontext (aplikace → jádro → server) a to se děje pro každý argument služby serveru dvakrát (velikost a data). Už chápu, proč v tak rané fázi umíte SMP :D
Ale ne, SMP jsme uz umeli driv nez jsme vubec nejaky userspace meli. Mate pravdu, ze posilani zprav ma nejakou rezii. A to jste jeste neprozkoumal tu cast mezi VFS a FAT serverem. Pred ipc_data_* vetsinou asynchronne posleme jeste nejakou jinou zpravu, ktera oznacuje zacatek requestu a pripadne jeste nese nejaky naklad. Diky tomu, ze to je asynchronni ale nedojde k prepnuti do serveru a zpet, maximalne se prepne na jiny fibril a pripadne se uspi cely thread pri cekani na odpoved. Trochu jsem neporozumnel tomu jak pisete, ze se to prepina pro kazdy argument sluzby serveru dvakrat. Nektere sluzby VFS serveru ipc_data_read/write() vubec nemaji, a to dvakrat mi take prijde podezrele.
Mimochodem zkusil jsem
cat /dev/con0a všechny console se zasekly. Tak jsem chtěl zabít cat z jaderné konzole, jenže ve výpisu úloh ani vláken nebyl (navíc jsem nezjistil, jak pozastavit scrollování). Jenže příkaz kill nějak není. Asi bych si to musel přes ipc domluvit s jádrem (po nastudování zdrojáků). Je to tak?
Pustil jste ten cat z /dev/vc0? Ocekaval bych, ze to zasekne ten vc, ze ktere jste to poustel a ten, ktery byl uveden jako parametr. U ostatnich bych cekal, ze to pujde normalne dal. V kazdem pripade bych to oznacil za bug, ktery je potreba opravit. Obecne lze rici, ze podobne problemy jsou zpusobeny "nedostatkem" fibrilu, ktere by nekde po ceste od aplikace pres VFS a DEVFS do console mohly vyridit nejaky dilci ukol.
To ze jste nevidel ulohu cat je logicke, protoze se jedna o built-in command bdsh, takze by bylo potreba zabyt jeden z bdsh tasku. Toho lze prozatim docilit z kconsole nejak takto:
call1 generic/src/proc/task.o:task_kill <cislo tasku>
Na 64-bit kernelech je potreba data call2 a jako druhy argument 0. Otazka ale je, ktery z tasku by bylo potreba zabit, aby se to zase rozebehlo a jestli by to takto vubec slo resit.
Pred ipc_data_* vetsinou asynchronne posleme jeste nejakou jinou zpravu, ktera oznacuje zacatek requestu a pripadne jeste nese nejaky naklad. Diky tomu, ze to je asynchronni ale nedojde k prepnuti do serveru a zpet, maximalne se prepne na jiny fibril a pripadne se uspi cely thread pri cekani na odpoved. Trochu jsem neporozumnel tomu jak pisete, ze se to prepina pro kazdy argument sluzby serveru dvakrat.
Jde o to, že u POSIXu předám všechny parametry na jeden syscall, tak tady se posílá každý parametr samostatným voláním.
Třeba mount() v libc pošle opcode VFS_IN_MOUNT (první přepnutní) a čeká, jestli server (druhé přepnutí) jej přijme, nebo odmítne (ENOTSUP). Pak odešle další argument a tak dále. Tím neříkám, že vždy je komunikace takto synchronizována potvrzováním.
a to dvakrat mi take prijde podezrele.
Moje chyba. Viděl jsem, že klient odesílá délku i obsah argumentu jednou funkcí, ale server si je čte zvlášť. To asi přenáší najednou (pokud se nezaplní buffer).
Pustil jste ten cat z /dev/vc0? Ocekaval bych, ze to zasekne ten vc, ze ktere jste to poustel a ten, ktery byl uveden jako parametr.
Teďka to zkouším znovu ostatní vc zůstaly fungovat. Třeba mám rozbité qemu, protože mi tehdy po nějaké době padl X server :(
Jde o to, že u POSIXu předám všechny parametry na jeden syscall, tak tady se posílá každý parametr samostatným voláním.
Aha. Je potreba rozlisovat mezi POSIXem jako normou a monolitickym kernelem, kteremu muzete poslat vsechna data najednou pomoci syscallu. Vy tomu nasemu libc mount()u predate take vsechny parametry najednou, ale on ten pozadavek musi rozsekat na mensi kousky. Take bychom mohli vsehna data dat do jednoho velkeho bufferu a poslat je VFS pomoci ipc_data_write(), ale proste to tak nedelame. Ten mount urcite neni nejak zasadni pro vykon. Kdyz si vezmete takovy VFS_IN_READ, tak to funguje take tak, ze se nejdrive posle uvodni zprava a potom nasleduje ipc_data_read(). Zde ma toto rozdeleni opodstatneni, protoze ta druha zprava se primo preposle cilovemu fs (treba FAT), ktery na ni odpovi primo. Takze jednim z duvodu pro takoveto cleneni na subrequesty je flexibilita a nutnost ruzne casti toho requestu forwardovat dalsim sluzbam (coz je naopak vyhodnejsi nez posilat uplne novou zpravu.)
Moje chyba. Viděl jsem, že klient odesílá délku i obsah argumentu jednou funkcí, ale server si je čte zvlášť. To asi přenáší najednou (pokud se nezaplní buffer).
To je trochu jinak. Klient posila serveru blok pameti urcite velikosti. Server se musi rozhodnout, zda se mu ta velikost libi, nebo zda prijme blok mensi. Takze to probiha ve ctyrech krocich:
Teďka to zkouším znovu ostatní vc zůstaly fungovat. Třeba mám rozbité qemu, protože mi tehdy po nějaké době padl X server :(
Super, prvne jste me vydesil
Opravdu koukam, ze to maji na svedomi cesi (kolik uz sme toho svetu dali a nemame z toho nic, ze - ale to je zase jina pisnicka)
Dozvedel jsem se to jen tak, ze jsem si precetl jmena autoru na jejich (anglicke) homepage. Myslim ze zminka ve zpravicce by nikomu neuskodila a naopak by spoustu lidi urcitym zpusobem potesila, ze i presto co se deje a jak tu s nama korporace v cele s modrym ptakem cvici, tu stale mame neskutecne chytre hlavy, experty, kteri delaji projekt takoveho rozsahu PRO DOBRO VSECH ne pro vlastni zisk.
Timto chci vyjadrit vsem vyvojarum muj respekt a dik.
5.8.2009 00:29
thingie | skóre: 8
kvuli tomu ze jsem se zminil o modrych ptacich, utocite na mou osobu protoze si myslite ze jsem sympatizant s rudochy? Zminil jsem je jen proto ze jsou u koryt nejdele ( po 89.) Kdyby tam byli oranzovi sasci, nebo cerveni, bylo by to UPLNE stejne, mily pratele.
Vysvetleni pro jednodussi ctenare: na barve nezalezi, je uplne jedno jestli je to modra, oranzova nebo ruda. Tito saskove jsou jen sproste loutky.
prestante o tomto polemizovat a pokouset se urazet kohokoliv, kdekoliv, ano - ani na internetu ne.
Takže zpátky k operačnímu systému HelenOS 0.4.1_32bit iso ve virtualboxu:
Booting 'HelenOS' root (cd) Filesystem type is iso9660, using whole disk kernel /boot/kernel.bin [multiboot-kludge, loadaddr=0x108000, text-and-data=0x7c634, bss=0x0, entry=0x108068] module /boot/ns [Multibvoot-module @ 0x185000, 0x10ddf bytes] module /boot/boot [Multibvoot-module @ 0x196000, 0x1020c bytes] module /boot/devmap [Multibvoot-module @ 0x1a7000, 0x116ae bytes] module /boot/rd [Multibvoot-module @ 0x1b9000, 0x103d2 bytes] module /boot/vfs [Multibvoot-module @ 0x1ca000, 0x14640 bytes] module /boot/fat [Multibvoot-module @ 0x1df000, 0x17a71 bytes] module /boot/loader [Multibvoot-module @ 0x1f7000, 0x1a969 bytes] module /boot/initrd.img [Multibvoot-module @ 0x212000, 0x206000 bytes] SYSENTER/SYSEXIT not supported. System halted.
ozvěte se za dalších 10 let, až to bude shopné bootnout alespoň do příkazové řádky ... Mimochodem, kdo z komentujících to zkusil pustit ?
Hm a vy se zase ujistete, ze reportujete problem HelenOSu a ne problem VirtualBoxu, jako v tomto pripade.
Actually this is not a bug but a feature. 
Chodí to v některém z emulátorů (qemu .. ?), nebo se to musí pouštět "na holém železe" ?
Chodi to v Qemu, Bochsu, VMware... Kdyz pustite amd64 verzi na virtualboxu, tak to pujde taky. Kdyz z HelenOS/ia32 odmaznete ten check na ten SYSENTER, tak to bude take normalne fungovat.
Kdyz pustite amd64 verzi na virtualboxu, tak to pujde taky.Ale musel jsem zapnout Povolit VT-x/AMD-V, jinak jsem skončil s
4.8.2009 15:57
4.8.2009 16:27
4.8.2009 19:57
4.8.2009 19:17
64 bit long mode not supported. System halted.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.