Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Abych vás nenutil hned zkraje odcházet na web výrobce, shrnu vám hlavní rysy CuBoxu.
Na rozdíl od Raspberry Pi dostanete svůj miniaturní počítač v černém plastovém obalu, není tedy „nahý“. Na zadní straně najdete vstup pro napájení 5 V, HDMI výstup, dva USB porty, eSATA port, slot pro kartu microSDHC a 1 Gbit/s ethernet port včetně indikace provozu. Zboku můžete vidět S/PDIF výstup, microUSB port a zpředu pak IR příjmač a červenou diodu indikující zapnutí.
Uvnitř krabičky se skrývá následující (základem je Marvell Armada 510 SoC):
Spotřeba samotného zařízení (bez napájení USB portů) by se měla vejít do 3 Wattů. Jako zavaděč je použit obvyklý U-Boot, který umožňuje boot nejen z SD karty, ale např. i z USB disku nebo sítě.
První boot byl dosti neveselý. Přístroj jsem zapojil, ale po spuštění mi na monitoru jen krátce problikl kurzor konzole a pak už bylo jen černo. Připojil jsem tedy CuBox k notebooku pomocí kabelu od mého telefonu. CuBox má sériovou konzoli dostupnou hezky pohodlně přes port microUSB, takže s příslušným modulem v jádře pak už stačí udělat jen screen /dev/ttyUSB0 115200.
Po chvíli zkoumání přes sériovou konzoli jsem zjistil, že framebuffer konzole funguje dobře, a to na FullHD rozlišení. X.Org ale na tom samém rozlišení naběhnout nechce – s mým monitorem HP se dostane do neshod: 1920x1200 totiž HDMI transmitter na CuBoxu neumí a na 1920x1080 se nepochopitelně pohádají. Prozatím jsem rozjel nouzových 1280x1024. Mimochodem, s televizí funguje CuBox na první pokus a hned si můžete ozkoušet, že Firefox a další věci na tom fungují dostatečně rychle.
Protože hodlám používat CuBox jako tenkého klienta s pár fígly (tzn., že takové přehrávání videa bude probíhat lokálně), hned jsem zkusil spustit X -query $xdmcp_server. Xka naběhla, já jsem se úspěšně přihlásil, ale hned po naběhnutí vzdáleného Xfce Xka spadla na kontrole paměti v Glibc. Něco je někde špatně. Po další zábavě, která vypadá takto:
root@cubox:~# pidof X 473 root@cubox:~# killall X X: no process found root@cubox:~# pidof X 473
jsem toho předinstalovaného Ubuntu měl plné zuby a rozhodl jsem se přejít na něco jiného, co bude hlavně rychlejší. To Ubuntu totiž mj. softwarově emuluje floating point operace (softfp), i když to tento hardware umí i pomocí koprocesoru (hardfp).
...na tak pomalém zařízení. Inu posuďte a sami se svým počítačem srovnejte, v jakých výkonnostních relacích se tu pohybujeme – výsledky z Ubuntu:
# openssl speed md5 Doing md5 for 3s on 16 size blocks: 394652 md5's in 3.00s Doing md5 for 3s on 64 size blocks: 351976 md5's in 3.00s Doing md5 for 3s on 256 size blocks: 265930 md5's in 3.00s Doing md5 for 3s on 1024 size blocks: 134109 md5's in 3.00s Doing md5 for 3s on 8192 size blocks: 23876 md5's in 3.00s OpenSSL 0.9.8k 25 Mar 2009 built on: Tue Jan 31 12:12:13 UTC 2012 options:bn(64,32) md2(int) rc4(ptr,int) des(idx,risc1,4,long) aes(partial) blowfish(idx) compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md5 2104.81k 7508.82k 22692.69k 45775.87k 65197.40k
Na druhou stranu je Gentoo vlastně dobrá volba, protože právě na takové herce se bude každá optimalizace hodit. Zásadní je nenechat CuBox v kompilaci napospas.
Prvním krokem bylo vytvoření crosskompilátoru na domácím (podstatně výkonnějším) serveru. Pak jsem na serveru rozbalil Gentoo stage3, vyexportoval ji přes NFS (nebudu kompilovat na pomalé SD kartě), na CuBoxu jsem se chrootnul a zkusil jsem první emerge. Tak pomalou kompilaci jsem už hodně dlouho neviděl – připomnělo mi to, když jsem jako osmiletý kluk proháněl MSVC++ na Pentiu 1 na 166 MHz. Ale teď CuBoxu trochu křivdím – než P1 rychejší je a hlavně má víc paměti.
Bohužel ani distcc v pump režimu se neukázalo býti přijatelně rychlé. Pak jsem zkusil qemu-arm a užitečný nástroj proot. Kompilace pod QEMU běží rychleji než nativně na CuBoxu. Navíc mi na serveru nedochází paměť, a tak se vyhnu zběsilostem jako swapování na flash disk (zdravím Windows a jejich TurboBoost) nebo na NBD (Network Block Device). Dalším řešením ale bylo sestavení jednoduchého skriptu, který spouští emerge v režimu crosskompilace. Za chvíli jsem takto ale systém dostal do stavu, kdy spuštění Bashe vyvolalo reakci Segmentation fault.
Teď už raději zase kompiluji přes noc přímo na CuBoxu, než pak muset hasit, co se kde pokazilo (co jsem kde pokazil).
A zatímco se Gentoo kompiluje, tak já přemýšlím, co mě vlastně čeká... OpenSSL z Gentoo stage3 dává tyto výsledky:
# openssl speed md5 Doing md5 for 3s on 16 size blocks: 506864 md5's in 3.00s Doing md5 for 3s on 64 size blocks: 443697 md5's in 3.00s Doing md5 for 3s on 256 size blocks: 316080 md5's in 3.00s Doing md5 for 3s on 1024 size blocks: 147246 md5's in 3.00s Doing md5 for 3s on 8192 size blocks: 24673 md5's in 3.00s OpenSSL 1.0.0g 18 Jan 2012 built on: Wed Mar 7 20:58:12 Local time zone must be set--see zic manual page 2012 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: armv7a-hardfloat-linux-gnueabi-gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -fno-strict-aliasing -Wa,--noexecstack The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md5 2703.27k 9465.54k 26972.16k 50259.97k 67373.74k
...což je znatelné přilepšení.
V jednu chvíli jsem si už myslel, že jsem poškodil ethernetový port nešetrným vytažením kabelu. Nakonec se jen ukázalo, že port je trochu háklivý na zapojení drátů – asi to mám v téhle zásuvce nějak divně (ale notebooku to vůbec nevadí), v jiné to už zase funguje.
Hardwarová akceleraci je důležitou věcí, pokud chcete na CuBoxu dělat něco víc než jen brouzdat po webu. Hardwarově je zde akcelerována 2D i 3D (OpenGL ES) grafika, stejně tak jako různé formáty videa (až do 1080p H.264), formáty obrázků (např. JPEG), ale i zvukové formáty.
Toť výcuc z informačního letáku a dalších „datasheetů“. Podstatné je, kolik toho out of box vlastně bude fungovat. Na Ubuntu asi rozchodíte akceleraci videa přes GStreamer (i když jsou na to dost stížnosti), ale na Gentoo mě všechno bude čekat od píky.
Prvním cílem je tedy rozchodit akcelerovaný framebuffer dovefb pod X.Org. Druhým cílem je mít fungující akceleraci videa pod MPlayerem, resp. FFmpeg. To bohužel znamená stát se programátorem a funkčnost si sám dopsat nad proprietární knihovnou od Marvellu. Při pohledu na větev (fork) XBMC s nově doplněnou podporou vMeta HD to ale nebude tak složité.
Ovladač dovefb není v Gentoo Portage. Asi je to proto, že je vyvíjen externě, a to zjevně v rámci projektu OLPC. Snad nebude padat.
Věci jako akcelerace dekomprese JPEG nebo třeba Vorbis OGG už beru jako naprostý bonus a pokud to náhodou implementuji, tak to už se budu sám plácat po ramenou.
CuBox má i zvukový výstup. Technicky má možná ten nejlepší možný zvukový výstup (optický S/PDIF), ale pro praktické použití to není úplně ono. Neboli sluchátka na to napřímo nepřipojíte a pokud ani váš monitor neoplývá zvukovým výstupem (z HDMI), tak nezbývá, než si sehnat nějaký ten převodník.
Já jsem zavítal na eBay a tam jsem hnedle nějaký našel. Akorát budu mít na stole místo jedné černé krabičky hnedle dvě. Nevadí. Pořád je mi to milejší než velká hučící bedna a nepříjemný účet od ČEZu... Zatím tedy čekám na zásilku z Hong Kongu.
V recenzi ozkouším jak původní Ubuntu, tak jiné (komunitně) nabízené systémy a jejich vhodnost ke každodennímu použití. Neopomenu i nějaké ty open source OpenGL hry a jejich výkon. A když už mám doma kino na bázi XBMC, tak otestuji, jak dobře by CuBox nahradil můj stroj postavený kolem NVIDIA VDPAU.
Zajímá mě ale i výkon ethernetového portu. Ten je oproti stomegabitovému portu na Raspberry Pi gigabitový, otázkou je, co hardware skutečně zvládne přenášet.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Pěkné, docela podobné mému TrimSlice Pro. (i když ten je samozřejmě hezčí :)
Další vývoj odhaduju takhle: pár dní si s tím budeš hrát, párkrát to přeinstaluješ, ale za týden, dva zjistíš že to je fakt moc pomalý na prakticky jakoukoliv činnost a skončí to v šuplíku. Resp v mém případě ve skříni ;)
To já uvažoval taky nad 8x8x8 3D krychlí, ale pouštěl bych tam muziku - teď nevzpomínám jak se tomu říká, prostě by to bylo jako osm bargrafů vedle sebe, co sloupec, to určitá frekvence. Akorát tohle by mělo navíc historii, frekvence posunování by byla nastavitelná - takže to vlastně jakoby pořád pojede
ale za týden, dva zjistíš že to je fakt moc pomalý na prakticky jakoukoliv činnost a skončí to v šuplíkuDíky této skutečnosti existuje tenhle článek
Tak to se obáváte špatně. Samozřejmě tedy záleží jak dokáže SW využít možnosti HW, to znamená jak dobře/špatně jsou napsané ovladače. Samotný 88AP510 po hardwarové stránce toho zvládne hodně (předpokládám hodiny 800 MHz):
Samozřejmě, při některých úlohách bude limitujícím prvkem CPU, ale ve skutečnosti bude počet takových nasazení celkem malý. 88AP510 obsahuje dost různých off-load periférií pro různé výpočty, šifrování apod. Otázka je, jestli implementace Linuxových ovladačů využívá všechny možnosti hardware.