Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.
3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.
Open source webový aplikační framework Django slaví 20. narozeniny.
V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.
Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.
Výroba 8bitových domácích počítačů Commodore 64 byla ukončena v dubnu 1994. Po více než 30 letech byl představen nový oficiální Commodore 64 Ultimate (YouTube). S deskou postavenou na FPGA. Ve 3 edicích v ceně od 299 dolarů a plánovaným dodáním v říjnu a listopadu letošního roku.
Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.
Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.
McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.
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: