Do prodeje jde tichá bezdrátová herní myš Logitech PRO X2 SUPERSTRIKE s analogovými spínači s haptickou odezvou (HITS, Haptic Inductive Trigger System). Cena je 4 459 Kč.
Microsoft na GitHubu zveřejnil zdrojový kód projektu LiteBox, jedná se o 'knihovní operační systém' (library OS) zaměřený na bezpečnost, využívající systémovou architekturu LVBS k ochraně jádra před útoky z uživatelského prostoru. LiteBox je napsán v Rustu a uvolněný pod licencí MIT. Projekt je teprve v rané fázi vývoje.
BreezyBox je open-source shell a virtuální terminál pro populární jednočip ESP32. Nabízí základní unixové příkazy, sledování aktuálního pracovního adresáře (CWD), jednoduchý instalátor a spouštěč aplikací v podobě ELF binárních souborů, zabudovaný HTTP server nebo třeba ovládání WiFi - ukázka použití coby 'malého osobního počítače'. Ačkoliv je BreezyBox inspirovaný BusyBoxem, oproti němu má tento projekt několik externích závislostí, zejména na ESP-IDF SDK. BreezyBox je dostupný pod licencí MIT.
Byl představen cross-assembler xa.sh, napsaný čistě v Bourne shell skriptu. Tento nástroj umožňuje zpracovávat assemblerový kód pro Intel 8080, přičemž je možné snadno přidat podporu i pro další architektury, například 6502 a 6809. Skript využívá pouze různé běžné unixové příkazy jako jsou awk, sed nebo printf. Skript si lze stáhnout z GitHubového repozitáře projektu.
Byla představena nová verze modelu Claude Opus 4.6 od společnosti Anthropic. Jako demonstraci možností Anthropic využil 16 agentů Claude Opus 4.6 k vytvoření kompilátoru jazyka C, napsaného v programovacím jazyce Rust. Claude pracoval téměř autonomně, projekt trval zhruba dva týdny a náklady činily přibližně 20 000 dolarů. Výsledkem je fungující kompilátor o 100 000 řádcích kódu, jehož zdrojový kód je volně dostupný na GitHubu pod licencí Creative Commons.
Kultovní britský seriál The IT Crowd (Ajťáci) oslavil dvacáté výročí svého prvního vysílání. Sitcom o dvou sociálně nemotorných pracovnících a jejich nadřízené zaujal diváky svým humorem a ikonickými hláškami. Seriál, který debutoval v roce 2006, si i po dvou dekádách udržuje silnou fanouškovskou základnu a pravidelně se objevuje v seznamech nejlepších komedií své doby. Nedávné zatčení autora seriálu Grahama Linehana za hatecrime však vyvolává otázku, jestli by tento sitcom v současné Velké Británii vůbec vznikl.
Společnost JetBrains oznámila, že počínaje verzí 2026.1 budou IDE založená na IntelliJ ve výchozím nastavení používat Wayland.
Společnost SpaceX amerického miliardáře Elona Muska podala žádost o vypuštění jednoho milionu satelitů na oběžnou dráhu kolem Země, odkud by pomohly zajistit provoz umělé inteligence (AI) a zároveň šetřily pozemské zdroje. Zatím se ale neví, kdy by se tak mělo stát. V žádosti Federální komisi pro spoje (FCC) se píše, že orbitální datová centra jsou nejúspornějším a energeticky nejúčinnějším způsobem, jak uspokojit rostoucí poptávku po
… více »Byla vydána nová verze 2.53.0 distribuovaného systému správy verzí Git. Přispělo 70 vývojářů, z toho 21 nových. Přehled novinek v poznámkách k vydání.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 216. sraz, který proběhne v pátek 20. února od 18:00 v Red Hat Labu (místnost Q304) na Fakultě informačních technologií VUT v Brně na ulici Božetěchova 1/2. Tématem srazu bude komunitní komunikační síť MeshCore. Jindřich Skácel představí, co je to MeshCore, předvede nejrůznější klientské zařízení a ukáže, jak v praxi vypadá nasazení vlastního repeateru.
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