PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
Představen byl notebook TUXEDO InfinityBook Pro 15 Gen10 s procesorem AMD Ryzen AI 300, integrovanou grafikou AMD Radeon 800M, 15,3 palcovým displejem s rozlišením 2560x1600 pixelů. V konfiguraci si lze vybrat až 128 GB RAM. Koupit jej lze s nainstalovaným TUXEDO OS nebo Ubuntu 24.04 LTS.
Po půl roce od vydání verze 2.41 byla vydána nová verze 2.42 knihovny glibc (GNU C Library). Přehled novinek v poznámkách k vydání a v souboru NEWS. Vypíchnout lze například podporu SFrame. Opraveny jsou zranitelnosti CVE-2025-0395, CVE-2025-5702, CVE-2025-5745 a CVE-2025-8058.
Byla vydána nová verze 9.15 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
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:
