Na YouTube byly publikovány videozáznamy přednášek a na Flickru fotografie z konference EuroPython 2026.
Byl vydán Debian 13.7, tj. sedmá opravná verze Debianu 13 s kódovým názvem Trixie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Jiří Eischmann se v příspěvku Fiasko jménem W Social na svém blogu věnuje evropské sociální síti W: "W Social je příkladem toho, že se problémy sociální sítí nedají řešit od exekutivního stolu. Když na začátku tohoto roku v Davosu oznámili vznik nové sociální sítě W Social, politici se mohli přetrhnout ve chvalozpěvech. Konečně evropská sociální síť a ještě s ověřením identity. … Jak se ukázalo, když v Davosu W Social oznamovali, neměli kromě
… více »Výrobce hardwarových kryptoměnových peněženek Trezor upozorňuje na bezpečnostní incident u společnosti Brevo, kterou využívá k odesílání newsletterů. Útočník na e-mailové adresy odeslal phishingový e-mail.
Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za srpen 2026. Aplikace XApp mají vlastní webovou stránku xapp-project.org. Představena byl čtečka EPUB s názvem Xepub a kalendář Clockenstein.
Byla vydána nová verze 3.2.6 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Bylo vydáno Ubuntu 24.04.5 LTS, tj. páté opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na poznámkách k vydání.
Švýcarsko testuje přechod z Microsoft 365 na FOSS, konkrétně balík openDesk (Wikipedie) od německé státní společnosti ZenDiS (Wikipedie), s cílem posílit digitální suverenitu.
V italském městě Pordenone probíhá LibreOffice Conference 2026. Zúčastnit se lze i online.
Svobodný (GPLv3) šachový engine Stockfish (Wikipedie) byl vydán ve verzi 19 (𝕏). Přehled novinek v příspěvku na blogu. Stockfish 19 je o 44 Elo silnější než Stockfish 18.
LOCALE="cs_CZ.UTF-8" HARDWARECLOCK="localtime" TIMEZONE="Europe/Prague" KEYMAP="cz" CONSOLEFONT="lat2-16" CONSOLEMAP="" USECOLOR="yes"locale:
LANG=cs_CZ.UTF-8 LC_CTYPE="cs_CZ.UTF-8" LC_NUMERIC="cs_CZ.UTF-8" LC_TIME="cs_CZ.UTF-8" LC_COLLATE=C LC_MONETARY="cs_CZ.UTF-8" LC_MESSAGES="cs_CZ.UTF-8" LC_PAPER="cs_CZ.UTF-8" LC_NAME="cs_CZ.UTF-8" LC_ADDRESS="cs_CZ.UTF-8" LC_TELEPHONE="cs_CZ.UTF-8" LC_MEASUREMENT="cs_CZ.UTF-8" LC_IDENTIFICATION="cs_CZ.UTF-8" LC_ALL=locale.gen:
cs_CZ.UTF-8 UTF-8 cs_CZ ISO-8859-2 en_US ISO-8859-1
Řešení dotazu:
LOCALE="cs_CZ.utf8" HARDWARECLOCK="UTC" TIMEZONE=Europe/Prague KEYMAP="cz" CONSOLEFONT="lat2-16.psfu.gz" CONSOLEMAP= USECOLOR="yes"
unicode_start
LOCALE="sk_SK.utf8" HARDWARECLOCK="localtime" TIMEZONE="Europe/Bratislava" KEYMAP="sk-qwerty" CONSOLEFONT="lat2-12" CONSOLEMAP="8859-15" USECOLOR="yes"
screen, která umožnuje měnit kodování operativně pro jednotlivá okna podle potřeby.
Potíž je v tom, že žádné ze zmíněných nastavení nefunguje. Zdánlivě se české znaky v terminálu normálně vypisují a ukládají, ale ve skutečnosti se ukládá smetí, které s UTF-8 nemá nic společného.
Lze to dokázat velmi snadno:
Co z toho plyne:
Pokud jde o řešení tohoto problému, zatím žádné neznám. Za žádných okolností by neměla být nastavena mapa kláves, která má něco společného s latin2. Bohužel toto nesplňuje žádná česká mapa kláves, která je v základní instalaci. Je víc než pravděpodobné, že řešení neexistuje.
Zde je vše skvěle vysvětleno. Přesně se potvrzuje to, co jsem psal o latin1. Cituji:
Some keymaps have dead keys (i.e., keys that don't produce a character by themselves, but put an accent on the character produced by the next key) or define composition rules (such as: “press Ctrl+. A E to get Æ” in the default keymap). Linux-2.6.18.1 in UTF-8 keyboard mode assumes that accented characters produced via dead keys or composing are in the Latin-1 range of Unicode, and it is impossible to change this assumption. Thus, accented characters needed for, e.g., the Czech language, can't be typed on Linux console in UTF-8 mode (but files containing these characters can be displayed correctly). The solution is either to avoid the use of UTF-8, or to install the X window system that doesn't have this limitation in its input handling.
Nezbývá než doufat, že se jednou nějakého řešení dočkáme. Pokud ale k editaci použijete konzolový program pro X, bude vše bez problémů. Horší je to například u serveru, který vůbec nemá X...
The solution is either to avoid the use of UTF-8, or to install the X window system that doesn't have this limitation in its input handling.Nebo pouzivat ceskou klavesnici, ktera si vystaci bez dead keys.
No dyť jo, ale pod pojmem "řešení" jsem rozuměl mít i bez X serveru plnohodnotnou českou klávesnici, jako je tomu například u ISO-8859-2.
Kromě toho, problém se netýká pouze dead keys. To je omyl (nejspíš anglicky mluvících) autorů onoho článku. Problém se týká všech českých znaků, které nejsou v ISO-8859-1, bez ohledu na to, zda se napíší pomocí deadkeys nebo ne. (Vyzokušeno.)
Vím, že se jedná o starý dotaz, téma je ale pořád aktuální.
setfont Lat2-Terminus16 -m 8859-2 loadkeys -u cz-lat2
Po zadání těchto příkazů můžu v konzoli napsat všechny české znaky (používám UTF-8). Záleží na pořadí příkazů a u fontu je nutné zadat -m 8859-2, přestože by to podle mě nemělo mít vliv. Může to prosím někdo vyzkoušet, popř. vysvětlit?
Díky.
#mkdir čřžý, pak mi prikaz #ls -l vypise misto nazvu adresare "????". Zvlastni je, ze treba z unicode mc vidim znaky spravne. Asi pouziva svuj font.. Locale mam en_us.urf8, distro Arch..
Mně v Archlinuxu v pohodě jede UTF-8 (čeština). Zde je část /etc/rc.conf, která se týká češtiny (tak to mám já):
LOCALE="cs_CZ.UTF-8" HARDWARECLOCK="localtime" TIMEZONE="Europe/Prague" KEYMAP="cz-us-qwertz" CONSOLEFONT="lat2-16.psfu" CONSOLEMAP="8859-2_to_uni.trans" USECOLOR="yes"
Tiskni
Sdílej: