Byla vydána nová verze 1.16.0 klienta a serveru VNC (Virtual Network Computing) s názvem TigerVNC (Wikipedie). Z novinek lze vypíchnout nový server w0vncserver pro sdílení Wayland desktopu. Zdrojové kódy jsou k dispozici na GitHubu. Binárky na SourceForge. TigerVNC je fork TightVNC.
Byla vydána nová verze 4.6 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Rozsáhlá modernizace hardwarové infrastruktury Základních registrů měla zabránit výpadkům digitálních služeb státu. Dnešnímu výpadku nezabránila.
Čínský startup Kimi představil open-source model umělé inteligence Kimi K2.5. Nová verze pracuje s textem i obrázky a poskytuje 'paradigma samosměřovaného roje agentů' pro rychlejší vykonávání úkolů. Kimi zdůrazňuje vylepšenou schopnost modelu vytvářet zdrojové kódy přímo z přirozeného jazyka. Natrénovaný model je dostupný na Hugging Face, trénovací skripty však ne. Model má 1 T (bilion) parametrů, 32 B (miliard) aktivních.
V Raspberry Pi OS lze nově snadno povolit USB Gadget Mode a díky balíčku rpi-usb-gadget (CDC-ECM/RNDIS) mít možnost se k Raspberry Pi připojovat přes USB kabel bez nutnosti konfigurování Wi-Fi nebo Ethernetu. K podporovaným Raspberry Pi připojeným do USB portu podporujícího OTG.
Konference Installfest 2026 proběhne o víkendu 28. a 29. března v budově FELu na Karlově náměstí v Praze. Přihlásit přednášku nebo workshop týkající se Linuxu, otevřených technologií, sítí, bezpečnosti, vývoje, programování a podobně lze do 18. února 0:15.
Fedora Flock 2026, tj. konference pro přispěvatele a příznivce Fedory, bude opět v Praze. Proběhne od 14. do 16. června. Na Flock navazuje DevConf.CZ 2026, který se uskuteční 18. a 19. června v Brně. Organizátoři konferencí hledají přednášející, vyhlásili Call for Proposals (CfP).
Z80-μLM je jazykový model 'konverzační umělé inteligence' optimalizovaný pro běh na 8-bitovém 4Mhz procesoru Z80 s 64kB RAM, technologii z roku 1976. Model používá 2-bitovou kvantizaci a trigramové hashování do 128 položek, což umožňuje zpracování textu i při velmi omezené paměti. Natrénovaný model se vejde do binárního souboru velkého pouhých 40 KB. Tento jazykový model patrně neprojde Turingovým testem 😅.
Digitální a informační agentura (DIA) na přelomu roku dokončila rozsáhlou modernizaci hardwarové infrastruktury základních registrů. Projekt za 236 milionů korun by měl zabránit výpadkům digitálních služeb státu, tak jako při loňských parlamentních volbách. Základní registry, tedy Registr práv a povinností (RPP), Informační systém základních registrů (ISZR) a Registr obyvatel (ROB), jsou jedním z pilířů veřejné správy. Denně
… více »Evropská komise (EK) zahájila nové vyšetřování americké internetové platformy 𝕏 miliardáře Elona Muska, a to podle unijního nařízení o digitálních službách (DSA). Vyšetřování souvisí se skandálem, kdy chatbot s umělou inteligencí (AI) Grok na žádost uživatelů na síti 𝕏 generoval sexualizované fotografie žen a dětí. Komise o tom dnes informovala ve svém sdělení. Americký podnik je podezřelý, že řádně neposoudil a nezmírnil rizika spojená se zavedením své umělé inteligence na on-line platformě.
19.9.2005 20:05
Pavel Stárek | skóre: 43
| blog: Tady bloguju já :-)
| Kolín
. Takže nápad podporuji.
) třeba takhle (za předpokladu, že id spotů jsou v čase rostoucí):
SELECT * FROM blog WHERE id IN (SELECT MAX(id) FROM blog GROUP BY autor) ORDER BY datum LIMIT 10
a nestačí na to náhodou .. max(id_prispevku) .. group by id_prispevku) ..Jako bez ORDER BY? To by stačit mohlo, ORDER BY jsem tam napsal ještě před tím, než jsem si uvědomil, že brát nejmladší příspěvek ve vniřním SELECTu by znamenalo asi třetí vnořený SELECT
Otázka také je, zda 
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
18.9.2005 20:25
18.9.2005 20:42
18.9.2005 20:09
18.9.2005 22:44
19.9.2005 10:25
WHERE id IN (...) zachovává pořadí z vnitřního SELECTu…
SELECT * FROM blog ORDER BY datum GROUP BY id_uzivatele LIMIT 10 ale to alespoň v mysql nefunguje - moje představa byla - uspořádá se to podle data, pak se z toho vytvoří ty skupiny (takže uvnitř skupiny to zůstane uspořádané) a vrátí se první řádek té skupiny vaše řešení samozřejmě funguje, ale zkoušel jsem to bez toho vnořeného dotazuTo nemůže fungovat z několika důvodů:
ORDER BY se provádí až po GROUP BY (a když to do SQL nepíšete opačně, dostanete nejspíš chybu syntaxe)SELECT pak můžete použít buď sloupec, který je v GROUP BY (protože ten je pro celou skupinu stejný), nebo agregační funkci (která se spočítá přes všechny řádky ve skupině. (to nedá moc práce, při jejich četnosti 
) Každopádně ty vnořené selecty by měly být novinka ve verzi čtyři jedna, aspoň si to myslím.
Ta cisla jsou skutecne rostouci, resp. byla nez jsem napsal odlozena publikovani. Takze by se ted muselo tridit podle created sloupecku. Ale to je detail.Kdepak, to by byl právě problém
Zatím intuitivně bych řekl, že by tam musel být ještě třetí vnořený SELECT, a to ještě bůhví jestli by to pomohlo…
Spise se snazim pochopit, co presne ten dotaz bude delat. Ten vnoreny nalezne cisla vsech zapisu podle autoru, ze? A bude to omezeno jen na nejvetsi cislo pro kazdeho uzivatele? To by bylo resenim, za predpokladu ze to mysql zvladne.Ten vnořený najde největší id od každého autora.
Pokud ano, jde omezit ten pocet uzivatelu v tom subselectu? Preci jen delat tuhle tabulku pro vsechny uzivatele, kdyz potrebuju jen prvnich dvacet .. Nejlepsi to bude vyzkouset v reale, treba to bude tak rychle, ze se nad tim mavne rukou ..Šlo by to omezit i uvnitř, je to dokonce lepší. Ten LIMIT na vnějším SELECTU je pozůstatek z doby, kdy jsem to uvnitř chtěl třídit podle času - než mi došlo, že to bude složitější.
Kazdopadne diky. Ja si to furt komplikoval ruznymi podminkami pro efektivnost ..To znám. Ale poslední dobou jsem skončil u SELECTů, u kterých mě překvapilo, že to databáze vůbec zvládne. Ale byl to jeden SELECT, ze kterého vypadly rovnou hodnoty, které jsem potřeboval, tak to stačilo
Tak jde to i podle data na 2 SELECTy, akorát to vybere autora a datum jeho nejnovějšího příspěvku, a pak to hledá záznam, kde je stejný autor a datum – což není úplně nejhezčí řešeníTa cisla jsou skutecne rostouci, resp. byla nez jsem napsal odlozena publikovani. Takze by se ted muselo tridit podle created sloupecku. Ale to je detail.Kdepak, to by byl právě problém
Ale on by ten třetí SELECT asi nedělal nic jiného Takže varianta B:
SELECT * FROM blog WHERE (autor, datum) IN (SELECT autor, MAX(datum) FROM blog GROUP BY autor LIMIT 10) ORDER BY datum
GROUP BY a místo MAX() je LIMIT, což je např. u PostgreSQL (zatím) rychlejší. Jestli to bude rychlejší i v MySQL je asi potřeba jedině vyzkoušet.
SELECT * FROM autor, blog
WHERE blog.autor = autor.id AND blog.id IN (
SELECT blog.id FROM blog
WHERE blog.autor = autor.id ORDER BY datum LIMIT 1
)
LIMIT 10
Ale bohuzel to s 4.0 verzi mysql nedam. Zkusim pozadat admina o upgrade, snad to na debianu pujde udelat rozumne. Stejne me tato verze stve, casto vidim v logu, ze se na cas zasekne a prestane komunikovat s JDBC ovladacem. Az si pomalu rikam, ze bych radsi presel treba na Firebird ..
Jen pro strycka prihodu, prelozene SQL do schematu abicka:
SELECT * FROM polozka WHERE (pridal, vytvoreno) IN (SELECT pridal, MAX(vytvoreno) FROM polozka where typ=12 GROUP BY pridal LIMIT 10) ORDER BY vytvorenoA to jsem neresil, ze tohle musim zapouzdrit jeste do joinu s tabulkou relace
Ten vnitrni select spustim, prvni volani trvalo pul sekundy, dalsi uz jen 2 setiny sekundy. Asi tedy ani nema cenu tvorit index na ten sloupecek vytvoreno. Vnitrni select ale skoncil na syntax error.
Ale bohuzel to s 4.0 verzi mysql nedam. Zkusim pozadat admina o upgrade, snad to na debianu pujde udelat rozumne. Stejne me tato verze stve, casto vidim v logu, ze se na cas zasekne a prestane komunikovat s JDBC ovladacem. Az si pomalu rikam, ze bych radsi presel treba na Firebird ..S Firebirdem jsem chvilku také koketoval, ale pak jsem skončil u PostgreSQL. A od té doby nepřemýšlím o tom, zda to umí databáze, ale jestli to dokážu v SQL napsat
(Pravda, u toho třetího SELECTu - bez GROUP BY - mne PostgreSQL příjemně překvapil, že i v tomhle vnitřním SELECTu se umí odkázat na vnější tabulku
Jen pro strycka prihodu, prelozene SQL do schematu abicka:
SELECT * FROM polozka WHERE (pridal, vytvoreno) IN (SELECT pridal, MAX(vytvoreno) FROM polozka where typ=12 GROUP BY pridal LIMIT 10) ORDER BY vytvoreno
Ten vnitrni select spustim, prvni volani trvalo pul sekundy, dalsi uz jen 2 setiny sekundy. Asi tedy ani nema cenu tvorit index na ten sloupecek vytvoreno. Vnitrni select ale skoncil na syntax error.Nevím, zda MySQL umí používat MAX() s indexem, pro ORDER BY by se každopádně index na
vytvoreno hodil. Ono by to šlo asi přepsat i bez toho vnitřního SELECTu, jenže to už by asi byl kartézský součin dvou nebo tří tabulek, spousta MINů nebo MAXů, a celkově by to byla spíš zkouška toho, co databáze vydrží, než použitelný příkaz
19.9.2005 20:20
Pavel Stárek | skóre: 43
| blog: Tady bloguju já :-)
| Kolín
všechny takové ty zápisky zavánějící nějakým flamováním a nedodržením těchto pravidel by se nějak zmrazily a zamklyTo je a) Velmi subjektivní. Co je pro jednoho otravné, je pro druhého zábavné. b) Náročné na čas. Nemáme lidi na to, aby kontrolovali kvalitu všech blogů.
Neomezovat. To leda tak vyvolá ve fanaticích pocit, že je jim nějak ubližováno a povede k mazání zápisů.Souhlasím. Omezování k blogům nepatří. Je-li problém se záplavou nezajímavých zápisů (i když je zajímavost relativní), mělo by se to řešit nějakou funkcí, která by usnadnila orientaci, ne limitem.
file:///. Informační hodnota je nulová, stránka při tom není prázdná a na většině počítačů to vypadá ve stejném prohlížeči stejně.
)
omezovat obsah blogů jenom na GNU/Linux se mi zdá, promiňte, scestné.S tím souhlasím.
Tiskni
Sdílej:
