Společnost Oracle vlastní ochrannou známku JAVASCRIPT. Komunita kolem programovacího jazyka JavaScript zastoupena společností Deno Land vede právní bitvu za její osvobození, viz petice a otevřený dopis na javascript.tm. Do 7. srpna se k nim má vyjádřit Oracle (USPTO TTAB).
Byl představen samostatný rádiový modul Raspberry Pi Radio Module 2 s Wi-Fi a Bluetooth.
Certifikační autorita Let’s Encrypt ukončila k 4. červnu zasílání e-mailových oznámení o vypršení platnosti certifikátů. Pokud e-maily potřebujete, Let’s Encrypt doporučuje některou z monitorovacích služeb.
Přemýšlíte, jak začít prázdniny? Už v úterý 1. července se bude konat Virtuální Bastlírna, tedy online setkání bastlířů, techniků, vědců i akademiků, kde se ve volné diskuzi probírají novinky ze světa techniky, ale i jiných zajímavých témat.
Za poslední měsíc jsme byli svědky plamenů několika raket. Zatímco malá raketa od Hondy se úspěšně vznesla a opět přistála, raketa od SpaceX se rozhodla letět všemi směry najednou. Díkybohu méně … více »Linus Torvalds zmínil, že souborový systém Bcachefs zřejmě odstraní z mainline Linuxu v začleňovacím okně pro vydání 6.17. Kent Overstreet mu totiž posílá kód s novou funkcionalitou i pro začlenění do kandidátů na vydání, kdy očekává pouze opravy chyb. Kent Overstreet byl již dříve z vývoje vyloučen kvůli konfliktní komunikaci.
Ministerstvo průmyslu a obchodu propaguje Microsoft. Ten ve spolupráci s Ministerstvem průmyslu a obchodu spouští AI National Skilling Plan v ČR. "Iniciativa Microsoftu přináší konkrétní a praktickou podporu právě tam, kde ji nejvíc potřebujeme – do škol, firem i veřejné správy.", říká ministr průmyslu a obchodu Lukáš Vlček.
Jste český ISP? Vyplněním krátkého dotazníku můžete pomoci nasměrovat vývoj nové generace routerů Turris Omnia [𝕏].
Celkové tržby společnosti Canonical za rok 2024 byly 292 milionů dolarů (pdf). Za rok 2023 to bylo 251 milionů dolarů.
Byla vydána verze 1.88.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Distribuce Tails specializující se ochranu online soukromí uživatele byla vydána ve verzi 6.17. Mimo jiné aktualizuje Tor Browser (14.5.4) a opravuje několik chyb.
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