plwm je nový, poměrně minimalistický správce oken pro X11. Podporuje dynamické dláždění okny, plochy, pravidla pro okna atd. Zvláštností je, že je napsaný v logickém programovacím jazyce Prolog. Používá implementaci SWI-Prolog.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Sean Heelan se na svém blogu rozepsal o tom, jak pomocí OpenAI o3 nalezl vzdálenou zranitelnost nultého dne CVE-2025-37899 v Linuxu v implementaci SMB.
Jiří Eischmann v příspěvku na svém blogu představuje typy, jak lépe chránit své soukromí na mobilním telefonu: "Asi dnes neexistuje způsob, jak se sledování vyhnout úplně. Minimálně ne způsob, který by byl kompatibilní s tím, jak lidé technologie běžně používají. Soukromí ovšem není binární věc, ale škála. Absolutního soukromí je dnes na Internetu dost dobře nedosažitelné, ale jen posun na škále blíže k němu se počítá. Čím méně dat se o vás posbírá, tím nepřesnější budou vaše profily a tím méně budou zneužitelné proti vám."
Byla vydána nová stabilní verze 25.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Warbler. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Multiplatformní open source spouštěč her Heroic Games Launcher byl vydán v nové stabilní verzi 2.17.0 Franky (Mastodon, 𝕏). Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 26 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Klávesnice IBM Enhanced Keyboard, známá také jako Model M, byla poprvé představena v roce 1985, tzn. před 40 lety, s počítači IBM 7531/7532 Industrial Computer a 3161/3163 ASCII Display Station. Výročí připomíná článek na zevrubném sběratelském webu Admiral Shark's Keyboards. Rozložení kláves IBM Enhanced Keyboard se stalo průmyslovým standardem.
Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
Java má dnes 30. narozeniny. Veřejnosti byla představena 23. května 1995.
19.9.2005 20:05
Pavel Stárek | skóre: 44
| 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: 44
| 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:
