plwm je nový, poměrně minimalistický správce oken pro X11. Podporuje dynamické dláždění okny, plochy, pravidla pro okna atd. Zvláštností je, že je napsaný v logickém programovacím jazyce Prolog. Používá implementaci SWI-Prolog.
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.
Sean Heelan se na svém blogu rozepsal o tom, jak pomocí OpenAI o3 nalezl vzdálenou zranitelnost nultého dne CVE-2025-37899 v Linuxu v implementaci SMB.
Jiří Eischmann v příspěvku na svém blogu představuje typy, jak lépe chránit své soukromí na mobilním telefonu: "Asi dnes neexistuje způsob, jak se sledování vyhnout úplně. Minimálně ne způsob, který by byl kompatibilní s tím, jak lidé technologie běžně používají. Soukromí ovšem není binární věc, ale škála. Absolutního soukromí je dnes na Internetu dost dobře nedosažitelné, ale jen posun na škále blíže k němu se počítá. Čím méně dat se o vás posbírá, tím nepřesnější budou vaše profily a tím méně budou zneužitelné proti vám."
Byla vydána nová stabilní verze 25.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Warbler. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Multiplatformní open source spouštěč her Heroic Games Launcher byl vydán v nové stabilní verzi 2.17.0 Franky (Mastodon, 𝕏). Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 26 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Klávesnice IBM Enhanced Keyboard, známá také jako Model M, byla poprvé představena v roce 1985, tzn. před 40 lety, s počítači IBM 7531/7532 Industrial Computer a 3161/3163 ASCII Display Station. Výročí připomíná článek na zevrubném sběratelském webu Admiral Shark's Keyboards. Rozložení kláves IBM Enhanced Keyboard se stalo průmyslovým standardem.
Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
Java má dnes 30. narozeniny. Veřejnosti byla představena 23. května 1995.
Už delší dobu jsem zvažoval jak vyřešit doma problémy s nedostatkem místa a nonstop přístupem k audiovizuální knihovně. Od prvních úvah o HTPC jsem se přes out-of-the-box NAS řešení dopracoval až k tomu, že nahradím můj starý a minimálně používaný PC takovým hybridem mezi NASkou, domácím serverem a příležitostným desktopem. Volba z důvodu spotřeby padla na Intel Atom s ION chipsetem. Jako úložná média bude obsahovat dva SATA disky 750GB a 1,5TB. Je jasné, že výkon takového stroje dokáže značně ovlivnit i práce s disky a proto jsem se rozhodl otestovat současné filesystémy, abych vybral pro mé potřeby pokud možno ten nejlepší.
Předem uvádím, že na testu nijak nebazíruji. I díky jiným testům, které jsem na webu našel je mi jasné, že neexistuje univerzálně správný a 100% vypovídající test, takže to berte spíš jako podělení se o zkušenost než cokoliv jiného. Testy samoté probíhaly na PC s Athlon XP 2500+, 2GB RAM, s několika různými disky z nichž jeden Seagate SATA 40GB jsem vyhradil pro testování. Před každou serií testů byl proveden restart PC a formát partition na příslušný FS. Samozřejmě jsem před testy vypnul KDE a jiné potenciální nařušitele klidu a míru, aby CPU mohl veškeré své drahocené zdroje propůjčit probíhajícím testům. Testovalo se na jádře 2.6.35.4 s Reiser4 patchem na Debian 6.0 Squeeze i386. Pro mountování všech systémů byly použity výchozí volby, pouze u Ext3 a Ext4 jsem použil 'data=writeback'. Meření bylo prováděno pomocí GNU Time. Každý test jsem 3x zopakoval, aby byly výsledky alespoň malinko věrohodné.
Test 1 - Rozbalení aktuálního jádra 2.6.35.4 z bz2 archivu, zdroj na jiném disku cíl na testovacím. [tar, bzip2]
Test 2 - Změna pořadí audiostop filmu v mkv (cca 9GB), zdroj na jiném disku cíl na testovacím. [mkvmerge]
Test 3 - Překopírování rozbaleného jádra z kroku 1 do jiného adresáře. [cp]
Test 4 - Smazání původního rozbaleného jádra z kroku 1. [rm]
Test 5 - Smazání vygenerovaného mkv souboru. [rm]
Výsledky dopadly takto:
Test1 |
Test2 | Test3 | Test4 | Test5 | |||||||
time [m:s] | cpu [%] | time [m:s] | cpu [%] | time [m:s] | cpu [%] | time [m:s] | cpu [%] | time [m:s] | cpu [%] | ||
JFS | Pass1 | 01:29,50 | 64 | 02:54,40 | 73 | 01:08,30 | 6 | 00:14,03 | 6 | 00:00,89 | 1 |
Pass2 | 01:29,18 | 64 | 02:59,00 | 71 | 01:10,11 | 6 | 00:13,24 | 6 | 00:01,19 | 0 | |
Pass3 | 01:26,31 | 65 | 02:53,71 | 77 | 01:26,24 | 6 | 00:16,61 | 5 | 00:01,19 | 1 | |
XFS | Pass1 | 01:58,41 | 50 | 02:57,32 | 73 | 01:39,05 | 5 | 01:18,94 | 4 | 00:00,03 | 94 |
Pass2 | 01:59,78 | 50 | 03:00,29 | 71 | 01:36,56 | 6 | 01:21,12 | 4 | 00:00,03 | 93 | |
Pass3 | 01:58,92 | 50 | 02:56,80 | 73 | 01:41,00 | 5 | 01:16,53 | 5 | 00:00,03 | 97 | |
Ext4 | Pass1 | 01:01,81 | 92 | 02:54,03 | 78 | 00:12,78 | 37 | 00:02,68 | 62 | 00:00,75 | 99 |
Pass2 | 00:59,38 | 96 | 02:54,68 | 77 | 00:13,29 | 34 | 00:01,83 | 81 | 00:00,78 | 99 | |
Pass3 | 00:58,96 | 96 | 02:50,13 | 82 | 00:08,92 | 51 | 00:01,75 | 98 | 00:00,74 | 99 | |
Reiser4 | Pass1 | 01:05,26 | 93 | 03:13,42 | 68 | 00:34,84 | 65 | 00:08,07 | 99 | 00:00,06 | 91 |
Pass2 | 01:03,16 | 96 | 03:11,61 | 69 | 00:32,58 | 69 | 00:07,86 | 99 | 00:00,05 | 89 | |
Pass3 | 01:03,86 | 96 | 03:13,11 | 67 | 00:32,76 | 67 | 00:08,22 | 99 | 00:00,06 | 92 | |
Btrfs | Pass1 | 01:13,09 | 91 | 03:27,91 | 63 | 00:21,43 | 53 | 00:11,98 | 94 | 00:00,23 | 98 |
Pass2 | 01:14,55 | 91 | 03:30,20 | 62 | 00:21,54 | 54 | 00:12,93 | 93 | 00:00,23 | 99 | |
Pass3 | 01:11,67 | 91 | 03:36,49 | 63 | 00:25,06 | 46 | 00:09,85 | 99 | 00:00,21 | 99 | |
Ext3 | Pass1 | 01:07,19 | 85 | 03:07,47 | 79 | 00:24,43 | 20 | 00:01,31 | 97 | 00:00,56 | 97 |
Pass2 | 01:07,73 | 85 | 03:08,37 | 78 | 00:24,06 | 20 | 00:01,26 | 98 | 00:00,63 | 99 | |
Pass3 | 01:11,67 | 80 | 03:08,81 | 79 | 00:26,43 | 19 | 00:01,36 | 99 | 00:00,62 | 99 |
Jak je vidět, celkově nejléve si vedla Ext4. V prvních třech testech zvítězila, i když v případě druhého jen velmi těsně s XFS a JFS. Ve třetím testu pak válcovala všechny FS. Až ve čtvrtém testu ji dokázala o malý kousek překonat Ext3. V pátém tesrtu pak s přehledem zvítězila XFS, nicméně rozdíly jsou jen v řádu setin vteřiny. Hodnocení využití procesoru je diskutabilní, nicméně dovolím so říct, že hodnoty nejsou nijak extrémní a v zásadě vyšší zátěž je vykoupena vyšší rychlostí prováděného úkolu. I když jsem byl povětšinou zastáncem XFS, po tomto výsledku dám na domácí NAS raději Ext4, která se jeví pro mé užívání vhodnější.
Tiskni
Sdílej:
trpel stejnym problemem
EXT4 žádný problém v tomto směru neměl. To jen některé programy nesprávně spoléhaly na chování, které poskytoval pouze jeden jediný fs (v té době ext3) a pouze v jednom konkrétním nastavení (joural_data_ordered, commit=5). Jiný FS toto nedokumentované a v podstatě nezamýšlené (do 5s byla data, ne jen metadata, na disku) chování neměl a nemá a samotný ext3 v jiném nastavení (např. writeback, commit=600).
spolehali na to, ze ext3 byl snad v kazdy distribuci default a i to data ordered bylo default. a liny programatori si na to zvykli a na budouci problemy bylo zadelano. a je snazsi vymenit fs nez kupu programu bez kterejch nemuzu zit (pokud je vubec za co je menit).
btw, jaka je v tyhle veci situace dneska? uz na to programy nespolehaji?Spíš se FS patřičně "přiškrtily"
Pokud mě paměť neklame, tak musely být splněny podmínky:
ad 1. Snad k tomu netřeba nic dodávat. Pokud někdo přijde o data vlivem padajícího HW, na vině je HW.
ad 2. Dobře napsané programy nespoléhají na nedokumentované chování a pokud data na disku potřebují, tak si to zařídí. Což je odpověď na tvoji poslední otázku. Např. aplikace typy DB toto řeší dnes a denně. Pokud vyhovuje ACID, tak po úspěšném příkazu COMMIT tam ta data najdeš bez ohledu na to, co se s PC děje dál.
ad 3. Pokud někdo ("vývojář" aplikace) spoléhá (v podstatě to nemůže ani ovlivnit) na nějaký konkrétní fs s konkrétním nastavení, je jen dobře, že přijde o data. Mimochodem, v žádné normě není napsané, jak se má FS zachovat v případě špinavého odpojení. Pokud by se vytvořil nový čistý, tak ano, je to v pořádku.
Co nastalo. První dva body se snad ani neřešily (no Teo se k tomu vyjádřil na svém blogu) a jenom se udělal patch do jádra. Chjo. Takže takyprogramátoři teď mohou prasit vesele dál a když někdo přijde o data na jiném FS, tak za to samozřejmě může ten jiný FS. Tohle je cesta do pekla. To už můžeme rovnou mountovat s volbou sync.
a liny programatori si na to zvykli a na budouci problemy bylo zadelano. a je snazsi vymenit fs nez kupu programu bez kterejch nemuzu zit (pokud je vubec za co je menit)
Proč měnit. Ti "programátoři" mohou na místo, kde "řeší" to přejmenování souboru (změna metadat) vložit nějaké volání sync a mají po starostech. Osobně bych předpokládal, že už to mají hotové.
Nemají a nemohou. Ti "Programátoři" to tak měli a fungovalo to dobře. Ovšem, mocný hekr Teo pak v ext3 zprasil implementaci fsync(). Náběh aplikací, toto volání používalo, trval děsivě dlouho. Ovšem, chování fsync() na ext3 odpovídá normě, takže to dodnes nikdo neopravil. "Programátoři" aplikací (KDE, Firefox) byli nuceni to nějak řešit. Využili vedlejších vlastností obvyklých u Linuxových filesystémů, aby ten problém obešli.
Následně velký Teo v ext4 zcela nesmyslně upřednostnil rychlejší práci s dočasnými soubory před bezpečným uložením dat a tyto vedlejší vlastnosti (opět v souladu s normou) změnil.
Když ho uživatelé upozornili na vzniklé problémy, zaštítil se alibisticky normou a arogantně všechno svedl na chudáky aplikační programátory. Později až pod hrubým nátlakem nasraného davu to konečně opravil. Ovšem, svou chybu nikdy neuznal a ve stejném duchu dodržování norem bez ohledu na okolní realitu pokračuje dál, takže se máme na co těšit.
Nikdy nezaváhal, ale na novou instalaci bych ho nikomu nedoporučil pač je odsouzen k zániku.Ale co to blábolíš? Reiserfs s námi bude ještě pěkně dlouhou dobu. Pravděpodobně si ho pleteš s Reiser4, co není v jádře a který zcela jistě nahradí Btrfs.
Co je pravdy na tom že kontrola integrity dat je u ext4 rychlejší?
Je to pravda a je to znát
Ono zas o tolik nejde, je o počítač sloužící jako datové úložištěpokud půjde jen o nějaký NAS, tedy jen o nějaké úložiště, pak bych se klonil k EXT3. V případě nějakého průseru - pádu disků apod. kdy by se musely data nějak obnovovat u EXT4/XFS je to na hodně dlouho a spolehlivě se struktura neobnoví. Problém je i, pokud na EXT4/XFS náhodou něco smažete a pak zjistíte, že to budete potřebovat pak je to celkem problém. U EXT3 se to nějak dá obnovit.
Dík za test.