Samsung na akci Galaxy Unpacked July 2026 (YouTube) představil své nové telefony Galaxy Z Fold8 Ultra, Fold8 a Flip8, hodinky Galaxy Watch Ultra2 a Watch9 a chytré brýle ve spolupráci s Gentle Monster a Warby Parker.
Po pěti letech vývoje vyšla česká počítačová hra Scarlet Deer Inn (ProtonDB). Scarlet Deer Inn je vyšívaná temná středověká pohádka. Zatímco život ve zdánlivě obyčejné vesnici se točí kolem běžných povinností a sousedských drbů, v podzemí se skrývají zlověstná tajemství.
Představen byl Raspberry Pi Touch Display 2 s uhlopříčkou 10 palců a rozlišením 1200 × 1920 pixelů. Cena je 80 dolarů.
RPCS3 (Wikipedie), tj. open source emulátor Sony PlayStation 3, snížil minimální požadavky. Nově jsou podporovány starší grafické karty ATI Radeon řady HD 2000, 3000 a 4000 z let 2007 až 2009. Na PC běží už 75 % všech her pro PlayStation 3. V budoucnu bude RPCS3 fungovat bez firmwaru z PS3. V RPCS3 byl implementován systémový modul cellSysmodule (𝕏).
Vyšel open-source nástroj winetop (MIT) — nativní CLI/TUI pro sledování a ukončování Wine, Proton, Lutris, Heroic a Bottles sezení. Seskupuje procesy podle WINEPREFIX / Steam AppId, umí bezpečně zabít jen hru (včetně Steam reaperu) a nabízí i skriptovatelné příkazy (list, kill, orphans, …). Balíčky jsou mimo jiné na crates.io, Copru (dnf copr enable kovariadam/winetop), PPA ppa:kovariadam/winetop a AUR (winetop-bin).
Ve spolupráci společností OpenAI a Work Louder byla představena (𝕏) hardwarová klávesnice Codex Micro pro práci s AI agenty. Cena klávesnice je 230 dolarů.
Byl vydán Mozilla Firefox 153.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 153 bude brzy k dispozici také na Flathubu a Snapcraftu.
V linux-cve-announce bylo oznámeno 433 zranitelností za jediný den (19. července).
Byla vydána nová verze 5.44 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 71 vývojářů. Změněno bylo přibližně 270 tisíc řádků v 1 300 souborech. Přehled novinek a změn v podrobném seznamu.
Na 23. září 2026 je do bratislavské Nové Cvernovky naplánovaná jednodenní konference #nobullshit.camp pro tech leadery, DevOps a platform inženýry. Mají tu zaznít upřímné příběhy z praxe o tom, co v produkčních systémech reálně fungovalo, co se pokazilo a co si z toho lidé odnesli. Témata pokrývají tři oblasti – DevOps a platformy (Kubernetes, cloud, provoz systémů), firemní kulturu a leadership. Program běží ve dvou formátech: hlavní
… více »
.
O SSD jako cache pro často používané soubory jsem přímo neslyšel (v kernelu na to IMO není přímo subsystém), ale asi by šlo na to použít něco z RAID subsystému. SSD i HDD by se pak pro userspace jevilo jako jeden konglomerát a o balancování by se staral kernel (nechat to na userspace je o data). Pokud by pak jeden z disků umřel, tak budeš mít problém se záchranou dat.
Pokud by nějaký takový ovladač existoval, tak bude fungovat tak, že při každé operaci zkontroluje seznam všech souborů, vloží do něj novej přístup a rozhodne se zda překopíruje soubor mezi SSD a HDD (a samozřejmě ho mezitím otevře). Tohle rozhodování bude žrát dost času a prodlužovat odezvu systému. Taky bude opotřebovávat SSD a ve worst case bude neustále obojí "swapovat".
Opět mám dojem, že bude nejlepší tohle rozhodovat ručně, tedy dát na SSD OS knihovny, aplikace a třeba nějaké obsáhlé datové soubory (kámoš tam má minecraft world databázi - a i na to je SSD overkill, ale hodí se třeba i image virtuálu) a pak případně přehazovat, co bude potřeba mezi home na HDD a system na SSD (třeba kompilace generuje masivní zápisy objektových souborů a masivní čtení zdrojáků a zároveň masivní spotřebu RAM na úkor diskové cache).
P.S. Na krátkodobou cache se používá přímo RAM (řekneme mezi rebooty) a ta je samozřejmě řádově rychlejší. Taky by šlo na SSD umístit swap, ale ten je zapisovanej hodně často a asi by bylo lepší investovat do víc RAM (která je levnější a lze z ní udělat i ta disková cache).
. Podle všeho to je fakt v RAID subsystému a tam jsem vlezl jen jednou před roky.
Ale pozor dm_cache je označený i v 4.8rc jako experimental.
Ve zkratce: Řešení je například Bcache a je na to spousta návodů, něco u Fedory, něco třeba na ArchWiki.
…při instalaci Fedory…
Proč při instalaci? To nedává smysl a pravděpodobně to nejde. Takové věci je lepší řešit až po instalaci, což má tu výhodu, že uživatel pochopí, co vlastně dělá a co se kde nastavuje.
…aby byl systém na HDD a SSD se používa jako cache často čtených souborů…
Bloků, nikoliv souborů. Cache na úrovni souborů nedává smysl.
Ještě by mě zajímalo, jaký souborový systém mám pro SSD zvolit?
Pro SSD samozřejmě žádný, pokud tam bude Bcache.
Jinak výhradně Btrfs. Pro SSD, pro HDD, všude. Jiná volba dnes na Linuxu nedává smysl, pokud člověk nechce záměrně používat zastaralé souborové systémy, které jsou 10 let za zenitem a jejichž návrh neodpovídá velikosti a dalším parametrům dnešních úložišť.
Taky bych chtěl varovat, že nejsem ajťák…
Tohle je zcela irelevantní. Návody na webu jsou přístupné komukoliv, bez ohledu na to, zda se považuje za „ajťáka“ nebo ne. Je lepší soustředit se na řešení problému a dotazy s ním související, nikoliv na to, co kdo je či není. :-/
Fedora + Bcache — tohle je rozumnější odkaz. Ale je to návod z dob Fedory 20, tj. na dnešní 24/25 se musí člověk dovtípit několika drobných odlišností.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
15.10.2016 13:50