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, …
ls -l ~/.local/share/baloo/ celkem 25567864 -rw-r--r-- 1 palovsky palovsky 18102980400611328 29. čec 14.39 index -rw-r--r-- 1 palovsky palovsky 8192 29. čec 14.39 index-lockJo, je to několika tisíckrát více než mám celý diskový prostor a pochopitelně to žádná záloha neudělá. Nerozumí tomu někdo?
# velikost volume df -h ... /dev/mapper/system 230G 221G 8,4G 97% /home ... # vytvoříme prázdný soubor o velikosti 5TB truncate -s 5T /home/test.img # ověříme, že má 5TB du -bhc /home/test.img 5,0T /home/test.img 5,0T celkem # koukneme přes ls ls -l /home/test.img -rw-r--r-- 1 max max 5497558138880 29. čec 15.16 /home/test.img # smažeme rm -f /home/test.imgNemusí tedy nutně jít o chybu na filesystému. Může se jednat i o nějaký bug v Baloo.
du -sh ~/.local/share/baloo/index
Jo, je to několika tisíckrát více než mám celý diskový prostor a pochopitelně to žádná záloha neudělá. Nerozumí tomu někdo?
To↑ jsou hned dva nesmysly v jednom odstavci. Udávaná velikost souboru přece nemusí nijak souviset s velikostí diskového prostoru. Existují řídké soubory, podobně jako existuje řídká stolice.
Každopádně, automatické zálohování nikdy nesmí kvůli řídkým souborům padat; musí si s nimi umět korektně poradit, tj. (1) detekovat a zachovat mezery v souborech a případně (2) z už alokovaných nulových bloků vytvořit nové mezery.
Takže na úvod a především bych zkontroloval (a raději zahodil a nahradil) onen automatický zálohovací mechanismus, který je zjevně rozbitý a neporadí si s obyčejným řídkým souborem. Já mám například na 2 TB SSD cca dvacet virtuálek a každá z nich má virtuální disk o (neméně virtuální) velikosti 1 až 10 TB. Jakpak se tam asi vejdou? Jakpak se asi zálohují? Inu, normálně; řídké soubory jsou úplně běžná věc. (Rozumné atomické zálohování typu btrfs send / btrfs receive s nimi pracuje bez problémů a na úrovni souborového API s nimi umí pracovat třeba rsync.)
K původnímu problému: Ano, Baloo je zabugovaný odpad, kterému je dobré se vyhnout.
Moje hypotéza ohledně toho, co se stalo: Zase se projevil jeden z mnoha bugů, nějaké číslo přeteklo či podteklo, nastal lseek64() do ohromné dálky a následně pak pár zápisů v té ohromné dálce. Což bohužel samozřejmě uspělo, protože … řídké soubory jsou běžná věc.
Tak schválně, jestlipak mám 8 exabytů minus 1 byte „místa“, jo? A navíc klidně dvakrát.
$ truncate -s 9223372036854775807 huge $ du -shb huge 9223372036854775807 huge $ du -sh huge 0 huge $ cp huge also_huge $ du -shb huge also_huge 9223372036854775807 huge 9223372036854775807 also_huge $ du -sh huge also_huge 0 huge 0 also_huge $ rm huge also_huge
Tiskni
Sdílej: