Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
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.
#!/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
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
|| 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ší.
31.12.2017 01:41
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:
