Branch Privilege Injection (CVE-2024-45332, Paper) je nejnovější bezpečnostní problém procesorů Intel. Intel jej řeší ve včerejším opravném vydání 20250512 mikrokódů pro své procesory. Neprivilegovaný uživatel si například může přečíst /etc/shadow (YouTube).
Dle plánu byl vývoj Firefoxu přesunut z Mercurialu na Git. Oficiální repozitář se zdrojovými kódy je na GitHubu.
V terminálovém multiplexoru GNU Screen byly nalezeny a v upstreamu ve verzi 5.0.1 už opraveny bezpečnostních chyby CVE-2025-23395, CVE-2025-46802, CVE-2025-46803, CVE-2025-46804 a CVE-2025-46805. Podrobnosti na blogu SUSE Security Teamu.
Training Solo (Paper, GitHub) je nejnovější bezpečnostní problém procesorů Intel s eIBRS a některých procesorů ARM. Intel vydal opravnou verzi 20250512 mikrokódů pro své procesory.
Byla vydána nová verze 25.05.11 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Svobodný elektronický platební systém GNU Taler (Wikipedie, cgit) byl vydán ve verzi 1.0. GNU Taler chrání soukromí plátců a zároveň zajišťuje, aby byl příjem viditelný pro úřady. S vydáním verze 1.0 byl systém spuštěn ve Švýcarsku.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Chtěl bych se zeptat na vliv úspořádání indexů.
Mám tabulku (2,2 mil záznamů) kde jsou sloupce kraj, orp, obec (INT) pomocí kterých se třídí jakési hlavní vypisování při procházení strukturou. Umístil jsem nad tyto sloupce indexy, čím se výrazně zrychlilo vypisování s ohledem na počet záznamů - úroveň kraj to samozřejmě prohledává nejdéle.
Můj dotaz však směřuje k tomu jestli je výhodnější a rychlejší když přidám index s názve radit nad sloupce kraj, orp, obec nebo když udělám tři indexy. Samostatně každý index na každý z těchto sloupců zvlášť.
CREATE TABLE
, ktorym je tabulka vytvorena a hlavne nam ukaz presny prikaz SELECT
, ktory sa snazis optimalizovat.
pripada mi to plus minus dost stejne..
SELECT nazev, ulice, obec, psc, orp FROM table WHERE kraj=3 // prvni uroven
SELECT nazev, ulice, obec, psc, orp FROM table WHERE kraj=3 AND orp=58 // druha uroven
SELECT nazev, ulice, obec, psc, orp FROM table WHERE kraj=3 AND orp=58 AND obec=6168 // treti uroven
druha a treti jsou bleskove.. v te prvni je výsledkem dotazu více jak 100 tisíc záznamů až 400 tisíc.
CREATE TABLE `firmy_zaklad` ( `ico` int(8) unsigned zerofill NOT NULL, `heslo` varchar(255) collate utf8_czech_ci NOT NULL, `nazev` varchar(255) collate utf8_czech_ci NOT NULL, `obor` int(11) NOT NULL, `kraj` int(11) NOT NULL, `orp` int(11) NOT NULL, `obec` int(11) NOT NULL, `castobce` varchar(40) collate utf8_czech_ci NOT NULL, `ulice` varchar(255) collate utf8_czech_ci NOT NULL, `psc` int(11) NOT NULL, PRIMARY KEY (`ico`), KEY `kraj` (`kraj`), KEY `orp` (`orp`), KEY `obec` (`obec`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;
sorry je tam jeste ORDER BY nazev LIMIT 0,30
vzdy je žádán jen jeden select podle toho v jake je to urovni, napred jdes do urovne kraj, vola se prvni select pak vyberes kliknutim ORP a vola si jiny select a pak ten treti..
ten dotaz je stejně dlouhý když ho spustím ve finalni aplikaci i když ho spustím v phpmyadminu, ale to je asi totéž., takže nevím jak bych měl poznat jestli je pomalý již při tom selektování
je tam jeste ORDER BY nazev LIMIT 0,30A to sa Ti zda ako nepodstatny detail? Ten prvy select trva dlho, lebo je potrebne tu hromadu zaznamov zotriedit. Pre prvy select odporucam index(kraj,nazev): podla polozky kraj sa bude vyhladavat, a vsetky najdene polozky budu v indexe usporiadane podla nazvu. Takze databaze staci, ze podla prvej urovne indexu najde spravny kraj a potom preiteruje cez vsetky najdene polozky, pretoze vie, ze ich ma zoradene podla nazvu, kedze su podla nazvu indexovane. Ak teda MySQL ma dostatok inteligencie na taketo pouzitie indexu; ale skor typujem ze ano.
Tiskni
Sdílej: