Offpunk byl vydán ve verzi 3.0. Jedná se o webový prohlížeč běžící v terminálu a podporující také protokoly Gemini, Gopher a RSS. Přibyl nástroj xkcdpunk pro zobrazení XKCD v terminálu.
Promethee je projekt, který implementuje UEFI (Unified Extensible Firmware Interface) bindingy pro JavaScript. Z bootovacího média načítá a spouští soubor 'script.js', který může používat UEFI služby. Cílem je vytvořit zavaděč, který lze přizpůsobit pomocí HTML/CSS/JS. Repozitář se zdrojovými kódy je na Codebergu.
Zpráva Justičního výboru Sněmovny reprezentantů upozorňuje na cenzurní kampaň Evropské komise, mířenou proti svobodě projevu na sociálních sítích. V dokumentu se uvádí, že se Evropská komise během posledních šesti let účastnila více než 100 uzavřených jednání, během nichž po platformách požadovala úpravy pravidel moderování obsahu, přičemž toto úsilí Komise zahrnovalo i cenzuru politických názorů a pravdivých informací. Výbor zdůrazňuje, že tento přístup Bruselu ohrožuje ústavou zaručená práva Američanů na svobodu projevu.
Linus Torvalds vydal jádro Linux 6.19. Podrobný výčet změn je ke zhlédnutí na stránce Kernel Newbies, stručné výběry v LWN (část první, druhá).
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.
Současné vývojové jádro je 2.6.39-rc1, které Linus vydal 29. března. Takže 2.6.39-rc1 je venku a začleňovací okno je uzavřené. Ještě se musím podívat na požadavek na přetažení cleancache (na což jsem měl spoustu času, ale rozhodl jsem se, že to reviduju až poté, co bláznění se začleňovacím oknem skončí). Jinak je hotovo. Mezi významné změny v 2.6.39 budou patřit systémová volání pro otevření podle manipulátoru, CLOCK_BOOTTIME, možnost vynutit běh obsluh přerušení ve vláknech, ipset, základní kód přechodné paměti, subsystém pro řízení multimédií, plánovač toku CHOKe a mnoho dalšího. Detaily najdete v kompletním changelogu.
Stabilní aktualizace: 28. března vyšla stabilní jádra 2.6.32.36, 2.6.33.9, 2.6.37.6 a 2.6.38.2. Každé obsahuje dlouhý seznam důležitých oprav; aktualizace 2.6.37.6 bude poslední pro sérii 2.6.37.
Předtím bylo vydáno 2.6.32.35 obsahující jedinou opravu chyby při překladu.
napsal Jonathan Corbet, 30. března 2011
Mechanismus návěští skoků jsme zde naposledy viděli v říjnu 2010. Ve zkratce umožňuje optimalizovat „vysoce nepravděpodobné“ větvení kódu tak, že běžná režie se blíží nule. Tohoto zrychlení se dosáhne patchováním kódu za běhu; to je také nákladem této metody: povolení nebo zakázání nepravděpodobného případu je drahá operace. Návěští skoků je tedy nejlepší používat pro kód, který není povolen téměř nikdy; zjevnými příklady jsou sledovací body a místa pro dynamické ladění.
Na prvotní implementaci návěští skoků bylo mnoho stížností včetně faktu, že je poměrně složité ho používat. V reakci na to byla zaslána přepracovaná verze, která výrazně mění rozhraní. Začne se deklarováním „klíče skoku“ [jump key]:
#include <linux/jump_label.h> struct jump_label_key my_key;
Povolení a zakázání klíče je jednoduchou záležitostí volání:
jump_label_inc(struct jump_label_key *key); jump_label_dec(struct jump_label_key *key);
A použití klíče pro řízení kódu, který je zapotřebí jenom výjimečně, vypadá následovně:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
if (static_branch(&my_key)) {
/* Nepravděpodobný kód zde */
}
Pokud chybí plná podpora pro návěští skoku, je klíč skoku reprezentován hodnotou atomic_t. Z jump_label_inc() se stane atomic_inc() a jump_label_dec() se změní na atomic_dec. static_branch() je implementováno pomocí atomic_read(). Pokud je do jádra zakonfigurována podpora návěští skoků, z povolení a zakázání klíčů skoku se stanou náročnější operace, zatímco static_branch() bude téměř zadarmo. Pro zamýšlená použití návěští skoků je to rozumná výměna.
V době psaní tohoto článku změny do 2.6.39 začleněny nebyly. Je vždy možné, že by mohly být přetaženy do -rc2, ale v tuto chvíli je pravděpodobnější, že nová návěští skoku budou moci skočit až do 2.6.40.
napsal Jonathan Corbet, 30. března 2011
Rozhraní pro správu napájení APM nikdy nebylo příliš milováno – dokonce i ACPI se považuje za lepší alternativu. Za posledních několik let bylo vyrobeno jenom málo hardwaru, který by na APM závisel – pokud vůbec nějaký; Windows evidentně přestaly APM podporovat roku 2006. V Linuxu nicméně funguje dál a to má své náklady, takže není překvapivé, že by Len Brown chtěl tuto podporu v 2.6.40 odstranit.
K tomu nicméně téměř určitě v době, kterou si Len vytýčil, nedojde; mnoho vývojářů namítlo, že se stále může používat hardware, na kterém by nemohla běžet nová jádra, a Linux se obecně snaží neopouštět uživatele starého hardware. APM s námi tedy nejspíše ještě nějaký čas zůstane, ale to představuje problém: udržování podpory APM je, zdá se, v konfliktu s potřebnými změnami v kódu cpuidle. Jinak řečeno snaha udržovat APM funkční může zdržet zlepšení pro většinu uživatelů, kteří mají hardware novější.
Řešením možná bude částečné odstranění podpory APM. Nejvýznamnější vlastností APM je pro uživatele starých strojů nejspíše možnost vypnout systém; ostatní vlastnosti budou méně důležité. Jak poznamenal Andi Kleen, podpora pro nečinnost takovým uživatelům nejspíše tak důležitá nepřijde:
Podpora APM jako taková tedy ještě nějaký čas zůstane, ale s postupem času může začít přicházet o některé vlastnosti.
napsal Jonathan Corbet, 29. března 2011
Od posledního dílu této série bylo do hlavní řady začleněno těsně nad 2 200 neslučovacích sad změn; pro tento vývojový cyklus to celkem dělá 8 757 změn. Začleňovací okno 2.6.39 je nyní zavřené, takže sada vlastností pro tento vývojový cyklus by měla být kompletní. Mezi změny viditelné pro uživatele, které byly začleněny v poslední fázi začleňovacího okna, patří:
Byly začleněny počátky jmenného prostoru pro uživatele. Tento jmenný prostor je určitý druh kontejneru, ve kterém lze procesům bezpečně dát práva superuživatele, aniž by byl schopen ovlivnit zbytek systému. Kompletní podpora kontejnerů je dlouhodobý projekt, ale s těmito patchi je jádro o krok dále.
Dostatečně privilegovaný proces může nyní zapisovat do souboru /proc/pid/mem.
Z I/O CFQ plánovače byla odstraněna volba pro „izolaci skupin“; vzhledem k tomu, že výkonnostní problémy tohoto režimu byly odstraněny, je izolace procesů zapnuta vždy.
Nové blokové zařízení „mtdswap“ umožňuje swapovat přímo na paměťové zařízení [memory technology device].
Mezi změny viditelné pro jaderné vývojáře patří:
V jádře se již nepoužívá typ dma64_addr_t, byl odstraněn.
Framework videobuf v subsystému Video4Linux2 byl nahrazen novější verzí „videobuf2“.
Byl začleněn subsystém pro řízení multimédií, který má systému umožnit exportovat informace o topologii složitých mediálních subsystémů do uživatelského prostoru.
printk() a spol. mají nový specifikátor formátu „%pB“, který vypíše symbol z výpisu volání [backtrace symbol] a jeho offset.
Ve stromě zdrojových kódu jádra byly sloučeny architektury m68k a m68knommu.
Byla přidána podpůrná knihovna pro kódování a dekódování pomocí BCH (Bose-Chaudhuri-Hocquenghem).
Změnila se jména některých nízkoúrovňových funkcí spojených s přerušeními:
| Staré | Nové |
|---|---|
| get_irq_chip() | irq_get_chip() |
| get_irq_chip_data() | irq_get_chip_data() |
| get_irq_msi() | irq_get_msi_desc() |
| irq_data_get_irq_data() | irq_data_get_irq_handler_data() |
| set_irq_chained_handler() | irq_set_chained_handler() |
| set_irq_chip() | irq_set_chip() |
| set_irq_chip_and_handler_name() | irq_set_chip_and_handler_name() |
| set_irq_data() | irq_set_handler_data() |
| set_irq_handler() | irq_set_handler() |
| set_irq_nested_thread() | irq_set_nested_thread() |
| set_irq_noprobe() | irq_set_noprobe() |
| set_irq_type() | irq_set_irq_type() |
| set_irq_wake() | irq_set_irq_wake() |
Prototypy těchto funkcí se jinak nemění.
Jádro 2.6.39 nyní přechází do stabilizační fáze vývojového cyklu. Pokud nedojde k nějakým výjimečnostem, můžeme očekávat, že před vydáním finální verze by mohlo být začleněno nějakých 2 000 oprav a že k samotnému vydání dojde začátkem června.
napsal Jonathan Corbet, 29. března 2011
Unixové systémy bývají dobře opevněné vůči útokům z vnějšku, ale mnohem náchylnější na útoky lokálních uživatelů. Jedno slabší místo se týká „fork bomb“ - procesů, které se šíleně fork()ují, dokud systému nedojdou zdroje. Proti těmto útokům je obtížné se bránit a je obtížné je zastavit bez rebootu; a občas k nim může dojít nešťastnou náhodou. Jestliže vyjde snaha, se kterou přišel Hiroyuki Kamezawa, v budoucnosti bude s fork bombami méně problémů.
Problémem fork bomb je to, že jsou to pohyblivé cíle; v době, kdy si správce systému všimne rapidně se množícího procesu, může již být vytvořeno mnoho potomků a počáteční proces sám o sobě již bude ukončen. Zabíjení procesů jednotlivě není možné; i program napsaný obzvláště k tomuto účelu nemusí stíhat proud nových procesů. Prostě není možné zvládnout celý strom škodících procesů z uživatelského prostoru. Není tedy překvapením, že nejlepším řešením je v této situaci zatáhnout za záchrannou brzdu a začít znovu. I když to – jako v Kamezawaově případě – znamená jít do jiné budovy, kde je postižený stroj umístěn.
Odchytit strom škodlivých procesů může být těžké i z jádra. Stromy procesů jako takové existují jenom do té doby, dokud je naživu předek; jakmile se ukončí, rodičem všech jeho potomků se stane init. Tím se strom zploští a ztíží se tak identifikace procesů, které se na útoku podílejí. Kamezawův patch tedy začíná přidáním nové struktury pro sledování procesů; ta je organizována jako jednoduchý strom odrážející skutečnou strukturu rodiny procesů v systému. Od existujících datových struktur se nicméně liší tím, že „strom historie“ zůstane zachován, i když se některé procesy ukončí. To jádru umožní najít celý strom procesů podílejících se na fork bombě, i když ten, který útok zahájil, již dlouho neexistuje.
Udržovat kompletní historii všech procesů vytvořených za celou dobu běhu linuxového systému by bylo drahé, je zjevné, že přijde chvíle, kdy je nutné historii zahodit. Proto se jádro jednou za čas (ve výchozím nastavení jednou za 30 sekund) pokusí zjistit, jestli neprobíhá útok fork bombou; pokud nic takového neobjeví, zahodí veškerou historii delší než 30 sekund.
Jak jádro přijde na to, že čelí útoku? Fork bomby systém obvykle zastaví tím, že dojde paměť, takže kód hledá známky nedostatku paměti: konkrétně jestli od poslední kontroly docházelo ke zpožděním alokace paměti nebo ke spouštění kswapd. Také sleduje, jestli se v systému nezvýšil počet procesů. Jestliže žádná z těchto kontrol nenajde nic podezřelého, starší historie se zahodí. Pokud jsou alokace paměti obtížnější a počet procesů roste, sledovací struktura se ponechá.
Když fork bomba způsobí vyčerpání paměti, první reakcí jádra bude spuštění zabijáka při nedostatku paměti [OOM killer]. Tomu se postupem času problém podaří překonat, ale faktem je, že OOM zabiják byl vždy navržen tak, aby našel a zabil jeden proces, který dělá problémy. Neumí najít celý strom procesů, které se rychle množí, a zabít je všechny.
Zde do hry vstupuje zabiják fork bomb [fork bomb killer], kterého spustí OOM zabiják. Zabiják fork bomb projde strom historie procesů a do každého uzlu zapíše počet procesů pod ním a celkový objem paměti, kterou tyto procesy využívají. Nakonec se prozkoumá proces s nejvyšším skóre; jestliže je v jeho historii deset procesů nebo více, je považován za fork bombu a on i jeho potomci jsou pozabíjeni. A je uklizeno – snad.
Do /sys/kernel/mm/oom přibývá několik ladících prvků. Historie se sleduje jenom v případě, že je do mm_tracking_enabled zapsáno „enabled“ (což je výchozí nastavení). Hodnota mm_tracking_reset_interval_msecs řídí, jak často se pročistí strom sledující procesy; výchozí hodnota je 30000. Poměrně překvapivě chybí možnost nastavit, kolik potomků musí proces mít, aby byl považován za fork bombu; přednastavená hodnota se zdá být poměrně nízká.
Přijetí tohoto patche nebylo úplně příznivé; komentátoři mají obavy z nákladů na správu sledovací struktury a naznačují, že řešení v uživatelském prostoru by mohlo být lepší. Kamezawa se podle všeho smířil s tím, že patch nemusí být začleněn, a řekl: Chodit o budovu vedle, abych stiskl reset, je dobré pro moje zdraví. Jiní administrátoři, kteří to ke svým strojům nemají tak blízko, nicméně možná budou mít pocit, že jejich zdraví by spíš prospěla větší ochrana proti fork bombám.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Tak zřejmě mám špatně nakonfigurované jádro: Modul se kompiluje, když je nastavený CONFIG_APM, a ten potřebuje CONFIG_PM_SLEEP a ten potřebuje SUSPEND || HIBERNATION || XEN_SAVE_RESTORE. Naivně jsem se domníval, že na vypnutí není CONFIG_SUSPEND potřeba, protože suspendovat stroj nepotřebuji.
Teď ještě jestli to vyřeší i vypínání monitoru. Podle arch/x86/kernel/apm_32.c bude nutné ještě zapnout CONFIG_APM_DISPLAY_BLANK. Vyzkouším.
11.4.2011 12:28
Nicky726 | skóre: 56
| blog: Nicky726
11.4.2011 20:24
josi | skóre: 10
17.4.2011 18:18
josi | skóre: 10
17.4.2011 18:19
josi | skóre: 10
Nevim presne jak je to s transkripci japonstiny, ale u cinstiny se vede uz skoro vecnej spor jestli je pro cechy lepsi zapisovat pomoci oficialni transkripce cinstina -> anglina a nebo pouziva ceskou, ktera je skvela srozumitelnost, ale nikdo mimo nas ji nerozumi.
Jako "kolemjdoucimu" je mi samozrejme prijemnejsi ceskej prepis, ale ten mezinarodni ma svoje vyhody ... tezko rict, tady by se mozna vic uplatnil ten ceskej.
Většina médií ale stejně používá obě transkripce zároveň, někdy dokonce nějaké hybridy a mají v tom obrovský guláš.
Pro ty, kteří to mají daleko, přece existuje xt_SYSRQ xtables modul!