Raspberry Pi Connect, tj. 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, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Velice zřídka píšu text i s diakritikou a když už na to příjde vystačím si většinou se znaky na klávesách. Poslední dobou ale párkrát potřeboval napsat ňŇťŤóÓ atd. a zjistil jsem, že v KDE aplikacích se háček i čárka napíše ihned po stisku klávesy a nečeká se na zadání dalšího znaku. Výstup pak vypadá takto: ˇnˇNˇtˇT´o´O.
Tato chyba se mi projevila nezávisle na třech počítačích s KDE na 32 i 64 bitovém Archu. Jediný stroj, kde se chyba neprojevuje je notebook, na kterém je narozdíl od ostatních počítačů nastavena česká klávesnice jako výchozí.
Nemáte někdo nápad, co to mohlo způsobit a jak to odstranit?
Řešení dotazu:
Díky za odkaz. Doposud jsem ibus, který mám na všech problematických strojích, nepodezříval. Zapátrám tímto směrem...
Tak ani vypnutí ibus démona nepomohlo. Nakonfigurován je tak, jak to popisují všechny dostupné články a funguje podle očekávání, takže bych v něm problém neviděl.
Nějaký další tip?
Ještě býval problém s ne-UTF-8 locale.
Nicméně hledat musíte vy. Ani jste nenapsal, jakou verzi KDE, Qt, Xorg máte. Jestli problém je jen v KDE programech, nebo i čistých Qt.
Být vámi, tak ukončím všechny KDE, kdm a podobný věci a z virtuální konzole spustím X (opravdu jenom příkaz X), z druhé konzole pustím qtconfig a v takto minimálním prostředí ověřím, jestli problém je opravdu tam.
Samozřejmě používám utf8 locale. Verze KDE, Qt i X serveru se už několikrát změnily, zatím co chyba přetrvává. Stávající verze jsou KDE 4.4.5, Qt 4.6.3 a X server 1.8.1.902, prostě to, co je dostupné v repozitářích Archu (a to nepoužívám testing repository) V /etc/X11/xorg.conf mám jen konfiguraci dvou monitorů...
Problém je určitě jak v KDE tak čistých Qt aplikacích, protože na jednom notesu mám Gnome s gdm a má stejné problémy.
Zajímalo by mě zda se stejné chování projevilo i jiným Archistům, kteří jen aktualizují. Osobně si nevybavuju, že bych mimo instalace rýpal do nastavení klávesnice, vstupních metod apod. Hledáním na netu i chyb v konfiguraci jsem už stávil nejeden večer, výsledkem je tento dotaz.
16.8.2010 21:10
Marek Niklíček | skóre: 17
| Rimavská Sobota / Banská Bystrica
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czLOCALE="en_US.UTF-8", na ostatných LOCALE="sk_SK.UTF-8". V /etc/locale.gen mám odkomentované riadky s cs_CZ, us_US, sk_SK.
Díky za reakci.
Zkusil jsem vypnout celé KDE, kdm se mi však po vypnutí vždy spustilo samo. I tak jsem spustil twm a ibus demona, nastavil cz a us rozložení klávesnice a testoval na qtconfig a konsole. Kupodivu žádné komplikace! Dokonce i kopírování funguje (viz. můj druhý dotaz s podobným titulkem)
Teď jen nevím, co z tohoto testu vyvodit. Problém s mrtvými znaky je někde jinde než v nastavení klávesnice a ibus? wtf?
Zkusil jsem vypnout celé KDE, kdm se mi však po vypnutí vždy spustilo samo.
init 3, /etc/init.d/xdm stop?
Smyslem bylo, aby jste dostal čisté prostředí bez inicializačních skriptů, které pouští diplay manager mezi přihlášením a spuštěním okenního správce.
Teď jen nevím, co z tohoto testu vyvodit.
Proměnné prostředí (hlavně ty kolem vstupních metod popsané ve vlákně odkazovaném úplně na začátku). Démoni pověšení na D-Bus. Nějaký kdečkový vynález, který chytá všechny vstupní události (třeba to přepínání klávesnice).
S vnitřnostmi KDE ale neporadím, protože je vůbec neznám.
Ještě mě napadá, že by KDE mohly místo setxkbmap používat přímo xmodmap nebo xkbcomp. Občas jsem pozoroval, že když se zkřížily dva X servery s různými ručně poskládanými mapami klávesnice, tak že některé kombinace kláves nefugovaly (třeba ty mrtvé klávesy).
17.8.2010 08:57
Jiří Poláček | skóre: 47
| blog: naopak
| Sivice
setxkbmap?
A nebude nejlepší od zlozvyku přepínání rozložení kláves se odprostit a používat jen jedno vlastní?
Výchozí mám anglické rozložení a přepínám jej pro každou aplikaci zvlášť pomocí Alt+Shift, což je nastaveno v KDE klikátku, které používá setxkbmap. Příkazy, které zobrazí toto klikátko, jsem použil při testu s TWM...
Co bych mohl zkusit zapnout/vypnout/změnit, abych vyloučil nový Xorg z podezřelých? Downgrade moc nepřipadá v úvahu kvůli závislostem, protože to Arch nepodporuje.
Mimochodem, užívat vlastní rozložení schvaluji jen u mobilních nebo embedded zařízení, všude jinde by mělo být standardní rozložení s možností přepínání, aby jej byli schopni ovládat všichni uživatelé (čti windowsáci, manželka, atd.) 
Tak nakonec se mi to povedlo nečekaně vyřešit. Nejsem si sice přesně jistý, který balíček zabral, ale důležitý je výsledek. Problém byl zakopaný v ibus.
Pro úplnost dodávám "řešení". Kompletně jsem odinstaloval ibus včetně zrušení příslušných systémových proměnných. Po restartu vše fungovalo samozřejmě až na možnost psát japonsky. Takže opětovný export proměnných a instalace ibus, ibus-anthy, ibus-qt (který měl problém vyřešit hned napoprvé, ale nezabral) a nově ibus-m17n (který vlastně ani nevím k čemu slouží). Po následném restartu je funkční téměř vše až na čisté X aplikace jako xterm, kde jsou mrtvé klávesy ignorovány. To mi ale vůbec nevadí. 
Tiskni
Sdílej:
