Byla vydána verze 4.2 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Anton Carniaux, právní zástupce Microsoft France, pod přísahou: Microsoft nemůže garantovat, že data z EU nepředá do USA bez EU souhlasu, musí dodržovat americké zákony.
Byl vydán Mozilla Firefox 141.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Lokální AI umí uspořádat podobné panely do skupin. Firefox na Linuxu využívá méně paměti. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 141 je již k dispozici také na Flathubu a Snapcraftu.
NÚKIB upozorňuje na kritickou zranitelnost v SharePointu. Jedná se o kritickou zranitelnost typu RCE (remote code execution) – CVE-2025-53770, která umožňuje neautentizovaný vzdálený přístup a spuštění kódu, což může vést k úplnému převzetí kontroly nad serverem. Zranitelné verze jsou pouze on-premise verze a to konkrétně SharePoint Server 2016, 2019 a Subscription Edition. SharePoint Online (Microsoft 365) není touto zranitelností ohrožen.
Společnost Valve zpřísnila pravidla pro obsah, který je možné distribuovat ve službě Steam. Současně řadu her ze Steamu odstranila. V zásadách a pravidlech přibylo omezení 15: Obsah, který by mohl porušovat pravidla a normy stanovené zpracovateli plateb a souvisejícími sítěmi platebních karet a bankami nebo poskytovateli připojení k internetu. Sem spadají zejména určité druhy obsahu pouze pro dospělé.
Dle analytics.usa.gov je za posledních 90 dnů 6,2 % přístupů k webových stránkám a aplikacím federální vlády Spojených států z Linuxu.
Jak si zobrazit pomocí Chrome a na Chromiu založených webových prohlížečích stránky s neplatným certifikátem? Stačí napsat thisisunsafe.
V repozitáři AUR (Arch User Repository) linuxové distribuce Arch Linux byly nalezeny a odstraněny tři balíčky s malwarem. Jedná se o librewolf-fix-bin, firefox-patch-bin a zen-browser-patched-bin.
Dle plánu by Debian 13 s kódovým názvem Trixie měl vyjít v sobotu 9. srpna.
Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
Mám na netu jednu PHP webovou aplikaci, která má dlouhodobě problémy s rychlostí pravděpodobně kvůli ne ideálně udělané databázi a SQL dotazů na ni. Často jede rychle, často se ale taky stává, že se na půl minuty zasekne.
Z logů slow_query. Velké množství dotazů, které překročil čas 5 vteřin vykonování (často i přes 30s) byl mezi jinými jednoduchý update. Konkrétně dotazy typu
UPDATE statistika SET doba_online = doba_online + '7' WHERE jmeno = 'Leinad'
Tabulka "statistika" má kromě pár dalších sloupců sloupce "jmeno", který je VARCHAR a index a "doba_online", který je TIME. Tato tabulka slouží pro logování, jaký čas daný uživatel strávil na webu, takže dotaz se provádí každým kliknutím uživatele. TAbulka je InnoDB a má cca 300 řádků.
Zkusil jsem přehodit tabulku na engine MyISAM a už se tyto dotazy v logách slow_query neobjevují. Mám podezření, že InnoDB má vyšší režii na disk. Jedu na virtuálním serveru a když jsem se chvíli koukal na "top", tak jsem viděl často vyskočit hodnotu %wa až na 100%.
Je možné, že InnoDB má až tak moc velkou režii proti MyISAM? Četl jsem, že má vyšší (kvůli transakcím), ale nedovedl jsem si nikdy představit, že by to takhle mohlo zlikvidovat výkon... Nemáte nějaký tip, co s tím?
(Rada dát všechny tabulky na MyISAM znemožní použití transakcí u dotazů, kde se to hodí. Rada dát část tabulek do MyISAM a zbytek nechat na InnoDB by asi pomohla zvýšit rychlost, ovšem zbývající dotazy typu UPDATE a INSERT budou stále dělat problémy, jen jich bude méně...)
MySQL verze "5.0.32-Debian_7etch3-log".
Pozn.: Očekávám kritiku návrhu tabulky, kdy není ideální použití pro index tabulky typu VARCHAR. Vím to, ale nemyslím si, že má cenu se pouštět do opravy, když to můj problém stejně nevyřeší.
Nevyužívá se cache databáze při dotazech typu SELECT, nikoliv UPDATE?
Zamykání by tam být u tohoto dotazu nemělo. Ta "statistika" je hlavně UPDATEována přihlášeným člověkem, málokdy jiným uživatelem. Tj. nemělo by tam být žádné čekání na zámek. V logu slow_query se psalo navíc u těch dotazů "Lock_time: 0", jen parametr "Query_time:" je vysoký...
Tak problém zdá se vyřešen. Zvýšení innodb_buffer_pool_size. Byl nastaven standardně na 8MB. Databázi jsem měl (hlavně asi díky fórám a logováním) velkou 30MB, takže velké tabulky s fórem zdá se vyhazovaly tabulky jako "statistika", do které se každým klikem uživatele zapisovalo. A přepnutí na MyISAM fungovalo zdá se proto, že má možná vlastní jiný parametr cache (ehm, jen domněnka).
Díky tedy za rady a omlouvám se, že jsem si dostatečně neprohledal web předem. Resp. googlil jsem před podáním dotazu tady na fóru a našel jsem, že cache ovlivňuje rychlost DB, ale našel jsem jen články o cache využívanou při dotazech typu SELECT, narazil jsem na rady ohledně indexů, atd., ale to že tam je ještě další cache pro celé tabulky jsem zjistil bohužel až teď. No, tak snad tato diskuse pomůže v budoucnu někomu dalšímu, kdo se s tímto problémem setká.
Jinak, ten článek, co mi pomohl, byl na adrese <a href="http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/</a>
Tiskni
Sdílej: