Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Existuje nějaký protokol/formát pro přírůstkové aktualizace relačních databází?
Dejme tomu, že mám nějaký veřejný registr a chci nabídnout přírůstkové aktualizace – aby si lidé nemusely stahovat pokaždé všechno znova.
Teoreticky by jim šlo dát SQL skript, který bude obsahovat INSERTy, UPDATy a DELETy, ale to je jednak takové dost volné (klient musí dost věřit serveru, aby si spustil jeho SQL skript) a jednak je to platformě závislé (dialekt konkrétního DBMS a vlastně i závislost na relačním schématu jako takovém – teoreticky si klient může ukládat data jinak a SQL třeba vůbec nepoužívá – chce jen platformě nezávislý seznam změn záznamů).
(k otázce mě inspiroval zápisek v blogu: Klient-server synchronizace – konečné řešení)
S tou bezpečností máš asi pravdu, možná je to zbytečná paranoia… jen je mi trochu proti srsti, aby někdo do mého systému cpal rovnou SQL. Ale ono stačí, když mu necháš třeba přístup k information_schema
a on ti tam pustí SELECT s kartézským součinem přes několik tabulek.
Jde mi o formát/protokol, který by byl vhodný i pro to veřejné nasazení a umožňoval jen to nutné minimum – přidávat záznamy, aktualizovat a mazat. A ve „WHERE“ podmínce by mohl být jen primární klíč, ne nějaké vnořené SELECTy atd., stejně tak ve „VALUES“ – tam by taky měly být jen prosté hodnoty.
Na druhou stranu, čím mocnější ten nástroj bude, tím efektivnější/stručnější inkrementy se dají napsat – např.
UPDATE tabulka SET sloupec_1 = sloupec_2 + 100 WHERE id IN (SELECT …)
Místo aby se vyjmenovával záznam po záznamu a jejich hodnoty… ale zase o to víc se to dá zneužít. A o to méně je to platformě nezávislé – když už to bude SQL, tak na straně klienta potřebuji minimálně nějaký parser SQL, abych si z toho vytahal ty hodnoty a aktualizoval si svoji lokální databázi (která třeba ani nemusí být relační).
Určitě by to měl být otevřený software nebo alespoň otevřený standard – jde o to, aby na straně příjmu těch dat mohl být kdokoli – veřejnost – a aby si to mohl napasovat na nějaké svoje řešení. Co nejjednodušší – tzn. během dne si přečtu specifikaci a napíšu parser, nebo použiji hotovou knihovnu a už můžu přijímat aktualizace dat.
Na straně zdroje ani není potřeba nějak duplikovat data do logů – klidně může být u každého záznamu číslo verze – rostoucí ID napříč celou databází – a klient si pak vyžádá všechny záznamy novější než určité ID (tzn. než určitý časový okamžik).
Není to žádná velká věda. On by to mohl být i třeba CSV soubor (soubory) nebo nějaký jednoduchý binární formát. Jen mi šlo o to, zda nevymýšlím něco, co už tu dávno je.
Ono hlavně ta druhá strana si bude chtít aktualizovat svoji databázi – tzn. udělat změny, ne všechno smazat a všechno znova nahrát. Takže ono to sice vypadá skvěle, že se použije Git jako hotový software, ale samo o sobě to nestačí, protože on dejme tomu zajistí přenos těch změn po síti, ale pak si stejně musím udělat diff a z něj pomocí nějakého nástroje (ten je potřeba napsat) zjistit, do jaké tabulky mají změny přijít, zda se má přidávat, mazat, aktualizovat, a když, tak co tzn. vydolovat z toho primární klíče, abychom věděli, co smazat/aktualizovat a vyrobit výsledné SQL (případně jiné příkazy). To je ten nejpracnější úkol a verzovací systém s ním nepomůže, leda ho může ještě zkomplikovat.
Tiskni Sdílej: