Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
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.
Aktuální předverze řady 2.6 je (k 16. 5. 2007) 2.6.22-rc1, vydaná 12. května. Od minulého týdne byly do 2.6.22 přidány následující věci: systémová volání eventfd, nový IEEE 1394 ("Firewire") stack, který je prý navržen tak, aby byl robustní a jednoduchý, ovladače pro KingSun DS-620 USB-IrDA, USB audio zařízení Native Instruments a audio kodeky WM8753 (používané v telefonu OpenMoko), velká sada oprav ovladače "libertas" a podpora několika nových ARM procesorů. Podrobnosti najdete v krátkém a dlouhém changelogu.
Od vydání 2.6.22-rc1 bylo do hlavního repozitáře přidáno asi 100 dalších změn (skoro všechno opravy).
Aktuální verze -mm stromu je 2.6.22-rc1-mm1. Mezi nedávné změny patří několik oprav ukládání [writeback] u souborových systémů, implementace CRC7 a vylepšená verze kódu pro přednatahování swapu.
Je docela udivující, že ačkoliv je spousta lidí, kteří dávají na web šifrovací klíče navzdory USSA zákonům, najdou se i lidé z oblasti svobodného softwaru, kteří se snaží odstranit zmínku o softwaru, který není součástí jádra, i když jde o svobodný software.
-- Alan Cox
Jádro 2.6.22-rc1 je venku a už se začínají objevovat zprávy o regresích. Dvě z nich se týkají změn v binárním rozhraní pro uživatelský prostor: jedna v rozhraní video4linux2 a druhá v kódu i2c (což se týká utilit pro monitorování hardwaru). Problém s V4L2 se týká změny ve struktuře, která je předávána z a do uživatelského prostoru; zdá se pravděpodobné, že to bude před vydáním finální verze 2.6.22 vráceno do původního stavu. Problém s i2c se dá prozatím "vyřešit" upgradem na verzi 2.10.3 balíku lm_sensors.
Linus však z nuceného upgradování lm_sensors nemá radost; požádal o nalezení způsobu, který by to nevyžadoval. Správce i2c Jean Delvare v reakci zapochyboval o stávajících pravidlech o zachovávání stabilního ABI:
Přestože úplně souhlasím s tím, že by věci měly být relativně stabilní, aby uživatelé nemuseli uživatelský prostor neustále upgradovat, jsem také přesvědčen, že vzhledem k současnému vývojovému tempu prostě nemůžeme slíbit nekonečně funkční uživatelská rozhraní. Mohli bychom zaručit výraznou časovou prodlevu, než se zbavíme kompatibility, ale "navždy" prostě není reálné.
Přesto se však Linuxu docela dobře daří udržovat kompatibilitu ABI pro uživatelský prostor už mnoho let. Existují sice výjimky, ale bylo jich málo a s velkými rozestupy, takže každá z nich je hned vidět. Christoph Hellwig však poukazuje na to, že situace není zrovna ideální:
Až na velmi ojedinělé případy (například podpora modulů) funguje kompatibilita systémových volání skvěle. Jenže to je proto, že systémová volání jsou velmi viditelnou součástí ABI, takže je nikdo nezmění omylem. Také nikdo nepřichází s bezva novým schématem, kterým by se všechna systémová volání musela řídit.
Srovnejte to však se sysfs...
ABI pro uživatelský prostor už nejsou jen systémová volání. Obrovské rozhraní sysfs (4800 souborů na mém desktopu) je velkou částí uživatelského pohledu na systém a je to také část, kde se těžko vyhýbá problémům. Adresáře v sysfs odpovídají datovým strukturám v jádře; změny těchto struktur se často v sysfs projeví. Takže si vývojáři jádra mohou myslet, že pracují daleko od uživatelského prostoru, ale nakonec v něm stejně něco pokazí. Součástí ABI jsou i Netlink, /proc a ioctl() a i ty je snadné poškodit. Regrese týkající se V4L2 je výsledkem pokusu o rozšíření jednoho ioctl() volání, což poškodilo jiná.
Nový vývojový model také ztěžuje udržování kompatibility. Čtyři nebo pět velkých verzí ročně, každá s plnou náloží velkých nových funkcí, to je hodně změn kódu. Neexistuje však žádný jasný okamžik, který by šel využít k začlenění nezbytných změn tak, aby to uživatele nepřekvapilo. Kdyby vývojáři jádra na rok nebo dva zmizeli a vrátili se s verzí 3.0, nikoho by nepřekvapilo, že by se uživatelský prostor musel trochu přizpůsobit. Ale verze 2.6.22 - která obsahuje potřebné opravy a nové ovladače, ale také nové funkce - by neměla na fungujících systémech působit potíže.
Přesto je však těžké hledat argumenty pro návrat ke starému vývojovému modelu. I přes občasné chybky věci obecně fungují lépe než před vydáním 2.6. Tempo vývoje se pravděpodobně nezpomalí, takže problém s ojedinělými regresemi v ABI tu bude i nadále. A jak platí ve většině případů, nejlepším způsobem, jak se takovým problémům vyhnout - hned po dostatečné pozornosti vývojářů - je důkladné testování. Změny ABI pro uživatelský prostor, které jsou zachyceny během vývojového cyklu, se téměř jistě nedožijí finální verze - ale je těžké opravit problémy, o kterých nikdo neví. Automatické testování bývá často obtížné; nikdo nedokáže simulovat všechny kombinace hardwaru a softwaru, se kterými přijde jádro do styku. Takže záslužná práce spočívající v udržování stabilního uživatelského rozhraní bude i v dohledné budoucnosti vyžadovat nemalou dávku lidské pozornosti.
Technologie ukládání dat na otáčející se magnetické disky nám slouží už dlouho. Nabízí velkou kapacitu (přičemž pojem "velká" znamená čím dál více), relativně rychlé a rovnoměrné přístupové časy a relativně dobrou spolehlivost. Obecně se očekává, že otáčející se disky budou ještě nějakou dobu součástí našich systémů. U menších velikostí jsou disky stále častěji vytlačovány pevnou flash pamětí - a "menší" je také čím dál menší. Flash je kompaktnější, potřebuje méně energie a umožňuje opravdu náhodný přístup, takže není divu, že se nasazuje ve stále více situacích.
Flash však má i své nevýhody. Poměrně vysoká cena omezuje možnosti aplikace a kromě toho si s sebou nese vlastní sadu manýrů, kterým musí vývojáři souborových systémů rozumět, a připravit se na ně. Přesto už existují notebooky pro speciální účely, které spoléhají na flash pro ukládání dat, a mluví se i o dalších připravovaných systémech založených na flash.
Nejzávažnější ze zmiňovaných "manýrů" jsou:
Tyto vlastnosti hardwaru mají několik zajímavých dopadů. Například, co se stane, když se operační systém pokusí přepsat jediný blok v rámci většího vymazávacího flash bloku? Naivní implementace by načetla celý vymazávací blok, provedla výmaz a pak data zapsala zpátky i s novou částí. Pokud by systém uprostřed takové operace spadl, všechna data ve vymazávacím bloku by mohla být ztracena. Ignoruje-li operační systém otázku životnosti bloků, je pravděpodobné, že budou některé vymazávací bloky používány častěji než ostatní, což by výrazně zkracovalo životnost celého zařízení. Když jde o málo často vymazávané zařízení, jako USB klíčenka, nemuselo by ignorování limitů vadit. Jde-li však o hlavní úložné zařízení, vyžaduje to chytřejší přístup.
Chytřejší přístup většinou znamená použití souborového systému, který byl navržen přímo pro práci s flash hardwarem. Takové souborové systémy mohou zapomenout na starosti, které mají jiné souborové systémy s uspořádáním bloků - na flash jednotkách nejsou žádné problémy s vyhledávacími časy [seek time] nebo rotační latencí. Na druhou stranu musí souborové systémy pro flash pamatovat na vymazávací cykly; nesmí riskovat ztrátu dat a měly by se snažit rozložit zátěž na celou jednotku, aby se maximálně využila životnost.
Výsledkem je, že souborové systémy pro flash zařízení s nimi zacházejí jako s kruhovým bufferem - nová data jsou vždy zapisována na konec. Takový přístup zajišťuje rychlý zápis, ale čtení může být komplikovanější. Jeden způsob řešení je připojit ke každému vymazávacímu bloku metadata popisující, kterému souboru daný blok patří, a obsahují číslo verze. Když má být vymazávací blok přepsán, vytvoří se na konci nová kopie s vyšším číslem verze; přečtení souboru pak spočívá v nalezení vymazávacího bloku s nejvyšší verzí.
Nalezení bloku vyžaduje procházení disku - což pravděpodobně nechceme dělat při každém čtení. Souborový systém JFFS2 (součást jádra) tento problém řeší provedením prohlídky při připojení. Sestaví v paměti datovou strukturu, která další přístupy výrazně zrychlí. Není to však zadarmo: počáteční prohlížení může zpomalit mountování a strom v paměti může zabírat dost místa. Vzhledem k tomu, že souborové systémy pro flash jsou často používány na malých, embedded systémech - kde není času na bootování ani paměti nazbyt - mohou to být dost výrazné nepříjemnosti.
Jörn Engel si myslí, že našel lepší způsob: souborový systém LogFS, který je navržen k začlenění do hlavního jádra. Hlavní myšlenkou LogFS je, že místo sestavování stromu souborového systému při připojení, by měl souborový systém ukládat strom přímo na zařízení, podobně jako tradiční souborové systémy. Přesun stromu na flash zařízení snižuje čas potřebný pro připojení (Jörn uvádí, že na OLPC to pak netrvá 3,3 vteřiny jako s JFFS2, ale 60 ms) a měl by výrazně snížit i paměťovou náročnost.
Strom na flash vypadá velmi podobně jako struktura, kterou používá ext2. Rozdíly jsou v tom, jak je spravován. Logová struktura souborového systému znamená, že bloky nelze přepsat na místě; kdykoliv je blok změněn, musí být přesunut a zapsán jinde. Pokud existují ukazatele na přesunutý blok (viz běžné nepřímé bloky používané k ukládání struktury větších souborů), musí být změněny (a tedy přesunuty) i bloky, které ukazatele obsahují. A to si vyžádá změny na vyšší úrovni stromu. Takže změny na konci stromu se projeví až v rootu. Říká se tomu algoritmus "stěhovavého stromu" [wandering tree]. Jednou z výhod je, že stará struktura souborového systému zůstává platná až do chvíle, kdy je přepsán root - pád by mohl způsobit ztrátu poslední operace, ale předchozí data a struktura souborového systému zůstanou nepoškozeny.
Správa celého adresářového stromu způsobem stěhovavého stromu by byla náročná; kromě toho, soubory s vícero pevnými linky [hard link] narušují strukturu stromu a implementaci velmi ztěžují. Takže vlastní strom, který implementuje LogFS, má úrovně jen dvě. "Inodový soubor" obsahuje inodové struktury každého souboru a adresáře v rámci souborového systému; každá inoda ukazuje na přiřazené bloky, které uchovávají data souboru. Adresářové položky obsahují obyčejný index (celé číslo), který udává offset inody v inodovém souboru. Změny inody tedy vyžadují pouze zápis samotné inody a inodového souboru; zbytek adresářové struktury zůstává netknutý.
Aby vše drželo pohromadě, vyčleňuje LogFS skupinu bloků ("záchytná oblast" [anchor area]), kde se nacházejí verzované ukazatele na root inodu. Připojení souborového systému vyžaduje prohlédnutí této záchytné oblasti, aby byla nalezena aktuální verze root inody - v tu chvíli je zpřístupněn zbytek souborového systému. Takový mechanismus umožňuje rychlé nalezení rootu, aniž by bylo nutné prohledávat celé zařízení.
LogFS už prošlo pár koly kontrol, přičemž pokaždé z toho byly výrazné změny. Nedojde-li k nějakým zásadním problémům, bude už pomalu hotový - možná se dočká začlenění v 2.6.23.
(Vizte také pojednání o LogFS od Jörna (PDF), ze kterého je obšlehnuta většina tohoto článku.)
I/O operace náročné na výkon obyčejně využívají přímý přístup k paměti (DMA - direct memory access). S DMA přenáší I/O zařízení data přímo z a do hlavní paměti, bez zásahu procesoru. Při nejjednodušší formě DMA je řadiči předán ukazatel na oblast paměti, určena velikost a je mu řečeno, ať se činí. Procesor pak může na celou operaci zapomenout - dokud zařízení nesignalizuje, že je práce hotova.
Tento jednoduchý pohled má však jedno mínus. Předpokládá totiž, že data, která mají být přenesena, jsou v paměti uložena souvisle. Když je I/O buffer v jádře, může se jádro často postarat o to, aby byl fyzicky souvislý - i když čím větší buffer, tím je to složitější. Je-li však buffer v uživatelském prostoru, je jisté, že bude po fyzické paměti roztroušen. Bylo by tedy fajn, kdyby mohly DMA operace fungovat s buffery, které jsou rozděleny na několik kusů.
Pokud je periferní zařízení rozumně schopné, je možné buffery rozdělit. Operace s takovými buffery se nazývají "scatter/gather I/O" [rozhodit/posbírat]; scatter/gather je v Linuxu už nějakou dobu dobře podporováno. Kapitola o DMA v knize Linux Device Drivers mluví o scatter/gather docela podrobně. Ve zkratce jde o to, že ovladač začne vyplněním polí struktur scatterlist, které (na architektuře i386) vypadají takto:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
struct scatterlist {
struct page *page;
unsigned int offset;
dma_addr_t dma_address;
unsigned int length;
};
Ukazatel page u každého segmentu říká, kde lze daný segment v paměti nalézt, offset popisuje, kde data (v rámci stránky) začínají, a length je délka segmentu. Jakmile je seznam naplněn, ovladač zavolá:
int dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction direction);
Tato operace (přinejmenším) vyplní pole dma_address u každé položky scatterlistu adresou, kterou lze předat periférii. Může však udělat více: fyzicky souvislé stránky mohou být sjednoceny do jediné položky v scatterlist nebo může být systémová jednotka pro správu I/O paměti naprogramována, aby zařídila, že budou části seznamu (nebo celý) z hlediska zařízení virtuálně souvislé. To vše - včetně přesné podoby struct scatterlist - je závislé na architektuře, ale rozhraní scatter/gather je připraveno tak, že se o detaily architektur ovladače nemusejí starat.
Nedávno se vynořil jeden konkrétní nedostatek scatter/gather rozhraní. Z různých důvodů je třeba, aby se scatterlisty vešly na jedinou stránku; to omezuje horní hranici počtu reprezentovatelných segmentů. Na architektuře i386 se zapnutou vyšší pamětí [high memory] vyžaduje struct scatterlist 20 bajtů, což scatterlist limituje na 204 položek. Pokud každá položka scatterlistu ukazuje na plnou stránku, bude maximální velikost pro DMA přenos přibližně 800 kB. Na x86-64 je situace horší: struktura zabírá 40 bajtů, takže je maximum poloviční.
Existují situace, ve kterých se větší I/O operace hodí. Blokový I/O subsystém je jednou z nich, ale jsou i jiné: příkladem může být třeba zařízení, které zachytává video s vysokým rozlišením. Omezení délky scatterlistu je jedním z motivačních faktorů pro vývojáře, kteří pracují na podpoře velkých bloků. Zvětšení velikosti stránky umožňuje navýšit maximum pro velikost I/O operací.
Ale zvětšní velikosti stránky není jediný možný přístup; také by šlo prostě prodloužit scatterlisty. Vícestránkové souvislé scatterlisty nejsou moc pravděpodobné, ale zřetězení jednostránkových scatterlistů je možné. Pracuje na tom Jens Axboe; jeho patch pro řetězení scatterlistů je teď v šesté verzi.
Zřetězování se provádí dalším natažením [overloading] ukazatele page v poslední položce scatterlistu na stránce. Nejméně významný bit je nastaven tak, aby ukazoval, že je položka ve skutečnosti spojovacím dílkem řetězu - ne dalším segmentem k přenosu. Z hlediska ovladačů jde o téměř transparentní změnu. V současných jádrech vypadá kód, který prochází scatterlisty, asi takto:
struct scatterlist *sg = &the_scatterlist[0];
for (i = 0; i < nentries; i++) {
program_io_operation(sg);
sg++;
}
Když se použije zřetězování, nestačí už obyčejné procházení polem. Jens tedy přidal jednoduché macro sg_next(), které - v případě potřeby - následuje dílky řetězu. Řádek sg++ se změní na něco jako:
sg = sg_next(sg);
Protože je potřeba změnit ovladače, neměly by se zřetězené scatterlisty používat, nejste-li si jisti, že je na ně ovladač připraven. Jensův patch opravuje několik ovladačů, především v blokovém subsystému. I tak však musí administrátor ručně zvýšit maximální velikost I/O (přes sysfs soubor), než může být zřetězování zapnuto. Jakmile je však povoleno, začne být možné provádět mnohamegabajtové I/O operace. Nejsou potřeba žádné rušivé změny ve správě paměti.
Následující obsah je © KernelTrap
10. kvě, originál
Keith Packard oznámil, že jsou k dispozici ovladače pro čipset 965GM Express od Intelu. Jeff Garzik reagoval: Skvělá zpráva. Doufejme, že Intel nakonec vyrobí samostatnou kartu, aby se ještě ukouslo z koláče konkurentům s uzavřenými ovladači. Keith v oznámení vysvětlil:
Čipset Intel® 965GM Express je první mobilní produkt, který implementuje čtvrtou generaci intelské grafické architektury. Je navržen tak, aby podporoval pokročilé renderovací funkce v moderních grafických API. Obsahuje podporu pro programovatelné vertex, geometry a fragment shadery.
V rámci stupňování intelského odhodlání spolupracovat s komunitami X.org a Mesa na neustálém zlepšování ovladačů je podpora pro tento nový čipset poskytována prostřednictvím ovladače Intel v X.org 2.0 a Mesa 6.5.3. Tyto ovladače představují hodně práce, kterou odvedl jak Intel, tak širší open source komunita.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
s/programovatelný vertex, geometrii/programovatelné vertex, geometry/, uvedeny preklad nedava smysl.
Informace viz treba http://cs.wikipedia.org/wiki/Shader.
Informace viz treba http://cs.wikipedia.org/wiki/Shader.Dík, opraveno.
7.6.2007 12:05
Prcek | skóre: 43
| Jindřichův Hradec / Brno
. Aspon budou pohromade a treba to bude pro ty kriklouny stravitelnejsi .
10.6.2007 11:16
Marek Bernát | skóre: 17
| blog: Arcadia
11.6.2007 01:02
Marek Bernát | skóre: 17
| blog: Arcadia
11.6.2007 16:57
Marek Bernát | skóre: 17
| blog: Arcadia
7.6.2007 10:02
andree | skóre: 39
| blog: andreeeeelog
7.6.2007 10:46
shread.
shred, aby to nebolo jeho nad sily hmm, možno, keby LogFS ignoroval sync, možno by to vyriešiť vedel ...
shred na LogFS je asi stejně rozumné, jako používat ho na mazání CD-RW. Myslím, že to není ani problém shredu, ani LogFS, ale problém toho, kdo tuhle kombinaci použije.
alias rm=shred na CD-RW nezafunguje, na LogFS hej.