Open source download manager Fatrat povstal z popela. Autor k dvacetiletému výročí projektu přidal do vínku podporu nejnovější knihovny libtorrent, rozhraní portoval na QT6, došlo k nahrazení podpory java rozšíření pythonem. Webové rozhraní bylo přepsáno s podporou mobilních zařízení. Aplikaci je taktéž možno zkompilovat bez podpory GUI. Více informací v releases.
Zranitelnost Broccoli2Shell (CVE-2026-111497) v kompresní knihovně Brotli se netýká pouze Node.js. Ohroženy jsou také aplikace využívající HTTP. Knihovnu používají webové prohlížeče, servery i řada dalších aplikací a technologií, například také Python nebo Bun. Identifikace všech zranitelných komponent může být obtížná, protože knihovna bývá součástí dalších softwarových balíčků nebo je přímo začleněna do spustitelných souborů aplikací.
Quad9, švýcarský celosvětově působící neziskový poskytovatel DNS, od 24. listopadu 2026 ukončí své služby ve Francii kvůli soudnímu sporu s katarskou televizní stanicí beIN. Ta požadovala blokování domén, které podle ní nelegálně zpřístupňují sportovní přenosy. Francouzský soud Katarům vyhověl a nařídil (🇫🇷, PDF) Quad9 blokaci zavést, pod hrozbou pokuty 1000 eur denně. Provozovatel příkaz odmítá s tím, že blokace
… více »Článek na blogu APNIC vysvětluje, jak správně vytvářet a používat ASPA záznamy — podepsané objekty v RPKI, které uvádějí, kteří poskytovatelé směrování jsou pro dané autonomní číslo (ASN) oprávněni. Síťoví operátoři je mohou využít k ověřování tras BGP a k odhalování úniků tras či podvržených tras.
Byla vydána (𝕏) verze 8.0.0 open source programu pro prolamování hesel hashcat (GitHub, Wikipedie). Přehled novinek v příspěvku v diskusním fóru a pdf.
Byla vydána (𝕏, Bluesky) nová verze 2026.3 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem 6 nových nástrojů v oficiálním oznámení na blogu.
Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ALTER TABLE Collections
ADD SV5_raw mediumint(5) unsigned AFTER DiskID,
ADD SV197_raw mediumint(5) unsigned AFTER SV5_raw,
ADD SV198_raw mediumint(5) unsigned AFTER SV197_raw,
ADD SV9_raw int(6) unsigned AFTER SV198_raw,
ADD SV9_val int(4) unsigned AFTER SV9_raw;
UPDATE Collections
SET
SV5_raw=( SELECT Raw FROM SmartValues WHERE Col_ID=Collections.ID AND SmartID = 5),
SV197_raw=( SELECT Raw FROM SmartValues WHERE Col_ID=Collections.ID AND SmartID = 197),
SV198_raw=( SELECT Raw FROM SmartValues WHERE Col_ID=Collections.ID AND SmartID = 198),
SV9_raw=( SELECT CAST( Raw AS INTEGER ) FROM SmartValues WHERE Col_ID=Collections.ID AND SmartID = 9),
SV9_val=( SELECT Value FROM SmartValues WHERE Col_ID=Collections.ID AND SmartID = 9SELECT ID, Raw, CAST( Raw AS INTEGER ) AS RawINT, `Value` FROM `SmartValues` WHERE `SmartID`=9 ORDER BY `SmartValues`.`Raw` ASC 2021 3381h+07m+45.900s 3381 97 2039 3381h+08m+03.770s 3381 97 2057 3381h+08m+27.660s 3381 97 65467 3382 3382 97Tady žádný problém, CAST se provede bez potíží. Takže CASTem to nebude ... ale pak čím ? Prohledal jsem tabulku, a nikde jinde kromě těch tří řádků se 3381h nevyskytuje... Takže fakt nevím v čem je problém. pokud někdo z vás má představu, budu rád za popostrčení. Předem díky Milan
Řešení dotazu:
Za prvé, u takovýchto dotazů je vhodné uvádět struktury jednotlivých tabulek.To dal. To ALTER TABLE.
Vůbec mi není jasné, o co se tam vlastně snažíte – ten text je evidentně nějaké textové vyjádření času.Cas asi uklada ako int cislo vyjadrujudruce pocet sekund od "zaciatku".
To dal. To ALTER TABLE.Dal alter table
Collections, ale problém je se selectem ze SmartValues.
Cas asi uklada ako int cislo vyjadrujudruce pocet sekund od "zaciatku".Právě že kdybychom měli strukturu tabulek, nemusíme se dohadovat, jaké typy tam asi jsou. Jinak text „3381h+07m+45.900s“ opravdu jako „int číslo“ nevypadá.
function cas_zo_stringu($text)
{
$casti=explode('+', $text);
$ret_cas=0;
foreach($casti as $c)
{
$cas=substr($c, 0, -1);
$hodnota=substr($c, -1);
switch ($hodnota)
{
case 'h':
$ret_cas+=$cas*3600;
break;
case 'm':
$ret_cas+=$cas*60;
break;
case 's':
$ret_cas+=$cas;
break;
default:
echo "neznamy cas\n";
break;
}
}
return $ret_cas;
}
echo cas_zo_stringu('3381h+07m+45.900s');
ale tady jde o ten princip, abych pochopil co je špatně, když se mi to zdá ok. M.Špatně je to, že se pokoušíte převést na číslo text, který rozhodně žádné číslo nereprezentuje. A také to, že se vám to zdá OK.
Nevím, co řešíte. Collections jste viděli, jak vypadá, raw z SMARTD je varchar.Přičemž jak vypadá
Collections je úplně jedno, podstatné je právě to smartd.raw.
Převést "3381h..." na integer ( počet naběhaných hodin ) JE MOŹNÉ, JAK UKAZUJE DRUHÝ DOTAZ, který korektně převede ten údaj ze SMARTu tak, že jakmile skončí číslice, přestane to řešit, a z číslic vytvoří číslo.Ne, nepřevede to korektně, převede to nějak. Takhle funguje MySQL – bez ohledu na to, jak velké dělá programátor chyby, snaží se vždy to nějak zpracovat. Pak přijdou trochu jiná data, než jaká testoval programátor, ty implicitní konverze budou dělat něco jiného, než by si uživatel představoval, a všichni se budou akorát divit, co se to děje. Třeba vám tam jednou nějaký disk pošle
140d 1h 23m 15.0023s a vy budete mít radost, že ten disk naběhal jenom 140 hodin.
Pokud to chcete dělat správně, ten vstup zpracujte už v tom PHP a do databáze si vedle té surové hodnoty uložte i zpracovaný údaj jako číslo. Pokud to chcete co nejvíc naprasit a nezajímá vás, že to nebude fungovat, řešte si to sám.
SELECT UNIX_TIMESTAMP(ADDTIME('1970-01-01 00:00:00', TRIM(TRAILING ':' FROM REGEXP_REPLACE("3381h+08m+27.660s", '[^0-9.]+', ':'))))
ale narazí se na jiný problém a to je max velikost TIME, která je 838:59:59 což je cca 840 hodin, takže opravdu nezbývá než napsat nějakou funkci, která to rozseká a udělá aritmetiku za vás (viz výše).
max velikost TIME, která je 838:59:59 což je cca 840 hodinA čo presnosť a rozsah DATETIME. nestačilo by ak nechce mať číselnú hodnotu interne rátanú v (mili)sekundách tak ako to ráta zdrojový HW?
no a tady problém způsobuje podivné chování toho CASTu, kdy při SELECTu hodí warnings, ale při UPDATE a INSERT errorNa to jste přišel jak? MySQL se sice ve spoustě případů chová divně (např. už jenom tím, že převádí na číslo texty, které obsahují něco jiného, než číslice, a jenom vypíše varování), ale jsem přesvědčen na 99 %, že se ten
CAST nechová různě při SELECTu a při UPDATE/INSERT.
Jak už jsem psal dříve, pokud vám data chodí v různých formátech, dokonce ve formátech, které předem neznáte, zpracovávat ty formáty až v databázi, navíc v MySQL, mi připadá jako velmi divoký nápad. Ale pokud si to děláte jen pro sebe a je vám jedno, že vám to nebude fungovat, je to vaše věc.
ale nyní mně fakt zajímá ten CASTA co vás na tom
CASTu zajímá? CAST převede vstup na jiný datový typ, pravidla jsou popsaná v manuálu, sám jste je tu citoval.
Pokud chcete řešit problém, budete muset problém nejprve popsat. Vy jste zatím napsal jenom svůj názor na řešení. Nevíme jak jste přišel na to, že by CAST mohl způsobovat problém, pořád nevíme strukturu té tabulky; nevíme, jak vypadají data, na kterých to pouštíte; nevíme, jaký je vámi očekávaný výsledek ani jaký je skutečný výsledek. Nevíme nic. Píšete, že dotaz vrátí false a sloupečky se neaktualizují. V příspěvku ale žádný dotaz není, je tam update. Navíc dotaz nic neaktualizuje, vy píšete, že očekáváte aktualizaci sloupečků. Takže asi myslíte ten update. Jenže update zase nevrací logickou hodnotu, vrací počet aktualizovaných záznamů. Prostě nevíme nic.
Takže pokud chcete opravdu poradit, nevymýšlejte, v čem by asi mohl být problém. Místo spekulací napište informace, které máte a které je snadné zjistit. Struktury tabulek (nejlepší je dát sem create table od obou tabulek). Asi máte jeden konkrétní záznam, který se podle vás chová špatně – tak sem dejte select s výpisem toho záznamu v tabulce, kterou chcete aktualizovat, a selecty příslušných záznamů z toho updatu. Možná už při tomhle dávání informací dohromady zjistíte, že vám ten select vlastně nic nenajde… No a pak sem dejte výstup toho příkazu update. Sice to asi bude „0 rows updated“ nebo jako to vypisuje MySQL konzole, ale aspoň uvidíme, že to je opravdu výstup toho příkazu a ne nějaká vaše interpretace.
Tiskni
Sdílej:
