Ministerstvo průmyslu a obchodu vyhlásilo druhou veřejnou soutěž v programu TWIST, který podporuje výzkum, vývoj a využití umělé inteligence v podnikání. Firmy mohou získat až 30 milionů korun na jeden projekt zaměřený na nové produkty či inovaci podnikových procesů. Návrhy projektů lze podávat od 31. října do 17. prosince 2025. Celková alokace výzvy činí 800 milionů korun.
Google v srpnu oznámil, ž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. Iniciativa Keep Android Open se to snaží zvrátit. Podepsat lze otevřený dopis adresovaný Googlu nebo petici na Change.org.
Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.
Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
Pro moddery Minecraftu: Java edice Minecraftu bude bez obfuskace.
Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].
Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.
Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
TrueNAS (Wikipedie), tj. open source storage platforma postavená na Linuxu, byl vydán ve verzi 25.10 Goldeye. Přináší NVMe over Fabric (NVMe-oF) nebo OpenZFS 2.3.4.
1) stop databáze 2) cp /var/lib/mysql/[databaze] /zaloha/nekam/bokem/ 3) start databáze 4) tar czf /zaloha/[databaze].tgz /zaloha/nekam/bokem/* 5) přenos jinam a užití snapshotu (třeba nahození nekonzistentního spadnutého replikačního slave z tohoto funkčního slave)Kritický krok 2, který vyžaduje zastavit db server, aby data neměnil pod rukama během snapshotování strašně dlouho trvá. Zde se tedy přímo nabízí copy on write a využití filesystemu, který COW umí. Pak je to otázka sekund. Co prosím by jste z vlastní zkušenosti doporučili za FS v dnešní době? Já to mám funkčně napsáno i s COW ale mám to na ext4, takže se mi teď tahle vlastnost neuplatňuje a trvá to a počítám s tím tak. Když jsem to dělal na BTRFS, začalo to nějak asi bobtnat a nedělal jsem něco co se s BTRFS dělat má a pak to už neměl čas studovat. Potřeboval bych nějaký FS který umí COW a nepotřebuje dál nějaký extra servis, nebo druhá varianta, potřebuju vědět co mám v takových případech použití dělat, aby FS stále svižně fungoval a nebobtnal. Ty zálohy dělané pomocí COW jsem vždy po zatarování samozřejmě smáznul. Tím by on měl nějak zahodit ty vazby mezi původním souborem a COW souborem a jet normálně dál ne? Nebo to bylo tím, že jsem samotnou tu databázi provozoval na BTRFS, což není dobré? Díky za podněty a postřehy a případné nakopnutí.
btrfs sub snap ; cp ; btrf sub del a je to. Za normálních okolností není potřeba dělat žádné další vyfikundace, btrfs si nahodí process cleaner a ten smazaný snapshot uklidí. Problém by mohl nastat pouze v případě, kdy by na to neměl čas (disk by byl tak zatížen, že zkrátka úklid trvá déle než intervaly mezi snapshotama).
Zkusim mozna jeste jednou BTRFS, treba se za ty roky neco vylepsilo ...Podle mě je to principiální problém. Můžeš zkusit zapnout autodefrag, ale nevím, jak moc to pomůže.
Existuje jeste neco jakoby mainstreamoveho (tedy s nejakou uz vetsi komunitou a ne stagnujici skolni projekt) co by bylo doporuceni hodne a zaroven umi COW i krom BTRFS ?Vždyť to píšu - LVM snapshoty jsou CoW. A výhoda je, že se CoW dělá jenom v okamžiku, kdy tam ten snapshot je - takže v tvém případě jenom po dobu kopírování.
Vždyť to píšu - LVM snapshoty jsou CoW. A výhoda je, že se CoW dělá jenom v okamžiku, kdy tam ten snapshot je - takže v tvém případě jenom po dobu kopírování.Něco podobného umí i BTRFS. Lze jej nastavit tak, aby COW neprováděl - a to jednak pro celý mountpoint nebo pro konkrétní adresář.
chattr -C - musí se to nastavit na prázdný adresář před nakopírováním dat a potom všechny soubory mají příznak nocow. Snapshoty fungují (ten fs si ty cow dělá dál podle potřeby, ale nepoužívá je při každém zápisu tak jak normálně - takže je to rychlejší).
Některé instalátory (třeba postgresql) chattr -C volají na datový adresář při jeho vytváření.
prakticky konzistentni dump za behu z podstaty veci bez nejake techniky zalozene na COW neudelameNo právě proto jsem psal o výběru jiného db produktu. Protože to, co tady řešíte - tedy konzistentní zálohu za běhu systému - to jiné db zvládají levou zadní. DB pracující na MVCC / MGA si něco jako cow implementují vnitřně (více generací dat; snapshoty), takže jsou schopné poskytnout konzistentní snímek dat. Toto se vy pokoušíte naimplementovat z vnějšku té db. Možná se vám to podaří, ale je otázkou, za jakou cenu a s jakým výsledkem.
jinak je to jako snapshot virtualizovaneho OS za behu, coz taky jaksi moc nejde, potreba ho minimalne pozastavitNevím, proč by to nešlo, snapshotů vm za běhu děláme stovky denně.
Zkusim mozna jeste jednou BTRFS, treba se za ty roky neco vylepsilo ... Existuje jeste neco jakoby mainstreamoveho (tedy s nejakou uz vetsi komunitou a ne stagnujici skolni projekt) co by bylo doporuceni hodne a zaroven umi COW i krom BTRFS ?Tak můžete zkusit zfsonlinux jestli chcete (nebo strčit mysql na freebsd), případně můžete zkusit LVM a dělat snapshoty LV - princip popsal lertimir, snapshoty LV se hodí právě na zálohování. (Akorát je s tím víc práce - udělat snapshot LV, připojit jej na mountpoint, vykopirovat data, odpojit, odstranit snapshot.)
Kritický krok 2, který vyžaduje zastavit db server, aby data neměnil pod rukama během snapshotování strašně dlouho trvá. Zde se tedy přímo nabízí copy on write a využití filesystemu, který COW umí. Pak je to otázka sekund.
Někdo by možná řekl, že se spíš nabízí použití databáze, kterou není potřeba kvůli záloze úplně shodit.
btrfs s CoW se při změnách uvnitř souborů, což databáze dělá, fragmentujeKaždý CoW souborový systém se při změnách uvnitř souborů fragmentuje – z principu CoW.
Trochu zmírnit se to dá úpravou postupu:
..ale teď mi přijde jako lepší volba než ext4).Do první ztráty dat. XFS má svoje specifika. Pokud jde o ext fs, tak osobně mám nejlepší zkušenosti s ext3.
Testoval jsem tvrdé ukončení a subjektivní "svižnost" systému na XFS, ext3, ext4, ext2, RaiserFS, JFS. Vždy čistá instalace a během vytažení ze zásuvky (10x) jsem nechal kopírovat nějaká data na disk. Nejlépe z toho vyšel (tehdy) ext3.
Ext4 (ne ext3!) měl zase bug - docházelo k poškození FS při použití v KVM virtualizaci.
Ovšem pro mě je XFS neocenitelný kvůli možnosti nastavit quotu na adresář (Samba).
Takže těžko radit, je potřeba si vše otestovat...
Tiskni
Sdílej: