Byl vydán Debian 13.3, tj. třetí opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.13, tj. třináctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Na stránkách Evropské komise, na portálu Podělte se o svůj názor, se lze do 3. února podělit o názor k iniciativě Evropské otevřené digitální ekosystémy řešící přístup EU k otevřenému softwaru.
Společnost Kagi stojící za stejnojmenným placeným vyhledávačem vydala (𝕏) alfa verzi linuxové verze (flatpak) svého proprietárního webového prohlížeče Orion.
Firma Bose se po tlaku uživatelů rozhodla, že otevře API svých chytrých reproduktorů SoundTouch, což umožní pokračovat v jejich používání i po plánovaném ukončení podpory v letošním roce. Pro ovládání také bude stále možné využívat oficiální aplikaci, ale už pouze lokálně bez cloudových služeb. Dokumentace API dostupná zde (soubor PDF).
Jiří Eischmann se v příspěvku na svém blogu rozepsal o open source AdGuard Home jako domácí ochraně nejen před reklamou. Adguard Home není plnohodnotným DNS resolverem, funguje jako DNS forwarder s možností filtrování. To znamená, že když přijme DNS dotaz, sám na něj neodpoví, ale přepošle ho na vybraný DNS server a odpovědi zpracovává a filtruje dle nastavených pravidel a následně posílá zpět klientům. Dá se tedy používat k blokování reklamy a škodlivých stránek a k rodičovské kontrole na úrovni DNS.
AI Claude Code od Anthropicu lépe rozumí frameworku Nette, tj. open source frameworku pro tvorbu webových aplikací v PHP. David Grudl napsal plugin Nette pro Claude Code.
Byla vydána prosincová aktualizace aneb nová verze 1.108 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.108 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Na lasvegaském veletrhu elektroniky CES byl předveden prototyp notebooku chlazeného pomocí plazmových aktuátorů (DBD). Ačkoliv se nejedná o první nápad svého druhu, nepochybně to je první ukázka praktického použití tohoto způsobu chlazení v běžné elektronice. Co činí plazmové chladící akční členy technologickou výzvou je především vysoká produkce jedovatého ozonu, tu se prý podařilo firmě YPlasma zredukovat dielektrickou
… více »Patchouli je open source implementace EMR grafického tabletu (polohovací zařízení). Projekt je hostován na GitLabu.
Český Nejvyšší soud potvrdil, že česká právní úprava plošného uchování dat o elektronické komunikaci porušuje právo Evropské unie. Pravomocným rozsudkem zamítl dovolání ministerstva průmyslu a obchodu. To se teď musí omluvit novináři Českého rozhlasu Janu Cibulkovi za zásah do práv na ochranu soukromí a osobních údajů. Ve sporu jde o povinnost provozovatelů sítí uchovávat údaje, ze kterých lze odvodit, kdo, s kým a odkud komunikoval.
Stav vydání jádra. Vydání jádra 4.18 se o týden zpozdí. Citáty týdne: Dan Williams, Linus Torvalds a Al Viro. Stručná historie alokátorů paměti v raných fázích zavádění systému.
Kernel release status. Jonathan Corbet. 1. srpna 2018
Současné vývojové jádro je 4.18-rc7, vydané 29. července. Linus řekl: „Takže pokud se nestane nic divného, tohle by měl být poslední kandidát na vydání 4.18.“ Něco divného se ovšem stalo, takže bychom měli očekávat ještě jednoho kandidáta na vydání.
Stabilní aktualizace: 4.17.11, 4.14.59, 4.9.116, 4.4.145 a 3.18.117 byly vydány 28. července.
The 4.18 kernel release will be delayed a week. 31. července 2018
Pokud netrpělivě očekáváte vydání jádra 4.18: zdá se, že Linus ho kvůli problémům odhaleným na poslední chvíli odloží o týden (na 12. srpna). „Pravidelný rytmus vydání _preferuji_, ale když je důvod k odkladu, vydání odložím.“
Quotes of the week. 1. srpna 2018
Možná jste se doslechli, že eBPF všechno nahradí a každému dá jednorožce. To se může stát, jestli/až se dočká lepší odpovědnosti, sledovatelnosti, laditelnosti, auditovatelnosti a široké podpory ovladačů XDP. Ovšem nftables je tady s námi dlouhá léta a většinou těchto záležitostí (ne-li všemi) disponuje již dnes.
Vážně. Žádné překlady. Žádné přípravy na překlady. Je to fakt hnusná díra a utrpení pro všechny.
Je tu další důvod, proč jsem _z principu_ proti překladům jakýchkoliv jaderných rozhraní. Když dostanu hlášení chyby, chci ho prostě prohnat ‚git grep‘. Překlady to fakticky znemožňují.
Takže se to má tak, že chci jednoduchá rozhraní v angličtině. A lidé, kteří s tím mají problém, ať je prostě nepoužívají. Konec vyprávění. Jestli chcete mezinárodní podporu, používejte stávající chybové kódy a smiřte se s tím, že jejich počet je výrazně omezený.
Velmi často je nejlepší strategie, jak přijít na to, co sakra znamená to naprosto nesmyslné hlášení, zkusit hádat, co za větu mohlo být takhle divně přeloženo do angličtiny.
A quick history of early-boot memory allocators. Mike Rapoport. 30. července 2018
Jeden by se mohl domnívat, že alokace paměti při zavádění systému by neměla být složitá: skoro všechna paměť je volná, nedochází k žádnému souběhu a žádné úlohy na pozadí nesoutěží o paměť. Ale i tak je správa paměti během zavádění systému záludný úkol. Fyzická paměť nemusí nutně být spojitá, její rozsah se liší systém od systému a detekce těchto rozsahů může být netriviální. NUMA situaci činí ještě složitější, protože aby se zajistila lokalita alokací, musí se určit přesná topologie paměti. Aby se s tím vším počítalo, jsou i v raných fázích procesu zavádění systému nezbytné sofistikované mechanismy správy paměti.
Nabízí se otázka, proč tedy nepoužívat ten samý alokátor, který Linux používá od samotného začátku? Háček je v tom, že primární alokátor stránek v Linuxu je složitá obluda a také potřebuje alokovat paměť k inicializaci sebe sama. Navíc by se při alokaci datových struktur alokátoru stránek mělo počítat s NUMA. Takže je potřeba jiné řešení, které nám uvede do chodu subsystém správy paměti.
Linux zpočátku alokátor paměti pro rané fáze zavádění systému neměl. Inicializace paměti v jádře 1.0 nebyla tak robustní a všestranná jako dnes. Všechna volání inicializující subsystémy, potažmo vlastně libovolná funkce volaná ze start_kernel(), měla přístup k počáteční adrese jediného bloku volné paměti, a to prostřednictvím globální proměnné memory_start. Když některá funkce potřebovala alokovat paměť, prostě navýšila hodnotu memory_start, o kolik bylo zrovna potřeba. V době vydání verze 2.0 už byl Linux portován na dalších pět architektur, ale správa paměti v raných fázích běhu vytrvala stále stejně jednoduchá. Jediný rozdíl spočíval v tom, že rozsahy fyzické paměti byly detekovány kódem specifickým pro danou architekturu. Nutno však podotknout, že tehdejší hardware byl výrazně jednodušší a bylo snazší detekovat různé konfigurace paměti.
Veškeré rané alokace paměti až do vydání 2.3.23pre3 používaly a patřičně upravovaly globální proměnné udávající začátek a konec volné paměti. Naštěstí byl záhy k dispozici alokátor stránek a slab alokátor, čehož šlo využít při intenzivním zatížení paměti, jako v případě buffers_init() a page_cache_init(). Jak se vyvíjel a zesložiťoval hardware, kód pro jednotlivé architektury narostl o hromadu balastu.
Skupina patchů ve 2.323pre3 obsahovala první implementací alokátoru bootmem, která k reprezentaci stavu jednotlivých stránek fyzické paměti používala bitmapu. Prázdné bity označovaly dostupné stránky a nastavené bity znamenaly, že příslušné stránky paměti byly zabrány nebo chyběly. Veškeré obecné funkce, které měnily memory_start, a kód inicializace na architektuře i386 přešly na bootmem, na ostatních architekturách se tomu tak ovšem nestalo. Na to došlo až k vydání 2.3.48. Mezitím se Linux dočkal portu na Itanium (ia64), což byla první architektura používající bootmem od samého začátku.
Časem se detekce paměti vyvinula od prostého dotazu na BIOS, jak je velký rozšířený blok paměti, k manipulaci s komplexními tabulkami, díly, bankami a klastry. Konkrétně architektura Power64 byla připravena s alokátorem Logical Memory Block (krátce LMB). Paměť je s LMB reprezentována dvěma poli rozsahů. První pole popisuje fyzicky souvislé rozsahy paměti, které jsou v rámci systému dostupné, zatímco pole druhé sleduje alokované rozsahy. Alokátor LMB se dostal i do 32bitové architektury PowerPC, když došlo ke sloučení 32bitové a 64bitové varianty. Později ho převzal SPARC. Časem se propracoval k dalším architekturám a stalo se z něj to, co dnes známe jako memblock.
Alokátor memblock poskytuje dvě základní primitiva, která se používají jako základ komplexnějších API pro alokaci: memblock_add() zaregistruje fyzický rozsah paměti a memblock_reserve() rozsah označí jako zabraný. Obě jsou nakonec založená na memblock_add_range(), které rozsah přidá do příslušného pole z těch dvou výše uvedených.
Zásadní nevýhoda bootmem spočívá v inicializaci bitmapy. Abychom ji mohli vytvořit, musíme znát fyzickou podobu paměti. Jak by správně měla být bitmapa velká? Která paměťová banka má dostatečně velký spojitý rozsah fyzické paměti, aby bitmapu mohla uložit? A samozřejmě, jak roste kapacita paměti, roste i bitmapa bootmem. Na systému se 32GB RAM vyžaduje 1 MB této paměti. Na druhé straně jde memblock použít hned, je totiž založený na statických polích, která jsou dost velká na to, aby obsáhla aspoň první registrace a alokace paměti. Když se vyskytne požadavek na rezervaci paměti, která by přetekla meze pole memblock, velikost tohoto pole se zdvojnásobí. Vychází se přitom z předpokladu, že do doby, kdy taková situace může nastat, se memblocku se přidá dost paměti na to, aby zvládal alokaci nových polí.
Návrh memblocku předpokládá, že než naběhne primární alokátor stránek, požadavků na (de)alokaci by mělo být poměrně málo. Jelikož doba činnosti memblocku, než předá veškerou paměť spřátelenému alokátoru stránek, je omezená, nemusí být nijak zvlášť sofistikovaný.
Aby se usnadnil náročný přechod od bootmem k memblocku, vznikla mezivrstva nobootmem. Nobootmem poskytuje (většinu) rozhraní jako bootmem, ale místo zaznamenávání zabraných stránek v bitmapě spoléhá na rezervacích memblocku. V jádře 4.17 bootmem používá jako jediný alokátor v raných fázích zavádění systému pouze pět z 24 architektur. 14 architektur používá memblock s nobootmem. Zbývajících pět používá memblock a bootmem zároveň.
Aktuálně se pracuje na umožnění použití memblock s nobootmem na všech architekturách. Několik architektur používajících stromy zařízení přešlo v důsledku nedávných změn rané správy paměti v ovladačích stromu zařízení. Dosud došlo ke zveřejnění patchů architektur alpha, c6x, m68k a nios2. Některé z nich již správci příslušných architektur začlenili, jiné jsou zatím revidovány.
Do doby začleňovacího okna 4.20 už snad všechny architektury opustí bootmem. Pak bude možné výrazně pročistit kód správy paměti v raných fázích zavádění systému. Mělo by to zahrnovat odstranění alokátoru bootmem a několika s ním spojených konfigurací jádra. Tím by se dále měl umožnit postupný přesun větší části funkcionality raných fází zavádění z podstromů dílčích architektur do společného kódu. V subsystému správy paměti nikdy není málo problémů, které potřebují vyřešit.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz