Přímý přenos (YouTube) z konference LinuxDays 2026, jež probíhá tento víkend v Praze v prostorách FIT ČVUT. Na programu je spousta zajímavých přednášek.
Byla vydána nová verze 0.17.0 programovacího jazyka Zig (Codeberg, Wikipedie). Přispělo 206 vývojářů. Přehled novinek v poznámkách k vydání.
Open-source projekt OpenDLSS-NR je 'bitově přesná reimplementace' neuronové rendrovací sítě DLSS 5 od společnosti NVIDIA, jenže pro grafické API Vulkan (DLSS slouží k vylepšování klasickým způsobem vyrendrovaných snímků pomocí lokálních modelů umělé inteligence, a to v reálném čase). Projekt není nijak spojen se společností NVIDIA, je pouze pro OS Windows a natrénované váhy modelu si uživatelé musí obstarat sami. Zdrojový kód je k dispozici na GitHubu, pod licencí MIT s výjimkou pro komponenty třetích stran.
Společnost Cloudflare představila Clef a Clef-Flash, open-source rozhodovací modely určené pro rychlou a konzistentní klasifikaci vstupů. Na rozdíl od klasických LLM vracejí tyto modely deterministické striktně typované strukturované odpovědi s exaktními pravděpodobnostmi, tedy odpovědi ve stylu přelomového modelu Jev.
… více »Byla vydána beta verze Ubuntu 26.10 s kódovým názvem Stonking Stingray. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 26.10 mělo vyjít 15. října 2026.
Byla vydána verze 1.99.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Od 13. do 15. října proběhne v Praze OpenSSL Conference 2026. Na YouTube lze zhlédnout videozáznamy přednášek z loňského roku.
Eben Upton oznámil další zdražení jednodeskových počítačů Raspberry Pi. Tentokrát 2 GB varianty o 12,50 dolarů. Nově 2 GB Raspberry Pi 4 stojí 67,50 dolarů a 2 GB Raspberry Pi 5 stojí 77,50 dolarů.
OpenMandriva ROME, tj. průběžně aktualizovaná (rolling) edice linuxové distribuce OpenMandriva, byla vydána ve verzi 26.09. Vedle Flatpaku také s podporou Snapu.
Edison Design Group po více než 30 letech zveřejnil zdrojový kód svého EDG C/C++ front-endu. Ten proslul širokou podporou standardů C++ a kompatibilitou s dialekty kompilátorů od Microsoftu, GNU, Clangu, Sunu a dokonce i s prehistorickým cfrontem. EDG byl použit například v kompilátoru Intel C++ Classic, kompilátoru NVCC od firmy NVIDIA pro platformu CUDA nebo v našeptávači kódu IntelliSense v produktech společnosti Microsoft. Projekt nyní spravuje organizace The C++ Alliance a kód je dostupný pod licencí Apache 2.0, doplněnou o výjimky projektu LLVM.
Jsem zakladatelem tohoto portálu. Linux jsem používal spousty let, nějaký čas jsem se aktivně podílel na jeho propagaci v Česku (CZLUG, časopisy ComputerWorld, Network Magazine atd). Se současným Abíčkem už nemám nic společného.
Kuriozně teď oznamuji něco, co vlastně nefunguje. Ale třeba mi to pomůžete rozchodit
.
Na seznamu se mi líbi hledání ve slovníku. Zadám pár písmen a objeví se mi seznam možných výrazů. Vím, nápad pochází od google, ale ten to v praxi nepoužívá na svých hlavních stránkách. Chtěl jsem tedy napsat něco podobného.
Vytvořil jsem si tabulku se seznamem hledaných řetězců včetně počtu hledání a naplnil jsem ji z logů. Našel jsem knihovnu suggest, která za mně udělá JS hrátky. Napsal jsem si krátký servlet, který vrací data začínající stejným textem seřazená dle počtu hledání. Doma mi to funguje slušně (knihovna má pár chyb, například tlačítko za vstupním políčkem se posune na nový řádek nebo formulář nejde odeslat klávesou enter). To vše bych do beta provozu překousl, jenže na serveru to nejede. Každé hledání (i ascii textu) skončí chybou:
Illegal mix of collations (latin2_general_ci,IMPLICIT) and (utf8_ge
neral_ci,COERCIBLE) for operation 'like'
Doma mi to nedělá, jen pro utf znaky v souborech s latin2 kodování. Na serveru mi to lítá pokaždé. Už bych to rád vyřešil, podobný problém bývá občas i ve variantách softwaru pro znaky s diakritikou. Zkoumal jsem pochopitelně dokumentaci k MySQL, ale nevyznám se v tom. Nějak nepočítají s nožností, že neporovnávám dvě tabulky, ale tabulku s příkazem přes JDBC ovladač.
Update: dostal jsem odpověď od autora Suggest, že jej přestal podporovat. Takže teď se musím rozhodnout, že buď jej zkusím opravit sám (nesnáším JS), nebo budu hledat jinou knihovnu. Je to pech, ta knihovnička je sympaticky malá a jednoduchá, narozdíl třeba od Yahoo UI Library.
Tiskni
Sdílej:
MySQL se pokoušíš porovnat UTF-8 a Latin2 stringy. Jestli se nepletu, tak databáze Abíčka je v Latin2, ale v parametrech JDBC spojení je useUnicode=true, takže tam se řetězec pravděpodobně předává v UTF-8.
Problém bude zřejmě v tom, na jakém charset se server s JDBC ovladačem "dohodnou" - asi to není Latin2, ale UTF-8. Možná by pomohlo jako parametr JDBC URL nastavit characterEncoding=ISO8859_2.
jdbc:mysql://…/devel?characterEncoding=ISO8859_2&mysqlEncoding=latin2
SHOW VARIABLES; | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | latin2 | | character_set_results | latin1 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | | collation_connection | latin1_swedish_ci | | collation_database | latin2_bin | | collation_server | utf8_general_ci | SHOW CHARACTER SET;
Je třeba dát MySQL na vědomí, aby s vámi komunikovala v daném kódování. To vůbec nesouvisí s tím, v jakém kódování jsou data v databázi uložena. Asi nejsnazší je do /etc/mysql/my.cnf přidat něco jako
[client] default-character-encoding=latin2Jeden drobný háček zrovna tohoto řešení je: všechny klientské programy MySQL by měly načítat konfiguraci ze sekce
client (kromě toho samozřejmě i ze sekce určené jenom pro ně, třeba pro řádkového klienta mysql je to sekce mysql) a když najdou volbu, kterou neznají, považovat to za chybu. A takový mysqlbinlog si zrovna s default-character-encoding neporadí
Více třeba na http://dev.mysql.com/doc/refman/4.1/en/charset-connection.html.
set names latin2, ten dělá totéž. Pro aktuální spojení.
default-character-set=latin2…
Převod dat v MySQL je jen o exportu, přenastavení kódování v databázi a importu zpět. A to jak tabulky, tak data &bdash; vymažeš celou DB, nastavíš ji na UTF8 a při importu tohle nastavení všecko zdědí. Ve zbytku už by to neměl být problém. Ještě to chce vyházet veškeré zmínky o kódování v CREATE dotazech.
)