Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
Společnost xAI a sociální síť X amerického miliardáře Elona Muska zažalovaly firmy Apple a OpenAI. Viní je z nezákonné konspirace s cílem potlačit konkurenci v oblasti umělé inteligence (AI).
Byla vydána nová verze 9.16 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Americká vláda se po převzetí zhruba desetiprocentního podílu ve výrobci čipů Intel chystá na další investice do vybraných firem. Na sociální síti Truth Social to napsal prezident Donald Trump. Jeho ekonomický poradce Kevin Hassett v rozhovoru v televizi CNBC řekl, že nemusí jít pouze o firmy z technologického sektoru, ale i z jiných odvětví.
V Amsterdamu probíhá Open Source Summit Europe. Organizace Linux Foundation představuje novinky. Pod svá křídla převzala open source dokumentovou databázi DocumentDB.
Přesně před 34 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
86Box, tj. emulátor retro počítačů založených na x86, byl vydán ve verzi 5.0. S integrovaným správcem VM. Na GitHubu jsou vedle zdrojových kódů ke stažení také připravené balíčky ve formátu AppImage.
Vláda Spojených států získala desetiprocentní podíl v americkém výrobci čipů Intel. Oznámili to podle agentur americký prezident Donald Trump a ministr obchodu Howard Lutnick. Společnost Intel uvedla, že výměnou za desetiprocentní podíl obdrží státní dotace v hodnotě 8,9 miliardy dolarů (zhruba 186 miliard Kč). Částka podle Intelu zahrnuje dříve přislíbené subvence 5,7 miliardy dolarů z programu CHIPS na podporu výroby čipů v USA,
… více »Organizace Apache Software Foundation (ASF) vydala verzi 27 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Současné vývojové jádro je 3.0-rc6 vydané 4. července. Obsahuje nový isci ovladač od Intelu, který přidává výrazný kus kódu, ale jinak se jedná o jednoduché opravy. Blíží se to k bodu, kdy si myslím, že bychom měli prostě vydat 3.0, byl poměrně klid a opravy nejsou nijak výrazně zajímavé. Detaily vizte v kompletním changelogu.
Stabilní aktualizace: během minulého týdne žádné nevyšly a žádné se v době psaní tohoto článku nerevidují.
-- Alan Cox
napsal Jake Edge, 7. července 2011
Patche, které rozšiřují funkcionalitu seccomp („secure computing“, bezpečné vykonávání kódu) poletují okolo hlavní řady dva roky, ale dostat se do ní se jim nedaří. Mnoho projektů má zájem rozšířený seccomp používat, ale patche samotné se dostaly do bezvýchodné situace. Jsou tu konfliktní představy o tom, jak by se tato vlastnost měla přidat, a není jasné, která možnost bude akceptovatelná pro všechny relevantní správce. Máme tedy užitečnou vlastnost bez jasné cesty do jádra, což je pro někoho nepochybně frustrující.
Když jsme se před více než dvěma lety poprvé dívali na seccomp sandbox, Adam Langley zaslal patche, které by procesu (a jeho potomkům) umožnily omezit systémová volání, která může provést. Cílem je umožnit procesu uzavřít se do sandboxu tím, že si může zvolit, která systémová volání jsou k dispozici, místo toho, aby byl omezen na natvrdo nastavená systémová volání (read(), write(), exit() a sigreturn()), jak to umožňuje existující implementace seccomp. Podnětem pro Adamovy patche bylo poskytnout jednodušší mechanismus pro omezení procesu webového prohlížeče Chromium – a umožnit odstranění poměrně složitého sandboxu, který Chromium v Linuxu používá nyní.
V té době Ingo Molnár naznačil, že rozšířené seccomp by bylo mnohem užitečnější s filtrováním ve stylu ftrace. Nápad jako takový nebyl všeobecně přijat a seccomp nečinně leželo, dokud ho v dubnu neoživil Will Drewry. Will přijal Ingovy návrhy a implementoval verzi seccomp, která umožňovala povolit, zakázat nebo filtrovat systémová volání jednoduchými výrazy (např. sys_read: (fd == 0)).
I když Ingo byl tímto krokem potěšen, nemyslel si, že zachází dost daleko, a navrhl, aby se místo prctl(), které používá současné seccomp, použilo rozhraní podobné perfu. Měl poměrně široce zaměřené nápady, jak aktivněji použít události výkonnosti [perf events] tak, aby to vedlo k lepším bezpečnostním řešením v jádře, než jaká nabízí existující přístup s linuxovými bezpečnostními moduly [Linux Security Modules, LSM]. Ani tento nápad nebyl přijat všeobecně, zejména vývojáři LSM jím nebyli okouzleni.
Will nicméně implementoval ukázkový patch tak, jak to navrhl Ingo. To vedlo ke stížnostem z poměrně překvapující strany, protože jak Peter Zijlstra, tak Thomas Gleixner naprosto nesouhlasili s použitím perfu v aktivní roli. Jejich odpovědi nenechaly žádný prostor pro kompromisy, protože Peter, který je společně s Ingem jedním ze správců perfu, řekl, že on i Thomas dají NAK každému a všem patchům, které by rozšířily perf/ftrace kamkoliv za roli pasivního pozorovatele.
To všechno vedlo Willa, který se v tu chvíli musel cítit jako někdo polapený mezi dvěma mlýnskými kameny, k návratu k sadě patchů, která podle všeho měla největší podporu: použít filtry ve stylu Ftrace/perf, ale zachovat prctl() rozhraní, které v současnosti používá seccomp. Linus Torvalds vyjádřil svoji skepsi, že by to mělo nějaké reálné použití, ale Will naznačil, jak by ji použilo Chromium, a několik dalších vývojářů se vyslovilo pro rozšíření seccomp s tím, že QEMU, Linuxové kontejnery [Linux containers, LXC] a další věci by tuto vlastnost využily také. Tato podpora společně s vyřešením několika dalších technických záležitostí byla dostatečná k tomu, aby Linus své námitky stáhl. Jak se ale dá uhodnout, Ingo stále s tímto přístupem není spokojen.
Když koncem června Will znovu zaslal sadu patchů a zeptal se, jak dál, Ingo poznamenal, že na jeho námitky není reagováno: V současnosti tlačíš na 'filtrovací engine', nikoliv na (mnohem) jednotnější přístup s 'filtry událostí'. Will se ale snaží najít střední cestu mezi potřebami uživatelů, požadavky ostatních správců a Ingovy požadavky, což je obtížné až nemožné:
Ingo je ale neústupný a tvrdí, že přístup s „filtrovacím engine“ je krátkozraký, jako důkaz citoval diffstat různých implementací:
bitová maska (2009): 6 files changed, 194 insertions(+), 22 deletions(-) filtrovací engine (2010): 18 files changed, 1100 insertions(+), 21 deletions(-) filtry událostí (2011): 5 files changed, 82 insertions(+), 16 deletions(-)
Jak ale Will upozornil, na ukázkovém prototypu je potřeba odvést ještě mnoho práce, než bude všechno kompletně vyřešené. Vzhledem k tomu, že daný přístup dostal několik NAK, odvedení veškeré práce nemá moc dobré vyhlídky. Will by chtěl, aby daná vlastnost byla k dispozici brzy a má obavy z toho, že práce na širších záležitostí ji významně zdrží, pokud se vůbec někdy dostane přes námitky: Pokud bude všechna ta ostatní práce předpokladem pro omezení systémových volání, bude velké štěstí, když něco uvidíme tento kalendářní rok, pokud vůbec za tu dobu dokážu napsat patche.
Inga to ale neodradilo a navrhl, aby se patch do jádra dostal přes strom, který spravuje:
Problém je v tom, že těch 5 % (tj. omezení systémových volání a sandbox) je ten kus, který by Will a ostatní rádi viděli v jádře. Ingo tedy nabízí poměrně velký kus práce, který by nakonec mohl tu „zajímavou“ část ponechat venku na mraze. Ingo možná věří, že může překonat námitky Petera Zijlstry a Thomase Gleixnera, ale Will takovým optimistou může být jenom těžko. Problém popsal tak, jak ho vidí on:
Peter i Thomas se této diskuze neúčastnili, takže je těžké říci, co si myslí. Dokud se ale neobjeví žádné náznaky, že mírní svůj odmítavý přístup, není dobrý nápad věřit, že si něco rozmysleli.
Je to problém, který jsme již dříve viděli, nová vlastnost je do určité míry držena jako rukojmí s požadavkem, aby byl vyřešen větší problém. To bylo diskutováno na Jaderném summitu 2009, kde došlo ke shodě že takové požadavky by pro příště měly být pouze doporučením a ne nutností. V tomto případě Ingo požaduje odvedení větší práce jenom tím, že nemá zájem přijmout kód přes strom -tip, pokud nevyřeší větší problém.
Není jasné, kudy se věci budou ubírat dál. Will řekl, že se to zkusí udělat tak, jak požaduje Ingo (ale jestli moje jediná šance, jak zařídit, aby to bylo přijato, je sdílet kód s perfem a vytvořit nové ABI, pak tuto práci odložím do doby, kdy se s něčím takovým budu schopen vypořádat), ale to může trvat ještě dlouho. V současnosti má několik projektů zájem tuto vlastnost používat.
Pokud návrat k verzi s bitovou masku těmto projektům bude stačit, je možné pokusit se dostat ji do jádra přes jiný strom (např. strom security). Ingo by bezpochyby měl námitky, ale pokud se za tento požadavek postaví dost uživatelů, může to být rozumný přístup. Vzniklo by tím ABI, které by bylo nutné do budoucna udržovat, což je jednou z Ingových námitek, ale pro Chromium a ostatní by to vyřešilo problémy.
Steven Rostedt navrhl prodiskutovat rozšíření seccomp v říjnu na Jaderném summitu, z čehož by mohla vzejít cesta kupředu. Je pravděpodobné, že všechny zainteresované strany budou přítomny, na rozdíl od Linux Security summitu, který se bude konat společně s Linux Plumbers Conference v září a který byl navržen jako alternativa. I když diskuze z očí do očí může pomoci, těžko věřit tomu, že vyřeší neshodu o aktivním vs. pasivním perfu. Na druhou stranu by mohl nějaké stanovisko zaujmout Linus – to by k vyřešení této záležitosti mohlo pomoci hodně.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: