Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 141 (pdf) a HackSpace 78 (pdf).
Byla vydána verze 2.0.0 programovacího jazyka Kotlin (Wikipedie, GitHub). Oficiálně bude představena ve čtvrtek na konferenci KotlinConf 2024 v Kodani. Livestream bude možné sledovat na YouTube.
Byla vydána nová major verze 27.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Byla vydána nová verze 1.8.0 svobodného multiplatformního softwaru pro konverzi video formátů HandBrake (Wikipedie). Přehled novinek v poznámkách k vydání na GitHubu. Instalovat lze také z Flathubu.
Microsoft představil nové označení počítačů Copilot+. Dle oznámení se jedná se o počítače poskytující funkce umělé inteligence. Vedle CPU a GPU mají také NPU (Neural Processing Unit). Uvnitř představených Copilot+ notebooků běží ARM čipy Qualcomm Snapdragon X Elite nebo X Plus.
Příspěvek na blogu Codean Labs rozebírá zranitelnost CVE-2024-4367 v PDF.js, tj. mj. prohlížeči PDF souborů ve Firefoxu. Při otevření útočníkem připraveného pdf souboru může být spuštěn libovolný kód v JavaScriptu. Vyřešeno ve Firefoxu 126.
Lazygit byl vydán ve verzi 0.42.0. Jedná se o TUI (Text User Interface) nadstavbu nad gitem.
K open source herní konzole Picopad přibyla (𝕏) vylepšená verze Picopad Pro s větším displejem, lepšími tlačítky a větší baterii. Na YouTube lze zhlédnout přednášku Picopad - open source herní konzole z LinuxDays 2023.
Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
Současný vývojový kernel 4.10-rc2 byl vydán 1. ledna. Od 4.10-rc1 z 25. prosince bylo začleněno pouze 27 nových patchů.
Stabilní aktualizace: od 15. prosince žádné nevyšly. Stabilní aktualizace 4.9.1, 4.8.16 a 4.4.40 byly v době psaní tohoto článku v procesu revidování, vydány byly 6. ledna.
Začleňovací okno 4.10 bylo podle očekávání uzavřeno 25. prosince vydáním verze 4.10-rc1. Nakonec bylo pro toto vydání do hlavního repozitáře začleněno 11 455 neslučovacích sad změn, čímž se tento vývojový cyklus zařadil k těm rušnějším, i když nebyl tak rušný jako 4.9. Téměř 400 změn bylo začleněno po vydání shrnutí z 22. prosince, tudíž je jejich seznam poměrně krátký.
Ze seznamu změn:
Stabilizační fáze cyklu 4.10 začala vzhledem ke svátkům později. Mezi verzemi 4.10-rc1 a 4.10-rc2 bylo aplikováno pouze 27 neslučovacích sad změn. Dá ale se předpokládat, že tempo vzroste, jakmile se vývojáři vrátí do práce a přiblíží se finální datum vydání 4.10 (pravděpodobně 12. nebo 19. února).
Výpočetní systémy od dob, kdy Linux vznikl, výrazně nabyly na složitosti. Jádro na to reagovalo vývojem nových mechanismů pro správu složitosti zařízení, včetně modelu ovladačů, dynamického přidělování čísel aj. Tyto mechanismy vyřešily spoustu problémů, ale přestože je problém správy závislostí mezi zdánlivě nezávislými zařízeními za běhu znám již delší dobu, řádného řešení se mu dostalo až v začleňovacím okně 4.10.
Některé závislosti zařízení jsou nedílnou součástí architektury systému. Například periferie připojené přes USB budou nepoužitelné, není-li k dispozici odpovídající hostitelský USB adaptér, který je nejspíš připojen k jiné systémové sběrnici, která musí být rovněž v provozu. Závislosti založené na topologii propojení v systému jsou relativně jednoduše reprezentovatelné stromovou strukturou: k tomu byl jaderný model zařízení vytvořen. Při použití tohoto modelu může jádro např. uspat zařízení v systému ve správném pořadí a zároveň udržovat zprostředkující zařízení v provozu, dokud nedojde k vypnutí všech ostatních zařízení, která na nich závisí.
V moderních systémech však může být graf závislostí poněkud složitější. Například „zařízení“ reprezentující fotoaparát pravděpodobně tvoří skupina vzájemně propojených zařízení, která jádro vidí jako nezávislá. Ve skutečnosti ovládání fotoaparátu vyžaduje senzor, pravděpodobně ovládaný přes sběrnici I2C, asi také závisí na několika GPIO zařízeních, která se starají o napájení a restartovací linky. Senzor je připojen k samostatné sběrnici zařízení, která získává obrazová data: tato sběrnice může potřebovat DMA řadič k přesunu dat do paměti. Součástí mohou být také další zařízení pro různé transformace obrazu (např. rotace nebo konverze barevného prostoru) implementované hardwarově.
Jde o to, že každou z těchto složek jádro vnímá jako samostatné zařízení. Tato zařízení přísluší samostatným řadičům a možná jsou na samostatných sběrnicích – z pohledu topologie systému nejsou nijak příbuzné. Ve většině případů je do funkčního celku seřadí nějaký nadřazený řadič. Informace, které k tomu potřebuje, se v dnešních systémech nacházejí ve stromové struktuře zařízení. Jenže jádro jaderných ovladačů něco může pokazit vypnutím některého z podřazených zařízení, když neví, že další zařízení na něm závisejí.
Ovladače dosud měly tendenci tento problém obcházet pomocí jednorázového kódu unikátního pro každé zařízení. Jak by se dalo očekávat, takové řešení vede k časté duplikaci kódu a spoustě polovičatých řešení. Bylo by mnohem lepší mít jedno řešení v jádře kódu ovladače, a to by fungovalo pro všechna zařízení. Posun k takovému řešení je cílem infrastruktury funkčních závislostí, která byla začleněna pro vydání 4.10.
Rozhraní tohoto mechanismu je celkem jednoduché, skládá se z jediné funkce, která indikuje existující závislost:
struct device_link *device_link_add(struct device *consumer, struct device *supplier, u32 flags);
Toto volání informuje jádro ovladače, že zařízení consumer závisí na zařízení supplier. Takže systém kupříkladu neuspí zařízení supplier, dokud není uspáno i zařízení consumer, a nepokusí se přistupovat k zařízení consumer nebo ho znovu spustit, dokud nepoběží supplier. Navíc, pokud bude zařízení supplier uvolněné (unbound), dojde k automatickému uvolnění i zařízení consumer, protože to by beztak nebylo schopno nadále fungovat.
Vazby mezi zařízeními jsou implicitně perzistentní a zůstanou v platnosti po dobu běhu systému. Pokud ovšem se při vytvoření vazby objeví příznak DL_FLAG_AUTOREMOVE, k automatickému odstranění vazby dojde tehdy, když je ovladač zařízení consumer uvolněný. Tyto neperzistentní vazby mohou být užitečné v situacích, kdy je možné hardware nastavit více způsoby a v průběhu času vytvářet různé závislosti. Příznak DL_FLAG_STATELESS se dá použít k vytvoření vazby pro seřazení při uspání/probuzení, o kterou se ale jinak jádro ovladače nestará.
Pokud je třeba explicitně odstranit vazbu zařízení, dá se tak učinit pomocí volání device_link_del():
void device_link_del(struct device_link *link);
Stav k vydání 4.10-rc2 je takový, že hlavní větvi jádra se tato nová infrastruktura využívá pouze na jednom místě (kód části pro správu paměti I/O SoC Exynos). Dá se však očekávat, že další využití se objeví během následujících vývojových cyklů. S trochou štěstí je bude doprovázet úbytek objemu kódu pro řízení závislostí v jednotlivých ovladačích a také celkové zlepšení kvality jádra.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
ve sporce to beha urcite. Pred par lety jsem to mel chvilku na starosti. HPUX 11, oracle db.. bezi tam jedna masina, a vedle se vali dve "nahradni kdyby neco" . Provoz minimalni, maji tam nejaky klienty (radove desitky), kterym dobihaj smlouvy. Ale co vim tak to bezi kvuli povinne archivaci a obcasne potrebe ucta..
co kdyz tam bude vice instanci toho zarizeni? mozna to vyresi parametry pro meta modul moznap ravidla v udev..