Apple představil nový iPad mini, iMac s čipem M6, 14palcový MacBook Pro s čipem M6 a MacBook Pro s PROLED XDR displejem – první Mac s dotykovým ovládáním.
Nedávno představený projekt mapSTL.com řeší budoucnost. 𝕏: "Netušil jsem, kolik patentů na generování map existuje. Existují patenty na generování fantasy map 🫣. Cokoliv je na 3D tiskárnu a tvoří to produkt, bude to mít patenty. Tak bacha na to!" … více »
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.4 (𝕏). Přehled novinek a vylepšení v poznámkách k vydání.
Byla objevena zranitelnost Tailworm v Tailscale a Headscale umožňující lokální eskalaci práv přihlášeného uživatele. Následně byla v Tailscale v opravené verzi 1.104.4+ změněna architektura aplikace. Viz příspěvek na blogu Tailscale.
Byl vydán Mozilla Firefox 159.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 159 bude brzy k dispozici také na Flathubu a Snapcraftu.
Nasazení softwaru, který nyní používá ve svých autech pro čínský trh, zvažuje automobilový koncern Volkswagen také v Evropě, kde by se mohl používat v budoucích vozech značek Volkswagen, Škoda a Cupra. Základem pro budoucí evropské modely by se mohla stát takzvaná China Electronic Architecture, elektronická architektura vyvinutá pro čínské modely ve spolupráci s tamní automobilkou Xpeng.
Vedoucím brněnské pobočky Red Hatu se stal Radek Vokál [LinkedIn].
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 »
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.
)