Czkawka a Krokiet, grafické aplikace pro hledání duplicitních a zbytečných souborů, byly vydány ve verzi 11.0. Podrobný přehled novinek v příspěvku na Medium. Od verze 7.0 je vedle frontendu Czkawka postaveného nad frameworkem GTK 4 vyvíjen nový frontend Krokiet postavený nad frameworkem Slint. Frontend Czkawka je už pouze v udržovacím módu. Novinky jsou implementovány ve frontendu Krokiet.
Jiří Eischmann na svém blogu publikoval článek Úvod do MeshCore: "Doteď mě radioamatérské vysílání úplně míjelo. Když jsem se ale dozvěděl, že existují komunity, které svépomocí budují bezdrátové sítě, které jsou nezávislé na Internetu a do značné míry taky elektrické síti a přes které můžete komunikovat s lidmi i na druhé straně republiky, zaujalo mě to. Když o tom přede mnou pořád básnili kolegové v práci, rozhodl jsem se, že to zkusím taky.
… více »Byla vydána verze 0.5.20 open source správce počítačových her na Linuxu Lutris (Wikipedie). Přehled novinek v oznámení na GitHubu. Instalovat lze také z Flathubu.
Peter Steinberger, autor open source AI asistenta OpenClaw, nastupuje do OpenAI. OpenClaw bude převeden pod nadaci a zůstane otevřený a nezávislý.
Společnost Backblaze zveřejnila statistiky spolehlivosti pevných disků používaných ve svých datových centrech za rok 2025. Ke konci roku 2025 vlastnila 349 462 pevných disků. Průměrná AFR (Annualized Failure Rate), tj. pravděpodobnost, že disk během roku selže, byla 1,36 %. V roce 2024 to bylo 1,57 %. V roce 2023 to bylo 1,70 %. V roce 2022 to bylo 1,37 %.
Nástroj sql-tap je proxy mezi aplikací a databází, které zachytává všechny SQL dotazy a zobrazuje je v terminálovém rozhraní. Zde lze téměř v reálném čase zkoumat dotazy, sledovat transakce a spouštět SQL příkaz EXPLAIN. Podporované databázové systémy jsou pouze PostgreSQL a MySQL. Zdrojový kód je dostupný na GitHubu, pod licencí MIT.
Byla vydána nová verze 9.2 textového editoru Vim (Vi IMproved). Přináší vylepšené doplňování, podporu schránky ve Waylandu, podporu XDG Base Directory (konfigurace v $HOME/.config/vim), vylepšené Vim9 skriptování nebo lepší zvýrazňování změn. Vim zůstává charityware. Nadále vybízí k podpoře dětí v Ugandě. Z důvodu úmrtí autora Vimu Brama Moolenaara a ukončení činnosti jím založené charitativní organizace ICCF Holland projekt Vim navázal spolupráci s charitativní organizaci Kuwasha.
Byl představen editor MonoSketch, webová aplikace pro tvorbu diagramů, technických nákresů, flowchartů a různých dalších vizualizací, to vše jenom z ASCII znaků. Všechny operace běží pouze v prohlížeči uživatele a neprobíhá tedy žádné nahrávání dat na server. Zdrojový kód aplikace (drtivá většina Kotlin, žádné C#) je dostupný na GitHubu pod licencí Apache 2.0.
Byla vydána nová verze 3.7.0 multiplatformního svobodného frameworku pro zpracování obrazu G'MIC (GREYC's Magic for Image Computing, Wikipedie). Přehled novinek i s náhledy nových filtrů na PIXLS.US.
Všem na AbcLinuxu vše nejlepší k Valentýnu aneb Dni lásky ke svobodnému softwaru (I love Free Software Day, Mastodon, 𝕏).
Na začátku považuji za nutné uvést, že jsem člověk značně konzervativní a v rozporu s Murphyho zákonem se snažím zachovat systém (nejen OS), který se osvědčil, pokud mě nic nenutí ke změně. Například mám už víc než 12 let stejný desktop na pracovním počítači v kanceláři. Na druhou stranu se mi několikrát stalo, že změna, do níž se mi moc nechtělo, měla nakonec pozitivní výsledek. Typickým příkladem byl přechod z Pascalu na C, o čemž jsem se zmínil v některém z předchozích blogů, nemluvě o přechodu z Windows na Linux zhruba před dvaceti lety.
Změna FS se netýká onoho pracovního počítače v kanceláři, ale pracovního notebooku. Jedná se o deset let starý ThinkPad, který mi v práci pořídili před sedmi lety jako repasovaný. Má procesor i5-4300U na 1,9GHz, 8GB pamětí, 230 GB SSD. Před třemi lety mi na něm vyměnili display a letos v zimě baterku, jinak šlape celou dobu jak hodinky. Hned od začátku na něm mám ArchLinux, který jsem v době pořízení už několik let používal.
Disk jsem tehdy rozdělil na 3 oddíly: jeden malý pro /boot, něco přes 30 GB pro kořen, zbytek pro /home. Kdysi jsem četl něco o tom, proč je dobré mít samostatný oddíl pro /boot, od té doby to používám. Je možné, že ty důvody pominuly, ale jak jsem předeslal, jsem člověk konzervativní. Samostatný /home jsem několikrát ocenil při změně linuxové distribuce. Ale z toho, co jsem přečetl o Btrfs, jsem naznal, že subvolume udělá stejnou službu.
S přibližujícím se termínem nástupu do lázní jsem zintenzivnil přípravy: kromě opětného pročítání různých informačních zdrojů jsem si připravil USB s live ArchLinuxem, potřebnou techniku pro zálohování a také pro záložní zálohování, jelikož jsem si jistější, když mám připraven i nějaký "plán B". (To mi připomíná prohlášení šéfa jedné dopravní společnosti, když začaly opravy D1 na trase Praha - Brno: "Máme zmapovány objízdné trasy a objízdné trasy objízdných tras.") Takže jsem si nachystal starší 1,5 TB interní SATA disk, který se nám doma povaloval, k němu samozřejmě USB interface, a externí 200GB SSD disk. Na ten interní disk jsem si nahrál i nějaké filmy (pár set GB dat, nechtělo se mi ztrácet čas vybíráním), kdyby lázeňská zábava vázla.
Do lázní jsem dorazil v pondělí. První dva dny jsem se zabydloval a snažil zorientovat v lázeňském prostředí, ve středu odpoledne po procedurách a po večeři (poněkud matoucí název pro jídlo v 16:40) jsem zahájil akci. Plán byl následující: oddíl s /boot nechat, jak je (Andrej by asi nesouhlasil), zálohovat všechna data, /home pro jistotu dvakrát na dva různé disky, pak oddíl s /home zrušit a kořenový oddíl zvětšit na veškeré dostupné místo na disku, převést ho na btrfs, udělat subvolume pro /home a potom do něj nakopírovat zpět data ze zálohy. Možná to jde udělat i jinak a líp, ale plán mi připadal reálný. Z tohoto článku jsem věděl, že konverze z ext4 je možná, jen jsem netušil, jestli bude lepší nejdřív oddíl konvertovat a pak zvětšit, nebo naopak. Ale doufal jsem, že to zjistím, až to zkusím. "Plán B" pro případ, že by konverze nevyšla, byl udělat čistý oddíl a do něj nakopírovat data, no a "plán C" v případě jeho selhání by znamenal novou instalaci systému.
Nejdřív jsem vyzkoušel konverzi na onom 1,5 TB disku. Kdyby to nedopadlo, tak bych maximálně přišel o zmíněné filmy. Protože jsem ještě jednou procházel návody všechno znovu kontroloval, začal jsem s tím až po deváté hodině večer. Navíc první pokus skončil chybovým hlášení, které se týkalo problému s reiserfs. Naštěstí to vyřešila instalace balíčku reiserfsprogs. V deset to ještě nebylo hotovo, takže jsem šel spát s tím, že do rána uvidím.
Ráno jsem omrknul výsledek, vše vypadalo v pořádku, tak jsem spustil btrfs scrub a šel se nasnídat. Po návratu jsem byl ovšem poněkud zklamán, po půl hodině neměl zkontrolováno ani 10 procent. Takže jsem to stopl v naději, že FS je v pořádku, spustil live distribuci a šel dělat zálohy. (Až později mě napadlo, že jsem mohl zkusit ještě btrfs check.) Na velký disk jsem hodil obrazy všech oddílů, na externí SSD jsem nakopíroval data z domovského adresáře, přičemž jsem některá méně důležitá vynechal. To zabralo skoro celý den, probíhalo to tak, že jsem spustil kopírování nebo program dd, šel na proceduru nebo na jídlo, po návratu zkontroloval stav a případně spustil další fázi zálohování.
Večer bylo vše hotovo. Zkusil jsem konverzi oddílu s kořenem, výsledkem bylo hlášení o nedostatku místa. Nebylo mi zcela jasné, jestli se jedná o místo v oddílu nebo by mohlo být i jinde na disku, takže jsem smazal oddíl s /home, ale pokus o konverzi skončil stejně. Ta se podařila až poté, co jsem zvětšil oddíl na maximum. Proběhla poměrně rychle, stejně tak rychlá byla i následná kontrola pomocí btrfs scrub. Předpokládám, že kromě menší velikosti disku hraje v tomto směru roli i skutečnost, že se jedná o SSD disk. Pak jsem vytvořil subvolume /home a spustil obnovu dat. Připojil jsem zálohovaný image a na kopírování použil rsync. Tohle jsem si možná mohl trochu líp promyslet, ale už bylo dost pozdě a chtělo se mi spát. Zpátky se tak nakopírovala spousta zbytečného smetí, např. cache webových prohlížečů, ale řekl jsem si, že do rána to bude hotové a šel spát.
Druhý den ráno, což bylo vlastně dnes, jsem se vzbudil trochu dřív, kopírování bylo hotovo, tak jsem spustil znovu btrfs scrub a přemýšlel, co dál. Jasně, nastavit správně UUID a typ FS v fstab. Změnu jsem provedl, počkal, až doběhne btrfs scrub (jen celkem šest a půl minuty) a zkusil nabootovat. (Uznávám, bylo to hodně ukvapené.) Pokus skončil hlášením "unknown filesystem type 'btrfs'". Napadlo mě, že můj zásah do fstab nebyl košer, takže jsem nabootoval live verzi, připojil disky a vytvořil fstab pomocí genfstab. Další pokus o boot - stejný výsledek. Spustil jsem live distribuci a chvilku pátral na internetu, ale pak už jsem musel jít na snídani, tak jsem počítač vypnul.
U snídaně mě napadlo, že to možná nebylo hlášení operačního systému, ale Grubu, takže mi hned došlo, že jsem neaktualizoval příslušný konfigurační soubor. Po snídani jsem měl hodinu čas do první procedury, takže opět live distribuce, připojení disků, arch-chroot a grub-mkconfig. A pro jistotu update systému - aktualizovaly se myslím jen tři baličky, mezi nimi i linux. A další pokus se stejným výsledkem, další pátrání. Při tom jsem náhodou narazil na radu, jak se dostat do položek v menu Grubu, což jsem sice nepotřeboval, ale napadlo mě spustit kernel linux, běžně totiž používám linux-lts. Jaké bylo mé překvapení, když systém naběhl tak, jak jsem býval zvyklý.
Jasně, při instalaci nové verze jádra se vytvořil nový soubor initramfs, ve kterém je patrně informace o upraveném FS, která v původním nebyla. (Doufám, že ten, kdo ví, jak to skutečně funguje, se jen shovívavě pousměje.) Takže jsem ještě z live verze reinstaloval linux-lts (asi by stačilo pustit mkinitcpio, ale nechtělo se mi zkoumat parametry) a už vše běželo jako dřív.
Po návratu z dopoledních lázeňských procedur jsem disk znovu otestoval, promazal nějaké zbytečné soubory, vyzkoušel nějaké příkazy dávající informace o FS. Vše fungovalo, jak má. A jelikož odpolední páteční procedury skončily brzo, napadlo mě všechno zapsat, dokud to mám v paměti. Možná někomu připadá, že jsem objevil Ameriku, no co už.
PS: Omlouvám se za dlouhý zápis, ale neměl jsem čas na krátký 
.
Tiskni
Sdílej:
20.7.2024 23:30
k3dAR | skóre: 63
23.7.2024 22:53
k3dAR | skóre: 63
btrfs scrumtrvalo 10 % 30 minut a potom 6 minut.
jakoze takovy nejaky poradnejsi testy nevidim nikoho delat, maximalne tak ty souborovy operace, single thread, single user...
Delal jsi nejaka mereni rychlosti s ext4 a pak s btrfs?Nedělal, nepotřebuji žádné rychlé zpracování velkých dat. A když už někdy kopíruji velké soubory, tak myslím, že rychlost je dána hlavně rychlostí připojení. Jirka
20.7.2024 23:32
k3dAR | skóre: 63
23.7.2024 22:59
k3dAR | skóre: 63
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
