Společnost Apple slaví padesáté narozeniny. Založena byla 1. dubna 1976.
FreeTube, desktopový klient pro YouTube využívající lokální API, byl vydán ve verzi 0.24.0. Toto velké opravné vydání implementuje SABR (Server-Based Adaptive Bit Rate), což řeší část nedávných problémů s načítáním videí z YouTube, a aktualizuje základní komponenty jako Electron nebo přehrávač Shaka Player.
Je tu opět apríl. O víkendu zmizel kamion s 12 tunami tyčinek KitKat. Firmy to využívají k aprílovým žertům. Groupon má super akci. Koupíte 1 tyčinku a dostanete 100 zdarma. Ryanair si přelepil letadla. Šéf Outlooku se ptá, proč mají v baráku 14 beden tyčinek KitKat (𝕏). Prusa Research představuje Prusa Pro ACU a vysvětluje proč přílišné sušení škodí vaším filamentům. Telefon Sony Xperia má miliónnásobný zoom (𝕏). PC.net představil Super Ultrabox 2600 se zajímavými parametry. Další aprílové novinky například na April Fools' Day On The Web.
Společnost OpenAI, která stojí za chatovacím robotem s umělou inteligencí (AI) ChatGPT, získala od investorů 122 miliard USD (2,6 bilionu Kč). Hodnota společnosti tak dosáhla 852 miliard dolarů (více než 18 bilionů Kč). Nejnovější kolo investování se stalo největší, jaké zatím firma uskutečnila, a peníze mají posílit ambiciózní plány rozšíření výpočetní kapacity, datových center a nábor talentů.
Nástroj k identifikaci občanů v on-line komunikaci s úřady byl dnes dopoledne zhruba dvě hodiny částečně nedostupný. Problém se objevil kolem 09:00 a podařilo se ho vyřešit kolem 11:00. Částečně nedostupná byla služba Národní identitní autority (NIA), problémy podle DIA (Digitální a informační agentura) ovlivňovaly přihlašování například i přes bankovní identitu. „Dostupnost NIA byla plně obnovena, přihlášení k digitálním službám
… více »Eben Upton oznámil další zdražení počítačů Raspberry Pi kvůli růstu cen pamětí a představil Raspberry Pi 4 s 3 GB RAM za 83,75 dolarů.
Anthropic patrně omylem zveřejnil celý zdrojový kód svého CLI nástroje Claude Code prostřednictvím přiloženého sourcemap souboru v npm balíčku. Únik odhalil doposud nijak nezveřejněné funkce jako je například režim v utajení, autonomní agent 'KAIROS', orchestrace multi‑agentů, režim snění nebo dokonce virtuální mazlíček Buddy. Zajímavostí je detekce naštvání uživatele pomocí obyčejného regexpu. Anthropic rychle odstranil sourcemap a vydal opravu, nicméně kopie kódu se již stihly na GitHubu rozšířit mezi prostým lidem.
Copilot automaticky vkládal do pull requestů 'propagační tipy', reklamní text se na GitHubu objevil ve více než jedenácti tisících pull requestech. Po vlně kritiky byla tato funkce zablokována a produktový manažer Tim Rogers připustil, že umožnit Copilotovi upravovat cizí pull requesty bez vědomí autorů byla chyba.
Je 31. března a tedy Světový den zálohování (World Backup Day). Co by se stalo, kdyby Vám právě teď odešel počítač, tablet nebo telefon, který používáte?
Digitální a informační agentura (DIA) přistupuje ke změně formátu důvěryhodného seznamu České republiky z verze TLv5 na verzi TLv6, která nastane 29. dubna 2026 v 00:00 (CET). Ke změně formátu důvěryhodných seznamů členských států (tzv. Trusted Lists) dochází na základě změn příslušné unijní legislativy. Důvěryhodné seznamy se používají v rámci informačních systémů a aplikací zejména pro účely ověřování platnosti elektronických
… více »Nevím jak ostatní, ale jsem v poslední době dosti nespokojený s tím, co se stalo s blogy.
Blogy na ABC jsem po jejich uvedení viděl jako velmi vítané osvěžení s možností diskuze nad věcmi, které třeba někoho pálí, nebo mu vrtají hlavou. Jenže v poslední době se z blogy roztrhl pytel. Což o to, to by nebyl problém. Jenže to nejsou blogy, kde by se snad věcně diskutovalo. Jsou to buď blogy plné provokací, nebo blogy, kde nám ten či onen sděluje své pokroky v prvním týdnu užívání linuxu, problémy se svou kočičkou, případně blogy zabývající se problematikou reality show.
Nechci nikomu brát možnost vyjádřit se do blogu, ale rád bych měl možnost některé z blogů popostrčit dopředu a některé zase popokopnout dozadu. Ale ... jen sám pro sebe, mé preference by se nijak nedotkly pořadí zápisů na homepage jiných uživatelů. Možná si někdo řeknete o co jde, ale mne skutečně nijak nezajímají něčí dětské krůčky s linuxem, názory na VyVolené nebo Plešingerovy provokace. Chci si číst blogposty Luka, Yetiho a podobné, ale ty se na homepage už ani neohřejí.
Prosím, Leoši, nešlo by s tím něco udělat!?
Tiskni
Sdílej:
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.