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.
Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Začleňovací okno pro verzi 3.2 je stále otevřené, takže v době psaní ještě nevyšla žádná předverze. Vizte článek níže pro přehled toho, co bylo doposud zařazeno.
Stabilní aktualizace: během uplynulého týdne žádné nevyšly. Aktualizace 2.6.32.47 a 2.6.33.20 jsou ve fázi posuzování; můžeme je čekat 4. listopadu nebo později. Obě dvě jsou významné, protože mají více než 100 oprav. 2.6.33.20 by mělo být poslední aktualizací pro 2.6.33 (tentokrát doopravdy); uživatelé realtime jsou vyzýváni k přechodu na 3.0, které bude mít dlouhou podporu.
/* * Více kouření haše místo výpočtů, ty brďo, * čumte na ty čísla, jak plovou.. Určitě mi * na paměť šlápl růžový slon. */ /* * Žádné bezejmenné parchanty tu nemůžeme trpět! */ /* * To, co je tady nahoře ^^^^^, vám doporučuju přečíst. */ /* * Zhola nemožné, zrovna jsme to zaregistrovali a zkontrolovali * jsme, že to nebylo NULL.. Vsadil bych se, že ta houbička, * co jsem snědl, byla dobrá! */ /* * Rozebral jsem to a zase jsem to složil, akorát mi teď * zbývají tyto 'náhradní' díly.. kam je mám dát. */ /* * Měli jsme na zdi N lahví piva, jedno jsme vypili, akorát že * teď na zdi nezbývá N-1 lahví piva... */
-- Někdo řekl Peteru Zijlstrovi, aby přidal nějaké komentáře
Subsystém pro průmyslové I/O (Industrial I/O; IIO) žije ve staging stromu už nějakou dobu. Poskytuje framework pro ovladače, které pracují s různými senzory, co měří veličiny jako napětí, teploty, akceleraci, okolní světlo a další. Během uplynulých let se objevily nějaké ty spory ohledně toho, jak tyto senzory mají zapadnout do jádra; doufá se, že IIO poskytne odpověď.
Jádro IIO sedělo mimo strom hodně dlouho; říká se, že stav kódu tomu odpovídá. Našlo se odhodlané úsilí věci ve staging stromě zlepšit, což mělo měřitelné výsledky. Nyní je tu sada patchů IIO jádra, která by podle správce Jonathana Camerona měla být připravena dostat se ze staging do hlavní řady.
IIO senzory se dost odlišují, od jednoduchých senzorů s nízkou šířkou pásma ke složitým zařízením s vysokou šířkou pásma. Počáteční posun IIO je zaměřen na první skupinu. U těchto typů senzorů se očekává, že uživatelské rozhraní bude výhradně fungovat v sysfs, pod /sys/bus/iio/devices. Každé zařízení bude mít řadu atributů; některé jako name a samping_frequency budou u všech. Ostatní budou záviset na tom, co senzor vlastně měří; navrhované ABI se snaží názvy těchto atributů standardizovat, kdykoliv je to možné.
Plánem je dostat toto rozhraní do hlavní řady a pak začít přesouvat menší (a čistší) ovladače. Podpora komplexnějších zařízení bude následovat. V době psaní tohoto textu ještě nebyl kód přetažen do 3.2, ale ještě se to může stát. Mezitím se velké množství změn v IIO dostalo do staging stromu pro 3.2; je tu zjevný zájem dát tento subsystém do kupy.
V říjnu vyjádřila komunita uživatelů btrfs znepokojení nad stále chybějícím nástrojem pro kontrolu a opravu souborového systému. Tehdy autor btrfs Chris Mason řekl, že doufá, že během své přednášky na LinuxCon Europe předvede funkční kontrolní nástroj. Váš redaktor z LWN byl v hloučku stojícího obecenstva, které čekalo na šou; demonstrace jsme se dočkali, ale asi to nebylo to, co někteří účastníci očekávali.
Chris začal mluvit o btrfs a jeho obecných cílech; o těch jsme tu dostatečně psali a nebudeme je opakovat. Zopakoval plán Oraclu použít btrfs jako hlavní souborový systém ve své distribuci odvozené od RHEL; není třeba dodávat, že toto vyžaduje naprosto stabilní implementaci. Proto se hodně sil věnovalo rozsáhlým testům a opravám chyb.
Vydání jádra označené 3.2 bude obsahovat výsledky této práce; půjde o spoustu oprav. Bude obsaženo i značné vylepšení logovacího kódu. Ukázalo se, že mnoho dat bylo logováno více než jednou, což značně zvyšovalo potřebu I/O; to bylo opraveno. Objem I/O u logu byl oproti dřívějšku snížen o 25 %.
Ve verzi 3.3 bude asi hlavním vylepšením užívání větších bloků pro uzly v B-stromu tohoto souborového systému. Větší bloky mohou samozřejmě obsahovat více dat a zejména pak metadat. To znamená, že metadata, která byla předtím roztříštěna po souborovém systému teď mohou být společně uchovaná v relevantním inode. To nakonec vede ke značenému zlepšení výkonu u řady operací nad souborovým systémem.
Další blížící se funkcí, která se očekává „hned po fsck“ je začlenění implementací RAID5 a RAID6 od Dava Woodhouse. Tato práce byla původně zaslána v roce 2009; Chris se omluvil, že trvalo tak dlouho, než to bylo začleněno. Jak bude tato práce ve skutečnosti používána, si žádá trochu zamyšlení; RAID 5 a 6 je docela dobrý pro data, ale může být problémový pro metadata, která mají tendenci nezaplnit ani zdaleka plný RAID stripe [proužek], což může vést k nízkému výkonu I/O. Naštěstí bylo btrfs už od počátku navrženo tak, aby mohlo uchovávat data a metadat odděleně; to znamená, že je možné věci udělat tak, že zatímco data budou chráněna plným RAIDem, metadata budou používat jednoduché zrcadlení.
Řeč o ochraně metadat samozřejmě vedla k problému obnovy souborového systému po poškození metadat. K tomuto slouží opravný program; btrfs se stalo čím dál tím známějším pro neexistenci řádného kontrolního nástroje (a především pak opravného). V době řeči na LinuxConu btrfs stále ještě opravný nástroj nemá, ale v tomto směru se už udělal nějaký ten pokrok a byla poskytnuta řada jiných mechanismů.
Copy-on-write [vytvoř kopii při zápisu] povaha btrfs implikuje, že bude existovat řada starých kopií metadat na souborovém systému v daném čase. Každá změna nakonec povede k vytvoření nové kopie a zanechání předchozí verze, než bude blok recyklován. Chris zjistil, že poškození souborového systému se jen výjimečně dotknou starších metadat, takže dává smysl je použít jako hlavní zdroj při obnově poškozeného disku. Nejprve je ale nutné umět najít starší metadata.
Pro toto btrfs udržuje pole obsahující místa bloků mnoha starších verzí kořenu souborového systému. Když jde o obnovu dat, tak je podle něj kořenový blok důležitější než superblok. Kořen je nahrazován často, neboť změny metadat probublávají na vrchol adresářové struktury, takže pole „starých kořenových bloků“ obsahuje odkazy na to, co je ve skutečnosti snapshotem velice nedávného stavu souborového systému. Toto bude jednoznačně nedocenitelným prostředkem, když se něco pokazí.
Jedním způsobem použití je prostě připojit souborový systém za použití starší verze kořene. Chris předvedl tuto funkci vyrobením děr v testovacím souborovém systému a následně připojením staršího kořene, čímž se věci vrátily do původního stavu. Pro prosté, rychle detekované problémy by starší kořenové bloky měly být rychlou cestou k řešení.
Nicméně nedá moc práce představit si situace, kdy tento přístup nebude fungovat. Pokud je blok metadat málokdy měněného podstromu například vynulován vinou selhání hardwaru, nemuselo by se na to nějakou dobu přijít. V době, kdy si uživatel uvědomí, že je něco špatně, už nemusí být k dispozici starší hierarchie obsahující informace potřebné pro obnovu. Proto mohou být zapotřebí jiná řešení.
Jedním takovým bude zjevně nástroj pro úplnou kontrolu a opravu souborového systému. Tento nástroj ale ještě není připravený. Vyrobit správný nástroj pro opravu je těžký problém; bez dostatečné péče může dobře míněný pokus o opravu snadno věci zhoršit. Data, která mohla před takovým pokusem být opravena, už pak nemusejí být opravitelná. I kdyby už dnes byl dostupný řádný btrfsck, trvalo by asi pár let, než by nasbíral dostatek zkušeností k vyvolání pocitu důvěry v uživatelích, kteří mají starost o svá data.
Takže to vypadá, že bude potřeba něco jiného. To „něco jiného“ bude asi nakonec nástroj pro obnovu dat od Josefa Bacika. Tento nástroj odvádí jednoduchou práci (jednoduchou na vysvětlení): prokopává se poškozeným souborovým systémem v režimu pouze ke čtení a extrahuje co nejvíce dat, co jen jde. Protože v něm nedělá žádné změny, nemůže věci zhoršit; vypadá to jako nástroj, který by stál za to, i kdyby existoval kompletní nástroj pro opravu.
Tento nástroj, spolu s potřebnou podporou souborového systému, by měl být k dipozici v době jádra 3.2. Mezitím vznikl nový repozitář btrfs-progs, ve kterém bude v blízké době obsahovat tento nástroj pro obnovu. Suma sumárum, není to zrovna btrfsck, ve který někteří uživatelé doufali, ale mělo by to stačit k tomu, aby tito uživatelé měli větší pocit jistoty, pokud vkládají svá data a důvěru v nový souborový systém. Podle velikosti davu během Chrisovy přednášky se dá soudit, že hodně lidí má právě o toto zájem.
[Váš redaktor z LWN by rád poděkoval Linux Foundation za uhrazení cesty na LinuxCon Europe.]
Linus vydal jádro 3.1 a otevřel začleňovací okno pro 3.2 dne 24. října, zatímco seděl na Kernel Summitu 2011. V době psaní tohoto textu bylo do hlavní řady přetaženo téměř 8200 neslučovacích změn. To je velké množství a řada významných stromů ještě čeká na přetažení. Vypadá to na nejaktivnější vývojový cyklus, co jsme tu v poslední době, a možná za celou dobu, měli.
Nejvýznamnější změny viditelné pro uživatele ve verzi 3.2 zahrnují:
ssize_t process_vm_readv(pid_t pid, const struct iovec *lvec,
unsigned long liovcnt, const struct iovec *rvec,
unsigned long riovcnt, unsigned long flags);
ssize_t process_vm_writev(pid_t pid, const struct iovec *lvec,
unsigned long liovcnt, const struct iovec *rvec,
unsigned long riovcnt, unsigned long flags);
Pro více informací vizte manuálovou stránku.
Změny viditelné vývojářům jádra zahrnují:
Začleňovací okno bude trvat asi až do 7. listopadu. Druhá část začleňovacího okna bude shrnuta v příštích Jaderných novinách.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
„S tímto algoritmem jsem dokázal zvýšit propustnost jedné IPsec linky z 344 Mbit/s na 464 Mbit/s na Core 2 Quad CPU za použití SSSE3 varianty – zrychlení o 34,8 %“.Nepíše se tam, jaké Core 2 Quad to bylo? Protože 45nm Core 2 má určitá významná zlepšení v SSE oproti 65nm (zejména rychlá "shuffle unit").