Byla vydána nová verze 1.16.0 klienta a serveru VNC (Virtual Network Computing) s názvem TigerVNC (Wikipedie). Z novinek lze vypíchnout nový server w0vncserver pro sdílení Wayland desktopu. Zdrojové kódy jsou k dispozici na GitHubu. Binárky na SourceForge. TigerVNC je fork TightVNC.
Byla vydána nová verze 4.6 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Rozsáhlá modernizace hardwarové infrastruktury Základních registrů měla zabránit výpadkům digitálních služeb státu. Dnešnímu výpadku nezabránila.
Čínský startup Kimi představil open-source model umělé inteligence Kimi K2.5. Nová verze pracuje s textem i obrázky a poskytuje 'paradigma samosměřovaného roje agentů' pro rychlejší vykonávání úkolů. Kimi zdůrazňuje vylepšenou schopnost modelu vytvářet zdrojové kódy přímo z přirozeného jazyka. Natrénovaný model je dostupný na Hugging Face, trénovací skripty však ne. Model má 1 T (bilion) parametrů, 32 B (miliard) aktivních.
V Raspberry Pi OS lze nově snadno povolit USB Gadget Mode a díky balíčku rpi-usb-gadget (CDC-ECM/RNDIS) mít možnost se k Raspberry Pi připojovat přes USB kabel bez nutnosti konfigurování Wi-Fi nebo Ethernetu. K podporovaným Raspberry Pi připojeným do USB portu podporujícího OTG.
Konference Installfest 2026 proběhne o víkendu 28. a 29. března v budově FELu na Karlově náměstí v Praze. Přihlásit přednášku nebo workshop týkající se Linuxu, otevřených technologií, sítí, bezpečnosti, vývoje, programování a podobně lze do 18. února 0:15.
Fedora Flock 2026, tj. konference pro přispěvatele a příznivce Fedory, bude opět v Praze. Proběhne od 14. do 16. června. Na Flock navazuje DevConf.CZ 2026, který se uskuteční 18. a 19. června v Brně. Organizátoři konferencí hledají přednášející, vyhlásili Call for Proposals (CfP).
Z80-μLM je jazykový model 'konverzační umělé inteligence' optimalizovaný pro běh na 8-bitovém 4Mhz procesoru Z80 s 64kB RAM, technologii z roku 1976. Model používá 2-bitovou kvantizaci a trigramové hashování do 128 položek, což umožňuje zpracování textu i při velmi omezené paměti. Natrénovaný model se vejde do binárního souboru velkého pouhých 40 KB. Tento jazykový model patrně neprojde Turingovým testem 😅.
Digitální a informační agentura (DIA) na přelomu roku dokončila rozsáhlou modernizaci hardwarové infrastruktury základních registrů. Projekt za 236 milionů korun by měl zabránit výpadkům digitálních služeb státu, tak jako při loňských parlamentních volbách. Základní registry, tedy Registr práv a povinností (RPP), Informační systém základních registrů (ISZR) a Registr obyvatel (ROB), jsou jedním z pilířů veřejné správy. Denně
… více »Evropská komise (EK) zahájila nové vyšetřování americké internetové platformy 𝕏 miliardáře Elona Muska, a to podle unijního nařízení o digitálních službách (DSA). Vyšetřování souvisí se skandálem, kdy chatbot s umělou inteligencí (AI) Grok na žádost uživatelů na síti 𝕏 generoval sexualizované fotografie žen a dětí. Komise o tom dnes informovala ve svém sdělení. Americký podnik je podezřelý, že řádně neposoudil a nezmírnil rizika spojená se zavedením své umělé inteligence na on-line platformě.
#!/bin/bash . /opt/Man Back Editor/run.sh || exit $?a tohle taky nefunguje (soubor ~/.bashrc)
alias mbe='/opt/Man Back Editor/run.sh' alias mbe="/opt/Man Back Editor/run.sh"
Řešení dotazu:
#!/bin/bash . '/opt/Man Back Editor/run.sh' || exit $?V případě toho aliasu musí být uvozovky dvoje – ty první se rozvinou v okamžiku, kdy definujete alias, proto tam musí být ty vnitřní, které s epoužijí, když alias použijete.
alias mbe='"/opt/Man Back Editor/run.sh"' alias mbe="'/opt/Man Back Editor/run.sh'"Nebo můžete mezeru uvodit zpětným lomítkem:
#!/bin/bash . /opt/Man\ Back\ Editor/run.sh || exit $?
alias mbe='/opt/Man\ Back\ Editor/run.sh'
/opt/Man\ Back\ Editor/run.shA to ve všech výše uvedených případech. Nebo, jak navrhoval předřečník, obalit to v uvozovkách:
'/opt/Man Back Editor/run.sh' "/opt/Man Back Editor/run.sh" alias mbe='"/opt/Man Back Editor/run.sh"' alias mbe="'/opt/Man Back Editor/run.sh'"No a pak je tu ještě pár drobností. Proč o to ten první skript sourcuje a nevolá? Není to spíše omyl než záměr? No a pokud je to celém tak
|| exit $? nedává ani trochu smysl, protože ať to tam je, nebo ne (a nebo taky && exit $?, či ; exit $?. Tak to dopadne vždycky stejně.
předně, mezery v názvech souborů jsou zlo. Nejlépe byste udělal, kdybyste to přejmenoval.Lidé víceslovné názvy běžně používají, a slova pak oddělují mezerami. Počítače jsou od toho, aby sloužily lidem, ne naopak. Mezery v názvech souborů jsou běžná věc, programy s tím umí zacházet – a pokud s tím nějaký konkrétní program má problém, je potřeba ho opravit. Používat mezery v názvech souborů je stejné „zlo“, jako používat shell místo assembleru nebo používat klávesnici a monitor místo děrných štítků a tiskárny.
Dodal bych jen, že používat v dnešní době počítač k řešení tak triviálních úloh je stejné "zlo", jako místo gelové propisky používat husí brk, či dokonce obyčejnou tužku!předně, mezery v názvech souborů jsou zlo. Nejlépe byste udělal, kdybyste to přejmenoval.Lidé víceslovné názvy běžně používají, a slova pak oddělují mezerami. Počítače jsou od toho, aby sloužily lidem, ne naopak. Mezery v názvech souborů jsou běžná věc, programy s tím umí zacházet – a pokud s tím nějaký konkrétní program má problém, je potřeba ho opravit. Používat mezery v názvech souborů je stejné „zlo“, jako používat shell místo assembleru nebo používat klávesnici a monitor místo děrných štítků a tiskárny.
Jenže v názvech souborů mezera jako oddělovač nefunguje – jako oddělovač tam slouží jen a pouze lomítko.V názvech souborů ne, ale v shellu a při třídění parametrů ano. Aby počítač sloužil člověku a ne naopak, zda se bytí jednodušší používat v názvu souborů podtržítko místo mezery a dělá to to, co má, i když někdo někde něco zapomněl ošetřit, protože špatně sloužil. Je asi jenom otázkou osobní preference, jestli otročim vzdáním se mezery ve jménu nebo escapováním při každém použití, kde na jméno narazím. A protože vím, co lidi píšou, tak raději žiju bez mezer. Nakonec pak sám mohu být trochu lenivější ve onelinerech (tedy méně sloužím). A při více sloupcích výstupu se mi to i lépe čte. Protože položky a slova v jedné položce se na první pohled liší.
find (jo jasně, můžu mu posloužit a na obou stranách dopsat, ať oddělí položku "nulou") nebo něco do smyčky nebo xargs či co. To je přesně ten případ, kdy oddělovač slov a položek kolidují.
Ale teď už jsem to pochopil. Jádro pudla je ta poznámka o GUI. Ale pořád je to ta samá otázka preferencí a pohledu na věc. Nechci počítači sloužit, tak se trochu naučím, abych úkony prováděl rychle a snadno? Nebo mu nechci sloužit učením a raději si to pro každé interakci odsloužím tím, že budu honit myš po stole a dirigovat ukazováčkem.
find s -exec. Ale nešlo jenom o find a i u něj jsou situace, kdy nebudu chtít forkovat nový proces pro každou položku.
Je to fakt jen otázka pohledu a preference, jak chci ne/sloužit. Jediný způsob jak pro ten počítač nic neudělat je ho vůbec nepoužívat.
Ale nešlo jenom o find a i u něj jsou situace, kdy nebudu chtít forkovat nový proces pro každou položku.
find -exec {} + znáte?
find jako nevhodný příklad a už se k němu nebudeme vracet. Omlouvám se, že jsem ho chybně uvedl. Zkusme třeba grep -l. Prostě něco vrací seznam souborů a něco dalšího s tím shell dělá. To je to, o co mi šlo. Vy možná ne, já to docela používám. Proto máme různé potřeby a postupy. A různé věci nás více nebo méně obtěžují.
S GUI se to bude řešit jinak. A podle mě více interaktivně a asi déle, proto to není moje volba. Ale určitě to jde. A komu to vyhovuje, nic proti tomu nemám.
Nicméně i pro uživatele GUI platí. Pokud se moc nechce učit, ale sem tam si zkopírujete nějaký skript z netu na přejmenování nebo kdo ví co, tak bude mít bez mezer méně nepříjemných překvapení. Jak ostatně svědčí i původní dotaz.
find -exec {} předává jméno souboru správně jako jeden parametr, bez ohledu na to, jaké znaky obsahuje. zsh, které používám, nejprve rozdělí vstup na jednotlivé argumenty, a teprve pak expanduje proměnné – takže ve smyčce nemám problém s mezerami v názvech souborů.
Pokud byste někde mezery ošetřit měl a neděláte to, asi spoléháte na to, že nemáte žádné soubory s mezerou. Já se na něco takového určitě spolehnout nemůžu, protože si spoustu souborů vyměňuji s ostatními, a rozhodně nemíním trávit čas tím, že budu soubory neustále přejmenovávat sem a tam.
Psal jsem o GUI, to vy jste si vymyslel honění myši po stole. Myslím, že se soubory pracuji rychle a snadno, a žádné mezery v názvech souborů mi v tom nepřekážejí.
Ať si každý (ne)používá, co (ne)chce. Když někdo dá na web soubor s mezerami v názvu, každý má právo si ten soubor nestáhnout. 
Počítače slouží lidem, nikoliv lidé počítačům. Pokud lidé uznají za nezbytné mít v názvech souborů mezery, ať tam klidně mezery jsou. Samozřejmě by bylo nejlepší tohle nějak standardizovat a používat třeba znak neoddělitelné mezery místo 0x20. Ale to už je spíš otázka budoucnosti.
Microsoft všem zmrvil kódování v jazycích, kterým nestačí 7 bitů z ASCII, na dobrá tři desetiletí. To je původní příčina všech absurdních debat o tom, jak se může/nemůže jmenovat soubor nebo co může/nemůže být napsáno tam či onde. Kvůli embrace-extend-extinguish experimentům s kódováním bylo roky problematické psát maily normálně česky. Kniha od jednoho raději nejmenovaného českého internetového taky-publicisty vybízela v podstatě k psaní celých webů v Notepadu bez zřetele ke kódování, protože v „obvyklém“ browseru se to zdálo být v pořádku.
Kdyby byly všechny názvy souborů už dávno povinně v UTF-8, nedělitelná mezera v názvech souborů už dávno mohla být běžná věc. Terminály by ji mohly ukazovat třeba jako golfový důlek oblíbený u některých učitelů programování.
Ještě k tomu problému + řešení: Buď můžu problém donekonečna obcházet — což je nejhorší varianta —, nebo ho můžu pořád dokola řešit — což napovídá, že moje řešení je pořád špatné, i po mnoha opakováních —, nebo ho můžu vyřešit pořádně a natrvalo — čemuž Microsoft úspěšně zabránil, co se kódování týká.
Netvrdím přece, že mezera není platný znak.
Měl jsem možná explicitně říct, že hlavní (a asi jedinou) výhodou nedělitelných mezer by byla redukce počtu kňouralů, kterým tak nepřekonatelně vadí mezery v názvech souborů. Mně osobně mezery až tolik nevadí, ale nějaká konvence kolem nedělitelných mezer by se mi celkem líbila.
Jediný, kdo má s non-ASCII znaky problém, jsou anonymové na ABCLinuxu, zdá se. Nebo je tohle komentář z roku 1995?
Údajný problém s unicodem je nesmyslná fáma, kvůli které dodnes tu a tam přežívá hnusná zkomolená pseudo-čeština bez diakritiky. V posledních víc než 10 letech jsem nenarazil na software, který by měl problém normálně používat unicode.
Jaký je standard v dnešní době - UTF-8, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, UTF-32LE nebo UTF-32/UCS-4?
Standard je UTF-8.
Ten seznam je hodně přehnaně dlouhý, protože všechna ta kódování, která mají fixní šířku znaku a potřebují BOM, jsou zbytečně uvedená třikrát — big endian, little endian a blíže neurčený endian. Jinak je to ale v principu pořád totéž, že ano. (Pořadí bytů se naštěstí UTF-8 příliš netýká a UTF-8 nepotřebuje BOM, i když ho z jakýchsi historických mít může.) Pokud vím, 16- a 32-bitová kódování s fixní šířkou znaku se ve filesystémech moc nenosí.
Těžko říct, proč se vůbec zabývat MySQL, když PostgreSQL je po všech stránkách asi tak o světelný rok dál.
Nepoužívá Windows 10 UTF-16?
Tak to bych se klidně podíval. Kde to najdu na GitHubu?
Předně, proč by měl někdo řešit nějaké Shitdows? Tohle je fórum o Linuxu a na Linuxu diakritika už minimálně desetiletí a půl není nejmenší problém. Někdy v roce 2003 jsem musel jeden čas používat Outlook Express, takové to nejbéčkovější free provedení, a nikdy jsem nenarazil na problém s češtinou nebo diakritikou. Ano, dalo se tenkrát narazit na obstarožní software, který neuměl UTF-8, ale zvolit ISO-8859-2 (a mít kódování správně specifikované v hlavičkách mailu) opravdu šlo už tenkrát.
Taky se mi už minimálně 15 let nestalo, že bych napsal mail s diakritikou — samozřejmě píšu všechny maily buď s diakritikou nebo anglicky; český text bez diakritiky považuji za sérii vulgarismů a krajní neslušnost — a že by snad měl příjemce s takovým mailem problém. Stačí mít rozumného mailového klienta (Thunderbird i KMail mi fungují bez problémů) a mít nastavené bezproblémové odchozí kódování, tedy UTF-8, protože nic jiného v podstatě nedává smysl.
Samozřejmě, pokud někdo v mailovém klientovi naschvál zvolí například ISO-8859-1, potom do příslušného widgetu pro text mailu napíše české znaky a na závěr ještě odklikne varovné hlášky o kódování (tedy o tom, že se zvoleným kódováním bude text nutně zprasený), může takovým způsobem (uměle a zbytečně) vytvořit problém s češtinou. Jenže proč by to někdo dělal?
Navíc drtivá většina BFU beztak používá webmail, ve kterém je kódování taktéž už dobrých 15 let vyřešená záležitost.
Tiskni
Sdílej: