Byla vydána nová verze 9.7 multiplatformní digitální pracovní stanice pro práci s audiem (DAW) Ardour. Přehled novinek, vylepšení a oprav v poznámkách k vydání.
Vývojáři webového prohlížeče Ladybird dnes oznámili, že mění způsob vývoje. S blížícím se vydáním alfa verze přestávají přijímat veřejné pull requesty. Všechny otevřené veřejné pull requesty budou uzavřeny. Tým nedokáže garantovat bezpečnost AI generovaných pull requestů.
OpenLogi (GitHub) je open source náhrada aplikace Logi Options+ pro přizpůsobení myší od společnosti Logitech. Zatím běží pouze na macOS.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za květen (YouTube).
Úřad pro ochranu osobních údajů řeší desítky stížností na jednotné měsíční hlášení zaměstnavatele, které stát spustil počátkem dubna. Systém, jenž má firmám odlehčit od desítek formulářů, nejenže výrazně zatížil jejich účetní oddělení, ale docházelo v něm i k únikům osobních dat zaměstnanců k firmám, kde nepracovali. Podle ministerstva práce a sociálních věcí stála za problémem technická chyba. „Incident se týkal několika stovek
… více »Byla vydána (𝕏, Bluesky) nová verze 22.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
Vim Classic byl vydán ve verzi 8.3. Drew DeVault oznámil tento fork editoru Vim (verze 8.2.0148, tj. těsně před zavedením Vim9 skriptování) v březnu letošního roku. Důvodem forku bylo, že vývojáři editorů Vim a Neovim začali při vývoji využívat LLM.
Open source konference DevConf.CZ 2026 proběhne 18. a 19. června v Brně na FIT VUT. Publikován byl program a spuštěna byla registrace.
Společnost JetBrains uvolnila verzi 2 svého open-source velkého jazykového modelu (LLM) pro vývojáře Mellum.
Probíhá konference Microsoft Build 2026. Microsoft představuje své novinky: kvantový čip Majorana 2, Surface Laptop Ultra a Surface RTX Spark Dev Box s NVIDIA RTX Spark, Intelligent Terminal, Coreutils for Windows (fork Rust Coreutils), AI modely MAI, AI agenta Scout, platformu pro agent-first zařízení Project Solara, …
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
