Názory k článku
KolibriOS: kolibří systém v 5 MB

Torvalds začínal na moderním počítači s procesorem 80386, držel se unixové koncepce a chápal smysl „vyšších“ jazyků typu C. Chápu, že v Rusku je v provozu spousta vykopávek, ale tyto pokusy beru jednoznačně jako krok špatným směrem.

Roller Coaster Tycoon vyzera dobre.

Vid chlasta pravidelne a pravidelne kodi nachlastani. A assembleri kodi veci ktore si nevies ani predstavit ;)

Jenze spousta zajimavych netbooku je s ARM procesorem a pokud je to psane cele v assembleru x86, tak to se bude portovat celkem dost obtizne.

Zatim je potreba dovazet ze zahranici, ale treba to jednoho krasneho dne dorazi i sem :)

NO jsme pesimista že by ARM převážilo nabídku bazarů plných notebooků x86 based! Dneska koupit je možné běžně koupit notebook s Intel Pentium 166 MHz za cca 2–3 tis. Kč. Pokud by bylo využití pro tyhle šunky, tak by to bylo moc fajn.

2–3 tisice? ste se blaznil, ne? :-D

http://www.acmshop.cz/produkt.php?id=21ee9b355d4a6eaa4cf3134e6ce4e083&kid=79&pid=395

Asi chtěl říct, kterej blázen by za to dal takový prachy. :o)

Běžné notebooky vydrží 2–3 roky a potom odchází jedna věc za druhou. Kupovat ojetý notebook jsou IMHO vyhozené peníze.

Já bych zrovna přivítal něco svižného s použitelnou klávesnicí a monitorem na čem by Debian vydržel alespoň 1/2 dne v provozu na baterky za rozumnou cenu (tedy nejsem ochotný do toho dát 4 a více násobek ceny běžného netebooku)

Musím říct že Kolibri OS jako projekt sleduji už nějaký ten rok nevidím v tom ani krok špatným směrem, ani absolutně bezdůvodný systém. Sice mu ještě chybí par věci do úplné krásy ale i tak stoji za to se na něj podívat blíže. A trochu lépe než někteří páni zde od stolu rovnou vyhodí soud o neužitečnosti a blbosti tohoto zařízeni.

Jádro Kolibri OS je založeno na základu Menuet OS který je už kompletně vyvíjen jen pro 64 systémy. Ve své podstatě proto není architektura omezena jen na x86.

Po stránce stability a rychlosti odezvy se mi pomalu lepší zdá jen QNX.

A upřimně, zkoušel jste někdy najít distribuci linuxu o velikosti jedné diskety která by bez problému najela docela pěkné GUI a k tomu ještě měla bezproblémové příslušenství aplikací? Já vím o jedné a o té škoda mluvit.

Rozhodně fandím tomuhle projektu už proto že není jen klon linuxu ale přináší svůj vlastní názor na řešení problému ( i když ten spíš už přinesl Menuet Os).

Po přečtení si to autor mohl přečíst, třeba větu „…i když spustíte větší množství informace…“ nějak nechápu…

po přečtení si to mohl autor předchozího příspěvku přečíst taky ;)

Omlouvám se hluboce, zmíněné (a další) chyby jsem opravil. Díky za upozornění

Jeste tu latinku, pane Krcmari. Cesi pisi latinkou (byt s nestandardnimi „znaky“ – teda ja ne :-) nekdy od odchodu Cyrila s Metodejem kamsi k vychodu. To mi vadi vic, nez nejake ty formality.

Takový systém by byl strašně cool před 25 lety. Teď je jeho jediným přínosem, že tvůrci zjistí, že je to k ničemu a budou dělat něco rozumnějšího. Psát v assembleru – na ZX spectru, Atari ST, trochu i na 8086 mělo ještě smysl. Dnes má smysl optimalizovat takto jen velmi malou část kódu.

Souhlas SSH a browser jsou dneska dost zásadní aplikací.

browser musim rict ze bych u podobneho systemu v zakladnim sestaveni vubec nepotreboval… ale kdyby bylo ssh, mohlo by byt treba ssh -X firefox ze silnejsiho stroje…

Jako programator v assembleru (byt na mainframu) prihodim svuj nazor. Ono je pomerne snadne napsat nejaky software, ktery je na prvni pohled rychlejsi nez systemy stavajici (a pokud ho budete psat v assembleru, pravdepodobne to tak dopadne).

Ovsem rychle narazite, pokud budete pak skutecne chtit implementovat veskerou funkcionalitu systemu, ktere se snazite kopirovat. A to bude problem i v pripade, kdy pujde o vyssi jazyk; v zasade budete kopirovat historii soucasnych systemu, ktere byly nekolikrat prepsany, casto za ucelem zvyseni vykonu.

Navic, assembler do toho vnasi dalsi problemy. Programy v nem nelze snadno refaktorovat (je to write-only jazyk), a pokud to zacnete delat, ztratite velkou cast puvodniho vykonu. Navic efektivni programy v assembleru jsou casto efektivni za cenu modularity, a pokud se tam tu modularitu pokusite dodat, zase skoncite se ztratou vykonu. V assembleru se take obtizne implementuji komplikovanejsi algoritmy, coz je zase potencialne ztrata vykonu. A to nemluvim o tom, ze dnesni prekladace jsou uz lepsi nez prumerny programator.

Vykon assembleru je navic zavisly na architekture procesoru; instrukce a zpusob psani efektivni pred 10–15 lety uz dnes efektivni neni (a to je ten lepsi pripad, kdy pouzivate instrukcni sadu pro stale zivy procesor).

Takze, abych to shrnul. Jasne, ze to startuje za 3s, protoze je to neobecne a nemodularne napsane, a neumi to tolik co soucasne desktopy. Podle me jsou to zkratka silenci, a prakticky vyznam to zadny nema (i kdyz naprosto chapu poetiku takoveho pocinu, kdyz jsem zacinal u nas ve firme, taky jsem chtel mit vsechno v mainframe assembleru).

Je pravda, ze pokial programator chape tomu ako funguje pocitac programuje napr v C++ s tym, ze ma aspon pribliznu predstavu ako vyzera prelozeny kod, tak vacsinou kod nema moc daleko od toho aby bol optimalny.

Problem je aj medzi jednotlivymi generaciami procesorov rovnakej architektury – kod v asembleri napisany pre netburst procesory ma daleko k optimalnosti na nehalem nebo k8.
Kod napisany vo vyssom jazyku sa pre danu architekturu prelozi znova, sice pravdepodobne suboptimalne, ale stale v akceptovatelnej kvalite a za neporovnatelnu ce­nu.

jsou to borci a ted kdyz tak skvele vidi do assembleru by meli zacit svuj system refaktorovat a co jde prepsat co C. pak by to mohla byt zajimava aktivita i z sirsiho pohledu.

Souhlasim temer ve vsech bodech, ale rozhodne odmitam, ze dnesni prekladace jsou lepsi nez prumerny programator. Vetsina programatoru v assembleru dokaze napsat rychlejsi kod nez jakykoliv prekladac. Rozhodne se to ale nevyplati.

O tom se budu hádat. Průměrný programátor nedokáže v hlavě uložit vztahy mezi části programu jedné trošku složitější šablony a to co překladač vyrobí za několik sekund, on bude navrhovat několik dní. Možná nakonec bude programátor lepší (překladač se neučí s chyb), ale za jakou cenu.

Proto se taky v assembleru pisou jen nektere casti, predevsim na vykon pomerne kriticke casti (jadra ruznych kodeku audia a videa, sifrovaci algoritmy, …), kde zrychleni treba o 20% je celkem dost pak v praxi znat a ke kterym casto lze pouzit nejake specialni instrukce (napr. instrukce pro AES u procesoru VIA) a vyrazne tak dany kod urychlit.

Přesně tak, překladač nikdy nepochopí, jak to člověk myslel. Tuhle jsem potřeboval na všechny bajty v souboru provést
rol [bajt], 2
Ve „vyšším“ jazyce jsem tedy číslo bajtu převedl na 16bitový integer, vynásobil 4, udělal pár masek AND a zbytek po dělení 256…
No a kód exáče se nafoukl o 20 kB!!! O pomalosti nemluvě.
Nezpochybňuji tady ekonomickou stránku vývoje aplikací, ale kompiler si může o rychlosti kódu od člověka nechat jen zdát.
Kdybych byl autor softwaru, který si klade ambice být rychlý, volil bych hybridní přístup – horká místa v ASM a zbytek v něčem blbovzdorném. A hlavně by se mělo dát volit, jestli se budou při každém volání funkce tyto kopírovat jinam do paměti (a dokonce relokovat), nebo se to zaonačí zásobníkem, což obvykle stačí a je to daleko úspornější.

Ja myslim ze zalezi na problemu. Ony prekladace to nemaji tak snadne, lecjaka informace v kodu chybi (treba vite ze nejaka funkce dostava argument vzdy nenulovy, ale kdyz ji kompilujete do knihovny tak jeste nemate vsechna jeji volani aby kompilator mohl neco takoveho odvodit – z toho duvodu se pak treba nekde uvnitr nevyoptimalizuje if). Nebo ta informace treba i ve zdrojaku je, ale slozite ji odvodit, takze se to nedela. Nebo je to neco vagniho, jako v takovych pripadech, kdy treba clovek zna typickou velikost vstupu. To pak s pomerne malou namahou muze napsat lepsi kod v ASM.

Ovsem architektura dnesnich CPU je takova ze lidem, resp. jejich dusevnimu zdravi moc nepreje. Jednak kdyz mate superskalarni CPU tak porad abyste pocital latence instrukci a jake mate vyuzit jednotek, atd. Druha vec je vyuziti cachi. Koukne na http://en.wikipedia.org/wiki/Polytope_model at vidite co treba se snazi delat gcccko. V kombinaci s http://en.wikipedia.org/wiki/Loop_tiling to muze nektere vypocty mnohonasobne zrychlit.

Jestli znate nejakeho prumerneho ASM programatora, ktery tohle dela rucne, tak ho rad taky poznam.

V tomhle je nejlepší překladač o informace neochuzovat. Ideálně je templatové nebo inlinové programování. Překladač má k dispozici všechny informace, včetně obsahů funkcí, může se rozhodnout, zda kód nechá ve funkci, nebo jí inlinuje, může si přeházet registry jak potřebuje, protože vidí do funkcí, ví, které registry se budou měnit. Jediný, co mi v současných překladačích chybí je určování četností podmínek, něco jako, „tahle podmínka nastává výjimečně“. Trošku se to řeší přes výjimky, tedy test na chybu se provede jen jednou a zbytek řeší výjimka mimo hlavní scope. Ale ideální to není, protože výjmky jsou tak náročné, že se hodí spíš pro vyjádření „tahle podmínka skoro nenastává“.

Jinak vývoj v překladačích pokračuje, dopředu jde jak GCCčko, tak Microsoft Visual Studio. Optimalizuje se všude, nelze tedy program psát s tím, že dopředu vím, jak se která konstrukce přeloží. Možná dneska, za rok už to může být jinak. Tak nad tím nepřemýšlím, maximálně to řeším v časově kritických částechm a těch je málo (jsou to extrabuřty, speciality). K tomu navíc pomáhají různé profiléry, napříkla MSVC nabízí profilér podmínek … což řeší částečně to co jsem psal nahoře… podmínky se pak překládaji z ohledem na to, které větve byly pravděpodobnější. Dále je to třeba Whole Program Optimizator, který provádí optimalizace při linkování, takže ta poznámka o tom, že překladač nevidí do knihoven nemusí úplně platit. Jisté optimalizace se provádí napříč celým kódem (MSVC).

Atd, atd. Proto preferuju C/C++, ten pokrok v optimalizacích je vysoký, a troufám si tvrdit, že jakékoliv frameworky, ať už jde o Javu, nebo .NET navzdory tomu, že mezikód překládají do nativní formy, nebudou mít nikdy k dispozici tolik informací, kolik lze vytěžit přímo ze zdrojáků. A taky jsem už slyšel, že JITcompilery využívají runtime informace a optimalizují vůči něm… jenže tomu zas tolik nevěřím, protože JITC je náročná operace, kterou nelze provádět pokaždé, když se runtime informace změní.

zaujimave veci

ta cetnost podmienok by bola fakt super pre prekladace, zaujimave ze MS to este nepridal

Ne, ono to tam je, ale přes profiler. Člověk to nemůže specifikovat v programu, ale musí přes profiler. Ale nezkoušel jsem to.

toto chce test a clanok

A pokud jste zkousel zapnout optimalizace, co to zkusit jeste (v GCC) s -fprofile-use (a spol.)?

Jeste -fwhole-program by mohlo pomoct.

Myslím že vypovídací hodnota toho je, že v tom cyklu zabere dereferencování pointeru na virtuální metodu víc času než tělo metody add. Což neznamená nic, pokud není řečeno, co ta metoda add() uvnitř dělá. Nesjpíš (skoro) nic, což ale není zrovna typický program, že…

Možno by tomu prospela POSIX vrstva – na začiatok niečo na spôsob cygwin, alebo preportovať dietlibc alebo uclib (alebo dokonca aj GNU libc). POSIX programy by potom stačilo „len“ prekompilovať, ale na druhej strane by s modernými aplikáciami už systém nereagoval svižne a potreboval by viac než 8MB RAM… ale v dnešnej dobe by to nestačilo, v dnešnej dobe sú hlavným problémom „alternatívnych“ OS ovládače…

TI posílají bezva operační systém plný her, trojských koňů a jiného užitečného
software. Zkus a nebudeš zklamaný.

Zdravíme všechny soudruhy!

Ha, ha. Ti „soudruzi“ tam dnes bojují o přežití. Samozřejmě ten internetový underground tam je, ale na infiltraci se skrz tak záslužný software každý vykašle. Ona totiž čest v OSS je víc, než nějaký průnik do… čeho vlastně, když to bootuje bez Windows a na NTFS to neumí zapisovat?

chi chi – schopnej prgoš si tu v průměru zarobí dost peněz.
A o schopné prgoše je tu velká nouze.
Tak se jim hodně platí.

No a vo tom to je. Nereagujme na kdejakej mýtus a omezený názor, který vyplývá z nedostatku přehledu a většinou i z absolutní neznalosti prostředí.

Mít to SSH, tak do toho jdu :)

kazdopadne diki za prijemne citanie, vylety do sveta alternativnych systemov su vzdy zaujimave.

nabuduce navrhujem haiku

U takovéhoto software se nemá smysl zabývat reálnou použitelností,a nejspíš to ví i autoři. Na druhou stranu, který programátor si někdy nenaprogramoval něco, jen protože „je to hezký“. A dotáhli to teda dost daleko.