Přesně před 34 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
86Box, tj. emulátor retro počítačů založených na x86, byl vydán ve verzi 5.0. S integrovaným správcem VM. Na GitHubu jsou vedle zdrojových kódů ke stažení také připravené balíčky ve formátu AppImage.
Vláda Spojených států získala desetiprocentní podíl v americkém výrobci čipů Intel. Oznámili to podle agentur americký prezident Donald Trump a ministr obchodu Howard Lutnick. Společnost Intel uvedla, že výměnou za desetiprocentní podíl obdrží státní dotace v hodnotě 8,9 miliardy dolarů (zhruba 186 miliard Kč). Částka podle Intelu zahrnuje dříve přislíbené subvence 5,7 miliardy dolarů z programu CHIPS na podporu výroby čipů v USA,
… více »Organizace Apache Software Foundation (ASF) vydala verzi 27 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2024 (pdf). V loňském roce NÚKIB evidoval dosud nejvíce kybernetických bezpečnostních incidentů s celkovým počtem 268. Oproti roku 2023 se však jedná pouze o drobný nárůst a závažnost dopadů evidovaných incidentů klesá již třetím rokem v řadě. V minulém roce NÚKIB evidoval pouze jeden velmi významný incident a významných incidentů bylo zaznamenáno 18, což oproti roku 2023 představuje pokles o více než polovinu.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované obrázky APNG a WebP.
Na chytré telefony a počítačové tablety v Rusku bude od začátku příštího měsíce povinné předinstalovávat státem podporovanou komunikační aplikaci MAX, která konkuruje aplikaci WhatsApp americké společnosti Meta Platforms. Oznámila to dnes ruská vláda. Ta by podle kritiků mohla aplikaci MAX používat ke sledování uživatelů. Ruská státní média obvinění ze špehování pomocí aplikace MAX popírají. Tvrdí, že MAX má méně oprávnění k přístupu k údajům o uživatelích než konkurenční aplikace WhatsApp a Telegram.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu srpnový souhrn novinek. Kvůli nedostatečnému zájmu byla ukončena výroba telefonů PinePhone Pro.
Po pěti měsících vývoje byla vydána nová verze 0.15.1 programovacího jazyka Zig (GitHub, Wikipedie). Verze 0.15.0 byla přeskočena. Přispělo 162 vývojářů. Přehled novinek v poznámkách k vydání.
Řešení dotazu:
aby ta data konzistentni byla, je treba bezicim aplikacim sdelit, ze se neco bude ditOpäť malá technická otázka: existuje na Linuxe na to nejaký systémový mechanizmus? Môže napr. moja aplikácia reagovať na to, že sa chystá urobiť "btrfs snapshot ..." ?
Pokud nějaká appka během pořízení snapshotu zapisuje na disk, tak pokud to dělá dobře, tak její data budou plně validní.Um, čo konkrétne znamená to "dělá dobře"?
// konzistentní T1 // nekonzistení T2 // konzistentníPro dva klienty:
C1T1 C2T1 -- klient 2 vidí nekonzistentní stav dat C1T2 C2T2 -- klient 2 ukládá data vyrobená na základě nekonzistentních dat.Tedy pokud je program napsaný takto a používá transakce blbě, tak to zhavaruje už během zcela normálního provozu a nemá to se snapshoty nic společného. A to jsem ten příklad schválně uvedl serializovaně, pokud by někdo namítal, že program může povolovat pouze jeden přístup v jeden čas. Ani Serializable nezajistí konzistenci dat, pokud appka transakce používá blbě.
Databaze si zapise ... rekneme polozky nejakyho dokladu ... v tenhle okamzik udelas snap ... a mas nekonzistentni data, protoze ti chybi hlavicka. Presne proto to nemuze fungovat. Viz muj post vejs.DB splňující ACID bude konzistentní, transakce jsou atomické. Buď se zapíší kompletně celé, nebo se nezapíší vůbec.
A presne proto ma kazda svepravna databaze API, pres ktery ji sdelis ze ten snap (nebo jinej zpusob zalohy) des delat, pockas, az ti rekne ze OK (= dokoncila vsechny bezici transakce) a teprve pak muzes.Atomický snap a "jiný způsob zálohy" je dost velký rozdíl. U jiného způsobu zálohy se počítá s tím, že různé soubory budou zkopírovány v různém čase a je tedy nutné uvést DB do stavu, kdy do datových souborů nezapisuje, ale jen plní logy. Viz třeba PITR. Jenže toto u atomického snapshotu neplatí, tam jsou všechny souboru zmrazeny ve stejném čase, takže DB ví, které transakce jsou dokončeny.
Uplne stejne to plati pochopitelne pro libovolnou jinou aplikaci, kdyz budes mit cojavim otevrenej nejakej textovej soubor, tak se s klidem muzes dostat do situace, kdy ty sice vidis dokonceny odstavec, ale aplikace ho zapsala jen 1/2, druha ceka na nejaky ten interval, a kdyz udelas snap, tak sice mas citelny soubor, ale chybi ti v nem data.Tak si ještě jednou přečti komentář, na který reaguješ. Existují a používají se atomické fs operace, takže slušně napsaný program nepřepisuje data na místě (a pokud ano, udělá si kopii původního), ale zapisuje někam jinam a potom to atomicky (třeba pomocí přejmenování), překlopí. Pro systémové služby by toto mělo být automatické. Pro uživatelské programy se mohou najít výjimky, ale tam asi nebude nikdo dělat snap během ukládání 2GB souboru v GIMPu a nebude asi očekávat, že ten soubor bude konzistentní.
Ze tys vzivote nikdy nikde zadnou databazi neprovozoval, natoz aby sis precet nejakou dokumentaci k ni?Kromě těch pár desítek DB o celkovém objemu dneska už skoro 10TB, ne, nic jsem neprovozoval. A už vůbec jsem nikdy nikomu neradil dávat všechna data do DB (ideálně jako BYTEA) a nemít to jako soubor na disku. Ne, vůbec. Jen těch pár TB, pouhých 12 let, ale jinak vůbec nic.
V pripade databazi pak v kazdym pripade dojde k nejaky ztrate dat.Nedojde. Všechny potvrzené transakce jsou spolehlivě uloženy na disku. Od toho je to ACID DB, aby právě tohle zajistila.
No, záleží na tom, jaký bude v tom snapshotu momentální stav (například) konfiguračních souborů běžících aplikací, které třeba zrovna své soubory zapsaly jen tak z poloviny. Pokud to z té poloviny rozchodí, jistě budou fungovat. Pokus nabootovat ze snapshotu je (jak píšeš) podobný bootu po odpojení natvrdo, jen s mírně lepšími garancemi kolem (vzájemné) konzistentnosti dat / souborů na celém subvolume.
Ad snapshot před startem systému: Asi by bylo nejlepší udělat si na to systemd unit spouštěný v initramfs. Systemd v initramfs by mohl takový snapshot vytvořit bez jakýchkoliv dalších operací nad filesystémem. GRUB to podle mě neumí; do většiny FS (záměrně) nedovede psát.
Nicméně i k vytvoření snapshotu během initramfs ten souborový systém musíš napřed namountovat read/write, takže implicitní read-only nastavení ve většině distribucí se nebude dát úplně snadno a přímo použít.
Pokud by read/write na konci initramfs vadil, tak potom snad leda že by ten initramfs napřed namountoval nový root read/write, pak by udělal snapshot a ve finále by ho přemountoval zase read-only, ať už si to dál pořeší systemd ve standardním systému podle fstab. Ale otázka je, proč takový přemet dělat.
Tiskni
Sdílej: