Na WWDC25 byl představen balíček Containerization a nástroj container pro spouštění linuxových kontejnerů na macOS. Jedná se o open source software pod licencí Apache 2.0 napsaný v programovacím jazyce Swift.
Do 16. června do 19:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | červen 2025 doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.
Apple na své vývojářské konferenci WWDC25 (Worldwide Developers Conference, keynote) představil řadu novinek: designový materiál Liquid Glass, iOS 26, iPadOS 26, macOS Tahoe 26, watchOS 26, visionOS 26, tvOS 26, nové funkce Apple Intelligence, …
Organizátoři konference LinuxDays 2025, jež proběhne o víkendu 4. a 5. října 2025 v Praze na FIT ČVUT, spustili přihlašování přednášek (do 31. srpna) a sběr námětů na zlepšení.
Po roce byla vydána nová stabilní verze 25.6.0 svobodného multiplatformního multimediálního přehrávače SMPlayer (Wikipedie).
DNS4EU, tj. evropská infrastruktura služeb DNS založená na vysoce federovaném a distribuovaném ochranném ekosystému, byla spuštěna v testovacím režimu [𝕏]. Na výběr je 5 možností filtrování DNS.
Skriptovací programovací jazyk PHP (PHP: Hypertext Preprocessor, původně Personal Home Page) dnes slaví 30 let. Přesně před třiceti lety, 8. června 1995, oznámil Rasmus Lerdorf vydání PHP Tools (Personal Home Page Tools) verze 1.0.
Ve středu v 17:00 byl ve Francii zablokován přístup k PornHubu a dalším webům pro dospělé. K 17:30 došlo k nárůstu počtu registrací Proton VPN o 1 000 % [𝕏]. Dle nového francouzského zákona jsou provozovatelé těchto webů povinni ověřovat věk uživatelů prostřednictvím průkazu totožnosti nebo platební karty.
Před 32 lety, 6. června 1993, byl spuštěn první český WWW server (ještě pod TLD .cs), pro potřeby fyziků zabývajících se problematikou vysokých energií.
Střílečku Borderlands 2 lze v rámci výprodeje série Borderlands na Steamu získat zdarma napořád, když aktivaci provedete do 8. června 19:00.
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