PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Aktuální vývojová verze jádra je 3.5-rc7 vydaná 14. července. Hele lidi, vzpomínáte na to, jak se všechno zklidňovalo a zpomalovalo a všichni jaderní vývojáři byli na letní dovolené? No, tak o tom si spolu musíme pěkně popovídat.
Stabilní aktualizace: verze 3.0.37 a 3.4.5 vyšly 16. července; verze 3.2.23 vyšla 13. července. Verze 3.0.38 a 3.4.6 se aktuálně revidují.
Nerad bych toto musel někomu vysvětlovat [...]
-#define HV_LINUX_GUEST_ID_HI 0xB16B00B5 +#define HV_LINUX_GUEST_ID_HI 0x0DEFACED
-- Signed-off-by: Matthew Garrett
A aby to bylo ještě horší, „x" bylo samo o sobě výsledkem “*&y". Což bylo asi napsáno Maxem, starším bratrem šílené opice, který strávil několik let žvýkáním metaqualonu, následkem čehož na tom jeho mozek také nebyl moc dobře. I na opici. A teď zrovna *jeho* pouštíš ke své klávesnici?
Na Linux.com vyšel rozhovor s Davem Jonesem, správcem jádra ve Fedoře, a to v rámci seriálu o jaderných vývojářích. Potřeboval jsem si sestavit vlastní jádro, protože ani jedno z distribučních nepodporovalo funkci, co jsem potřeboval. A tato funkce byla v té době dostupná jen ve vývojovém stromě (což tehdy bylo 2.1.x). Už ani nevím, co to bylo, ale možná to bylo něco hloupého jako VFAT. Ne vždycky bylo jádro stabilní, tak jsem si navykl jej pravidelně aktualizovat (z univerzity jsem si domů odnášel poslední tarball vždy na ZIP disketě). Začal jsem posílat patche, kdykoliv jsem narazil na něco, co bych mohl vylepšit. Už si nemohu vzpomenout na svou první skutečně významnou věc. V řadě 2.1.x jsem opravoval AFFS. Předtím šlo o desítky drobností.
Nastavování jádra dříve bývalo přímočaré, stačilo jen vědět, pro jaký hardware je třeba mít podporu. Časem se to trochu zkomplikovalo, hlavně ale distribuce začaly záviset na konkrétních funkcích jádra – pro běžného uživatele může být obtížné tyto závislosti zjistit. To vedlo Linuse Torvaldse k sepsání návrhu RFC, aby do jádra byly zařazeny konfigurační volby pro konkrétní distribuce.
Problém má svůj původ v tom, že uživatelský prostor distribuce vyžaduje pro správné fungování zapnutí některých konfiguračních voleb. Věci jako tmpfs a devtmpfs, řídící skupiny, bezpečnostní volby (jako SELinux, AppArmor) a dokonce i podpora surových tabulek netfilter byla zařazena na seznam voleb „podpůrné infrastruktury“, jež různé distribuce vyžadují. Kromě toho, že je těžké na toto všechno přijít, se tyto volby časem mění, takže konfigurace použitelná pro Fedoru N nemusí fungovat na Fedoře N+1. Výsledné problémy může být těžké odhalit, jak Torvalds poznamenal: Párkrát se mi už stalo, že jsem začal se svým minimálním config souborem a výsledné jádro sice nabootovalo, ale některé věci nefungovaly zrovna správně a může jít o dosti nenápadné problémy.
Proto navrhl přidání souborů Kconfig pro konkrétní distribuce:
Postupně se dostávám k tomu, že bych velice rád viděl *distribuční* soubory Kconfig, kde by distribuce mohly určit svou minimální konfiguraci, se kterou budou fungovat. Takže bychom měli podmenu „Distribuce“, kde byste si mohli vybrat svou distribuci a pak i verzi [...] což by to značně usnadnilo obyčejným uživatelům (a upřímně řečeno bych se do této skupiny také rád zařadil) vytváření jaderných konfigurací, které zkrátka fungují.
Našla by se i jiná řešení, ale ta by měla své nedostatky. Kopírování distribučního souboru config by mohlo stačit, ale znamenalo by to spoustu nadbytečných voleb, které nejsou pro správné fungování distribuce skutečně zapotřebí. Používání make localmodconfig (které vybere všechny volby podle spuštěného jádra) trpí v podstatě tím samým problémem, jak říká. Cílem je to, aby jádra dokázalo sestavovat více lidí.
Skutečně si myslím, že „jak stvořím config soubor pro jádro“ je problémem, který od kompilace vlastního jádra odrazuje spoustu lidí. Ale my *chceme*, aby si lidé kompilovali vlastní jádra, aby nám mohli pomoci třeba s bisect atd. Čím více, tím lépe.
Na linux-kernel se nápad setkal se souhlasem. Vyskytly se obavy o to, jak by soubory distribucí byly udržovány a že někdy nemusejí odrážet aktuální požadavky. Dave Jones poznamenal, že je občas požadavky na jádro ve Fedoře zaskočen (a to je jeho správcem).
Torvalds dává jasně najevo, že nehledá dokonalé řešení, ale spíše prostě jen něco lepšího: i config soubor postavený na základě kvalifikovaného odhadu je lepší než to, co máme teď. V tomto mailu popisuje dva požadavky, které na funkci má. První je to, že každá konfigurační volba nastavená pro určitou distribuci musí u sebe mít vysvětlení, proč je zapotřebí. Druhým je to, že musí jít o sadu minimálních voleb, které jsou nutné pro správné fungování systému – a ne že to bude mít nakonec všechny volby jen proto, že se někdo rozhodl přidávat náhodné volby, dokud to nezačalo fungovat.
Okomentování vyžadovaných voleb může ale být obtížné i pro ty, co pracují přímo s distribučními jádry. Ben Hutchings (který spravuje jádro Debianu) upozornil, že ani on sám nemusí znát důvod, proč byla určitá volba povolena, zejména, když už je to delší doba: jen to, že někdy bylo o volbu požádáno kvůli podpoře čehosi v uživatelském prostoru, neznamená, že vím, co to používá nebo co na tom závisí teď.
Je ale možné povolit i další volby. V původní zprávě Torvalds zmínil konfigurace pro „běžné platformy“ jako „moderní notebook“, které by vybraly to, co je pro ně nutné (USB storage, FAT/VFAT, správa výkonu apod.). Konkrétně řekl, že nastavení platformy by mělo být považováno za věc oddělenou od myšlenky distribucí.
I uživatelé KVM (a jiných virtualizací) měli zájem o vytvoření volby, která by vybrala všechny ovladače a další volby nutné pro tato jádra. Aktuálně musíte prolézt přes >30 různých menu, abyste našli všechno to, co je pro běh základního systému pod KVM potřeba; tak to popsal Trond Myklebust. O nutnosti přidání lepších voleb pro virtualizaci se diskutovalo hodně, ale to už se téma dostalo od původního Linusova návrhu dost daleko.
Není překvapením, že jaderní vývojáři začali přemýšlet nad tím, jak by právě oni mohli tuto funkci zužitkovat. Vyskytly se obavy, že zvolení konkrétní distribuce a jejích závislostí by jaderným vývojářům mohlo ztížit další úpravy nastavení. David Lang měl konkrétní stížnosti na postup navržený v RFC – například by bylo těžké vybrat jádro pro Fedoru bez SELinuxu. Ale Torvalds dal jasně najevo, že Lang a ostatní jaderní hackeři nejsou cílovou skupinou.
To, oč žádám, je pro obyčejné lidi. Pro lidi, které konfigurační soubor NEZAJÍMÁ, a jen chtějí sestavit jádro pro svůj stroj.
Nekomplikujte věc kladením zcela nesouvisejících otázek. Neničte funkci užitečnou pro 99 % lidí jen proto, že nejste mezi nimi.
Potěšit všechny může přesto být možné – Lang si to tak jako tak myslel – ale než někdo dodá nějaký ten kód, je těžké o tom mluvit. Ačkoliv se všichni shodli, že funkce může být užitečná, nikdo se nehlásil jako dobrovolník. Zda šlo Torvaldsovi jen o to nadhodit myšlenku a nechat někoho jiného to uskutečnit, není jasné, ale vypadá to jako něco, co by stálo za to mít.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
To vedlo Linuse Torvaldse k sepsání návrhu RFC, aby do jádra byly zařazeny konfigurační volby pro konkrétní distribuce.A to se zrovna snažím vykopat zbytečné závislosti na distribucích z NetworkManageru. Názor Linuse hodně moc uznávám, ale v tomhle případě se mi zdá, že to není ústupek na správném místě.
http://kmuto.jp/debian/hcl/ tohle?
Nebo pokud te to vic zajima, muzes se primo podivat, jak se dela distribucni jadro:
fedpkg clone --anonymous kernel
Tak si naklonujes git repozitar se vsemi skripty, patchi a konfiguraky. Btw treba v README.txt se pise:
config heirarchy.
-----------------
Instead of having to maintain a config file for every arch variant we build on,
the kernel spec uses a nested system of configs. At the top level, is
config-generic. Add options here that should be present in every possible
config on all architectures.
Beneath this are per-arch overrides. For example config-x86-generic add
additional x86 specific options, and also _override_ any options that were
set in config-generic.
The heirarchy looks like this..
config-generic
|
config-x86-generic
| |
config-x86-32-generic config-x86-64-generic
An option set in a lower level will override the same option set in one
of the higher levels.
There exist two additional overrides, config-debug, and config-nodebug,
which override -generic, and the per-arch overrides. It is documented
further below.
/proc/config.gz, je pořád možné, že je konfigurace v jádře obsažena a dá se z něj vytáhnout pomocí scripts/extract-ikconfig (viz volby CONFIG_IKCONFIG a CONFIG_IKCONFIG_PROC).
buil-essential).
Docela by se to hodilo i pro ne-x86 platformy (rozličné SoC ARMy obzvlášť), kde je docela problematické zjistit, co tom kterém zařízení je (u x86 je alespoň lspci), takže pokud distribuční/defaultní jádro nemá vestavěný .config.gz, tak to znamená spousta googlení, prolézání hlášek jádra a zkoumání jednotlivých obvodů na desce.
Já osobně používám na svých strojích vlastní jádro "odjakživa" a mám přehled, co je potřeba a co ne, ale kdybych musel dělat jádro pro jinou distribuci než Debian nebo specializovaný pseudo-LFS, tak bych podobný přehled toho, co je třeba zapnou, uvítal.
Zbytečně závislosti NM lze elegantně vyřešit jeho odistalováním a nahrazením Connmanem...Co by mi to přineslo?