Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
Evropská komise (EK) nařídila americké společnosti Meta, že musí znovu umožnit bezplatný přístup konkurenčním obecně zaměřeným asistentům umělé inteligence (AI) k WhatsAppu a tento přístup musí zachovat až do ukončení antimonopolního šetření. Opatření je dočasné a má zabránit vážnému a nevratnému poškození konkurence na rychle rostoucím trhu s obecnými AI asistenty. Meta uvedla, že se proti rozhodnutí odvolá.
Společnost Anthropic představila AI modely Claude Fable 5 a Claude Mythos 5. Claude Fable 5 je první model třídy Mythos určený pro běžné použití.
Byla vydána nová stabilní verze 3.24.0, tj. první z nové řady 3.24, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Přehled novinek v poznámkách k vydání.
Na čem pracují vývojáři v Rustu napsaného mikrokernelového unixového operačního systému Redox OS (Wikipedie)? Byl publikován přehled vývoje za květen. Vypíchnout lze nový scheduler EEVDF nebo port desktopového prostředí Xfce na Redox OS.
Myslim, ze tato tema, ako namet na clanok, by bola vysoko ocenena
LC_CTYPE slouží především pro klasifikaci znaků. Aplikace potřebují vědět, co je písmeno, které znaky jsou zobrazitelné na terminál apod. Tyhle věci se v jednotlivých jazycích (a občas i variantách) liší.
UTF-8 poznal, jakým jazykem to má mluvit.
Lze při změně klávesnice automaticky změnit hodnotu LC_CTYPE a aktuální font?
Nejde a taková otázka vůbec nemá smysl -- hodnoty LC_CTYPE a aktuální font čeho? Používej UTF-8.
Také se vám zdá situace kolem klávesnice (prakticky nejzákladnější HW) na linuxu značně neutěšená?
Ne.
Měl jsem na mysli LC_CTYPE, u ostatních locales je mi to jasné.
Měl jsem na mysli LC_CTYPE a aktuální font pro příslušnou aplikaci. UTF-8 je patrně řešení, ale ne vše už uspokojivě funguje...
Domníval jsem se, že když stisknu klávesu, dostane program informaci závislou na kódování a bude jí podle stavu LC_CTYPE interpretovat. Když teda změním kódování měl by o tom program vědět. Pokud bude program ke stisknuté klávese vykreslovat znak, měl by vědět v jakém kódování, a zvolit příslušný font (nemyslím tedy měnit rodinu fontu ale pouze kódování, je li to možné).
...závislost chování aplikací na klávesnici je odporná vlasnost MS Windows, kterou rozhodně není dobrý nápad reprodukovat -- tobě se opravdu líbí, když máš text ve wordprocesoru napsaný střídavě po několika znacích různými fonty...Tohle bych opravdu nechtěl, ale MS Windows a wordprocesory prakticky nikdy nepoužívám.
V Linuxu to nefunguje špatně, ale logicky. Tvůj názor, že je situace s klávesnicí neutěšená (a ostatně i tvoje představy o locale) spíš ukazuje na to, že naprosto netušíš, jak to funguje, než že to funguje špatně. Takže doporučuji nejprve si něco nastudovat.Opravdu se snažím pochopit(nastudovat) jak to funguje, často bohužel metodou pokus-omyl. Snažím se zjistit proč mi některé věci nefugují, nebo fugují jinak nž bych očekával. Uznávám, že mám značně zkreslené představy o locales. V systému mám nastaveno pouze LC_CTYPE, a snažím se zjistit k čemu vlastně je. V jeho existenci vidím spory, které zřejmě nejsou problém, a tak jsem chtel vědět proč.
Ano, to jsem zjistil programem xev. Právě to byl důvod, proč jsem se začal zajímat o LC_CTYPE. Symbol zřejmě dostane podle nastavené klávesnice a nezávisle na LC_CTYPE nebo jinde nastaveném kódování. Proč však je však symbol při neadekvátně nastavené LC_CTYPE chybně(vůbec ne) interpretován když je naprosto jasné o co jde nezávisle na kódování(např. xterm)? Očekával bych třeba chybovou hlášku, že program si není jistý co s takovým symbolem dělat.
/
zgrep -l "CYRILLIC SMALL LETTER SHCHA" $(zgrep -l "SMALL LETTER N WITH CARON" /usr/share/i18n/charmaps/*)
Tiskni
Sdílej: