Cheat Engine (Wikipedie) je s verzí 7.7 k dispozici už také pro Linux. Jedná se o proprietární skener/debugger paměti používaný především k cheatování v počítačových hrách.
Vláda USA nařídila společnosti Anthropic pozastavit přístup k modelům Fable 5 a Mythos 5 pro všechny cizince, včetně zaměstnanců Anthropicu.
Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Tento blog obsahuje nebezpečnou symboliku.
Poslední měsíc jsem se docela intensivně věnoval nastavení disků, rozdělení oddílů a výběru správného FS.
Mám tyto disky:
/dev/hda:
Model=WDC WD2000JB-00GVA0, FwRev=08.02D08, SerialNo=WD-WCAL81446368
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74
BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Timing cached reads: 1216 MB in 2.00 seconds = 607.96 MB/sec
Timing buffered disk reads: 164 MB in 3.03 seconds = 54.09 MB/sec
/dev/hdb:
Model=ST3160023A, FwRev=8.01, SerialNo=3JS3WBXS
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Timing cached reads: 1368 MB in 2.00 seconds = 683.96 MB/sec
Timing buffered disk reads: 164 MB in 3.04 seconds = 54.02 MB/sec
Zkrátka: 200GB WesternDigital, 160GB Seagate. Oba 8MB cache a ATA133. Rychlosti uvádím pro další srovnání.
Na disku hda mám WindowsXP a Fedora Core 4. Původní rozdělení vypadalo nějak takto:
hda1 NTFS 38GB hda2 EXT3 36GB / hda3 free 4GB hda4 JFS 114GB sklad
Vzhledem k tomu, že Windows používám minimálně, tak jsem zmenšil oddíl na 10GB (ten NTFS je něco přes tři roky starý a byl několikrát kopírován na jiné fyzické disky, zmenšení v PQMagic bez problémů) a zbytek disku přerozdělil takto:
hda1 NTFS 10GB hda2 EXT2 512MB /boot hda5 EXT3 2GB / hda6 EXT3 8GB /usr hda7 EXT3 4GB /var hda8 EXT3 30GB /home hda9 JFS 137GB sklad
Toto rozdělení mi +/- poradil človek, který je šefredaktorem časopisu o linuxu a dlouholetým uživatelem Gentoo. Říkal, že je lepší rozdělit disk na jednoúčelové partišny a doporučoval mi ext3. Výhody tohoto rozdělení: samostatný boot (toho využívám i teď), lze libovolně měnit FS (není takový problém zazálohovat 8GB partičnu), lepší možnosti zálohování. Nevýhody: plýtvání místem a velké problémy při seeku (toto se ukázalo být tak velkým problémem, že jsem si disk nakonec rozdělil jinak, viz dále).
Pár poznámek:
Mám asi 300 000 souborů s maily (maildir). Tyto soubory se z ext3 (vytvořil jsem si speciální 2GB partišnu JEN pro emaily), čtou rychlostí 600kB/s. Mám 1GB paměti a tedy není problém třeba 40% té partisny mít v diskové cache. Tohle opravdu nechápu. Disk neustále seekoval a na PC se prakticky nedalo pracovat.
Další problém nastal s JFS. Soused má malý disk a má u mě share (přes 100mbps síť). Kopírovat asi 50GB na ten čertvě vytvoření oddíl s JFS a jelo to tak 3MB/s. Říkal jsem si, fajn soused má moc fragmentovaný disk. Hmm. On ne. Já. Když jsem ty jeho data pak kopíroval na hdb, tak to jelo v podstatě max 5MB/s a opět bylo slyšet kmitající hlavičky.
Pokračování za chvíli... Tak jsem zpět.
Poslední a finální rozdělení vypadá takto:
hda1 NTFS 10GB hda2 ext2 512MB /boot hda5 ext3 9GB / hda6 XFS 167GB /home hdb1 XFS 146GB sklad
Copy z hda na hdb kolem 35MB/s (srovnej s JFS...). Na /home mám 300 000 mailů, squid cache, dva weby, pár DVD ISO a 20GB soubor(y). Je to rychlé, seek disku prakticky není slyšet.
Výsledkem tohoto testu je, že nejlepším FS je pro mě XFS. Dost lidí tu psalo, že se jim ztratila data při výpadku napájení atp. Mě se nic takového nikdy nestalo (na hdb používám XFS od začátku). Dále jsem slyšel, že XFS nemá rád mnoho souborů. Squid cache a maily jsou daleko rychlejší než při použití ext3 a dokonce i reiserfs (což mě dost překvapilo).
Na LVM se vrhnu, až budu mít pořádný RAID řadič. Vytvořit 300GB oddíl přes dva obyčejné ATA disky opravdu nechci. Na jednom kanálu to mám z důvodu nemožnosti jiného uspořádání v case (během 14 dnů si koupím nový).
Abych to celé srhnul: Překvapilo mě jak disk seekoval na ext3; vysoká fragmentace na čistém JFS; pomalá práce se statisíci soubory u ext3 reiserfs.
Stroj: Athlon XP 2400+, 1GB 333DDR, VIA KT400. Více
Nastavení ext3: dir_index, writeback, noatime, commit=60. Ostatní FS default + noatime.
Tiskni
Sdílej:
/boot ext3 100MB / xfs/reiserfs 5-6GB /var xfs/reiserfs 1GB /dataVG xfs/reiserfs ~GB LVMja osobne preferujem XFS. Myslite, ze ma zmysel na desktope delit / a /usr ?
), úžasně flexibilní.
Taky jako filesystem já osobně preferuju reiserfs, mam s ním mnohem lepší zkušenosti než s ext3 (ext3 mi na starém PC několikrát odešel, kdežto reiserfs tam funguje krásně už mnohem delší dobu... a také je znatelně o hodně rychlejší
). Vím, že o reiserfs stále ještě kolují různé děsivé mýty, ale to je jen odkaz minulosti, u mě se např. jak už jsem psal ukázal mnohem stabilnější a robustnější (a také pro naprostou většinu operací rychlejší) než ext3.
Co se týče XFS, tak ten bych si na disk v počítači bez UPSky teda opravdu nedal. To že si s ním při tvrdých výpadcích (vypnutí PC za běhu, výpadek proudu, atp.) nepřišel o žádná data je IMHO jen neskutečné štěstí. Ten filesystem je tak prostě stavěn... je to skvělý fs, ale bez UPS prostě podle mě sebevražda
To si říkám taky. Ale /home se zálohuje denně, takže o důležité věci by uživatelé nepřišli. V podstatě bych jen musel znova stahovat ISO těch pár live distribucí, což není taková tragedie.
BTW: Asi by bylo dorbý, kdyby se to stalo, aspoň bych konečně přišel o ty kraviny, který nemám odvahu smazat s tím, že je možná někdy budu potřebovat. 