Byla vydána (𝕏) nová verze 2025.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Dánské ministerstvo pro digitální záležitosti má v plánu přejít na Linux a LibreOffice [It's FOSS News].
V úterý Google vydal Android 16. Zdrojové kódy jsou k dispozici na AOSP (Android Open Source Project). Chybí (zatím?) ale zdrojové kódy specifické pro telefony Pixel od Googlu. Projekty jako CalyxOS a GrapheneOS řeší, jak tyto telefony nadále podporovat. Nejistá je podpora budoucích Pixelů. Souvisí to s hrozícím rozdělením Googlu (Google, Chrome, Android)?
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.101 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.101 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
V Brně na FIT VUT probíhá třídenní open source komunitní konference DevConf.CZ 2025. Vstup je zdarma, nutná je ale registrace. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.
Vyloučení technologií, které by mohly představovat bezpečnostní riziko pro stát, má umožnit zákon o kybernetické bezpečnosti, který včera Senát schválil spolu s novelami navazujících právních předpisů. Norma, kterou nyní dostane k podpisu prezident, počítá rovněž s prověřováním dodavatelů technologií pro stát. Normy mají nabýt účinnosti od třetího měsíce po jejich vyhlášení ve Sbírce zákonů.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.6.
Po Red Hat Enterprise Linuxu a AlmaLinuxu byl v nové stabilní verzi 10.0 vydán také Rocky Linux. Přehled novinek v poznámkách k vydání.
Bylo vydáno Eclipse IDE 2025-06 aneb Eclipse 4.36. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Americká filmová studia Walt Disney a Universal Pictures podala žalobu na provozovatele populárního generátoru obrázků pomocí umělé inteligence (AI) Midjourney. Zdůvodňují to údajným porušováním autorských práv. V žalobě podané u federálního soudu v Los Angeles označují firmu za „bezednou jámu plagiátorství“, neboť podle nich bez povolení bezostyšně kopíruje a šíří postavy z filmů jako Star Wars, Ledové království nebo Já, padouch, aniž by do nich investovala jediný cent.
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í:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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").
15.11.2011 08:14
Bedňa | skóre: 34
| blog: Žumpa
| Horňany