Google představil telefon Pixel 10a. S funkci Satelitní SOS, která vás spojí se záchrannými složkami i v místech bez signálu Wi-Fi nebo mobilní sítě. Cena telefonu je od 13 290 Kč.
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Fedora 43 Asahi Remix s KDE Plasma už funguje na M3. Zatím ale bez GPU akcelerace. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Red Hat představil nový nástroj Digital Sovereignty Readiness Assessment (GitHub), který organizacím umožní vyhodnotit jejich aktuální schopnosti v oblasti digitální suverenity a nastavit strategii pro nezávislé a bezpečné řízení IT prostředí.
BarraCUDA je neoficiální open-source CUDA kompilátor, ale pro grafické karty AMD (CUDA je proprietární technologie společnosti NVIDIA). BarraCUDA dokáže přeložit zdrojové *.cu soubory (prakticky C/C++) přímo do strojového kódu mikroarchitektury GFX11 a vytvořit tak ELF *.hsaco binární soubory, spustitelné na grafické kartě AMD. Zdrojový kód (převážně C99) je k dispozici na GitHubu, pod licencí Apache-2.0.
Podvodné reklamy na sociálních internetových platformách, jako je Facebook, Instagram nebo X, vytvořily loni v Česku jejich provozovatelům příjmy 139 milionů eur, tedy zhruba 3,4 miliardy korun. Proti roku 2022 je to nárůst o 51 procent. Vyplývá to z analýzy Juniper Research pro společnost Revolut. Podle výzkumu je v Česku zhruba jedna ze sedmi zobrazených reklam podvodná. Je to o 14,5 procenta více, než je evropský průměr, kde je podvodná každá desátá reklama.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.6 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
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ý.
Řešení dotazu:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
/var/log
Ty máš křišťálovou kouli, že víš co mu zabírá nejvíc místa? Každopádně truncate nic nemaže. Je to použitelné řešení v situaci, kdy máš zaprásknutý disk až do mrtě.
ls =l ? Ak tie rôzne čísla porovnáš, tak sa dostaneme ku sparse súborom, a na čo som narážal pri reakcii "nejvíce zbytnělý log ve /var/log". Medzi také súbory ktoré sa začiatočníkovi javia ako moc veľké patria vo /var/log aj [last,fail]log.
Ale s tým truncate, tak mi prezraď ako uvoľní miesto na disku ak sú inody skracovaného súboru obsadené bežiacim procesom. Skús to vysvetliť tvojím začiatočníckym spôsobom.
Toľko ku tým tvojím žvástom akými sa chváli lamička ktorú na MDD nikto nechce.
/var/log má smysl jen když něco řešíš. U lamy tedy většinou žádný. Truncate používám jen v případě, že potřebuji uvolnit alespoň tolik místa, aby zafungoval journalctl. Zkrátím velikost na 0 bajtů, ty stávající data se zahodí a ten proces začne zapisovat nová. Si to vyzkoušej mameluku.
Ohľadne tej infraštruktúry ktorú akože spravuješ, tak by som poprosil sieťový rozsah. Rád si ho preventívne zablokujem.
Beze všeho: 192.168.x.y – za x a y si dosaď libovolné číslo od 0 do 255
Mimochodem, ten tvůj /var/log/wtmp obsahuje data, která jsou úplně k hovnu. Viz /var/log/wtmp
Je to jen zbytečný bordel zabírající místo, který se při restartu může s klidnou duší zahodit, protože (u mne) jsou klíčové informace uložené jinde, ve výrazně srozumitelnější formě. Soubor, ve kterém jsou veškeré informace za posledních 334 dní má všeho všudy 65MB
A největší log /var/log/lastlog má u mne trapných 100MB
Je rok 2025. Na co systmd-journald poštve nějaké zkracování, to je věcí jeho konfigurace. A ne, podstatná část diskového prostoru se opravdu (ale opravdu (ale opravdu)) neuvolní zkrácením (binárních, komprimovaných) logů.
Budeš se divit, ale jo. Speciálně u zaplácnutého Btrfs. A příkaz journalctl --vacuum-time=1d sem tam také použiju.
Nevím, no. Když mám podezření, že je něco špatně, podívám se na journalctl -f. Pokud se něco objevuje častěji než jednou za (se)kundu, obvykle je potřeba řešit příčinu toho problému, ne až následek. Dokonce mám na některých stojích alert odvozený od „produktivity“ journalctl -f.
Přečti si prosím ještě jednou, od samého počátku tuhle diskuzi prosím.
Pořádné sračky. Až to bolí číst. Hlavně tedy ten truncate.
Mysli si o tom co chceš, pro mne je důležité, že to funguje0.
(0) Před 15+ lety by to možná fungovalo [pozn. red.].
Pohled do kalendáře mě utvrzuje v jistotě, že nezáleží na tom, co si kdo myslí. Věci v té strohé realitě prostě už nějak jsou.
21.6.2025 16:07
Jendа | skóre: 78
| blog: Jenda
| JO70FB
zkrácením (binárních, komprimovaných) logůMožná mám journald špatně nastavený, ale zabírá mi mnohem víc prostoru, než ekvivalentní textová reprezentace. Konkrétní experimenty:
to z tebe teda zbyla troska
journalctl | wc -c ukáže 1325903166 (1.3 giga), ale /var/log/journal má 4.3 GB. Člověk by čekal, že tam ještě budou efektivně uložené timestampy a další metadata.
Textový /var/log/syslog, do kterého podle mě přeposílám veškeré zprávy co jsou v journalu, má od neděle 327 MB. journalctl --since "6 days ago"| wc -c ukáže 267377143 (267 mega), čili řádově by to odpovídalo. Následně jsem spustil journalctl --vacuum-time=6d a /var/log/journal se zmenšilo na 782 MB, stále je tedy 2-3x větší než hloupý textový syslog.
Obsah adresáře /var/log/journal jsem zkopíroval a zkusil zkomprimovat defaultním gzipem. Zmenšil se na 175 MB (4.5x). To znamená, že původní data vůbec nejsou komprimována, naopak.
Též jsem gzipem zkomprimoval textový /var/log/syslog. Ten se zkomprimoval na 22.5 MB (skoro 8x lépe než komprimovaný binární journal). Tedy ani například transparentně komprimující souborový systém by s journalem tolik nepomohl.
Naposledy jako zpětná kontrola: teď když jsem udělal vacuum za 6 dní, tak mám
journalctl | wc -c: 245 megajournalctl | gzip | wc -c: 12.5 megadu -sh --si /var/log/journal/: 782 megaJo, to netuším, co je špatně. Přičiním jenom několik „stating the obvious“ poznámek:
-u nebo podle času, takže se nedá srovnat 1:1 s tím, co ukládá journald.man journald.conf neklame, implicitně se komprimují jen záznamy (== jednotlivé „zprávy“ v logu, velikostí něco mezi „řádkou“ a „backtrace“ ), pokud přesáhnou 512 B. Tohle se sice dá nastavit (snížit), ale pokud má každý záznam svůj oddělený kontext/slovník pro kompresi, bude taková komprese velmi neúčinná.Seal= (FSS), což v některých distrech může být implicitně nastavené při instalaci, bez vědomého přičinění uživatele, můžou data logů ještě víc nabobtnat./var/log/journal není příliš fair srovnání, protože tam je uložené všechno z journalctl + všechno z journalctl --user + všechno z journalctl --user pro všechny ostatní uživatele.Ještě pro upřesnění, co jsem myslel tímto:
A ne, podstatná část diskového prostoru se opravdu (ale opravdu (ale opravdu)) neuvolní zkrácením (binárních, komprimovaných) logů.
Výše zmíněné checksumy zajistí, že poškození (náhodné zkrácení) binárních logů od journald učiní tyto soubory nečitelnými. Tudíž místo předvídatelného zkrácení dojde ke ztrátě dat z podstatné části příslušného souboru (výrazně větší než uříznutá část), popřípadě z celého souboru, který může journalctl odmítnout číst. A při každém přístupu přes journalctl se bude ukazovat chybová hláška o poškozeném souboru.
Proto↑ jsem příslušnou „radu“ považoval za kolosální nesmysl. Měl jsem se vyjádřit přesněji.
3.8.2025 21:33
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
df -h, protože může být nějak hloupě rozdělený. Dál lze pátrat po velikosti jednotlivých adresářů příkazem du viz příklady třeba zde.
Vlákno bylo přesunuto do samostatné diskuse.
sudo bash
cd /
du -sh * |sort -h
zoradi podla velkosti
3.6.2025 14:17
|🇵🇸 | skóre: 94
| blog:
3.8.2025 21:28
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Tiskni
Sdílej:
