Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
* - 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: