Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.
Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.
Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.
Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.
MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
* - centrální db * - spravovaná postgresql databáze * - spravovaná OpenLDAP databáze postup změny hesla: 1. zamknu příslušné řádky v centrální databázi 2. změním jméno ve spravované postgresql db 3. selhání změny jména v OpenLDAP db, protože v té samé chvíli někdo založil uživatele se stejným jménem v této db proto: 4. pokusím se změnit jméno v postgresql databázi zpět, ale nastane problém, protože to staré jméno v tu samou chvíli zabere jiný (nový) uživatel ... v této chvíli mám naprosto nekonzistentní záznamy, protože nyní bude monitoring fungovat jen na databázi postgresql, ale ještě ke všemu nad úplně jiným uživatelem (ačkoliv počítám s tím, že pokud má uživatel ve všech db stejné jméno, jedná se o toho samého člověka, tak zde by měl třeba jiné uid či jiné údaje ...)... No snad jsem tu situaci popsal jasně. Nedokážu vymyslet způsob, jakým by uživ. jméno šlo bezpečně změnit (nedá se předpokládat, že všechny spravované databáze umí transakce apod. věci). Napadá vás prosím někoho řešení nebo bych se na to měl vykašlat a v případě potřeby měnit jména ručně v každé databázi zvlášť (nebo neměnit vůbec) a neriskovat nekonzistenci dat? Existují v dnešní době vůbec systémy, které neumožňují změnu uživatelského jména?
Uživatelská jména by se neměla měnitSpíš primární klíč by se neměl měnit. Otázka je, jestli používat uživatelské jméno jako PK. Ale uživatelská jména se docela mění – např. vdané ženy budou chtít nové jméno, prominentní uživatelé můžou chtít nějaké nestandardní, nebo když se jména generují automaticky a někomu tam vyjde nevhodná posloupnost písmen jako třeba „fuck“ tak se to pak taky mění. Ale zažil jsem i uživatele, který chtěl změnit číselné ID, protože se mu nelíbilo a chtěl jiné…
Váš případ nemá univerzální a spolehlivé řešení – klidně se může stát, že někdo založí uživatele v LDAPu a někdo jiný stejné jméno ale pro jiného uživatele v databázi, a máte z toho taky konflikt – a ani jste nemusel nic přejmenovávat.Stačí nadefinovat pravidlo, že všechny tyto změny je nutné nejprve autorizovat v LDAPu a na konci potvrdit. Potom ke kolizi nemůže dojít. Nikdo nesmí bez souhlasu LDAPu založit, přejmenovat nebo zrušit databázi.
To ale neznamená že nemůže nastat a že by se to nemělo ošetřit.Optimistická strategie, o které jsem hovořil, to ošetřuje, ale předpokládá, že se změna povede napoprvé, tudíž nepoužívá zámky. Viz např. http://en.wikipedia.org/wiki/Optimistic_concurrency_control
Uvědomil jsem si, že největší problém je výpadek aplikace během změn, kde některé zůstanou provedené, jiné ne.To lze řešit stejným způsobem. Napište si program, který ověří konzistenci všech databází a můžete ho pouštět třeba cronem nebo napojit na nagios/zabbix/... V případě nekonzistence můžete opravit buď ručně nebo jednoduché případy automatizovat. Ale je zase potřeba zvážit, kolik "oprav" za rok se bude dělat, jestli má nějaká jejich automatizace význam.
Tiskni
Sdílej: