Počítače etc...

Na prahu 32 bitové mentality.

20. srpna 2015 v 5:22 | Petr
Nedávno se na mně obrátila jistá vysoce postavená kolegyně z Laboratoří Agel s dotazy stran počítačových systémů ve zdravotnictví - a při té příležitosti jsem byl nucen hluboce se zamyslet a zjistil jsem, že dnešní gigabajtové a gigahertzové počítače nekladou programátorovi prakticky žádná technická omezení. Přesto ( proto ? ) jsou často výsledky běhu programů žalostné. Velice jsem přemýšlel a zjistil jsem že patrně existují něco jako různé stupně "progamátorské mentality"

Příkladem budiž - to, na co jsem byl kolegyní tázán - tedy předávání zdravotnické dokumentace mezi počítačovými systémy špitálů. Zde tedy příklady:

"8 bitová mentalita" - předávaná data :
ů)VŔo'";.ŤFĐbÍ`iüF\ˇ ˜ ‡Ż˘"ľ5NńĚÔÁG"cÁcWK'LX[R ç­~ˆ†&Ë
ĘČuERQŤłÎHđžR«Ę¨CßÔhžĆO‰u‰Á󎼵ĺpPúż©ŇŚ(˛qćóÂú…ţ´ÎN-§Ë®sFu:r%
}ô҇^WKpT×˙oS‡4áq_Ž1(-wP´iRŹä> ÔŻą3ÖsÚŠ‹› ő(P!-Ś‡t#|r< Ň Ś°¨Gr_úݱ 7˝8ý_O¸A}¤ăĽy^n˘Á JftbYÂIЃ&¶°|­űßŕƒFrj"

Tedy - to, "co jedna procedura vyplodí" uloží se na disk a pošle se napříč internetetem - zcela proprietární nedefinovaná struktura s jakoukoliv změnou softwaru - automaticky se mění formát zprávy, který je komukoliv krom "přijímací procedury" přesně stejné verze jako "vysílací" - zcela nesrozumitelný - odolnost proti chybám přenosu : může být docela vysoká kvůli kontrolním součtům atd. ale odolnost proti "chybám protokolu" - tedy proti tomu, když programátor nepochopí rozdíl mezi znakem "smějící se obličej" s koutky nahorů a dolů - naprosto nulová. Použitelnost takových dat pro jiný software - taky naprosto nulová - pokud to není zrovna software firem NSA, KGB, CIA a další "z branže".

"16 bitová mentalita" - předávaná data :
AE\\\\\\\\01\01\281326\455853\32\45585332\20150710_0383\1\STATIM\201507110600\I2LH\IN2L\PBOX
03\Diagnoza\I21.4,I70.20,I25.9,I50.9,I34.0,I48.1,Z95.0,I10,I69.3,Z87.8,N18.3,N08.3,E11.2,M25.59,J84.9,J42,I70.90,Z98.8,Z88.8\Plocha tela\\Vyska\\Hmotnost
04\Moc_ml\\Moc_hod
11\10001\25\1\\\\\\\\\OKBI
11\10002\25\1\\\\\\\\\OKBI
11\10003\25\1\\\\\\\\\OKBI
11\10010\25\1\\\\\\\\\OKBI
11\10011\25\1\\\\\\\\\OKBI
11\10100\25\1\\\\\\\\\OKBI
25\OKB\526
26\\Miroslav\\20.04.1938\2\380420/989\1248/12\700 30\Ostrava-Hrab…vka\I2LH\1H7\CZ\\303003 27\1\111\P\380420416\DV111 28\Heczko\Marcel\MUDr.\91001720\070

Kdyby vás zajímalo co to je - tak to je parodie na "zdravotnický komunikační jazyk" HL7 verze 2 z dílny firmy, která vytvořila náš špitální počítačový systém.
Vlastnosti tohoto levelu - sejde se "international executive board", který vymyslí "human readable code" - ovšem jak vidíte s tou "human readability" to hoši moc nepřehánějí, a hlavně - každá tečka je podstatná - ale význam žádné tečky není nikde detailně popsaný - ergo odolnost proti programátorským "chybám protokolu" je mizivá a tím je mizivá i přenositelnost dat mezi počítačovými programy různých výrobců. Dokonce i když samotní autoři "mateřského softwaru" v rámci "neustálého vylepšování" - vynechají omylem jedno lomítko - tak program sice neskončí hláškou "unhandled exception at line XXXXX" - jako u 8 bitového levelu, ale přeto prostě "data nedojdou" a vy budete marně pátrat proč.

"32 bitová mentalita" - předávaná data :
Toto je HL7 - verze 3 alias XML využité pro medicínská data - amatérům sice toto nepřipadá o moc čitelnější než předchozí případy - ale je to XML - standard jasně definovaný s miliony progamů, které s ním umí pracovat, navíc má jasnou strukturu syntaktickou i logickou ergo - pokud při programování "datového rozhrani" vynecháte někde čárečku - tak místo týdenního zasedání "krizové skupiny expertů" - je nalezení takové chyby otázkou 5 minut práce mladíka, co právě rozchodil své první Raspberry PI. Navíc díky neustálému a úmornému opakovaní tagů je zotavení se z "nepatrné změny" datového formátu pro software relativně snadné, a díky tomu je přenositelnost dat mezi softwary různých výrobců relativně vysoká.

"64 bitová mentalita" - předávaná data :
Vstupní Vyšetření : 59letá žena s CHOPN 3/C hospitalizovaná na plicním oddělení pro zhoršení dušnosti a kardiální dekompenzaci s otoky dolních končetin a břicha. Vstupní středně těžká obstrukce a hypoxémie, sérové parametry v normě, zavedena medikace bronchodilatační, diuretická, oxygenační. Stav přechodně zlepšen, ale za 14 dní dochází ke zhoršení klinickému i laboratornímu (S-urea 15 mmol/l, S-kreatinin 138 µmol/l, S­-CRP 114 mg/l), byl odebrán vzorek moče a proveden rtg snímek hrudníku (nález bez plicní infiltrace).
Výsledky provedených testů (moč): pH 6,0, hustota 1016, bílkovina 3 arb.j., krev 3 arb.j., leukocyty 4 arb.j. , ostatní políčka negativní

Tedy je to "prostý text" nebo maximálně do úrovně "RTF" formátovaný text - plně "human readable" a velmi často taky "human generated". Dovolím si poznamenat, že aby se takový formát řadil do "64 bitové mentality" musí software jevit známky schopnosti porozumět takovému textu - tedy najít v něm jméno, rodné číslo, datumy, laboratorní hodnoty. Softwary, které se chubí tím, že s takovými daty umí pracovat a přítom mu nerozumí ani zbla - řadím někam do 8 bitové mentality, protože ani tam "binárnímu bordelu" de facto software nerozumi.

Jistě jste pochopili, že počítačoví neumětelové v oblecích, kteří, ve snaze prodat svůj sotware, pořádají prezentace "smart technologií" pro managementy špitálů - zatím nikdy "64 bitové mentality" nedosáhli, ale řekněte sami - jaké technické prostředky chybí k tomu aby se tak stalo ? Nevejde se slovník medicínské češtiny zvíci 50 000 průměrně 7 písmen dlouhých slov do paměti ? Není dostatečný výkon procesoru pro "překlad" textu, dle výše uvedeného slovníku do nějakého ( uživatele nezajímajícího ) vnitřního formátu ? Nemáme - dokonce "open source" - syntaktické a lexikální analyzátory a parsery z projektů velkých kompilátorů programovacích jazyků, které by se daly použít jako základ ?

Inženýrům mezi čtenářstvem teď vaří krev, neboť mají 1001 námitek, proč to nejde, ale problém není v tom proč to nejde - problém je v tom, že 50 let zkušeností s počítači ve špitálech ukazují, že krom nestrukturovaného lidského jazyka je jakýkoliv umělý "standard by comitee" vždy brzy zastaralý a omezující - tedy firma, která poprvé předvede jak její software pozře a povrchně porozumí zdravotnickým textům - bude mít obrovskou výhodu a bude mít v ruce "konečné řešení" otázky komunikace mezi počítači ve zdravotnictvní. Nemluvě o tom, že tato úloha je mnohem snazší než se zdá, protože lékařské zprávy prošly od dob Hippokrata dlouhým vývojem a jsou vnitřně strukturované více než si dovedete představit.

Samozřejmě narážíme na Moravcův paradox a taky na "česká specifika" - tedy za software, který produkuje "binární bordel" na úrovni 8 bitové mentality, a proto má každý týden poruchu, která vyžaduje - 2 dny dlouhé - "krizové zasedání expertní skupiny" - lze od státních špitálů žádat nestoudné prachy, ale za software, který hladce "čte i píše" - lidem srozumitelné zprávy - toto žádat nelze neboť - proč platit peníze za něco, co "umí i zdravotní sestra" - žejo ?

Jen jako výhled do budoucnosti : "SkyNet / Matrix mentalita" - předávaná data :
Ale to už si naprogramují samy stroje - a to si můžete být 100% jisti, že ty zdaleka nebudou tak líné ani zkorumpované, jako frikulíní v oblecích, kteří berou těžkou hlínu zato, že komplikují skutečná řešení počítačových problémů, tvrdíc, že "se zabývají problematikou datových komunikací v elektronických systémech ( EU ) projektů pro e-zdravotnictví" !

Poznámka při druhém čtení - dva dny poté, co jsem dopsal tento článek jsem řešil problém jistého počítačového systému, který, aby poznal, že datová věta je textová - potřebuje jako první slovo heslo "text". Dovolím si to nazvat "matláckou mentalitou" a považovat to za příznak toho, jak hluboké je neumětelství počítačových expertů ve zdravotictví, když v roce 2015 jim dělá problém věc, která v "Basicu 6" na IQ-151 v roce 1986 byla zcela snadná, i bez trapného pomocného nápisu.

Opět chybějící elektronika !!!

25. září 2014 v 6:05 | Petr
Ještě než se rodzepíšu - podotýkán, že jsem "spíše na ty drátečky" a proto nemohu vyloučit, že mi chybí něco, co je běžně dostupné, proto dávám předem výzvu - drazí čtenářové - hrr na mně v diskusi - dneska snesu označení "zaostalý blb" i horší....

Takže výsledek - minule jsem si chválil IP kameru od Edimaxu - a haněl jsem obslužný software, který - ač téměř nepoužitelný - je Edimaxem vynášen do marketingového nebe. Tedy Edimaxovský "camera cloud" který vám má umožnit sledovat vlastní IP kameru dokudoliv je opravdový shit - pravděpodobnost že tato "přenositelná JAVOVÁ aplikace" bude fungovat je u náhodného PC tak 1% - takže mě přestalo bavit vykládat všem jak hlídáme psa IP kamerou a pak se omlouvat "pardon u vás mi to nefunguje".....

Tedy jsem pronikl do kamery a vytvořil tam účet "Tchýně" - se silně omezenými právy - a pak jsem pronikl do routeru a HTTP port 80 z venku jsem přesměroval na WWW stránku v kameře s videostreamem - pod účtem "Tchýně"...... Když jsem to předváděl známým - prohlašovali, že mám svoji IP adresu a heslo zveřejnit zde na blogu, aby mi psa hlídala celá republika.


Vtip je v tom, že paní Kubáčová občas zapomene a vyběhne zcela nahá z koupelny, aby psíkovi vyměnila vodu - takže vážení soudruzi - nic nebude - protože stačí, že mě zanedbává kvůli psisku - ne tak aby provozovala ještě nechtěný erotický videochat zadarmo.

Nicméně při té příležitosti jsem si uvědomil sílu internetu - vstutku můžete za pár peněz nejenom sledovat, co se doma děje, ale i ovládat nějakou tu domácí automatizaci, nebo si vytvořit domácí WWW server, nebo domácí FTP - přístupné odkudkoliv ze světa - vskutku možnosti neuvěřitelné, které my drátečkáři ani neumíme docenit. ALE ....

Ale představte si tuto situaci - v polici v obyváku sídlí router a sídlí tam ethernetový síťový disk, pokud bych chtěl možnosti, které jsem právě ochutnal využít naplno - tak by tam sídlil i nějaký mini linuxový stroj alá Raspberry PI (minimálně), k tomu všemu ethernetové kabely, k tomu všemu napájení k tomu prodlužovačka s několika adaptéry a další moře drátů. Takže výsledek - pokud tohle chcete udělat a nejste nejmenovaný kolega, co má serverovnu v garáži - patrně budete vyhozen manželkou i s domácí automatizací.

Tedy proč není ke koupi bedna která je zároveň Router, Switch , WIFI access point, NAS, pár USB portů (nebyl by marný ani UART / RS485 pro tu domácí automatizaci) a navíc na něm běží nějaký uživateli prístupný a uživatelem konfigurovatelný Linux , aby se daly dělat i ty ostatní blbosti ?
  • Že by to bylo nekonfigurovatelné monstrum, které by uživatelé měli tendenci rozhrkat a už nedat dohromady ?
  • Že by tahle věc spadla do kategorie "special technology" za dlóóóuhé prachy ?
  • Že by to podrylo prodeje ve 4-5 dalších kategoriích "plastových krabiček" ?
  • Že si něco takového můžu už teď postavit ? Mimochodem ukažte mi motherboard s alespoň 4 portovým svitchem na palubě ?
  • Že to už existuje a já jsem blb ?
Poslední odpověď by mě potěšila nejvíce, ale vzhledem k tomu, jaké síťové vybavení stejné má doma každý - si myslím že tato "univerzální bedna" snad jednou příjde. Dokud to nenastane berte to opět jako další příspěvek do kategorie "open source nápadů" a opokud tohle začnete vyrábět - nezapomeňte dát vědět - kde je to ke koupi, nebo na které Crowdfundingovém serveru to mám podpořit.....

Čínská logika a záhady v elektronice

18. září 2014 v 5:10 | Petr
Již jsem psal, že máme nového člena domácnosti - psa - švyckého honiče Maxíka. Ten pochází z velkého chovu a tak má občas záchvaty "separační úzkosti" kdy hrůza z toho, že je sám vede k tomu, že vyje a vyje a vyje. Abychom měli přehled, co se děje doma - rozhodl jsem důrazně - nainstalujeme do chodby kameru a budeme se koukat, co pejsek dělá.

Tak jsem hledal a hledal a pro provizorní řešení do pejskovy dospělosti se mi jevila jako ideální kamera Edimax IC-7001 která má otáčení, WIFI, přisvětlení IR LEDkami, slibuje obousměrný přenos zvuku a neurazí vzhledem ani cenou. Jako obvykle jsem dostal kameru, na které je zjevné vidět, to co je vidět na celém IT byznysu. Hardwaroví inženýři na ní pracovali mnohem usilovněji než softwaroví inženýři.

Nesouhlasíte s tímto pravidlem - podívejte se do domácího PC - multi core procesor, kde každé jádro je paralelní out of order, superpipelined obvod, který přes několik levelů cache komunikuje s mnohakanálovou RAM pamětí - a na tom všem běží javová hra na Facebooku, kterou napsal nějaký jouda, protože má pocit že je COOL IMAGE když navštevuje seance "startupistů" a na krku se mu komíhá poslední model iPhonu.....


Tedy Hardware kamery - skvělý - díky IR přisvětlení nemá kamera anti IR filtr a tudíž barva divanu v našem obýváku - vymalovaném oranžvě je divná, ale tohle může vadit snad jedině paní Kubáčové. Pak ovšem dojdeme k softwaru a najednou to dostane spoustu děr.
Celý zvukový modul softwaru je TODO - a vzhledem k tomu že kamera už je nějaký pátek na trhu - patrně TODO zůstane, takže nečekejte že budete poslouchat, nebo nedej bože mluvit na "hlídaný objekt".
Aby Edimax usnadnil uživatelů průnik videostreamu přes domácí routery nabízí "Edimax Cloud" kdy kamera informume server Edimaxu o své existenci a vy zadáte XXXXXXXXXXXX.myedimax.com - kde XXXXX je MAC adresa vaší kamery a na této stránce se vám stáhne JAVA applet kterým koukáte na video - odkudkoliv.
JAVA Applet - je typické čínské dílo - ve stylu kamenných chránů držených ve vzpřímené poloze rákosem svázanými bambusovými tyčemi. Tedy ač "přenositelná" JAVA - aby té přenositelnosti nebylo příliš - volá WINDOSOWSKÉ DLL - takže na Linuxových počítačích "si nevrznete". Navíc to DLL volá tak, že pokud nejste přihlášen jako admin volání skončí chybovou hláškou. (Obvyklý stav ve Widlích)....

Takže výsledek je jasný - nějaký manažer v Edimaxu křičel rychle rychle rychle - a "IT CROWD" mu předvedl že (na jediném počítači v budově) jim všechno funguje a tak byl produkt vypuštěn na trh. Přesně stejné je to i z uživatelského hlediska - se všemi destíkami a desítkami počítačů ke kterým mám přístup mi jejich "cloud" funguje na jdenom PC v práci a na WIN_XP notebooku doma, kde jsem pod účtem administrátora změnil přístupová práva k "p2pMGR.dll" abych pod účtem usera mohl sledovat "co dělá Maxík"

Tedy shrnuji - kvalita obslužného softwaru je v kategorii "hnus velebnosti" a zcela vážně přemýšlím, že bych překonfiguroval router abych se k videostreamu dostal z Internetu přímo do kamery - což v lokální síti je dětsky snadné a pohodlné.

Po rozčilování se softwarem nastala instalace fyzická. Takže jsem již jedoucí kameru položil v chodbě na židličku. Jenomže jak jste si všimli kamera má čtvercovou základnu a kulovitou "hlavu", která se svojí velikostí velice blíží rozměru tenisáku..... ERGO kamera v mozečku psíka spustila nějaký "hravý" podmíněný reflex a psisko ji "chytilo za kouli" a radostně s ní pohazovalo po chodbě. Tak jsme psíka okřikli, uslintanou čočku vyčistili a co dále ? Přišroubovat na strop !
Tedy jsme hledali místo odkud "je vidět všechno" a stále jsme buď neviděli koutek kam psisko chodí trhat boty, nebo koutek kam chodí dělat loužičky. Po několikanásobném a velmi nepohodlném přesouvání se se štokrletem po chodbě se žena zeptala : "A proč nejdělají kamery na robotickém podvozku ?"

To skutečně udeřila hřebík na hlavičku - protože ona moc dobře zná mé "diferenciálně řízené roboty". A když se nad tím zamyslíte - co má kamera : kamerový modul, 2 motorky s převodovkami, a motherboard s WIFI a nějakým Linuxem na ARMu. Co by měl "hlídací robot" ? Kamerový modul, 2 motorky s převodovkami, motherobard s WIFI a nějakým Linuxem - a ještě by měl baterku navíc. Takže opět otázka : Proč nejsou ?

Problém je v tom, že jsou, jenom v jiné kategorii. Kamera s motorky uvnitř je v kategorii "PAN/TILT camera" asi tak za 2000-5000 korun. Kamera s motorky (a kolečky) venku může být buď "security robot" nebo pokud vezmeme v úvahu "two way audio" může takové zařízení spadnout i do kategorie "telepresence device", takže cena pak "může spadnout" kamkoliv od 2000 Eur do nekonečna ( v případě IT zakázky pro náš laskavý stát - i víc než to ).

Smamozřejmě se vnucuje otázka - je "security" robot o tolik technologicky náročnější aby to obhájilo nárůst ceny ? Nikoliv, ale je "security" - tedy je nutno připočítat cenu za naleštěné prdy, které se prodávají spolu s ním. Nicméně "security robot" by se dal postavit i na základě Raspberry PI a Webkamery za 199. Takže až na Kickstarteru odstartujete kampaň na finacování jeho výtoby - hlavně mě nezapomeňte upozornit - okamžitě beru jeden kus....

Lubuntu - Linux, který "lze přežít"

24. července 2014 v 5:10 | Petr
Téměř přesně před 2 roky jsem psal o zprovoznění malého netbooku Asus EEE Pc 901 a o tom, že jsem na něj instaloval Easy Peasy - což je netbooková varianta Linuxu vycházející z nesmírně populárního Ubuntu 10.04. Firma Canonical - tvůrce Ubuntu - totiž jde ve stopách Microsoftu, a to v tom smyslu, že vytvořila naprosto špičkový operační systém na Linuxovém základě, ale pak se vývoj stal obětí "marketingu" a "zasedání komisí" a výsledek se dostavil - místo skvělého a dokonale odladěného grafického prostředí GNOME 2 si začali hrát se zblijem jménem Unity. Canonical Unity je sice něco jiného než Microsoft Metro - ale v pozadí je stejná myšlenka - obětovali jsme efektivitu práce na oltář "COOL" a "WOW" efektu - tedy nová tabletově-facebooková generace jásá a my ostatní sedíme u PC, kroutíme hlavou a říkáme si nebyl "MS-DOS" nakonec lepší ?

Takže jsem na malinkatý netbook EEE 901 instaloval Easy Peasy, které je opravdu Linux pro blbé - s velikými ikonami a klikacími tlačítky, ale ani to mi dlouhodobě nestačilo, takže jsem původní grafické rozhraní přepnul na Gnome, pak jsem potřeboval v malinkatém notebooku alespoň občas editovat plošné spoje v KiCadu - takže jsem si hrál s X-serverem abych dostal rolující virtuální obrazovku 1024 x 1024 pixelů, instaloval jsem tunu multimediálních přehrávačů až jsem skončil u VLC, a nakonec po všech změnách připomínalo EasyPeasy spíše Trabant rádoby předělaný na Mercedes.

Kromě značné "záplatovanosti" se s EasyPeasy stala ještě druhá věc - autor této distribuce sice hrdě oznamuje nové a nové verze, ale repozitáře s balíčky pro EasyPeasy už rok nefungují. Proto jsem používal repozitáře Ubuntu 10.04 - a výsledek se dostavil - asi před 14 dny jsem aktualizoval "malinkatý notebook" a s touto aktualizací přišla chyba, která způsobila, že mi padají Internetové stránky ve Flashi. Takže jsem byl postaven před dvě možnosti - dále "debugovat" nastavení Easy Peasy, nebo "sesednout z mrtvého koně" a instalovat něco jiného.

Jistě jste pochopili, že jsem zvolil možnost č. 2 a s tím vyvstal problém jakou distribuci zvolit. Bereme-li to systematicky - tak mé zkušenosti s Linuxem jsou relativně skromné a zahrnují tato distra:
  • Mandriva - kdysi dávno kolem roku 2008 - s katastrofálními výsledky
  • Easy Peasy
  • Linux Mint Mate 32bitů - jsem instaloval do netbooku dceři (Mate je pokračování Gnome 2) Nastavil jsem jí plochu tak aby co nejvíce připomínala Windows - a měl jsem obavu co puboši ve škole, ale problěhlo to dobře - puboše totiž fascinoval applet "oči" natolik, že si patrně nevšimli, že na notebooku běží Linux.
Linux Mint by v této konfiguraci určitě šel i na EEE 901, ale chtěl jsem vyzkoušet něco jiného a tak jsem se pustil do legendami opředeného Lubuntu - ve verzi 14.04 - tedy Ubuntu s grafickým manažerem LXDE. Proč říkám "legendami opředený" - Lubuntu je patrně asi nejméně instalovaný klon Ubunutu, který navíc jde mimo oficiální "válku" mezi Gnome a KDE. Navíc LXDE se mi zdá jako vyloženě minoritní grafické prostředí. Přesto Canonical tvrdil, že to je nejúspornější varianta jejich systému z hlediska nároků na procesor, paměť a výdrž baterie.



Jak jsem tedy na to šel - při instalaci Linuxu na netbook se SSD mám už takové své "finty" - tedy šetřím zápisy do datového úložiště tím, že jako filesystém používám EXT2 místo žurnálovacího EXT3. Kromě toho vypnu swap - což mi moje EEE s 1GB RAM v pohodě dovolí. A nakonec fintička, ke které mě dovedla léta zkušeností : EEE 901 má dvě datová úložiště pomalé 16GB a rychlé 4 GB - při úvodním formátování disku vždy nechávám to ryché pro adresář /USR - kde jsou všechny programy, které se musí rychle načítat - pokud to takto neuděláte Linux má tendenci se celý vecpat na rychlé úložiště včetně /TMP a tím riskujete, že budete mít problémy s místem na disku při aktualizacích. Opačná varianta - nacpat celou instalaci na pomalé 16GB úložiště sice taky funguje, ale EEE je pak viditelně pomalejší.

Vše proběhlo hladce a nastává sekce "prvních dojmů" - Zprávy Canonicalu o "maximální optimalizaci" systému na minimální spotřebu výpočetních prostředků počítače jsou 100% pravdivé. LXDE - je velmi rozumné prostředí - vycházející z GTK 2 a tudíž podobné starému Gnome 2. Uživatelé na internetu si stěžují na "malou konfigurovatelnost" LXDE - jako příznivce minimalismu a milovník Windows XP - nemohu tento názor potvrdit. Prostředí jsem si nastavil - jako vždycky - "ve stylu WIN XP" s lištou a "tlačítkem Start" Po instalaci vše funguje "na první klik". Firefox hladce surfuje po internetu. Open/Libre Office není součástí běžné instalace pouze kombinace AbiWord a Gnumeric (Linuxový Excel) - což naprosto stačí. To, že optimalizace je dokonalá je vidět i z výdrže baterie, která oproti mému "zmršenému" Easy Peasy - vzrostla na stejném netbooku ze 3,5 na 4,5 hodiny - při čtení PDF a surfování po Internetu bez videa.

Abych jenom nechválil - Lubuntu je opravdu dokonale optimalizované - někdy máte pocit, že "až moc". Nastavíte si do lišty applet "zátěž procesoru" - u každé distribuce s KDE nebo GNOME - kliknutí na tento applet spouští Task Manager - zde ne. Pustíte Task Manager ručně a čekáte křivky vytížení procesoru, paměti a sítě - ale nedočkáte se "žraly by paměť". Místo nich máte jenom grafické ukazatele okamžité zátěže. Při instalaci balíčků používám místo APT-GET - modernější "APTITUDE" - to však není instalováno, protože vyžaduje Python, který taky chybí. V liště není standardně ukazatel připojení na WIFI a spoustu dalších drobných úprav o kterých víte, že tam nejsou "neboť by žraly výkon", ale práce bez nich je pro vás krajně zvláštní - asi jako řízení bez brejlí nebo chození bosky.

Kromě těchto věcí - souvisejících s optimalizací systému - je tu ještě jedna nepříjemná věc - neodvratně spojená s LXDE - každá "blbost pro Linux" očekává že pojede pod některým majoritním grafickým prostředím tedy KDE, GNOME, XFCE nebo tak, LXDE je opravdu minorita, proto si "každá blbost" při instalaci stáhne stovky záhadných balíčků pocházejících buď z Gnome, nebo z QT (základ KDE) - pokud máte dost místa na disku - a to po fintě s /USR máte - není problém.

Některé věci - které jsou de facto "chyby" jsou vlastně jisté "zkulturnění" systému - nefunguje například přepínání mezi vlastním a externím monitorem pomocí tlačítka. Asus samozřejmě drivery pro tuto funkci má, ale pro Linuxy 5 let staré, takže řešení - dal jsem na plochu ikonu "manažeru monitorů" kde si naklikáte které monitory a v kterém rozlišení se mají spustit - daleko rychlejší než "promačkání se" přes všechny kombinace - funkčním tlačítkem u původního Easy Peasy.

Nakonec - jestli doporučuju, nebo nedoporučuju ? Osobně jsem 100% spokojen a vaše babička neznalá Linuxu bude taky 100% spokojená, ale pokud máte rádi "to své jisté" a známé prostředí - buďte připraveni na 2 hodiny "ladění" celé instalace.

Tím jsme pro dnešek skončili a zbývá už jenom tradiční rada pro blondýny - Tanga byla prý vymyšlena proto, aby se kalhotky nerýsovaly pod šaty a přislušná blondýna mohla předstírat, že je "naostro". My chlapi o tom máme jisté pochybnosti - proč mást veřejnost, že jsem / nejsem naostro, zejména když tanga jsou i z hygienického hlediska velice pochybné prádlo - a navíc - guma od kalhotek rýsující se pod obepjatou sukní - má taky svůj nezanedbatelný "erotický aspekt".

Poznámka při druhém čtení - po prvním přihlášení na YouTube mi přistálo i v nové instalaci fízlovací "tracking cookie" od Googlu - a zase mi při práci s čímkoliv od Google vyskakují stránky v Azbuce. Trošku děsivé, že "Velký bratr" potřeboval na moji identifikaci méně než 15 minut ne ?

Instrukční sady procesorů 3. ARM, Thumb + 2

18. dubna 2013 v 5:11 | Petr
Jen rekapituluju, co jsem psal minule a předminule - instrukční sada procesoru zásadně ovlivňuje konstrukci a výkon kompilátoru což zásadně ovliňuje vlastnosti celého počítače - viz SmartPhony a Tablety s ARMem které při několikanásobně menší spotřebě proudu se téměř vyrovnají netbookům s Intel Atomem.
Jak vypadají instrukce procesoru ovlivňuje tzv. Instrukční dekodér, který předkládá "opkódy" instrukcí do vniřních signálů řídícich fukční jednotky procesoru.

A teď už jsme zase u RISC procesorů.V éře CISC procesorů byla idea že co příkaz programovacího jazyka - to jedna instrukce - což vedlo k tomu že strojový kód procesorů byl složitý - Intelovské procesory typu 8086 (až po dneční mnohajádrové a nadupané) mají instrukce dlouhé 1, 2 , 3, 4 bajty - takže dekódovaní probíhá tak, že trpajzlici přečtou první bajt následující instrukce a pak přemýšlejí "dává nám to smysl" nebo musíme načíst ještě další bajt a další a další ..... Stejně tak vykonávání takových instrukcí - trvalo kdysi minimálně 4 ale i 8, 16 a více taktů podle složitosti.

Není divu že Intelovské procesory už takto nefungují, protože "takhle by to nešlo" a místo toho fungují tak, že jsou udělány jako procesor v procesrou kdy instrukčn ídekodér je vlastně celý samostatný procesor, který překládá archaický 8086 kód do RISC kódu každého procesoru. A teprve ten pak "nadupané CORE" vykonává.

Instrukce v RISC světě zásadně vypadají tak, že mají jednotný formát - moje milované AVR má 16 bitové instrukce PICky mají v rámci Harvardské architektury instrukce exotických délek 10, 12, 14, 16 bitů a dokonce mají i slova v programové paměti v těcho "divných délkách". No a ARM měl v první verzi instrukce 32 bitové.
Už to samo je zrychení, protože v každém taktu prostě načtete 32 bitů z paměti a co to znamená řeší už jiní trpajzlíci.
Takže formát instrukcí ARMu vidíte na obrázku. Bity 31-28 jsou přítznakové bity, - každá ARM instrukce tedy může být vykonána podmíněně, existuje dokonce i kombinace přiznaků "DO NOT EXECUTE" a tedy ARM má asi nejvíce typů NOP instrukce ze všech procesorů na světě.
Pak je pár bitů, které u ostatních procesorů znamenjí něco jako "operační kód", který rozhoduje o tom co instrukce bude dělat - u ARMU těcho pár bitů rozdhoduje o tom do které skupiny instrukčních kódů patří zbytek instrukce a podle toho je pak nastaven i ten zbytek - viz obrázek.
Nebudeme probírat celou insrukční sadu. Jenom pro ilustraci ARMovského konceptu "Instrukce v instrukci" jsem vybral podkapitolu "aritmetických instrukcí". Vidíte tam pole pro zdrojový a cílový registr a pak pole kam se dává buď druhý zdrojový registr - vrámci tříregistrové ARMovské aritemtiky, nebo "imediate value" - konstanta která se použije do výpočtu.
Hodnotu registru je ještě možné rotovat, takže pole pro třetí operand má ještě svůj vlastní subformát, který vidíte na obrázku.
Koncept "Instrukce v instrukci v instrukci" je opravdu účinný - takže měkteré vybrané ARMovské instrukce odpovídají celým kratičkým fragmetům kódu jiných procesorů o délce 3-4 instrukce. Tudíž u ARMu nevadí ani to, co se někdy RISCovýcm procesorům vyšítá a to jsou příliš dlouhé 32 bitové instrukce.

Jenom pro demonstraci opakuju příklad překladu jediné instrukce ARM "BICEQ R2, R3, ASL #3" do kódu 8086, který má 4 Instrukce :
JZ je_nula - přeskoč celou sekvenci pokud je nastaven nulový příznak
SHR EBX, 3 - posuň EBX o 3 bity ( to je to #3 u ARMu )
NOT EBX - neguj Bity v EBX
AND EAX, EBX - udělej logický součin s EAX
:je_nula - toto není instrukce - jen adresa kam se skočí když není nastaven nulový příznak

32 bitů široké instrukce nedělají problémy ve stolních PC a v klasických procesorech s 32 bitovými sběrnicemi, ale ARM prorazil i na pole mikrokontrolérů - a tahat po plošném spoji nějakého soustruhu, robota, váhy, nebo stojanu na benzín 32 drátů je problém, takže se objevily ARMy jen se 16 bitovou datovou sběrnicí. Tím bylo nutno instrukce načítat ve dvou taktech - což srazilo výkon "jednotaktových" ARMů na polovinu. Dnes už klasický příklad je Gameboy Advance - který byl ve své době velmi populární, protože Hackeři našli cestu jak do něj nahrát vlastní firmware a udělat z něj výkonný malinkatý a laciný počítač v době kdy ještě "nebyly smartphony" ani Raspberry PI - taková věc byla vzácností.
Firma ARM (Arm znamená Acorn Risc Macines ale taky to znamená "paže") proto vymyslela řešení. Nakonec přece jenom doplnili "druhou vrstvu" instrukčního dekodéru a přidali do ARMu druhou instrukční sadu "Thumb" což zas pro změnu znamená "palec".
Thumb Instrukce jsou 16 bitové a toho je dosaženo tím, že
  • nemají pole podmínek (ušetříme 4 bity)
  • jsou dvouregistrové (ušetříme jedno 4 bitové registrové pole)
  • Mohou pracovat jen s 8 registry (ušetříte dva bity z čísel instrukcí)
  • atd ....
Jinými slovy THUMB připomíná daleko více "normální instrukční sadu normálního procesoru"
Když jsme se zbavili výhod ARMovského instrukčního souboru - patrně byste očekávali, že dopad na výkon procesoru bude katastrofální, ale kupodivu ne - i "Bezstarosťák" kdysi popisoval své osobní zkušenosti, že C přeložené do THUMB kódu je jen o pár procent pomalejší než C v ARM kóud a při komunikaci po 16 bitové sběrnci je dokonce rychlejší (pochopitelně).

To že následky na výkon nejsou tak tragické - mě podporuje v názoru, že ARM instrukční sada je příliš komplexní pro nedostatečnou inteligenci kompilátorů a teprve jednodušší THUMB umožní při konstrukci kompilátoru využít letité zkušenosti z ostatních architektur.

Aby pohádce pořád nebyl ještě konec - dneska je zcela jiná situace než v době vzniku ARMu v roce 1985, protože dnes už se v architerturách čipů nebojuje o ušetření každého tranzistoru. Takže s nástupem ARM jader typu CORTEX se patrně zdála vývojářům od ARMu THUMB instrukční sada příliš omezujcí - tak zavedli instrukční sadu THUMB 2. Ta mezi striktně 16 bitové Thumb Instrukce přidává další 32 bitové THUMB 2 instrukce - které se dají volně "místit" mezi 16 bitové THUMB instrukce (bez přepínání režimu ARM/THUMB jako u puvodnho ARMu) Je zvláštní že 32 bitové THUMB instrukce jsou jiného formátu než 32 bitové ARM instrukce (nemají například pole podmínek).

Je zajímavé jak se může procesorová architektura postupně vyvíjet - až se nakonec všechhy architektury začnou poněkud podobat - asi jako se delfíni podobají žralokům, když už oba žijí v moři. V každém případě ARM je momentálně nejrozšířenější procesorová architektura na zeměkouli, a vzhledem k množství typu a cenám procesorů ji doporučuju vaší důtklivé pozornosti.

Tím bych pojednání o procesorech považoval prozatím za vyčerpané - zbývá už jenom tradiční rada pro blondýny : Barevná shoda boty - kabelka je pro důchodkyně - jestli jste náležitě odvážné zkuste barevnou shodu - kabelka - kalhotky, které občas "ukážete" pod větrem povlávající minisukní.

Instrukční sady procesorů 2. Instrukční dekodéry

11. dubna 2013 v 5:11 | Petr
Čistě jenom pro pobavení jsem namaloval (a mobilem vyfotil) obrázek "své představy" procesoru z minulého povídání
Takže jestli jste přestali slzet smíchem tak jenom dodávám, že ten zamračený profesor s nečitelným popiskem nahoře je "Instruction Decoder". Takže jenom pro informaci - buldozer občas nazývaný "bus interface unit" skrývající se pod assemblerovou instrukcí LOAD - hrne zelí na pás, kde roboti - fukční jednotky - jej postutpně zpracovávají na konzervy se segedínským gulášem, který "bus interface unit" - tentokrát reprezentovaná instrukcí STORE - ukládá zpátky do skladiště (paměti) - jak se mají "roboti" hýbat určuje loutkář "instrukční dekodér", který tahá za drátky.
Možná se budete divit, ale ta představa zase není tak absurdní jak se zdá, protože mezi instrukčním dekodérem a výkonnými jednotkami jsou v procesorech opravdu sběrnice s desítkami signálů a spolupráce instruční dekodér - aritmetická jednotka se nápadně podobá výpočtům na kalkulačce, která má taky klidně 60 tlačítek.

Přestavíme - li si že z instrukčního dekodéru vychází taky 60 signálů pak množství kombinací které může dekodér vygenerovat je 2^60. Vzhledem k tomu, že žádá procesorová architektura nemá tolik instrukcí je jasné, že při konstrukci procesoru se postupuje takto :
- Všechny signály nutné pro řízení aritmetických jenotek se vyvedou na nějakou sběrnici (to je těch 60)
- pak se z nich vyberou smysluplné kombinace - které odpovídají použitelným instrukcím
- smysluplné kombinace se očíslují (to jsou kódy instrukcí v paměti)
- čísla instrukcí jsou zároveň adresou paměti instrukčního dekodéru - kde každé slovo má 60 bitů a obsahuje kombinaci signálů nutných pro vykonání dané instrukce

Jasné ? V dnešní RISCové době je to tak jednoduché - v době klasických procesoů CISC to bylo ještě poněkud komplikovanější, protože číslo instrukce bylo vlastně startovací adresou "mikroporgramu" skládajícího se s vnitřních "mikroinstrukcí" které se vykonávaly často mnoho taktů než byla instrukce hotova.

Místo mikroprogramů mají dnes CISC procesory typu 8086 hardwarový překladač, který dělá de - facto to samé, ale "před vraty továrny" takže "za vraty" už je jenom jenotaktový dekodér vnitřních RISC instrukcí - jak jsem popsal. Výhodou "dělání RISC kódu" ještě před instrukčním dekodérem, je to, že pak se dají RISC (mikro) instrukce různě párovat, kombinovat a vysílat do různých funkčních jednotek ALU, CPU, které pracují všechny paralelně a daleko rychleji než CISC procesor s mikrokódem.

Proč mě tak fascinuje ARM - protože u něho ten bod s "očíslováním smysluplných kombinací signálů" neproběhl a tudíž ARM ač RISC tedy Reduced Instruction Set Computer - má tolik kobminací instrukcí, že snad žádná architektura nemá v tak (relativně) skromném hardwaru takové možnosti.

Proč je to důležité - jestli je instrukční kód jednoduchý nebo složitý ?
Pokud máte 35 jednoznačně definovaných instrukcí - psát dobrý program v assmebleru dokáže i programátor blbec nebo kompilátor blbec. Tudíž i programátor kompilátoru - blbec - bude se svým výsledkem produkovat alespoň "standardní" kvalitu kompilovaného kódu.

Naopak pokud máte velice komplexní assembler , kde jedna instrukce dělá tolik operací jako malý podprográmek na jiné architektuře. Viz už zmmiňovaný BICEQ R2, R3, ASL #3 - je otázka generování optimálního kódu velice složitá - a osobně si o programech pro ARM myslím, že krom nějakých intenzivně probádaných procedur u si u ARM assembleru nikdy nemůžete být jisti jestli neexistuje ještě lepší způsob jak danou věc naprogramovat - což platí jak pro lidi tak pro kompilátory. Asi na tom něco bude, protože podle různých informací se rycholost i velikost kódu pro ARM výrazně liší podle kompilátoru nebo dokonce podle verze kompilátoru.

Dnes už opět končíme, zbývá opět jenom tradiční rada pro blondýny : Muži mají jenom dvě emoce - buď jsou nadržení, nebo hladoví, takže pokud ten váš nemá erekci - vařte večeři.
Angelina Jolie

Instrukční sady procesorů 1. Great processors of the past.

4. dubna 2013 v 5:23 | Petr
Ještě než začnu cokoliv psát MUSÍM doporučit skvělé čtení na toto téma Great Microprocessors of the past and present. Což je fascinující čtení o plahočení se za maximálním procesorovým výkonem, které prostě musíte přečíst jinak u mě nejste Geek !!

Jinak je to jasné - mládež je z dnešního příspěvku plná zklamání ze "strejda je chce unudit k smrti" když přece kažej ví, že o ten hnusný strojový kód se stará kompilátor Céčka. Jenomže, to není zdaleka tak snadné - názory na instrukční sady procesorů se vyvíjely, a máme neúspěšné instruční sady jko je Intanium, nebo Intel 432. Pak máme instrukční sady, které jsou schopny poskytnout obrovský výkon, ale jsou složité, takže kompilátory to nezvládají jako je Intel 860.
Pak je docela zajímavé sledovat zásadu čím je jednodušší hardware, tím musí být (většinou) komplikovanější software, toho je příkladem vývoj procesorů od PIC10 po PIC32.

Všechno se dočtete v "procesorech", které jsem vám doporučoval, co ale chci dneska probrat je mikrokontrolér a mikroprocesor současnosti a patrně i dlouhé budoucnosti a to je ARM a ty záležitosti jeho designu a instrukční sady, které jsem nakousl minule.

Takže vezměme nejprve jak vypadá procesor - když jsme my chteli mít jedničku museli jsme u tabule vykládat, že se sklárá z aritmeticko - logické jednotky, řadiče a bůh ví čeho ještě, co jsme už tehdy věděli, že není tak úplně pravda.
Takže procesor je "továrna" na výpočty, pokud má více jader - je to více továren v jedné hale. Středem haly vede pás na "rozdělané" instrukce, který je z obou stran hustě obstoupen "trpajzlíky" kteří na výpočtech intenzivně dělají.
Před tímto pásem jsou dvě skladiště - nazvaná data a program. Pokud jsou data i program ve stejné paměti je to Von Neumannovský procesor, pokud jsou data i program každá ve své paměti je to Harvardský procesor. Paní učitelka dává za neznalost tohoto rozdělení pětky, ale stejně je to jedno protože dneska všechny procesory se z venku jeví jako Von Neumanovské ale uvnitř maji rozdělenou datovou a instrukční cache, takže jsou bez výjimky Harvardské.
Montážní linka s trpajzlíky končí zase v paměti pro data - bez ohledu na architekturu procesoru.

Už minule jsem psal, že existují CISC s komplexními instrukcemi a RISC procesory s jednoduchými instrukcemi, což zase je důvod dávat ve škole pětky, ale dávno to není pravda, protože dneska jsou CISC procesory architektonicky neodlišitelné od RISC a naopak existují RISC procesory zrovna jako ARM nebo PowerPC, které mají tak komplexní a složité instrukční sady, že by se za to ani leckterý CISC nemusel stydět.

Prakticky je dělení jiné - filosoficky - jsou dvě velké skupiny procesorů - LOAD / STORE - ty si představujte tak, že na začátku výrobní linky je velký bagr LOAD, který vybírá data z paměti a klade je na pás a na druhé straně je buldozer STORE, který tlačí data zpátky do paměti a nikdo s trpajzlíků už nemá do paměti přístup. Takhle je udělána většina procesorů označovaných jako RISC.
Druhá varianta je tzv. MEMORY / DATA architektura - ta je starší a dá se popsat tak že každý trpajzlík kolem pásu jednou rukou se hrabe v tom co jede po pásu a druhou rukou - ohromně dlóóóúhou se hrabe v paměti. Takhle jsou udělány starší procesory typu CISC. Už z tohoto dětského příměru je jasné, která architektura je rychlejší, dneska používanější a proč tomu tak je.
Tvrdíte, že jste četli že nějaké to CORE i7 u vás doma je procesor typu 8086 a tudíž je CISC - taky jste naletěli na tu fintu? Problém je v tom, že jednoduché procesory typu RISC se ukázaly natolik výkonnější, že dnešní procesory, které z důvodu historické instrukční sady musí být CISC se vyrábějí jako "procesor v procesoru". To znamená, že nejprve je hardwarový překladač z kódu 8086 do nám utajeného RISCového kódu - tenhle hardwarový překladač je sám o sobě složitější než celé procesory v minulosti - teprve jeho výstupem je RISC kód, kterému CORE rozumí.
Pokud se chystáte rozebrat doma notebook - tak zadržte - překladač je uvnitř čipu samotného CORE - takže nekažte taťkovi notebook.

Hardwarový překlad 8086 instrukcí je opravdu extrém, ale každý procesor potřebuje bajty v paměti nějak překládat na instrukce a instrukce zase potřebuje překládat na příkazy "za které páky tahat". Takže centrem každého procesoru je instrukční dekodér, který rozhoduje o tom jestli takový procesor bude v assembleru "radost" nebo "hrůza" programovat.

Jak to tedy funguje - řekněme že máme RISC který má 32 registrů - což vzato číselně je binární číslo o 5 bitech. Instrukce takového procesoru musí obsahovat minimálně 3 části. Co se má dělat - řekněme že je to extrémní RISC, který má jenom 16 možností - to jsou 4 bity v instrukci, pak odkud brát data - to je jednočíslo registru - 5 bitů a pak kam dát výsledek - druhé číslo registru - to je dalších 5 bitů. Každá taková RISCová instrukce má tedy 14 bitů. U harwardských procesorů typu PIC to může znamenat, že máte i paměť pro program složenou ze 14 bitových slov - což je zrovna případ PIC16 jestli se nepletu. U Von Neumannovských procesorů je lepší zachovat instrukce jako násobky 16 bitů takže instrukce často bývá doplněna o další bity se speciální funkcí.

Jak tedy takový procesor pracuje - vezme instrukci a 4 "příkazové" bity vyšle do aritmetické jenotky na znamení co se má udělat. A 2x 5 bitů pošle na vnitřní sběrnici procesoru, která má většinou dvě větve "zdrojový" a "cílový" registr - patřičné dva registry se připojí k vstupním a výstupním hradlům aritmetické jednoty a ta v příštím taktu udělá výpočet.

Jednnoduché jako facka ?
Zas ta jednoduché to není - budu se ptát a sám si odpovídat - jak moderní procesory stihnou udělat v každém taktu jednu instrukci když každá instrukce vyžaduje několik operací ? - Princip je právě v tom pásovém zpracování - anglicky "pipelined insruction" - jako v automobilce na páse jde procesorem pás různě nehotových instrukcí a každým taktem se instrukce o jednu pozici posunou - ergo každým taktem na konci jedna hotová vypadne.

Jak se dělají instrukce, které nic nikam nezapisují ? Většina RISCových instrukčních sad má své "finty" které uživateli moc neukazuje - když dáte v AVR instrukci CLR R16 tedy vynuluj registr - budete překvapeni že assembler to přeloží jako XOR R16, R16, protože žádná instrukce nulování de facto neexistuje. Navíc spousta RISC procesorů má jeden registr na tvrdo nastavený na 0 - ať do něj píšete co chcete pořád je to nula - pak třeba instrukce NOP - čekej jeden takt se překládá ADD R1, R0 kde R0 je "nulový registr".
Nebo některé procesory (zrovna ARM) je tříregistrový procesor takže umí udělat ADD R1, R2, R3 což znamená že v instrukci jsou 3 pole pro číslo registru a instukce znamená že R1 = R2 + R3. pak jednoduchá instrukce MOV R1, R2 vlastně je identická s instrukcí ADD R1, R2, R0 neboli R1 = R2 + 0.

Opět jsem přecenil své možnosti, takže na samotný ARM se dostaneme příště.
Dnes už jenom tradiční rada pro blondýny : když máte 160 cm výšky a 80 kilo váhy je to body mass index 31,3 - v pásmu obezity, pokud si vezmete 20 centimetrové podpatky budete mít 180 cm a to je při stejné váze body mass index 24,7 - v pásmu normy - a pak že prý "podpatky škodí zdraví" - pche....

Přesýpací hodiny, které jdou čím dál rychleji.

30. září 2012 v 4:59 | Petr
Škoda, že si nevedu nějakou bibliografii, protože teď bych nutně potřeboval link na prorocký článek, který jsem četl už aspoň před 10 lety. Ten článek popisoval situaci v oblasti PC softwaru, kde pokaždé, když uživatelský interfejs dosáhne rychlosti Klasické Amigy, s procesorem 68000 na 8 MHz přijde nějaký jouda a vymyslí nějakou úroveň abstrakce která usnadní život programátorům, ale zato pozře nadbytečný výkon. JAko důkaz uváděl ECLIPSE což je IDE psané v intepretovaném jazyku - JAVĚ.

Osobně dráždím mládež, která prd pamatuje otázkou, proč jsme tak dlouho vydrželi s operačními systémy baz multitaskingu - jako je legendární a dnes už zapomenutý MS-DOS. Starci v mém věku odpověď znají, ale mladým musím napsat smutnou pravdu. Mutitasking jsme nepotřebovali, protože to jediné k čemu jej uživatel běžně využívá - to jest k přepínání programů z "lišty" na "celou obrazovku" a zpět bylo nahrazeno startováním programů, které byly schopny nastartovat rychleji než dnešní softwary překreslí obrazovku. V závěru MS-DOSu bylo standardem, že programy si pamatovaly poslední nastavení, takže když jste přepínali mezi MATem (textový editor) a Quattro pro (tabulkový kalkulátor - pro blondýny pra-EXCEL) byla odezva PC stejná, nebo lepší než dnes - s výkonem o mnoho řádů menším.

Když pozdeji přišel multitasking ve windows ten byl až do WIN95 kooperativní - takže všechny programy si předávaly procesor "dobrovolně" takže to byl vlastně zase MS-DOS akorát programy byly v paměti všechny najednou, což neslo nevýhodu že jeden spadlý program s sebou vzal všechny ostatní.

Pak přišly WIN95 které si hrály na preemptivní mutitasking dnešního stylu, ale to byla jen iluze, protože ten fungoval jen pro 32 bitové programy, kterých po vládě 16 bitových Widows 3.11 byla žalostná menšina.

Pokud to vezmeme reálně tak Microsoft vyrobil jen dva slušné operační systémy - Windows 2000, které jsou dodnes považovány za krále MS OS a pak - líbívou verzi téhož Windows XP, které byly opravdu tak dobré, že se jich dodnes nemůže zbavit.

Čím to je, že Quattro startovalo v roce 1994 za vteřinu a Excel dneska minutu a o Open Office (které je částečně v Javě) ani nemluvím ? Jsou to ty další "úrovně abstrakce" kdy dvacátá vrstva softwaru absolutně netuší co 19 vrstev pod ní vlastně dělá ?
Nebo je to tím, že všechno se dneska programuje objektově takže když napíšete
A := A + 3
Kompilátor vyhodí chybu, protože v objektové době jste měli napsat
SystemObjectInstance.A.Add (SystemObject.GetNumber (3))
(příklad jsem si vymyslel, ale takové zdrojáky se dnes běžně píšou).

No a samozřejmě přichází nepříjemná otázka - vyzná se kompilátor v objektovém kódu do té míry aby příkad 2 optimalizoval až na kód identický s příkladem 1 (když oba dělají stejnou věc). Protože naivním překladem objektového kódu vznikne mižmaš procedur dlouhých několik bajtů a skákání mezi nimi.
Je takovým mižmašem napsaný dnešní software ? Který ještě pro jistotou a pro "Easy portability" je napsán v nějakém skriptu nebo Javě ? Který běží na Operačním systému psaném stejným mižmašem ? Vědí programátoři (v Microsoftu), že výkon procesorů už léta (fakticky) neroste ?

ATD, ATD mohl bych vypsat ještě stránku spekulací, ale místo toho zase výlet do historie. V 80 - 90 letech se vždycky psalo - pokud poroste výkon PC jako dneska za 5 let budou počítače mluvit, rozumět mluvenému slovu, samy rozhodovat, nakupovat, vařit, provozovat sex, atd. (dosaď další podle fantazie) - uplynulo 30 let a nic. Teda ne nic - je tu třeba SIRI na Applu - ale to že se nerozšířila ven svědčí o tom že to je nezralá věc, kterou nelze používat bez nekritického obdivu k celému "jablečnému ekosystému".

Kde jste roboti chodící pro nákup ? Kde jste expertní systémy diagnostikující rakovinu z nepatrných příznaků (kromě článků, na základě kterých se pan docent stal panem profesorem) ?
Kde jste počítačová moudrosti - sežrala vás lenost lidí, kteří upřednostňují rychlost programování (politicky korektně zvanou produktivita) před kvalitou kódu ? Má 1 směna práce programátora větší cenu než milionkrát 1 sekunda čekání uživatelů ? Pesimista by řekl, že nic ze Sci-fi možností počítačů nebude. Já optimista doufám, že až i baba Dymáková pochopí, že výpočetní technika je už leta na fyzikálních limitech, třeba si někdo sedne a začne přemýšlet jak psát programy alespoň tak efektině jako hry pro ZX Spectrum z roku 1983 .....

Úloha posvátné hrůzy ve výpočetní technice

15. července 2012 v 5:44 | Petr
První opravdové PC jsem viděl v roce 1989 na Brněnské Hvězdárně. Kdo absolvoval kurs, zapsal se do pořadníku, byl vyzván, ukázal, že má umyté ruce (klávesnice ze Zbrojovky Brno stála kolem 200 000) mohl pak hodinu třeba programovat v Turbo Pascalu na 8086 na 4,77MHz se 256 kB (kilobyte!!) RAM. Je zvláštní, že subjektivně tohle PC mělo mnohem pomalejší odezvu než moje domácí Atárko 800XL.

Nicméně v roce 1992 začalo být jasné, že Atárko je morálně mrtvé a je čas přeorientovat se na PC. V podivuhodné době vycházela podivuhodná literatura. Takže jsem si koupil knihu Assembler a BIOS a pak knihu Příkazy MS DOSu - obě jsem podrobně přečetl a protože v obou knihách chyběly na samém začátku tři řádky o tom jakou úlohu hraje předmět knihy tedy BIOS, nebo příkazy COMMAND.COMu v celém systému PC, tak jsem prakticky nic nepochopil.

Pak máti koupila PC, které bylo třeba rozchodit, po zapnutí se objevilo C:\>_ . Tak jsem ve smrtelné hrůze napsal DIR a odentroval - a najednou se to stalo - obsah obou knih najednou začal dávat smysl a já jsem se ve vteříně stal nejorientovanějším v PC na celém sídlišti. Mimochodem kdo ví co znamemá "C:\>_" a "DIR" ať se jen tak pro srandu ozve do diskuse. Takže jsem rozchodil nějaký program pro generování "disket" pro VZP pro mojí máti, pro její sousedku pediatryni MUDr. Petříkovou a tím se můj věhlas rozšířil tak daleko, až se mi ozvali z Brněnského ústavu pro slepce, kde koupili za 2400 kč OEM verzi DBASE III, ve které, ode mně, chtěli naprogramovat evidenci slepých děcek - taková to byla doba .....

Pak se mi stalo, že na Invexu 1993 jsem zabloudil k počítači s grafickým displejem a myší - tak jsem klikal na okénka a ony se různě obracely a deformovaly - jenom nedostatek informací mi zachránil život protože ten stánek byl Silicon Graphics v době svého vrcholu a onen počítač byla nějaká 64bitová 3D grafická stanice jménem "SGI ONYX" - velikosti malé ledníčky za mnoho miliónů s jejich 3D IRIXovým file managerem.... Možná kdyby se Microsoft hodně snažil tak ode dneška za 10 let bude mít takové GUI, které mimochodem už tehdy trochu připomínalo monitory ve hře DOOM 3.

Po této zkušenosti byl přichod Windows pro mně neustálým čekáním kdy konečně to bude "jako na Invexu" a musím konstatovat, že tomu tak není dodnes. Navíc Microsoft Windows mají minimum charizmatu - klikáte na ikony a maximálně se do některých zákoutí systému nedostanete, neboť tam sídlí informace o tom jak na vás Widle práskají Microsoftu, že jste zkoušeli pustit upirátěný prográmek z flashky....
Naopak v Linuxu, se kterým teď experimentuju je charizma a posvátná hrůza hlavním designovým principem. Stačí jenom sledovat úvodní obrazovku "initializing ALSA Daemon ...." Boha jeho - ALZA démoni v mém počítači, který jsem přece koupil od Kamila ne ? ;-)) Nebo všudypřítomá nenápadná symbolika - Linux pustí 7 terminálů a až ten 7. je X-terminal, ten vás pustí ke známým věcem jako je myš a ikonky - 7-pater pekla přímo ve vašem PC....

Pak začnete zkoumat filesystém a na rozdíl od Widlí se jako ROOT dostanete všude - "SUDO MC" ;-)) - ale stejně Vám to nepomůže, protože nerozumíte ničemu. Díky filosofii "vše jako soubor" si v adresáří /proc/ (který ve skutečnosti neexistuje) - otevřete procesor a sledujete jakou frekvencí právě jede - neuvěřitelné - v hlubinách systému se "malé EEE" tváří stejně jako 500 procesorový mainframe v cenrále Lehman Brothers ještě před krachem....

Říká se že LINUX je odolný proti virům a blbosti uživatele, ale není řečeno proč. Konstrukce softwaru v tom hraje jenom menší roli - větší roli hraje posvátná hrůza lidí i virů, nad systémem, kde modernost součastnosi a historie 60 let typu "/dev/tty2/" umí existovat pohromadě.

kilo mega giga tera peta exa zetta yotta

1. července 2012 v 4:32 | Petr
Dobu kdy člověk trafopájkou v potu tváře stvářel PMI 80, které mělo v první verzi snad jen 256 byte RAM jsem teda nezažil, ale zažil jsem "kilobajtovou" dobu kdy jsme seděli u Atárka 800XL a čekali 5 minut až se z kazety nahraje Fort Apocalypse, které podle tehdejší šeptandy mělo celých 24 Kilobyte !!
Pak si pamatuju na AMD 386DX40 která se dodával s harddiskem standardní velikosti 40 megabyte. A na ten jsem si potajmu nahrál Wolfenstein 3D který měl 2,4 Megabyte - z jeho grafiky se mi úplně točila hlava a když jsem potkal milence cestou z ordinace mojí máti (doma jsme PC neměli) tak jsem instinktivně na ně prstem udělal PUF PUF PUF a pak jsem těžce přemýšlel jestli bych té střílečky něměl nechat. (Mimochodem pořád ji mám i na současném disku a umím ji v Dos Emulátoru rozdchodit !!!)
DOOM 1 už na 386 moc dobře nešel. Muselo se snížit rozlišení a hra vypadala jako svět penzisty se šedým zákalem a navíc měl úplně drzých 18 Megabyte což bylo na 40 megabajtový disk už moc.
Pak se stalo mnoho věcí a jedna z nich byla, že jsem si koupil první Pentium 75 MHz se 8 MB RAM a tehdy populárním 524 Megabajtovým diskem. Tam už Doom jel jako báseň a celá ulice chodila ke mně pařit. Dodneška si pamatuju jak jsem s kámošem jel v dešti na kole z Frýdku na Visalaje a uklidňoval jsem ho ať svůj 400 MB disk nemění za 524, že i ten se jenou zaplní ....
Pak jsem chvilku přestal PC svět sledovat a najednou bylo všechno v desítkách gigabajtů - na radio-burze jsem obrovsky výhodně koupil disk - 80 Gigabajtů a pak jsem se dočetl v místní černé kronice, že z havarovaného polského kamiónu se jich tisíce ztratily. Pak jsem k němu přikoupil ještě 120 což už tehdy byla nejmenší velikost, ale moje WINDOWS 98 stejně z neho viděly jen 80 GB - oba mám ještě doma. Pak jsem koupil notebook se sériovým a paralelním portem - což vyhnalo jeho cenu nad 30 000 a musel jsem kopmromisně koupit disk do notebooku zase jen 80 GB ale k němu jsem časem koupil 320 GB externí.
Pak nastala ta nehoda, že mě sbalila ženská, která konzumuje romantické komedie jako divá, když jich bylo 200 Gigabyte koupil jsem tento víkend 2 terrabajtový sítový disk. Na obrázku stojí u zdi ani jako pořádná knížka není. Kdo by si v době Fort Apocalypse myslel že se dožiju 2 terrabyte to je v desítkové míře 2*10^15 byte nebo ve dvojkové je to 2^51.

Kam to dojde - za 30 let jsme se posunuli o 12 řádů takže než umřu budou disky 10^27 to jest Yotta-bajty ? Nebo narazíme na "meze růstu" jak už jsem jednou psal ? V každém případě v době Atárka nam stačila předpona Mega - desítky Megahertzů na rádiu a stovky Megawattů elektříny, které v rámci soudružské pomoci tekly z Dukovan do Sovětkého svazu, jak nám vysvětlil soudruh Bilak.

Terrabajtový disk si vrní v obyváku a já čichám za rohem technologickou singularitu, nebo mnohem pravděpodobněji joudy z EU / BSA / Microsoftu, kteží v rámci mého blaha a na základě smluv typu ACTA - PIPA - SOPA, mi přijdou tuhle hračku zabavit ....
 
 

Reklama