Správa služeb hlavního města Prahy se potýká s následky kyberútoku. Hackerská skupina začala zveřejňovat na internetu některé z ukradených materiálů a vyzvala organizaci k vyjednávání. Ta zatím podrobnosti k případu sdělovat nechce. Případem se zabývá policie i Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB).
OCCT je oficiálně k dispozici na Linuxu (YouTube). Jedná se o proprietární software pro zátěžové testování a monitorování hardwaru.
Společnost OpenAI představila AI modely o3 a o4-mini (𝕏).
Canonical vydal Ubuntu 25.04 Plucky Puffin. Přehled novinek v poznámkách k vydání. Jedná se o průběžné vydání s podporou 9 měsíců, tj. do ledna 2026.
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.2.0. Přehled novinek v poznámkách k vydání.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 25.04. Přehled novinek i s náhledy a videi v oficiálním oznámení.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 152 (pdf) a Hello World 26 (pdf).
Zajímá vás Open Build Service (OBS) a vývoj linuxového jádra pro IBM Mainframe? V rámci Informatických večerů na FIT ČVUT v Praze proběhne v pondělí 28. dubna přednáška Linux on Z Development s podtitulem „From packaging in the openSUSE Build Service until Linux Kernel Development at IBM“. Přednáška proběhne v anglickém jazyce. Vstup je zdarma a bez předchozí registrace.
Vyšla nová verze XMPP (Jabber) klienta Dino. Mezi novinky patří vylepšený přenos souborů (XEP-0447: Stateless file sharing), přepracované dialogy a další. Vyzkoušet lze i na (linuxových) telefonech.
Vyšla nová verze XMPP (Jabber) klienta Gajim, která přidává podporu nového způsobu synchronizace informací o přečtení zpráv (XEP-0490: Message Displayed Synchronization jako nástupce XEP-0333: Displayed Markers), dále centrální stránku pro přehled všech aktivit (Activity feed) nebo vylepšení přepínání mezi více účty. Přehled dalších změn je k dispozici na oficiálních stránkách.
username | sql/email | ldap/kvota ----------------------------------------- usr1 | e@email.com | 500 usr2 | d@email.com | 500 usr3 | c@email.com | 500 usr4 | b@email.com | 500 usr5 | a@email.com | 500 Teď se rozhodnu seřadit je podle kvóty a pak podle emalu, tzn. ldap vrátí první 3, ty pak se ty tři seřadí jako c@..., d@..., e@... Správně by ale měl výpis vypadat takto: usr5 | a@email.com | 500 usr4 | b@email.com | 500 usr3 | c@email.com | 500Doufám v nějakou dobrou duši, která mi s tím pomůže
(-------PHP APLIKACE--------)--(centrální db v mysql) | | | (ftp/mysql) (mail/ldap) (*/*)...
(-------PHP APLIKACE--------)--(centrální db v mysql) || (-------Backend manager-----) | | | (ftp/mysql) (mail/ldap) (*/*)...A v centrální DB si kešuj všechny potřebné informace. Update centrální DB pak spouštěj buď periodicky nebo občas při dotazu či nejlépe ať si každá služba aktualizuje svá data sama (pár scriptů to obstará; = backend manager). Krom toho, že se ti výrazně zrychlí "PHP APLIKACE", tak si ušetříš starosti s přílišnou různorodostí služeb, resp. je vytlačíš stranou, kde nestraší.
Starost s nedostupností služeb bych viděl jako celkem podstatný argument pro kešování.I jako argument proti. Třeba služba ftp je nedostupná pro aplikaci php z důvodu částečného výpadku spojení, ale uživatelé ftp normálně používají a můžou si měnit hesla. PHP aplikace ale ftp službu nevidí a tak veškeré úpravy bude provádět lokálně. Ve chvíli kdy bude služba dostupná i pro php aplikaci nastane konflikt: aktualizovat cache podle služby nebo službu podle cache. Jinak to s těmi částečnými dotazy je výborný nápad, asi to udělám tak, děkuju.
PHP aplikace ale ftp službu nevidí a tak veškeré úpravy bude provádět lokálně.Cache bude z pohledu aplikace read-only, takže nic takového nemůže nastat. Úpravy se udělají normálaně přímo s danou službou, jakoby žádná cache nebyla. Uživatel dostane potvrzení o úspěšnosti přímo od služby. Je to takové kolečko, které se otočí s každou provedenou úpravou.
Tiskni
Sdílej: