Zig Software Foundation stojící za programovacím jazykem Zig publikovala finanční zprávu za rok 2024. Současně s prosbou o finanční příspěvek.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za srpen (YouTube). Vypíchnuta je podpora Tabulek Google, implementace Gamepad API a Cookie Store API nebo také podpora WebGL na Linuxu.
openSUSE Leap 16, včetně Leap Micra 6.2+, nově nabízí 24 měsíců podpory pro každé vydání. To je dva roky aktualizací a stability, což z něj činí nejdéle podporovanou komunitní distribuci vůbec. Leap se tak stává ideální platformou pro všechny, kdo hledají moderní, stabilní a dlouhodobě podporovanou komunitní Linux distribuci.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal dne 3. 9. 2025 VAROVÁNÍ před hrozbou v oblasti kybernetické bezpečnosti spočívající v předávání systémových a uživatelských dat do Čínské lidové republiky a ve vzdálené správě technických aktiv vykonávané z území Čínské lidové republiky. Varováním se musí zabývat povinné osoby podle zákona o kybernetické bezpečnosti.
Americká internetová společnost Google nemusí prodat svůj prohlížeč Chrome ani operační systém Android. Rozhodl o tom soud ve Washingtonu, který tak zamítl požadavek amerického ministerstva spravedlnosti. Soud ale firmě nařídil sdílet data s jinými podniky v zájmu posílení konkurence v oblasti internetového vyhledávání. Zároveň Googlu zakázal uzavírat dohody s výrobci mobilních a dalších zařízení, které by znemožňovaly
… více »Prvního září ozbrojení policisté zatkli na na londýnském letišti Heathrow scénáristu a režiséra Grahama Linehana, známého především komediálními seriály Ajťáci, Otec Ted nebo Black Books. Během výslechu měl 57letý Graham nebezpečně zvýšený krevní tlak až na samou hranici mrtvice a proto byl z policejní stanice převezen do nemocnice. Důvodem zatčení bylo údajné podněcování násilí v jeho 'vtipných' příspěvcích na sociální síti
… více »Studentská dílna Macgyver zve na další Virtuální Bastlírnu - pravidelné online setkání všech, kdo mají blízko k bastlení, elektronice, IT, vědě a technice. Letní prázdniny jsou za námi a je čas probrat novinky, které se přes srpen nahromadily. Tentokrát jich je více než 50! Těšit se můžete mimo jiné na:
Hardware – Bus Pirate na ESP32, reverse engineering Raspberry Pi, pseudo-ZX-80 na RISC-V, PicoCalc, organizéry na nářadí z pěny nebo … více »Google Chrome 140 byl prohlášen za stabilní. Nejnovější stabilní verze 140.0.7339.80 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 6 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
LeoCAD (Wikipedie) je svobodná multiplatformní aplikace umožňující také na Linuxu vytvářet virtuální 3D modely z kostek lega. Vydána byla verze 25.09. Zdrojové kódy a AppImage jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
RubyMine, tj. IDE pro Ruby a Rails od společnosti JetBrains, je nově zdarma pro nekomerční použití.
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