Názory k článku
Unununium

Skoro mi to přijde jako redesign Smalltalkovských konceptů... :o))) V moderním hávu rozhraní a modulů, ale přeci. Což ovšem neznamená, že je to špatný nápad. Ale přeci jen bych zkusil trošku jiný jazyk...

Na strance se pise, ze se snazi implementovat unununium jako userspacovy proces na linuxu --- takze z toho nakonec bude neco jako corba :-/ Kernelspacove drivery tam maji taky, ale vyvoj kernelspacu ukoncili asi pro prilisnou slozitost.

S hlavnou temou clanku to sice velmi nesuvisi, ale aby sme uviedli veci na spravnu mieru... TAI – UTC = 33 s [http://www.bipm.org/en/practical_info/news] a nie spominanych 32 (ach, ake to pekne cislo :) ).

S tím časem je to vůbec jen taková onanie. Vážně si někdo myslí, že za 30 let se bude TIME uchovávat v 32bitovém integeru?

Ale jistě, výjimky budou.

Jen kvůli tomu není potřeba navrhovat nový OS a v tomto článku to tak zdůrazňovat. Ostatně IMHO stačí zkompilovat Linux (a glibc) na 64bitovém procesoru a je to. Pokud ta hodnota 64bitová v současných jádrech už není (i při kompilaci pro IA32).

Prostě onanie, tohle je prkotina, kterou vyřeší každý středoškolák.

K tomu, aby se na definici času mohl 32bitový integer používat trvale (je to totiž standardizované), stačí, aby se jednou za 30 let změnila definice tohoto integeru - nějakou dobu by byl unsigned, pak signed, pak by se změnil čas pro počítání počátku a byl by opět unsigned atd.

Standardizované? Já tedy žiju v přesvědčení, že standardizované je, že k ukládání těch hodnot se používá typ time_t (mimochodem, na svém systému mám sizeof(time_t) == 8, takže podle autora článku nemám unixový systém) a třikrát běda tomu, kdo by si myslel, že je k tomu určen long, int nebo dokonce int32_t…

Spíš je problém s binárními datovými formáty a komunikačními protokoly, které počítají natvrdo s 32-bitovými hodnotami. Třeba time a de facto i NTP. Ty budou muset být včas nahrazeny.

jen misto Moduly pouzivaji Python. Skoda, ze Oberon odumira. Jak se rika nic noveho pod sluncem. Bych si rypnul. O neco podobneho se Msofti snazi uz furu let, a mam pocit, ze u byla tak pred pul rokem zpravicka o os v c#

COM, COM+, WebServices, RPC, CORBA a ja nevim co jeste... myslenka je porad jedna aporad nedotazena aspon do rozumneho "bezneho" pouzivani...

Ohledne te CORBY bych se trosku ohrazoval, ta je trochu o necem jinem nezli je nejaky operacni system zalozeny na pythonu...

Ja ale nemluvil o OS, ale o IPC... a je uplne jedno jak ho nazvete, podstatne je pohodli pro programatora, narocnost na systemove zdroje, podpora ze strany OS a mira abstrakce, kterou poskytuje...

Ehm... nechci rýpat, ale nastíněná převratná koncepce se ve světě výpočetní techniky používá už nejméně 40 let. Říká se tomu úloha (job) a skript (scénář, dávka,...). Oceňuji, že si všimli toho, že v GUI tato koncepce zatím silně kulhá, ovšem je to takový objev Ameriky.
Výhody nového přístupu k ukládání dat na disk (principiálně totožný s klasickým unixovým systémem bufferů, vyvinutým na konci 60. let) mi nějak unikají.
IMHO největším problémem současných OS je GUI, které už v polovíně 90. let narazilo na své hranice - s rostoucím počtem objektů a možných vazeb mezi nimi neúměrně roste režie systému a vytrácí se to, kvůli čemu bylo GUI vytvořeno - přehlednost, rychlost a jednoduchost ovládání OS.

francouzština je divnej jazyk. "atomic" se tam píše "atomique". viz http://en.wikipedia.org/wiki/TAI. :)

co neznamena ze prispevky tohto typu su "kvalitne"

Toto je kvalitní příspěvěk! :-D

Článek nám říká že začneme v novém systému užívat ostatní moduly pro sdílení úloh toto dělá již Windows a jak to vypadá asi nemusím říkat . Raději by měli vymyslet systém kde bude každé aplikaci přidělen samostatný prostor v paměti a sdílet se bude né do registrů ale do jádra které nebude na aplikacích vůbec závislé . Výsledek by byl nárůst nároku na paměť cca z 256 Mb na 2048Mb což by nebyl dnes problém vše by šlo uvnitř ram a ve virtuálních jádrech jako spuštěné samostatné systémy například pro představu windows 95 nebo Linux jádro ale desetkrát pro deset aplikací . Tím skončí ty nekonečné problémy s registry a jádrem systému protože každá aplikace bude mít systém svůj a jen pro sebe. Namítnete že by to trvalo dlouho to spustit , ale kdo říká že by se to mělo vypínat vždyť ram PO VYPNUTÍ pc může zůstat v chodu a moduly v ní v případě kolapsu znovu restartují , ale jen sami sebe a né systém ostatních modulů . Jenže takový systém by předpokládal přehodnotit dosavadní nahlížení na systém jako na celek a vše by se muselo naprogramovat nově .???!!!

To co popisujete velmi vzdáleně a s velkou dávkou fantazie připomíná koncepci čehosi, čemu se říká exokernel. Ale opravdu velmi vzdáleně, neboť OS dle vašich představ by se hodil maximálně tak k efektivnímu plýtvání prostředky počítače, ale jinak by byl úplně k ničemu (význam pojmů "sdílení do registrů" a "sdílení do jádra" mi poněkud uniká - tím myslíte zhruba co?). Jinak jestli vám to ještě nikdo neřekl, tak samostatný adresový prostor se přiděluje každé aplikaci téměř v každém OS (včetně Linuxu, Windows, OS/2...). Taková ta chyba "obecné porušení ochrany" ve Windows nebo "segmentation fault" v Linuxu bývá způsobena právě pokusem aplikace přistupovat do adresového prostoru, ke kterému nemá přístupová práva.
P.S.: doufám že se nezabýváte programováním :-). A jestli ano, tak stav ve kterém jste tu myšlenku splodil tipuju minimálně na 10 piv ;-)

Rozhodně se nechci přít je to jen nápad přidělit každé aplikaci čistý a samostatný systém tak aby se nemohlo stát to co se jinak děje pořád a to je vzájemné křížení při adresování aplikací v systémech.
Také by to znamenalo že by mohlo na jednom PC současně běžet třeba Windows Linux i MAC a to tak že by spolu komunikovali přes hlavní jádro, které by bylo nezávislé na systému a podporující všechny platformy . Znamenalo by to absolutní svobodu ve volbě aplikací a současně maximální zabezpečení chodu i přístupu k operačním systémů spuštěným jako moduly. Pokud se vám to zdá jako plýtvání tak se o tom můžeme pobavit tak za 5 let kdy 5 Gb ram zřejmě již nebude finanční problém.

"Také by to znamenalo že by mohlo na jednom PC současně běžet třeba Windows Linux i MAC a to tak že by spolu komunikovali přes hlavní jádro, které by bylo nezávislé na systému a podporující všechny platformy ."

To co jste popsal je de facto něco podobného tomu jak pracuje třeba takový Xen. Sice pokud pod ním chcete provozovat OS, který není pro něj upraven (Windows, MacOS X, atp.), musíte mít podporu virtualizace v CPU (AMD Pacifica, Intel VTx), ale pak vám přesně něco takového umožní...

Uvědomělému uživateli se okamžitě vybaví spíš VM/CMS než Xen... ;-)

Jenže ten váš nápad v podstatě nic neřeší - jen do počítače zanáší další (zbytečnou, za to ovšem poměrně rozsáhlou a náročnou) mezivrstvu, která nijak nemůže zabránit zkolabování jednotlivé aplikace, ale sama musí být komplikovaným správcem HW prostředků, jehož zhroucení povede ke zhroucení všeho, co stojí nad ním. Do programového vybavení počítače tak akorát přidáte další možný zdroj nestability, toť vše.
Domnívám se, že cesta, kdy k řešení problému, k němuž je postačující pár MB paměti, bude nutné použít paměti o jeden až tři řády více, není tou nejšťastnější.
Například onen zmíněný model exokernelu problém řeší na úrovni tzv. systémových knihoven, ovšem mnohem efektivněji. Ne cestou přidávání mezivrstev a zbytečným duplikováním částí kódu, ale naopak náhradou některých vrstev jádra částmi ze systémových knihoven na základě požadavků té které aplikace.

Tezko muzou chtit delat prevratne zmeny s 'klasickym' jazykem. Pokud chteji neco zmenit, musi zacit u jazyka jako takoveho. Mne osobne chyby nevo takoveho jako sul :) Naprosto drtiva vetsina realne pouzitelnych jazyku (c,c++,python,java,c#...) jsou 'C' like s par zmenama, ale fylozofie je prakticky stejna. Tezko lze pak neco menit o patro niz.

Jinak jak uz nekdo rekl, taky mi to prijde spise jako omylani neceho co uz tu bylo, bez poradne koncepce (tj. pocinaje zapisem tech programu, jazykem).

R.

Tak proti tomuhle se tedy musim silně ohradit! Python absolutně není žádný "C like" jazyk. Je to krásný čistý objektově orientovaný jazyk (který si bere mnoho dobrých myšlenek třeba i z čistě objektového Smalltalku), ale přitom umožňuje programovat i procedurálně a funkcionálně. Ovšem to že to umožňuje v žádném případě neznamená, že je "C like". S Javou či C# se nedá srovnávat (v dobrém slova smyslu pro něj), porovnávat ho můžete s Ruby či dokonce Smalltalkem (i když ten je v "objektovosti" ještě mnohem dál ;-)).

2005-03-12 09:49:48 je cas posledni novinky na webu...

Mozno sa mylim, ale podobne myslienky (aspon tie, ktore su v clanku uvedene ako prvy ciel projektu) boli uz realizovane spolocnocnostou NeXT v polovici 80. rokov, ked vznikol system NeXTStep, zalozeny na objektovo orientovanom prostredi OpenStep. OpenStep bol zaciatkom 90. rokov rokov portovany aj na ine platformy. Dnes je na takomto systeme zalozeny Mac OS X (teda aspon cast, ktora je pisana v prostredi Cocoa) spolocnosti Apple.

V ramci GNU je k dispozicii prostredie GNUstep, ktore uz ma implementovanu vacsinu funkcii podla povodnej specifikacie OpenStep, k dispozicii su aj nastroje pre tvorbu aplikacii v tomto prostredi.

Next preji smrt :)
BeOS forever..tedy mikrokernel.

Jistě je vám znám základní problém modelu mikrojádra - inherentně daná nízká efektivita. Mikrojádro má smysl v podstatě jedině na systémech bez ochrany paměti. V ostatních případech efektivita monolitického jádra je vždy vyšší.

Blbost. Ty rozdíly jsou minimální a vyvažuje to spolehlivost a bezpečnost (spadne server, nahodí se znova = žádný reboot).
Je to otázka jak dobře je systém navrhnutý a napsaný.

Pro OpenSoft je ale monolitické jádro výhodnější, protožě se daleko lépe udržuje a taky rychlost vývoje je daleko rychlejší než u microkernelu.