Byl vydán Mozilla Firefox 126.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vylepšena byla funkce "Zkopírovat odkaz bez sledovacích prvků". Přidána byla podpora zstd (Zstandard). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 126 je již k dispozici také na Flathubu a Snapcraftu.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 11.0. Přehled novinek v aktualizované dokumentaci.
Byla vydána nová verze 24.0 linuxové distribuce Manjaro (Wikipedie). Její kódové jméno je Wynsdey. Ke stažení je v edicích GNOME, KDE PLASMA a XFCE.
Byla představena oficiální rozšiřující deska Raspberry Pi M.2 HAT+ pro připojování M.2 periferii jako jsou NVMe disky a AI akcelerátory k Raspberry Pi 5. Cena je 12 dolarů.
V Praze o víkendu proběhla bastlířská událost roku - výstava Maker Fair v Praze. I strahovští bastlíři nelenili a bastly ostatních prozkoumali. Přijďte si proto i vy na Virtuální Bastlírnu popovídat, co Vás nejvíce zaujalo a jaké projekty jste si přinesli! Samozřejmě, nejen českou bastlířskou scénou je člověk živ - takže co se stalo ve světě a o čem mohou strahováci něco říct? Smutnou zprávou může být to, že provozovatel Sigfoxu jde do
… více »Kam asi vede IllllIllIIl.llIlI.lI? Zkracovač URL llIlI.lI.
Společnost OpenAI představila svůj nejnovější AI model GPT-4o (o jako omni, tj. vše). Nově také "vidí" a "slyší". Videoukázky na 𝕏 nebo YouTube.
Ondřej Filip publikoval reportáž z ceremonie podpisu kořenové zóny DNS. Zhlédnout lze také jeho nedávnou přednášku Jak se podepisuje kořenová zóna Internetu v rámci cyklu Fyzikální čtvrtky FEL ČVUT.
Společnost BenQ uvádí na trh novou řadu monitorů RD určenou pro programátory. První z nich je RD240Q.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem nadále zůstává Frontier od HPE (Cray) s výkonem 1,206 exaFLOPS. Druhá Aurora má oproti loňsku přibližně dvojnásobný počet jader a dvojnásobný výkon: 1,012 exaFLOPS. Novým počítačem v první desítce je na 6. místě Alps. Novým českým počítačem v TOP500 je na 112. místě C24 ve Škoda Auto v Mladé Boleslavi. Ostravská Karolina, GPU
… více »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í