Nizozemská vláda ve snaze šetřit a zvyšovat efektivitu s využitím umělé inteligence (AI) hodlá zrušit asi 25.000 pracovních míst ve státní správě. Cílem je postupně dosáhnout ročních úspor až 3,5 miliardy eur (85,2 miliardy Kč). Na konci loňského roku ve státní správě pracovalo rekordních 160.000 lidí. „Nemůžeme pokračovat v tom, co jsme dělali dosud,“ uvedl státní tajemník pro efektivní fungování vlády Eric van den Burg. „Proto
… více »Příspěvek na blogu PRUSA 3D představuje fotoaparát CAIM1 (Counter Artificial Intelligence Machine 1). Uměle vytvořený obsah je každým dnem těžší rozeznat od skutečných záběrů či fotografií, což podrývá důvěryhodnost žurnalistiky, archivních materiálů i každodenní tvorby obsahu. Fotoaparát CAIM1 byl vyvinut právě k tomu, aby ověřoval původ fotografií a videí přímo během jejich pořizování. Uvnitř fotoaparátu se nachází hardwarová Web3 peněženka se zabezpečovacím čipem Tropic Square TROPIC01.
Jonathan Thomas oznámil vydání nové verze 4.1 video editoru OpenShot (Wikipedie). Zdrojové kódy OpenShotu jsou k dispozici na GitHubu. Ke stažení je i balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo na spouštění a spustit.
Při běžné migraci virtuálního stroje mezi hypervizory se jeho MAC adresa přesune na jiný leaf switch. EVPN tuto změnu distribuuje pomocí BGP Type-2 route a MAC mobility sequence number. Problém nastává, pokud útočník podvrhne zdrojovou MAC adresu jiného zařízení. Leaf může změnu interpretovat jako legitimní přesun MAC a rozšířit ji přes BGP do celé fabric. Výsledkem může být přesměrování provozu určeného původnímu zařízení. Autor článku rozebírá možnosti detekce pomocí sledování MAC moves, BGP route reflektorů a kontroly na přístupové vrstvě.
Vývojáři desktopového prostředí Enlightenment (Wikipedie) a souvisejících knihoven Enlightenment Foundation Libraries (EFL) vydali nové verze. Enlightenment byl vydán ve verzi 0.28.0 a Enlightenment Foundation Libraries ve verzi 1.29.
Cloudflare zjistil, že některé odpovědi modelu GLM-5.3 obsahovaly části dat z předchozích požadavků jiných zákazníků. Příčinou byla kombinace chybné konfigurace a chyby v inference enginu SGLang. Model podporoval kontextové okno 1 048 576 tokenů, ale GPU KV cache pool měl kapacitu pouze 681 280 tokenů. Při překročení kapacity docházelo k nesprávnému zpracování odmítnutého požadavku. Decode část systému následně pracovala se starými
… více »Vývojáři Knot Resolver vysvětlují, jak změnili rozhodování o tom, které DNS záznamy ponechat v cache a které odstranit. Článek obsahuje skutečná měření: devět hodin DNS provozu při 2 000 QPS, srovnání cache o velikosti 25 MB a 40 GB a také porovnání s BIND 9, kromě algoritmů obsahuje konkrétní doporučení pro konfiguraci a diagnostiku.
Největší kryptoměnová burza světa Binance se stala terčem útoku, při kterém podvodníci odcizili během několika minut kryptoměny v hodnotě přibližně 6,3 miliardy dolarů. Jedná se o největší kryptoměnovou krádež v historii, přibližně čtyřikrát větší než loňský útok na burzu Bybit. Binance se podařilo ve spolupráci s partnery zmrazit aspoň aktiva v hodnotě zhruba 3 miliard dolarů a slíbila, že veškeré ztráty pokryje z vlastních prostředků.
Zranitelnost CVE-2026-98432 s CVSS 9.8 odhalila AI od společnosti Anthropic. Jedná se o kritickou chybu v implementaci MPTCP (multipath TCP). Debian vydal patche 16.10. a 22.10., ale např. Ubuntu je zatím bez opravy. Více informací na The Hacker News.
Na Slovensku vznikla úplne nová rally hra, ktorá je zadarmo a funguje vo Windowse, Linuxe či na Macu. Greenie Rally má viac ako 50 tratí a vozidiel, šampionáty či turnaje. Má retro feeling a imituje automobilové hry z prelomu tisícročí. Vyskúšate prejsť všetky mapy na Škode 130RS?
Ne, tento blog opravdu nemá nic společného s vývojem Linuxového jádra :-) Jako "Jaderný blog" jsem jej pojmenoval jen kvůli mé oblibě jaderné fyziky a chemie.
Věnovat se chci především Linuxu a Free Softwaru, prezentovat zde svůj pohled na věc a věnovat se všem palčivým otázkám a problémům, na které narazím. Určitě se zde také objeví články týkající se KDE, jelikož jsem velkým milovníkem tohoto desktopového prostředí a obecně eye-candy (k velké nevůli "pravověrných" Linuxáků ;-)).
No a když už se to tu jmenuje Jaderný blog, možná se někdy dočkáte i nějakého populárně-vědeckého příspěvku, především pokud se bude jednat o nějaké ožehavé aktuální téma...
Už jsem na pár místech sliboval, že vysvětlím důvody, které mě vedly k přechodu z mého milovaného Gentoo na můj (nyní již také milovaný) Arch Linux... takže tady to máte 
Začátky (klidně přeskočte
)
Asi tak před 2 lety (možná o něco málo déle) jsem přešel z Windows na Linux. Mojí první distribucí byl Red Hat 8.0 (který jsem velmi brzy upgradoval na 9.0). Vše bylo krásné a začal jsem pomalu pronikat do světa Linuxu. Ovšem asi tak po roce, když jsem již do tajů Linuxu jakž takž pronikl, mi Red Hat přestal vyhovovat. Za tu dobu se z mé instalace Red Hatu stala nesmírně "bloated" věc (nebo možno také použít výrazu "bordel"
), zažil jsem si trochu toho RPM dependency hell a hlavně mi strašně vadilo, že jsem v Red Hatu neměl dokonalou kontrolu nad systémem. Systém jakým v Red Hatu byly řešeny některé konfigurace, atp. se mi prostě zhnusil.
Vzhledem k tomu, že jsem chtěl mít nad systémem opravdu dokonalou kontrolu (a už tehdy se mi líbila myšlenka kompilace celé distribuce ze zdrojáků), rozhodoval jsem se mezi dvěmi možnostmi - Linux From Scratch a Gentoo. Jelikož nejsem masochista (nic proti lidem kteří LFS používají, obdivuji je
) a svůj system sem chtěl mít neustále aktuální, rozhodl jsem se nakonec pro Gentoo.
Mé milované Gentoo
Gentoo jsem si nesmírně zamiloval. Nejvíce mě na něm uchvátila portage, rychlost a stálá aktuálnost systému. Vskutku ze začátku jsem měl vždy prakticky ihned ty nejnovější verze programů a to jsem používal stable x86 system. Princip "rolling-updates" jsem si zamiloval, někdo může sice potřebou mít vždy ty nejaktuálnější verze programů opovrhovat, ale každý jsme prostě jiný a máme jiné priority 
Za tu dobu co jsem používal Gentoo jsem se (nejen) o Linuxu naučil neuvěřitelnou spoustu věcí. Stále se považuji za začátečníka (protože člověk se má pořád co učit), ale to nic nemění na tom, že Gentoo mě k získávání stále nových a nových informací a zkoušení nových věcí nesmírně motivovalo. Je pravda, že instalaci Gentoo podle dokumentace by zvládl možná každý kdo umí číst a dělal někdy na PC, ale Gentoo prostě člověka tak nějak vede k tomu, aby se toho o Linuxu naučil více.
Co mě tedy k přechodu z Gentoo na Arch Linux dovedlo? Vždycky sem chtěl mít system co nejaktuálnější, ovšem nechtěl jsem nad ním ztrácet kontrolu. Zprvu jsem i při použití stable x86 system krásně aktuální měl, avšak později jsem musel přidávat stále více a více věcí do /etc/portage/package.keywords jako unstable ~x86. Nakonec to dopadlo tak, že můj soubor package.keywords měl délku přes 6 obrazovek a pomalu mi začínala docházet trpělivost. Zvažoval jsem i kompletní přechod na ~x86, ale to se z mého hlediska rovnalo ztrátě kontroly nad systemem, čemuž jsem se chtěl za každou cenu vyvarovat. Některé ebuildy byly navíc neaktuální i v jejich ~x86 verzi, jiné zas byly hard-masked (a odmaskovávat hard-masked ebuildy jsem opravdu nechtěl). A co mě ještě více vadilo - spousta balíčků v portage vubec nebyla a musela se hledat po fórech a v bugzille.
To všechno by ani nebyl až zas takový problém, ovšem poslední kapkou bylo, když jsem viděl jak se spousta ebuildů na novější verze či chybějící programy sice válí v bugzille, nicméně se tam válela již dosti dlouho a to že by byly přijaty do portage se jevilo v nedohlednu. Gentoo developeři (kterých si jinak velmi vážím, prosím neberte to nijak špatně!) se sice omlouvali stylem "je nás málo", ovšem že by začali více přijímat nové developery z řad komunity nebo zrevidovali system přijímání ebuildů a udělali ho otevřenější komunitě, to ne.
Můj milovaný Arch
A tak jsem tedy vyzkoušel Arch. A jsem s ním spokojen
Na Archu se mi líbí, že je to nesmírně čistý system (podobně jako Gentoo nebo Slackware... osobně jej právě považuji za spojení toho nejlepšího z Gentoo a Slackwaru), disponuje výborným balíčkovacím managerem pacman (který se v mnohém vyrovná emerge a v něčem ho i předčí - třeba v tom že podporuje "reverse dependencies") a ABS (Arch Build Systemem), což je systém portů podobných portage pro kompilaci ze zdrojáků. Navíc je Arch optimalizován pro i686 a jedná se o vskutku velmi rychlý system. Co je ovšem pro mě taktéž velmi důležité - striktně se drží filosofie "rolling-updates" a vždy máte k dispozici ty nejnovější verze
programů, některé často novější i než unstable ~x86 verze v Gentoo.
Co se mi také hrozně moc líbí na Archu je jeho otevřený přístup ke komunitě. Na stránkách archu máte AUR (Arch User Repository) - repozitář PKGBUILDů (obdoba ebuildů z Gentoo určená pro Arch Build System), kam může naprosto každý přispívat svými vlastními PKGBUILDy. Neznamená to ovšem, že by zde neexistovalo žádné QA - nad AUR dohlíží skupina Trusted Users, kteří ho mají rozděleni podle kategorií a oblíbené PKGBUILDy mohou přijmout pod svůj patronát (přejdou z unsupported do community), načež později mohou přejít i do oficiálního extra či current repozitáře Archu. Tohle je přesně ten otevřený přístup ke komunitě, který mi u Gentoo chyběl, což mě ve svých důsledcích dovedlo až k tomu, že jsem přestoupil na Arch.
I přes to všechno co jsem napsal se prosím nenechte zmýlit - Gentoo stále považuji za z mého pohledu nejlepší distribuci pod Sluncem a pokud se v něm situace zlepší, možná se k němu v budoucnosti vrátím...
Tiskni
Sdílej:
Nicméně nic jako USE flagy nepodporuje, bylo by to v takovémto případě (jak se Arch jako distribuce profiluje) myslim i docela zbytečné...Navic IMHO i neresitelne, proste by nemeli sanci udelat buildy tolika balicku...
Zvažoval jsem i kompletní přechod na ~x86, ale to se z mého hlediska rovnalo ztrátě kontroly nad systemem, čemuž jsem se chtěl za každou cenu vyvarovat.Jak to myslis? Jaka ztrata kontroly?
Některé ebuildy byly navíc neaktuální i v jejich ~x86 verzi, jiné zas byly hard-masked (a odmaskovávat hard-masked ebuildy jsem opravdu nechtěl).Z jakeho duvodu? Pokud si myslis, ze vis lepe nez vyvojari distribuce, ze dany balicek bude stabilni, tak si ho klidne odmaskuj. Ale pokud jim veris, ze to opravdu blbne, tak nechapu, kde beres jistotu, ze to jinde blbnout nebude.
A co mě ještě více vadilo - spousta balíčků v portage vubec nebyla a musela se hledat po fórech a v bugzille.http://www.gentoo.org/proj/en/devrel/staffing-needs/index.xml
To všechno by ani nebyl až zas takový problém, ovšem poslední kapkou bylo, když jsem viděl jak se spousta ebuildů na novější verze či chybějící programy sice válí v bugzille, nicméně se tam válela již dosti dlouho a to že by byly přijaty do portage se jevilo v nedohlednu. Gentoo developeři (kterých si jinak velmi vážím, prosím neberte to nijak špatně!) se sice omlouvali stylem "je nás málo", ovšem že by začali více přijímat nové developery z řad komunity nebo zrevidovali system přijímání ebuildů a udělali ho otevřenější komunitě, to ne.A co maji delat? Davat commit access do portage kazdemu, kdo submittne dva ebuildy? Co treba nejaky "rm in global scope", cili jeden malicky ebuild, ktery ti pri `emerge sync` "smaze pulku systemu" (on je tam sandbox, ale jde o princip - proste tyhle prava se nerozdavaji automaticky...)?
) to nedělá problémy
) Ale byly i jiné příklady (na které si teď už asi nevzpomenu), u kterých mi důvod jejich hard-maskování přišel (z mého hlediska) neoprávněný.
"A co maji delat? Davat commit access do portage kazdemu, kdo submittne dva ebuildy? Co treba nejaky "rm in global scope", cili jeden malicky ebuild, ktery ti pri `emerge sync` "smaze pulku systemu" (on je tam sandbox, ale jde o princip - proste tyhle prava se nerozdavaji automaticky...)?"
To je jednoduché (a v mém příspěvku jsem to také napsal) - buď udělat aktivnější proces přijímání nových developerů z řad uživatelů (což ovšem není nutné a mohlo by to být i kontraproduktivní), nebo založit něco na způsob Arch User Repository, který funguje velmi dobře. Jak jsem psal QA by v takovém případě nechybělo - byly by tam prostě 2 kategorie ebuildů - "unsupported" (za které by nikdo neručil, mohli by být vyprodukovány kýmkoliv) a ty by lidé ze skupiny Trusted Users mohli přijmout vždy pod svůj patronát, načež by se staly "supported" a následně se přesunuly do portage. Takovýto centralizovaný systém (který by si lidé mohli přímo přidat jako zdroj do portage) by byl rozhodně lepší než to když se hromada ebuildů povaluje po fórech a v bugzille. Bylo by to otevřenější komunitě a mohlo to urychlit cestu nových ebuildů do portage.
"Jak to myslis? Jaka ztrata kontroly?" V okamžiku kdy přejdu na celý systém unstable ~x86 kontrolu (alespoň z mého pohledu) opravdu částečně ztrácím. Věci se pak velmi rychle mění a za tu dobu co používám Gentoo se v ~x86 už párkrát nějaké kritičtější problémy objevili. Pokud vím přesně které balíčky mám unstable, prostě mám nad tím větší kontrolu.Nejak se mi nechce verit, ze by Arch Linux (ktery podle meho odhadu bude mit asi mensi user-base i pocet vyvojaru nez Gentoo, ktere tu uz nejaky ten patek je) mel lepsi QA nez Gentoo, i kdyz muze byt.
Navíc v případě použití unstable ~x86 bych částečně ztratil podporu developerů v případě nějakých problémů (respektive řešení problému by mohlo trvat o dost déle).To neni pravda. Proc by to melo trvat dele? Samozrejme musis hlasit bugreporty v rozumen podobe, ne "GNOME stopped working".
Prostě preferuju takovou distribuci, která bude plně aktuální (a spodporou) i v její stable verzi. Jsou to mé preference, nic jiného...Jak muze neco byt "stabilni, vyzkouseny a podporovany", kdyz je to tri hodiny stare?
"A co maji delat? Davat commit access do portage kazdemu, kdo submittne dva ebuildy? Co treba nejaky "rm in global scope", cili jeden malicky ebuild, ktery ti pri `emerge sync` "smaze pulku systemu" (on je tam sandbox, ale jde o princip - proste tyhle prava se nerozdavaji automaticky...)?" To je jednoduché (a v mém příspěvku jsem to také napsal) - buď udělat aktivnější proces přijímání nových developerů z řad uživatelů (což ovšem není nutné a mohlo by to být i kontraproduktivní), nebo založit něco na způsob Arch User Repository, který funguje velmi dobře. Jak jsem psal QA by v takovém případě nechybělo - byly by tam prostě 2 kategorie ebuildů - "unsupported" (za které by nikdo neručil, mohli by být vyprodukovány kýmkoliv) a ty by lidé ze skupiny Trusted Users mohli přijmout vždy pod svůj patronát, načež by se staly "supported" a následně se přesunuly do portage. Takovýto centralizovaný systém (který by si lidé mohli přímo přidat jako zdroj do portage) by byl rozhodně lepší než to když se hromada ebuildů povaluje po fórech a v bugzille. Bylo by to otevřenější komunitě a mohlo to urychlit cestu nových ebuildů do portage.Takovy "system" tu uz je. Predpokladam, ze i Arch to resi tak, ze aby ses mohl stat "Trusted Userem", musis neco delat, napriklad casto opravovat chyby v baliccich od jinejch lidi. Myslim, ze pokdu budes v Gentoo Bugzille dostatecne aktivni, dostanes commit access taky.
To neni pravda. Proc by to melo trvat dele? Samozrejme musis hlasit bugreporty v rozumen podobe, ne "GNOME stopped working".No samozrejme, ze to je uplny nesmysl, od toho tam prece ty unstable verze jsou, aby se odladily chyby.
< Šlo o věci jako třeba Java 1.5 (od Sunu). Důvod proč byla (a možná ještě je) hard-masked sem si samozřejmě četl, ale zajímavé je, že v jiných distribucích (tedy tam kde Java vubec jeTo bude asi tim, ze v jinych distribucich uzivatele proti te Jave nekompilujou balicky... :-P Co si treba projit bugzillu a zjistit, kolik veci se s tim neda zkompilovat nebo je jinak rozbitych?) to nedělá problémy
)
nebo založit něco na způsob Arch User Repository, který funguje velmi dobře.Uz jsem ti jednou psal, at si do overlay das, co uznas za vhodne. Existuje i nekolik predpripravenych jinymi lidmi, coz ovsem nebrani blbcum psat do Gentoo bugzilly, ze jim ty ebuildy buhviodkud nefungujou.
NAvic ma clovek v pripade veci z takovych zdroju nulovou podporu od Gentoo developeru. Proto rikam ze je mnohem lepsi system centralizovaneho (to slovo "centralizovaneho" je tu kliceve) komunitniho repozitare, kam by mohl ebuildy prispivat zcela kdokoliv a oni "Trusted Users" by nad tim dohlizeli.No tak nulovou podporu bys mel tak jako tak, jestli by to bylo uskladneno na jednom miste nebo na deseti. Ebuildy v pouzitelnem stavu se dostanou do portage, se zbytkem si porad, jak chces. Opravdu nemam pocit, ze by tam tech balicku bylo malo.
To všechno by ani nebyl až zas takový problém, ovšem poslední kapkou bylo, když jsem viděl jak se spousta ebuildů na novější verze či chybějící programy sice válí v bugzille, nicméně se tam válela již dosti dlouho a to že by byly přijaty do portage se jevilo v nedohlednu.Tak si udelej vlastni overlay a tam si je pridej a spravuj a uved je do takoveho stavu, aby se do portage dostaly. Naprosta vetsina tech, co v bugzille jsou, v takovem stavu bohuzel neni...
Zadat prikaz pacman -U /var/cache/pacman/pkg/nvidia-srara_verze.pkg.tar.gzTakhle bych to jiste resil, kdybych na zminenem miste starsi verzi mel, neboli kdyby neslo o prvni instalaci. Kdyz jsem psal, ze hodinu hledam, tak to nebyl jen recnicky obrat.
Zapominate na to, ze Arch je narozdil od Gentoo binarni distribuci. Skladovat binarni balicky pro vsechny mozne starsi verze by nebylo zrovna efektivni.Huh? Eh? Souvislost? Unikla?
Kdyz chcete jinou verzi nez je defaultne v Archu nabizena, tak od toho tu je Arch Build System, abyste si ji zkompiloval.Huh^2? Vy mate zdrojaky k tem nVidia ovladacum?
Ovsem jde jen o modul co se vklada do kernelu, ktery sam o sobe nic nedela, jen pouziva ony closed-source binarni ovladace
nebo proste a jednoduse pouzijte ABS, v PKGBUILDu pro nvidia drivery zmente cislo verze na starsi, pomoci makepkg ji zkompilujte, pomoci pacman -U nainstalujte a nasledne do pacman.conf pridejte radek IgnorePkg = nvidia. Nevim jak vam, ale me to slozite neprijde.Diky, vskutku to slozite nevypada. Pokus v praxi dneska rano ovsem nedopadl nejlip, tady jsem se o tom rozepsal. Ty uz jsi neco takhle downgradoval?