Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 4. snapshot Ubuntu 25.10 (Questing Quokka).
Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Alyssa Anne Rosenzweig v příspěvku na svém blogu oznámila, že opustila Asahi Linux a nastoupila do Intelu. Místo Apple M1 a M2 se bude věnovat architektuře Intel Xe-HPG.
EU chce (pořád) skenovat soukromé zprávy a fotografie. Návrh "Chat Control" by nařídil skenování všech soukromých digitálních komunikací, včetně šifrovaných zpráv a fotografií.
Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
Společnost xAI a sociální síť X amerického miliardáře Elona Muska zažalovaly firmy Apple a OpenAI. Viní je z nezákonné konspirace s cílem potlačit konkurenci v oblasti umělé inteligence (AI).
Label: 'archiv' uuid: d1722103-0c1e-4627-bbc7-9f1f0bf91739 Total devices 4 FS bytes used 4.56TiB devid 1 size 3.64TiB used 3.30TiB path /dev/mapper/archiv devid 2 size 3.64TiB used 3.30TiB path /dev/mapper/com devid 3 size 1.36TiB used 1.03TiB path /dev/mapper/miraza devid 4 size 1.82TiB used 1.49TiB path /dev/mapper/securestoragecíl: extení disk USB 3.0 připojený jako
sdo
má ntfs filesystem. Kopírování rsync -av zdroj cíl
To co mne zaráží je mrňavé požadavky na IOPS pro zápis na ntfs a naopak obrovské IOPS, které se koncentrují do disku com
. Soubor throughput ukazuje, že co se přečte, to se zapíše. mount btrfs je/dev/mapper/archiv /disky/archiv btrfs commit=100,defaults 0 0(v mount je
type btrfs (rw,relatime,space_cache,commit=100,subvolid=5,subvol=/)
) a ntfs je standardní automount(v mount je type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
) Případně jak pole mountnout aby výkon byl větší (každý /dev/mapper toho pole je LUKS2 volume)
Naopak kdybys mel btrfs na obou stranachPokud je to záloha, tak je dobré mít pro zálohu jiný FS než na zálohovaném systému. Kdyby byl bug v kernel modulu daného FS, který by ten FS zničil, tak ti to zničí jak originální FS tak i zálohu. Takže jiný FS je zde na místě. (Otázkou je proč zrovna NTFS přes fuse...)
To co mne zaráží je mrňavé požadavky na IOPS pro zápis na ntfs a naopak obrovské IOPSAno, tohle je docela běžné, protože pro zápis se používá mnoho technik pro odložený zápis, aby si to FS mohl srovnat v paměti a zapsat to co nejefektivněji. Při čtení těch souborů se příliš optimalizovat nedá, program ty soubory čte v neoptimalizovaném pořadí (protože ho ani nemá jak zjistit), FS musí vyhledat soubor v adresářovém stromu a FS musí vyhledat polohu bloků daného souboru v inodě. Tzn při náhodném čtení mnoha souborů je tam těch IOPS víc než při zápisu, kdy to FS může zapsat všechno naráz (po větších celcích). (Jaké přesně má optimalizace NTFS nevím, ale výše popsané platí třeba pro XFS nebo pro ext4 - delayed allocation).
které se koncentrují do disku comPodle obsazeného místa soudím, že v tom raid1 byly nejdřív disky archiv a com, které jsou plné a potom se tam přidaly ty dva další disky. Tedy ty fotky budou asi zřejmě uloženy pouze na devid 1 a devid 2 a btrfs je čte pouze z jednoho disku (proč taky ne). Celkově na té situaci nevidím nic zvláštního (teda až na poměrně creativně pojmenované disky v tom r1).
Fakticky jsem dosáhl rychlosti jen asi 50-60 MB/s což mi připadalo trochu málo.No pokud tam jsou soubory o velikosti 1MB a ten disk předpokládám 7200rpm, tak pro každý soubor je potřeba přečíst inode a potom začít číst bloky toho souboru. Tj 2 operace per soubor (a to jen pokud není fragmentovanej). 60*2 = 120 IOPS, což přesně odpovídá 7200rpm (7200rpm/60s = 120IOPS). Čtení těch rawů by mělo jít rychleji. Ono taky záleží, kde na tom disku ta data jsou, protože rychlost čtení rotačního disku na obvodu disku je nejrychlejší (to jsou úžasné hodnoty v testech) a potom to ke středu disku klesá docela znatelně. Tj disk zvládající 140MB/s může u středu klidně spadnout až pod 80MB/s.
ostatně ani to inode by nemusel číst při každé operaciPsal jsem per soubor. Program si vyžádá data souboru, FS se musí podívat na to, které bloky má přečíst (tj v inode) a potom je začne číst. To jsou dvě operace. Navíc je to btrfs, takže by si měl na druhém disku číst ještě checksum a porovnávat jej s těmi čtenými daty. Tj další operace, ale na druhém disku.
time du -a * | wc -l 105632 du -a * 0,10s user 0,42s system 99% cpu 0,524 total wc -l 0,03s user 0,31s system 64% cpu 0,523 total
Myslel jsem to tak, že by přečetl balík inode dopředu a ty měl v paměti a pak už je jen z paměti vybral.Pro x různých souborů? Ten FS neví, které další soubory bude ten program po něm chtít. Jasně, kdyby existovala možnost tomu fs říct: "připrav si všechny tyhle soubory, za chvíli je po tobě budu chtít", tak je to jiná. Ale FS tohle neumožňuje.
2k: 4194303 * 2k = 8 GiB 4k: 4194303 * 4k = 16 GiB 8k: 4194303 * 8k = 32 GiB 16k: 4194303 * 16k = 64 GiB 32k: 4194303 * 32k = 128 GiBKaždopádně je rozumné mít full backup v nějakých intervalech, protože je mnohem rychlejší obnovit full dump a dohrát pár dní transakčních logů, než dohrávat transakční logy třeba za měsíc. Obzvláště, pokud se jede na minimální rollback a každou minutu, někdy i častěji z db padají logy a za den je těch souborů třeba 15 000.
Export dat je zase v některých případech výhodný v tom, že se lze dostat k nějaké tabulce z noční zálohy do pár minut.Pokud tedy rebuild potřebných indexů nad tabulkou netrvá déle než úplná záloha/obnova.
To fakt není FS na 2GB flashku.
Tiskni
Sdílej: