Počítačová hra Factorio (Wikipedie) nově běží nativně na ARM64 Linuxu a headsetu Steam Frame.
Fugleramme, v překladu 'ptačí rámeček', je open-source projekt postavený na Raspberry Pi, který pomocí lokální umělé inteligence BirdNET-Go rozpoznává ptačí druhy podle jejich zpěvu a na displeji následně zobrazuje koláž tvořenou odpovídajícími ilustracemi. Databáze obsahuje přes 800 ručně vybraných historických přírodovědných ilustrací více než 400 druhů ptáků.
… více »Unicode Consortium, nezisková organizace koordinující rozvoj standardu Unicode, oznámila vydání Unicode 18.0. Přidáno bylo 13 007 nových znaků. Celkově jich je 172 808. Přibylo 9 nových Emoji.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 169 (pdf).
Byla vydána nová verze 6.4 programovacího jazyka Swift (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Německý kancléř Friedrich Merz (CDU) se během debaty s finalisty studentské vědecké soutěže Jugend forscht vyjádřil pro konec anonymity na internetu a vyslovil názor, že pro uživatele Internetu by měla platit podobná právní odpovědnost jako pro novináře tradičních médií. Na dotaz studenta, jak by se tedy povinnost uvádět pravé jméno slučovala s prací investigativních novinářů nebo ochranou jejich zdrojů, Merz neodpověděl, ve své
… více »Společnost Fujitsu představila FUJITSU-MONAKA CPU a Fujitsu MONAKA Server. Navrženo, vyvinuto a vyrobeno v Japonsku. Pro suverénní AI infrastrukturu.
Předprodej v květnu představených notebooků Googlebook, nástupců notebooků Chromebook, bude spuštěn v pondělí 21. září.
Byla vydána betaverze Fedora Linuxu 45 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 20. října. S konzolí kmscon místo fbcon. Současně byla vydána betaverze Fedora Linux Asahi Remixu 45. S podporou čipů M3.
Po půl roce vývoje od vydání verze 50 bylo vydáno GNOME 51 s kódovým názvem "A Coruña" (Mastodon). Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře. Videopředstavení na PeerTube a YouTube.
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: