Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
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