Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
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ů.
Aktuální předverze je i nadále 2.6.24-rc8; během minulého týdne nevyšly žádné další. Od vydání -rc8 se do repozitáře hlavního jádra dostalo přibližně 100 patchů. Dá se předpokládat, že finální vydání 2.6.24 přijde těsně předtím, než všichni odjedou na linux.conf.au.
Aktuální verze -mm stromu je 2.6.24-rc8-mm1. Andrew je dost nespokojen s tím, jak se -mm patche navzájem mlátí:
Množství rejectů a chyb při kompilaci, jež způsobují správci subsystémů, kteří se vrtají v cízích věcech, se vymyká kontrole. Je potřeba s tím něco udělat.
Prozatím se udělalo to, že bylo z tohoto vydání dost git stromů vyřazeno. K dalším změnám patří podpora asynchronního šifrování v mapovači zařízení, několik čínských překladů základní dokumentace jádra, hodně aktualizací IDE a ovladač pro Sony memory stick.
Starší jádra: 2.6.16.59 vyšlo 19. ledna s asi desítkou oprav. 2.6.16.60-rc1 (22. ledna) načalo nový cyklus několika dalšími opravami.
Jak by řekla moje dcera: ten patch spadl z ošklivého stromu a cestou dolu narazil do každé větve. Velmi působivé.
-- Linus Torvalds (pro zvědavce, tady je ten patch).
Tyhle věci jsou o tolik jednodušší než všechno to, co je potřeba dělat v jádře. Je to úplná hračka ve srovnání s tím, co děláme v rámci jádra, abychom zařídili totéž s pomocí nahrávatelných hešů [pluggable hashes] na základě jednotlivých součástí cesty [per-path-component basis] atd.
(Vývojáři, kteří dělají v uživatelském prostoru, jsou srabíci. Jedna z nejlepších věcí na vývoji gitu bylo to, jak bylo vše jednoduché ;).
-- Linus Torvalds (díky Nicholasi Pitreovi)
Jedna z věcí, se kterou se jádro nikdy nemuselo potýkat, je 15 let stagnace s hromadou obezliček nahromaděných nad tím vším.
Chceš říct, že ten linux dokáže na počítači běžet úplně bez windows? Teda bez boot disku, ovladačů a jakýchkoliv služeb?
To mi připadá nesmyslný.
Předchozí Jaderné noviny byly sice trochu zatížené na souborové systémy, ale pořád ještě jedno důležité téma chybí: ext4. A protože bude ext4 nástupcem ext3, je dost možné, že jej mnoho z nás bude za pár let používat. Moc se o něm nemluvilo - tedy kromě konferencí zaměřených na projekt - ale vývojáři nezaháleli. Něco z toho, na čem pracovali, se teď objevilo ve zprávě, v níž Ted Ts'o představuje plány na začlenění ext4 do 2.6.25.
Jednou ze změn, které se dostaly do ext4, je uvolnění dlouhotrvajícího omezení velikosti bloku na 4 kB. To však neznamená, že by fungovala libovolná velikost a těžit z této nové vlastnosti bude moci méně lidí, než by se zdálo. To proto, že velikost bloků pořád nemůže být větší než velikost stránek hostitelského systému. Takže ti z nás, kteří používají x86 systémy se 4kB stránkami, budou mít i nadále maximálně 4kB bloky. Maximální velikost bloků je 64 kB.
Úsměvné na tom je, že velikost záznamu o adresáři teď může být až 64 kB. Ale pole, které uchovává velikost adresářových položek, je jen 16 bitů široké, takže bylo nutné použít speciální hack, který 64kB adresářové záznamy rozpozná.
Některé interní proměnné mají s přetečením také problém. Čísla bloků jsou ukládána jako 32bitové hodnoty se znaménkem, stejně jako čísla skupin bloků. To omezuje maximální velikost souborového systému na pouhých 256 PB. V 2.6.25 se z těch hodnot staly bezznaménkové proměnné typu long, což odstranilo ten neomluvitelně nízký limit velikosti oddílu. S pomocí trošky kouzlení bude inodové pole, které ukládá počet bloků spojených se souborem, rozšířeno na 48 bitů, což zvýší maximální velikost jednotlivých souborů na skoro 248 512bajtových bloků.
Tím to však nekončí: další patch to pole redefinuje tak, aby značilo počet bloků souborového systému (místo 512bajtových sektorů), které soubor používá. To je změna, na kterou se muselo jít v rukavičkách, protože se jedná o změnu formátu na disku, jež mohla způsobit potíže lidem, kteří už mají ext4 oddíly. Každý, kdo používá ext4, by si měl být vědom, že jde o vývojový souborový systém, který se hodí pouze pro ukládání souborů, u nichž se neočekává, že byly k něčemu dobré déle než přibližně 30 minut - například aktualizace OpenOffice.org z Fedory Rawhide. Ale i tak by bylo fajn, kdyby se podařilo nezlikvidovat všechny již vytvořené ext4. Takže pole i_blocks bude ve výchozím nastavení i nadále uchovávat počet 512bajtových bloků. Ale pokud pole přesáhne 32 bitů a vynutí si použití 48bitových čísel, začne být od té chvíle interpretováno jako bloky souborového systému. A protože žádný souborový systém zatím 48bitová čísla nepoužívá, tak se tento přístup úspěšně vyhýbá problémům.
Pro 2.6.25 jsou také připraveny kontrolní součty žurnálu. V případě pádu systému je žurnál využit k záchraně transakcí, které byly zadány, ale nestihly to na disk. Určitě by bylo fajn se ujistit, že žurnál uložený v souborovém systému je v pořádku, než se použije k provádění změn. Kontrolní součet souborovému systému umožňuje se přesvědčit, že je žurnál neporušený, a zabránit (dalšímu) poškození systému. Zajímavý vedlejší účinek je to, že kontrolní součet uvolňuje omezení týkající se způsobu zápisu žurnálu na disk, protože nekompletně zapsaný žurnál teď bude odhalen; to by mělo mírně zlepšit výkon souborového systému.
Kontrolní součty všech dat u ext4 zatím nejsou na pořadu dne, ale kontrola žurnálu je dobrý (i když malý) krůček tím správným směrem.
Další změna proběhla ve VFS API - pole i_version struktury inode je teď na všech architekturách bezznaménková 64bitová hodnota. Číslo verze je zvýšeno při změně souboru a uloženo (rozdělené do dvou polí) do inody na disku. 64bitová čísla verzí vyžaduje NFS4, který je používá k poskytování obávané chyby "stale file handle", když dojde ke změně.
Přibyla ioctl() (EXT4_IOC_MIGRATE), kterou lze použít k výslovnému požádání o to, aby byla disková inoda souboru převedena na formát ext4.
Ext4 je založen na rozsazích [extent-based], a to už nějakou dobu. Že je "založen na rozsazích", znamená, že sleduje alokace bloků podle rozsahů (první blok, počet bloků), místo aby ukládal ukazatele na každý jednotlivý blok jako to dělá ext3. Má to několik výkonnostních výhod, obzvláště u větších souborů. Tyto výhody však zmizí, pokud nemohou být bloky souboru seskupeny do co nejmenšího počtu rozsahů.
Jeden způsob, který s optimalizací alokací bloků pro soubory velmi pomáhá, je alokace v relativně velkých skupinách (oproti jednotlivému alokování). V 2.6.25 bude ext4 obsahovat víceblokový alokátor, který je určen právě k tomu. Mohlo by se zdát, že alokování několika bloků najednou nebude představovat velkou změnu, ale ve skutečnosti je víceblokový alokátor nejkomplikovanějším patchem v sadě. Rozhodování o tom, kolik bloků alokovat, zahrnuje hodně heuristiky, stejně jako nalezení optimální sady bloků, sledování alokace, uvolňování bloků, které nakonec nejsou použity, zajištění, aby aplikace nemohly číst předalokované (ale nezapsané) bloky ve snaze odhalit uniklá tajemství, atd. Je to dost kódu, ale stojí za to; víceblokové alokování bude v 2.6.25 ve výchozím nastavení zapnuto.
Jak bylo řečeno, několik těchto patchů si vynucuje změny datových struktur na disku. Podle Teda by však mělo jít o poslední takové změny u ext4. Pár funkcí ještě do 2.6.25 zařazeno nebude - například zpožděné alokování a online defragmentace - ale ty by neměly vyžadovat změnu formátu. Ext4 se tedy blíží ke stavu, kdy jej bude možné považovat za způsobilý k produkčnímu nasazení.
Zatím však tak daleko není a lidé, kteří ho používají, to dělají na vlastní riziko. Aby to ještě více zdůraznil, navrhl Ted nový příznak pro připojování (nazvaný test_fs), který uživateli jádra říká, že se chystá připojit vývojový souborový systém a ať si nestěžuje, kdyby se něco pokazilo. Bez tohoto parametru se ext4 odmítne připojit.
Cukavé audio nebo nereagující desktop - většinou způsobeny latencí operačního systému - jsou věci, které uživatelům lezou na nervy. Může však být těžké hledat jejich příčinu, protože jsou přechodné a navíc ukryté hluboko v jádře. Nový nástroj LatencyTOP se snaží poskytovat informace o tom, kde se latence vyskytuje, aby ji šlo opravit nebo jí předejít.
Latence je čas od začátku akce až po okamžik, kdy je vidět efekt, který způsobila. Pokud uživatel klikne na tlačítko v aplikaci, je latence doba mezi kliknutím a začátkem přiřazené akce. Latence má mnoho příčin, z nichž některé nemůže Linux ovlivnit; takže schopnost měřit, jakou latencí přispívá operační systém, je velmi užitečná. LatencyTOP se zabývá specifickou podmnožinou příčin latence. Viz oznámení:
Existuje mnoho druhů a příčin latence, ale LatencyTOP se zaměřuje na ty, které způsobují přeskakování audia a zasekávání desktopu. Konkrétně se LatencyTOP zabývá případy, ve kterých chtějí aplikace spustit užitečný kód, ale nějaký zdroj právě není k dispozici (a jádro proces zablokuje). Provádíme to jak na úrovni systému, tak na úrovni jednotlivých procesů, takže vidíte, co se se systémem děje a který proces je latencí postižený nebo ji způsobuje.
LatencyTOP měří průměrnou a maximální latenci při různých operacích pomocí vkládání anotačních volání do jádra. Příklad z oznámení:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
asmlinkage long sys_sync(void)
{
+ struct latency_entry reason;
+ set_latency_reason("sync system call", &reason);
do_sync(1);
+ restore_latency_reason(&reason);
+
return 0;
}
Plánovač nahromadí čas strávený spaním mezi voláními set_latency_reason() a restore_latency_reason() a dá ho na účet "sync system call". Jakákoliv volání nižší úrovně, která by se snažila nastavit důvod latence, budou při této cestě kódem [code path] ignorována (užitečná mohou být při jiných cestách), protože je latence vždy přičtena aktivnímu důvodu nejvyšší úrovně.
Stávající anotační rozhraní se pravděpodobně změní, i když sémantika zůstane stejná. V komentářích se objevil návrh použít jaderné značkovače, které byly začleněny do jádra 2.6.24. Zdá se, že vývojář LatencyTOP Arjan van de Ven s tím souhlasí; obecně bývá lepší použít již existující rozhraní než přidávat nové. Práce je však ještě dost - patch byl představen, aby jej mohli ostatní vývojáři testovat a komentovat, ne k začlenění do hlavního jádra.
LatencyTOP nabízí uživatelskou aplikaci, která zobrazuje shromážděné informace. Načítá je ze souboru /proc/latency_stats, který vytváří patch s infrastrukturou LatencyTOPu, pokud při konfiguraci jádra povolíte CONFIG_LATENCYTOP. V horním panelu se ukazuje devět - v kódu je o jednu méně, jelikož to vypadá, že bylo zamýšleno deset - největších latencí za posledních 30 vteřin.
Na spodním řádku je seznam názvů procesů, na který se dostanete šipkami. Zdroje latencí těchto procesů se pak zobrazí ve spodním panelu. Příklad vlevo ukazuje nástroj s vybraným procesem firefox. Jak vidíte, na mnoha místech pořád ještě schází anotace - v případě, že ještě nebyl důvod nastaven, se zobrazí "Unknown reason" [neznámý důvod] a čekací kanál [wait channel]. Při určování problému by pro hackery jádra nemělo být obtížné doplnit na patřičná místa anotace.
LatencyTOP, podobně jako brášku PowerTOP, vyvíjí van de Ven v rámci Intel Open Source Technology Center. Je to velmi šikovný nástroj pro odhalování problémů v systému. Je pravděpodobné, že se ještě bude měnit, protože uživatelská aplikace je zatím dost strohá a sbírání dat v jádře potřebuje jemnější zamykání.
Virtualizované hostované systémy by si rády myslely, že se o správu své paměti starají samy. Pravda je však taková, že hostitelský systém nemůže hostovaným systémům dovolit přímé úpravování tabulek stránek, které používá hardware; to by narušilo bezpečnost hostitele. Hostitel tedy musí být nějakým způsobem do správy paměti hostů zapojen. Jedna častá technika je založena na stínových tabulkách stránek. Hostované systémy spravují své vlastní tabulky stránek, ale nejsou to ty samé, které používá hlavní správa paměti. Místo toho to funguje tak, že kdykoliv provede host změnu ve svých tabulkách, hostitel tu operaci zachytí, zkontroluje, jestli je v pořádku a nakonec změnu odrazí ve skutečných tabulkách stránek.
Jeden problém s touto technikou (tak, jak ji v současné době Linux implementuje) je to, že neexistuje jednoduchý způsob, jak by mohl hostitel zpravit hosta o změnách v tabulkách. Především když se hostitelský systém rozhodne vytlačit určitou stránku do swapu, nemůže hostu říct, že už stránka není v paměti. Virtualizační řešení jako KVM tento problém obcházejí tím, že stránky mapované ve stínových stránkách natvrdo přidrží v paměti. To sice problém řeší, ale je kvůli tomu nemožné odswapovat procesy, ve kterých běží virtualizované stroje založené na KVM.
Bylo by dobré to opravit. A to je přesně to, oč se snaží patch MMU notifiers, který představil Andrea Arcangeli (ze své nablýskané nové adresy u firmy Qumranet). Patch umožňuje, aby byl systém, který to zajímá, upozorněn, kdykoliv dojde k určitým změnám ve správě paměti. Pro začátek je potřeba nastavit sadu zpětných volání:
struct mmu_notifier_ops {
void (*release)(struct mmu_notifier *mn,
struct mm_struct *mm);
int (*age_page)(struct mmu_notifier *mn,
struct mm_struct *mm,
unsigned long address);
void (*invalidate_page)(struct mmu_notifier *mn,
struct mm_struct *mm,
unsigned long address);
void (*invalidate_range)(struct mmu_notifier *mn,
struct mm_struct *mm,
unsigned long start, unsigned long end);
};
Tato zpětná volání jsou poskládána do struktury mmu_notifier:
struct mmu_notifier {
struct hlist_node hlist;
const struct mmu_notifier_ops *ops;
};
Kód, který má o informace zájem, si pak zaregistruje své oznamovače pomocí:
void mmu_notifier_register(struct mmu_notifier *mn,
struct mm_struct *mm);
mm je struktura mm_struct spojená s daným adresním prostorem. Nepředpokládá se, že by někoho zajímaly všechny události týkající se správy paměti, takže jsou oznamovače přiřazeny ke specifickým adresním prostorům. Jakmile je oznamovač na místě, budou zpětná volání volána, když dojde k něčemu zajímavému:
Pokud jste zvědaví, tak KVM patche (které ukazují, jak by tam byly oznamovače použity) byly také připraveny.
Ačkoliv je tento patch určen pro KVM, objevil se zájem i odjinud - virtuální stroje nejsou jediná místa, kde se spravují samostatné (ale související) tabulky stránek. Jednotky pro zpracování grafiky mohou posloužit jako příklad - mají svou vlastní správu paměti a také zajímavé problémy s touto správou. Další potenciální uživatel jsou RDMA (Remote DMA) enginy. Patche tedy přilákaly i komentáře od několika možných zájemců a od prvního představení doznaly mnoha změn. Diskuze stále probíhá, takže je možné, že dojde ještě k dalším změnám, než si oznamovače najdou cestu do jádra.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
To co je tu uvedeno mezi citáty je jen velmi slabý odvar toho originálu 
.
. Perfekne to charakterizuje citat Jiriho Matouska (znamy hlavne diky knize "Sest miliard Amerik" od Ivy Pekarkove), ze "Amerika je zeme neomezenych moznosti i nemozne omezenosti".
vobec nechapem ako sa to sem mohlo dostatŽe by překladem originálu?
29.2.2008 20:27
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Heh? Tobě se nelíbí IT Crowd? Považuji IT Crowd jednoznačně za nejlepší britský sitcom vubec!Ale kdepak. Na "Jistě, pane ministře" a "Jistě, pane premiére" zdaleka nemá.
a v akej suvislosti je to v tom originale? ja nechapemJako „citáty týdne“ – „Quotes of the week“. Když si kliknete na výše uvedený odkaz, nebo odkaz na zdroj na konci článku, nebudu vám to tady muset vyprávět. Pokud se vám zdá, že to nemělo být v tom originálním článku, pak asi píšete do špatné diskuze.
On autor byl vůl a překladatel není, rozumíte, proto to tak je.Jenom se obávám, že to tenkrát Werich myslel jako vtip…
tak ako to je?Je to tak, že autor rubriky Kernel na LWN ten citát považoval za dost vtipný na to, aby stálo za to ho zařadit k ostatní citátům. Možná proto, že i ty ostatní citáty jsou obyčejně vybírány kvůli humornému vyznění. A já s původním autorem souhlasil, a proto jsem to zařadil také do překladu. Pokud se ti ten citát nelíbí, tak jej přeskoč a hotovo.
Takže to není překlad jen tak něčeho, co někdo někde napsal.v tom pripade je nazov clanku uplne zavadzajuci, navyse sa tu dokola striedaju postoje "neprekladame cokolvek" a "prekladatel predsa musi prelozit vsetko" nazov clanku je strasne zavadzajuci, nie su to ziadne "jaderne noviny", ale "nemyslime, prekladame" nabuduce tam budu rozoberat co bolo v novej casti nejakej mexickej telenovely a vy to tu s najvacsim potesenim uverejnite...
v svetle tychto prelomovych informacii to tu asi prestanem citatTo nás všechny bude mrzet... fakt.
2) Věta "Jedna z nejlepších věcí na vývoji s gitem je to, jak je vše jednoduché" měla znít spíš "Jednou z nejzábavnějších věcí na vývoji gitu bylo ...", což dává alespoň podle originálu větší smysl, řekl bych.
Jinak obvyklé pochvaly, tohle je jedna z nejlepších věcí ke čtení široko daleko. Dík.
2) Věta "Jedna z nejlepších věcí na vývoji s gitem je to, jak je vše jednoduché" měla znít spíš "Jednou z nejzábavnějších věcí na vývoji gitu bylo ...", což dává alespoň podle originálu větší smysl, řekl bych.Pravda, díky.