V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Společnost Framework Computer představila novou vylepšenou verzi svého modulárního notebooku Framework Laptop 13 s Intel Core Ultra Series 1, displej s lepším rozlišením a novou webovou kameru. Přímo do Česka jej zatím koupit nelze.
Byla vydána nová verze 2.16 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
TerminalTextEffects (TTE) je engine pro vizuální efekty v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Od čtvrtka 30. 5. do soboty 1. 6. lze v Praze navštívit Veletrh vědy, tj. největší populárně naučnou akci v České republice, kterou každoročně od roku 2015 pořádá Akademie věd ČR. Vstup zdarma.
Canonical představil Ubuntu optimalizované pro jednodeskový počítač s RISC-V procesorem Milk-V Mars.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 24.5.1 Havier. Přehled novinek v Changelogu.
Společnost xAI založena Elonem Muskem a stojící za AI LLM modelem Grok získala investici 6 miliard dolarů.
Tak mě napadlo (poté, co jsem dumal nad ovladači pro WiFi a vyslechl přednášku o OpenFirmwaru - ahoj, Aničko, opravdu se mi líbila), proč vlastně nepřidat do kernelu malý interpret nějakého bytekódu v duchu Forthu?
Jistě se ptáte, k čemu by to bylo dobré (tedy kromě duševního cvičení).
Správná otázka. Nuže: Na drivery. Zejména na ty, které nejsou součástí základního jádra.
Kdyby se totiž driver napsal v bytekódu, který by měl předem dané a známé instrukce, vyřešil by se tím problém proměnlivosti vnitřních struktur jádra. Autor driveru by se prostě s těmito strukturami a voláními vůbec nezabýval, to by za něj udělal interpreter bytekódu. Pokaždé, když by se tyto vnitřní věci změnily, patřičně by se upravily vnitřnosti interpreteru, instrukce by ale zůstaly stejné a drivery by fungovaly beze změn.
Co práce a nervů by se ušetřilo - zvlášť pro autory externích kernelových modulů... Možná i výrobci hardwaru by byli ochotnější dodávat drivery pro Linux, kdyby věděli, že to nebudou muset přepisovat s každou další verzí kernelu.
Co na to říkáte? Je to geniální myšlenka, nebo úplná pitomost?
Přinejmenším jeden argument proti už mám: Kolega, kterému jsem se s tímto nápadem svěřil, zastává názor, že by to bylo příliš pomalé. To je bohužel velmi platná připomínka, ale doufám, že přinejmenším u určité skupiny driverů, například taková Wifi, by to nevadilo.
Tiskni Sdílej:
Na experimentování s mikrojádrem máme HURD, tak ať Linusův kernel zůstane hezky tak jak je, ale ten nápad s interpretem nevypadá špatně. Mít více možností nemusí být na škodu.
Jinak upozorňuji, že v problematice se neorientuji ;).
ale to si udělá každý při kompilaci jádra. Takže autora ovladače to neobtěžuje, nic nemusí měnit.S vynimkou closed source driverov, o ktorych je rec
Třeba protože tam už jeden dynamický překladač bytekódu je, a je efektivně implementován v hardware? (x86 ISA -> ROPs).O tom vůbec nevím, co dělá, takže k tomu to nemůžu nic říct...
Navíc netuším jak by mohla abstakce *KÓDU* odstínit od změn v datových strukturách.Programátor v bytekódu nemusí přistupovat přímo na datové struktury v jádře, protože nepotřebuje volat funkce z jádra, která s nimi pracují. To místo něj dělají instrukce bytekódu a odpovídající data mu bytekód dodává dohodnutým, předem definovaným způsobem.
To je záležitost zavedení a dodržování (dnes neexistujícího) kernelového ABI, a ničeho jiného.No jo, jenže zavedení jednotného kernelového ABI není v současné době reálné a má to kromě formálních i technické důvody, takže tudy cesta nevede, alespoň teď ne...
Ten "dohodnutý způsob" odpovídá zmrazení binárního rozhraní do kernelu v určité verzi- to lze ale snadno realizovat i bez bytekódu, ten je pouze nadbytečný a nijak nepomůže.Myslím, že to není úplně pravda. Interpret bytekódu jako "tlumočník" mezi driverem a zbytkem jádra může provádět poměrně složité věci, které by se pomocí wrapper-funkcí dělaly špatně. Hodně vykonstruovaný příklad: bytekód může umožnit, aby driver fungoval jako stavový stroj bez složitých callbacků. Například si představ instrukci "alokuj určitou oblast paměti/připrav nějaké zařízení a zavolej mi, až to bude hotovo", která se vykoná a hned se vrátí; interpret si něco chroustá v pozadí, zatímco bytekód normálně běží, a až je dokonáno, přesměruje se vykonávání bytekódu někam jinam.
Např. pro každý struct lze přístup k jeho položkám buď ustálit na konstantních offsetech, nebo je zpřístupnit pomocí set_/get_ funkcí.Mám pocit, že konstantní offsety struktur by při dalším vývoji kernelu strašně překážely. Funkce set/get by asi šly, ale pochybuju, že by všechno šlo napasovat na tenhle model.
Navíc každý virtuální stroj rovná se ztráta rychlosti a efektivity kóduTakhle obecně to asi nebude moc pravda, protože virtuální stroj mi umožňuje dělat dynamické optimalizace (když už ten cyklus prochází po 1000, tak si VM může říct, že by možná stálo za to vnitřek cyklu zoptimalizovat na rychlost), takže někdy může být virtuální stroj i rychlejší. Nic to ale nemění na tom, že pro psaní ovladačů mi to přijde jako dost velký úlet. Nehledě na to, že napsat takový virtuální stroj, který by byl schopen usoudit "hele, teď paří Dooma, tak mu ten ovladač WiFi zoptimalizuju na Dooma", by bylo složitější než s pomocí reverzního inženýrství napsat opensource ovladače ke všem myslitelným čipsetům WiFi karet v klasickém C a udržovat jejich API
vim
optimalizovaný pro dlouhé řádky nebo kontrolu pravopisu (třeba). Čímž stráví nesrovnatelně víc času, než vim
prováděním algoritmu optimalizovaného pro krátké řádky nad jedním dlouhý řádkem.
V praxi ony rovné podmínky nastávají jen zřídka kdy (nejlépe nějaké bechmarky ), takže ve výsledku se po tom nejrychlejším sprinterovi taky někdy chce, aby plaval nebo jel na kole, a tam už opravdu může být někdo jiný rychlejší
Jestli se nepletu, jsou už teď v linuxovém jádře vlastně dynamické optimalizace např. ve virtual memory subsystému (VM se snaží chovat jinak, pokud má málo paměti než když jí má habakuk), optimalizace zde ale není řešena bytekódem a samostatnou virtual machine, ale pouze jistou virtualizací samotného C kódu. Někdo, kdo sleduje vývoj kernelu víc než "jen" z Jaderných novin mne snad doplní, upraví nebo rovnou popraví