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 je (k 19. 9. 2007) 2.6.23-rc7, vydaná 19. září. Obsahuje slušnou řádku oprav a vrátil se ovladač sk98lin. Mělo by jít o poslední předverzi před finální vydáním 2.6.23. Podrobnosti najdete v dlouhém changelogu.
Aktuální verze -mm je 2.6.23-rc6-mm1. Mezi nedávné změny patří patch, který vypíná systémové volání timerfd() (aby se získalo trochu času na ujasnění, jak má vlastně API vypadat), randomizace systémového volání brk() na architekturách i386 a x86_64 a spousta oprav.
Zabralo mi více než dva dny než se mi tohoto drobečka podařilo zkompilovat a na pár strojích nabootovat. Vyžadovalo to přibližně devadesát opravných patchů a vyházení některých jiných patchů. Pořád je tam několik chyb, o kterých vím (podrobnosti níže) a pravděpodobně hodně dalších, o kterých nevím. Musím říct, že takhle už to prostě dál nejde.
-- Andrew Morton vydává 2.6.23-rc6-mm1
Vývojáři Linuxu si pevně drží svou nezávislost a často se neřídí našimi radami.
Ano, uvědomuji si, že je na světě spousta bláznivých lidí. Většinou však o jádře nerozhodujeme podle nich. Ale můžeme ty bláznivé lidi pohladit po hlavě a říct: "nemůžeme zaručit, že vám to bude fungovat, ale když si vezmete svoje prášky a necháte nás na pokoji, tak si klidně běžte dělat blbosti".
Většina vývojářů jádra subsystému virtuální paměti se sešla na mini-summitu těsně před 2007 Kernel Summit v Cambridge. Rozcházeli se s pocitem, že vyřešili řadu problémů se škálovatelností VM. Následné diskuze však ukázaly, že se možná radovali předčasně. Sice došli k závěrům, ale není zcela jasné, jestli všichni ke stejným.
Všechny probírané otázky se tak či onak týkají škálovatelnosti. Ačkoliv subsystém virtuální paměti prošel mnoha změnami zaměřenými na spolehlivé fungování na současných systémech, jeden klíčový aspekt zůstává v podstatě nezměněn již od počátku: velikost stránek 4096 bajtů (na většině architektur). Od té doby, kdy byl kód psán, se velikost paměti instalované na běžných systémech zvětšila o tři řády - to je 1000× více stránek, které musí jádro spravovat, a 1000× více výpadků stránek, které je nutné zpracovat. A protože to nevypadá, že by tento trend měl zpomalovat, máme problém se škálovatelností, o který je potřeba se postarat.
Komplikuje to skutečnost, že Linux má tendenci paměť fragmentovat. Téměř všechny alokace paměti jsou prováděny po jednotlivých stránkách, což způsobuje, že je RAM systému roztříštěná na spousty jednostránkových kousků. Jaderný alokátor paměti se snaží držet skupiny stránek pohromadě, ale jeho úspěšnost má své meze. Přiblížit situaci může soubor /proc/buddyinfo; na systému, který už nějakou chvíli běží, bude počet stránek vyššího řádu (větších) (ve sloupcích úplně vpravo) hodně nízký.
Hlavní zbraní proti fragmentaci paměti byla dosud snaha vyhýbat se alokacím vyššího řádu, kde jen to bylo možné. V jádře je jen málo míst, kde se provádějí alokace více souvislých stránek. Tento přístup nějakou dobu fungoval, ale vyhýbání se větším alokacím neznamená, že přestanou být potřeba. Ve skutečnosti je dost případů, ve kterých by se větší souvislé oblasti paměti hodily:
Žádný z těchto problémů není velké překvapení; vývojáři už nějakou dobu věděli, že přijdou. Je už tedy připraveno několik možných řešení. Chybí však shoda o tom, které z těchto řešení je nejlepší.
Jedním dílkem skládačky by mohla být práce Mela Gormana na předcházení fragmentaci. Melovy patche vyhledávají samostatné alokace, které mohou být ve fyzické paměti přesunuty. Když jsou přesunutelné alokace seskupeny, může jádro (v případě potřeby), vytvořit skupiny vyššího řádu tím, že přesune překážející alokace. Něco z toho už je v 2.6.23; další kód bude možná zařazen do 2.6.24. Patche lumpy reclaim [uvolňování stránek po kusech]) (také v 2.6.23) usnadňují vytváření větších bloků, protože se při uvolňování zaměřují na sousedící stránky.
Hlavním důvodem pro obnovenou diskuzi však byla nová verze patchů zavádějících větší velikosti bloků od Christopha Lametera. Christoph zalepil poslední velkou díru v této sadě patchů, když implementoval podporu mmap(). Kód umožňuje, aby keš stránek spravovala větší kusy souborových dat než je jedna stránka, což řeší mnohé problémy s I/O a souborovými systémy. Christoph připojil dlouhý seznam důvodů, proč by měl být patch začleněn, ale všeobecná shoda nepanuje.
První mezi připomínkami je patrně skutečnost, že velké bloky vyžadují funkční zpřístupňování stránek vyššího řádu; neexistuje žádné záložní řešení pro případ, že by byla paměť natolik fragmentovaná, že by tyto alokace nebyly dostupné. Takže systém, jehož souborové systémy by používaly větší velikosti bloků, se při nedostatku velkých souvislých bloků paměti (na linuxových systémech nic neobvyklého) začne hroutit. Patche zabraňující fragmentaci paměti s tím mohou trochu pomoci, ale neexistuje žádná záruka, že k fragmentaci nedojde - ať už v důsledku specifické zátěže, nebo kvůli úmyslnému útoku. Takže pokud bude tento patch začleněn, budou někteří vývojáři chtít, aby obsahoval velké varování, které by mělo uživatelům (a distributorům) vysvětlit, že vlastně vůbec nemusí fungovat.
Alternativou je práce Nicka Piggina na fsblock. Lidé si často stěžují na vrstvu buffer head [hlava bufferu] v aktuálních jádrech, ale ta vrstva má svůj účel: sleduje mapování mezi bloky keše stránek a příslušnými fyzickými sektory disku. Patch fsblock nahrazuje kód buffer head novou implementací, která by měla přinést lepší výkon a čistší abstrakce.
Jedna z věcí, kterou fsblock umí, je podpora velkých bloků pro souborové systémy. Aktuální patch k tomu nepoužívá alokace vyššího řádu; místo toho je pomocí volání vmap() zařízeno, aby byly velké bloky virtuálně souvislé v prostoru vmalloc() - tak to v současné době dělá XFS. Výhoda používání vmap() spočívá v tom, že souborový systém vidí velké souvislé bloky, aniž by bylo nutné, aby spolu fyzicky sousedily, takže fragmentace nevadí.
Na druhou stranu je používání vmap() poměrně pomalé. Navíc adresní prostor, který má vmap() k dispozici na 32bitových systémech, je dost malý, což by mohlo působit potíže. A konečně použití vmap() nijak nepomůže na úrovni I/O. Nick tedy plánuje rozšířit fsblock, aby podporoval velké bloky se souvislými alokacemi, ale s možností návratu k vmap(), když nebudou velké alokace k dispozici. Teoreticky by tento přístup měl brát od obou možností to nejlepší. Umožňoval by využití výhod velkých bloků, aniž by se sesypal v případě fragmentace. Nick k tomu napsal:
Fsblock dokáže vše, co dokáže keš stránek vyššího řádu: vyhýbat se vmap a blokovým zařízením poskytovat souvislou paměť pomocí oportunistického alokování stránek vyššího řádu - pokud se alokace nepovedou, může se k vmap vrátit.
Z diskuze to vypadá, že dost vývojářů ve fsblock vidí budoucí řešení. Ale blízká budoucnost to nebude. Je to velký, rozlezlý a strašidelný patch, což jeho postup zpomalí (nehledě na to, že patche zasahující do správy paměti obecně bývají začleňovány hlemýždí rychlostí). Navíc mu chybí funkce velkých bloků. Jen minixový souborový systém byl aktualizován, aby fsblock používal, ale byl to dost velký patch. Všichni (včetně Nicka) předpokládají, že komplexnější souborové systémy - třeba ty, které mají funkce jako žurnálování - ještě přinesou nejedno překvapení a budou vyžadovat změny, o kterých zatím nikdo neví, jak budou velké. Fsblock není rychlé řešení.
Jeden Christophův nedávno poslaný patch by mohl s některými problémy pomoci. Patch implementující funkci "virtuální složená stránka" [virtual compound page] jadernému kódu umožňuje požadovat velkou souvislou alokaci; je-li to možné, bude požadavek splněn vrácením fyzicky souvislé paměti. Pokud taková paměť není k dispozici, bude vrácena virtuálně souvislá paměť. Kromě toho, že fsblocku poskytuje funkci alokace velkých bloků, tak by mohl být používán na mnoha místech, kde je teď používána vmalloc(), což by mělo za následek vyšší výkon v situacích, kde paměť není příliš fragmentovaná.
Andrea Arcangeli se zatím neprojevoval, ale neměli bychom zapomínat, že je autorem většiny VM kódu, který teď v jádře je. Andrea prosazuje úplně jiný přístup:
Já jsem přesvědčen, že jediným rozumným řešením škálovatelnosti VM a problému větších fyzicky souvislých stránek je patch CONFIG_PAGE_SHIFT (tj. velká PAGE_SIZE od Hugha pro 2.4).
Patch CONFIG_PAGE_SHIFT je přepracováním staré myšlenky: oddělit velikost stránky, jak ji vidí operační systém, od toho, co si o velikosti stránky myslí hardware. Hardwarové stránky mohou být seskupeny dohromady, aby vytvořily větší softwarové stránky, které se pak stanou základní jednotkou správy paměti. Pokud by například všechny stránky v systému měly velikost 64 kB, 64kB buffer by znamenal alokaci jediné stránky bez jakýchkoliv problémů s fragmentací.
Má-li mít systém větší stránky, je jedinou možností vytvářet je softwarově. Většina procesorů podporuje více než jednu velikost hardwarových stránek, ale nejmenší z větších možností bývají pro běžné použití příliš velké. Například i386 nemá žádné velikosti stránek mezi 4 kB a 2 MB. Softwarové seskupování [clustering] stránek umožňuje použití rozumnějších velikostí a poskytuje pružnost potřebnou pro optimalizaci velikosti při očekávaném zatížení systému. Takový přístup by podporu velkých bloků zjednodušil a také by se tím vyřešily problémy s výkonem I/O. Seskupování stránek neřeší problémy TLB, ale s tím se obecně nedá moc dělat.
Největším nedostatkem seskupování stránek je tedy pravděpodobně to, že místo fragmentace externí způsobuje fragmentaci interní. Když bude 64kB stránka použita jako keš stránek pro 1kB soubor, vyplýtvá se 63 kB paměti. Andreův patch obsahuje opatření, která rozdělí velké stránky, aby k takovým situacím nedocházelo; ačkoliv Andrea tvrdí, že toto rozdělování nepovede ke stejným problémům s fragmentací, jaké vidíme u současných systémů, zatím se mu o tom nepodařilo přesvědčit ostatní.
Závěrů se z této diskuze moc vyčíst nedá; v jednu chvíli se Mel Gorman zeptal: Shodneme se na nějakém plánu, nebo se tu ukecáme k smrti? Linus celou diskuzi označil za idiotskou. Je možné, že patche implementující velké velikosti bloků budou - s varováním - začleněny, aby se malá část uživatelů upokojila a zároveň se získalo více informací o celém problému.
Dynamické jaderné trasování by si přálo mnoho uživatelů Linuxu. Přestože už bylo vytváření pokročilých trasovacích funkcí věnováno mnoho úsilí, jen málo z této práce si našlo cestu do hlavního jádra. Nedávné představení malého kousku infrastruktury by však mohlo pomoci situaci změnit.
Jde o trasovací vrstvu, kterou poslal David Wilder. Jejím cílem je usnadnit trasovacím aplikacím připravit věci v jádře a umožnit uživateli trasovací proces ovládat. Za tím účelem poskytuje jaderné API a sadu kontrolních souborů v souborovém systému debugfs.
Na straně jádra by věci nastavil trasovací modul voláním
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
#include <linux/trace.h>
struct trace_info *trace_setup(const char *root, const char *name,
u32 buf_size, u32 buf_nr, u32 flags);
root je název kořenového adresáře, který se objeví v debugfs, name je název kontrolního adresáře v root, buf_size a buf_nr ukazují velikost a počet přenosových buffer [relay buffers], které mají být vytvořeny, a flags určuje různé možnosti kanálů. Příznak TRACE_GLOBAL_CHANNEL říká, že má být použita jen jediná sada přenosových kanálů; TRACE_FLIGHT_CHANNEL zapíná režim "černá skříňka" [flight recorder], ve kterém přetečení přenosového bufferu způsobí přepsání starých dat, a TRACE_DISABLE_STATE vypne ovládání kanálu přes debugfs.
Návratová hodnota (pokud vše proběhlo v pořádku) bude ukazatel na strukturu trace_info kanálu. Tato struktura má několik polí, ale nejpodstatnější bude rchan, což je ukazatel na přenosový kanál přiřazený k danému trasovacímu bodu.
Když má začít vlastní trasování, měl by jaderný modul zavolat
int trace_start(struct trace_info *trace);
Návratová hodnota se řídí konvencí "nula nebo záporná chybová hodnota". Trasování se vypíná takto:
int trace_stop(struct trace_info *trace);
Jakmile trasovací modul ukončí činnost, měl by vypnout trasování:
void trace_cleanup(struct trace_info *trace);
Žádný z těchto vstupních bodů nemá nic společného s umístěním nebo aktivací trasovacích bodů nebo vytvářením trasovacích dat. To vše musí samostatně udělat trasovací modul. Takže typický modul nastaví (po zavolání trace_start()) jednu nebo více kprobes nebo aktivuje statický jaderný značkovač [marker]. "Průzkumná" [probe] funkce připojená k trasovacím bodům by měla udělat něco jako:
rcu_read_lock();
if (trace_running(trace)) {
/* Zformátuj trasovací data a předej
výstup pomocí přenosového kanálu */
}
rcu_read_unlock();
Kromě toho by měla průzkumná funkce (pokud byl nastaven příznak TRACE_GLOBAL_CHANNEL) chránit přístup k přenosovému kanálu pomocí spinlocku. Taková ochrana může být také potřeba v situacích, kdy je trasován zpracovávač přerušení.
V uživatelském prostoru se trasovací informace objeví v /debug/root/name, kde debug je přípojné místo debugfs a root a name jsou názvy adresářů předané funkci trace_setup(). Ze souboru state může být přečten aktuální stav trasování; aplikace mohou zapisovat do start nebo stop, čímž trasování zapnou nebo vypnou. Soubor trace0 je přenosový kanál, odkud lze číst trasovací data; na SMP systémech s kanály pro každý procesor budou pro další procesory další soubory (trace1...). Ze souboru dropped lze vyčíst, kolik záznamů o trasování (pokud nějaké) bylo zahozeno kvůli plnému bufferu.
Nejedná se o moc komplikovaný kód. Asi nejpodstatnější vlastností tohoto patche je fakt, že je součástí infrastruktury vytvořené a používané projektem SystemTap. Zařazení kódu do hlavního jádra distributorům usnadní poskytování trasování s kvalitní podporou.
Finální vydání verze 2.6.23 se blíží. V tuto chvíli už by bylo velmi překvapivé, kdyby se do jádra dostaly ještě nějaké změny API, takže si můžeme provedené úpravy shrnout.
Nová funkce:
char *kstrndup(const char *s, size_t max, gfp_t gfp);
Duplikuje řetězec podobně jako strndup() v uživatelském prostoru.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
2.10.2007 00:27
Prcek | skóre: 43
| Jindřichův Hradec / Brno
2.10.2007 20:47
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
2.10.2007 21:41
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
V takových situacích je IMHO nejlepší zavřít slovník a použít to, co by řekl Čech.
)
Nicméně nemá cenu se dohadovat kvůli nějakému anonymnímu trollovi.
I hate the fuc*ing czech n00bz like you.Máš v tom chyby, troubo.
Aktuální předverze je (k 19. 9. 2007) 2.6.23-rc7, vydaná 19. září. Obsahuje slušnou řádku oprav a vrátil se ovladač sk98lin. Mělo by jít o poslední předverzi před finální vydáním 2.6.23.To "poslední před vydáním" jim moc nevyšlo, současná předverze je -rc9...
