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.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »V Qt Labs se začalo uvažovat o Qt 5. Qt 4 vyšlo poprvé v červnu 2005 a ačkoliv jsou s ním vývojáři spokojení, je třeba uvažovat o některých nekompatibilních změnách. Qt 5 má nabídnout vyšší využívání GPU, usnadnit tvorbu uživatelského rozhraní s QML a JavaScriptem, usnadnit propojování s webem a webovými službami a zredukovat množství kódu nutného pro přípravu portu Qt na jinou platformu. Přechod by ale neměl být bolestivý, jako tomu bylo mezi Qt 3 a 4.
Tiskni
Sdílej:
Utf-16 prakticky má taky všechny znaky stejně dlouhý.Právě to slovo „prakticky“ dělá z utf-16 ten největší průser. Sám jsi tím dokázal, že obyčejný programátor si může myslet, že utf-16 je fixed-size a na zákadě toho ho implementovat špatně. V případě utf-8 se to může stát taky (viz třeba špatný návrh pythonu 2 ohledně unicode). Hlavní rozdíl je v tom, že u utf-8 se na to velmi rychle přijde a chyba se odhalí. V případě utf-16 ta chyba může zůstat neodhalená roky. A protože jde o disproporci mezi délkou řetězce ve znacích a délkou řetězce v dvoubajtech, může to vést na špatnou velikost bufferu, a tím až hrubou bezpečnostní chybu, která by se v utf-8 dřív a snáze odhalila.
Sám jsi tím dokázal, že obyčejný programátor si může myslet, že utf-16 je fixed-size a na zákadě toho ho implementovat špatně.No to může, co s tím můžu dělat
Že utf-8 je "blbuvzdornější", to asi je... ale za určitou (výkonnostní) cenu.
A protože jde o disproporci mezi délkou řetězce ve znacích a délkou řetězce v dvoubajtech, může to vést na špatnou velikost bufferu, a tím až hrubou bezpečnostní chybuNo, pokud si někdo špatně naimplementuje utf-16 - ie bude si myslet, že je fixed-sized, pak když mu přijde na vstup string se surrogate pairs, bude ten string považovat za delší co do počtu znaků a správně dlouhý co do počtu bajtů, takže se imho nestane, že by naalokoval menší buffer, než je třeba.
o to může, co s tím můžu dělatNemám v ruce reálná data, ale to ty nejspíš taky ne. Výkonový rozdíl utf-8 si dovolím odhadovat jako naprosto bezvýznamný.
No, pokud si někdo špatně naimplementuje utf-16 - ie bude si myslet, že je fixed-sized, pak když mu přijde na vstup string se surrogate pairs, bude ten string považovat za delší co do počtu znaků a správně dlouhý co do počtu bajtů, takže se imho nestane, že by naalokoval menší buffer, než je třeba.To je dost krátkozraký pohled. Ony se totiž při tvorbě software někdy používají knihovny nebo dokonce na jednom software pracuje více lidí. Nikdo ti nezaručí, že se programátoři budou plést konzistentně.
Výkonový rozdíl utf-8 si dovolím odhadovat jako naprosto bezvýznamný.Bezvýznamný pravědpodobně nebude. Validace utf-16 je algoritmicky o hodně jednodušší (jeden snadno předvídatelnej if) a narozdíl od utf-8 máš v ~95% případů konstatní přístup k prvku stringu, kdežto v utf-8 lineární vždy/velmi často.
"If the programming environment is not an issue, UTF-16 is recommended as a good compromise between elegance, performance, and storage."[odtud]
Ony se totiž při tvorbě software někdy používají knihovny nebo dokonce na jednom software pracuje více lidí. Nikdo ti nezaručí, že se programátoři budou plést konzistentně.Heh, neber to tak doslova, pochopitelně nepředpokládám, že by programátoři dělali chyby konzistentně. Mně se stejně opravdu nechce diskutovat na téma "standard X je špatný, protože programátor by ho mohl špatně pochopit."
Bezvýznamný pravědpodobně nebude. Validace utf-16 je algoritmicky o hodně jednodušší (jeden snadno předvídatelnej if) a narozdíl od utf-8 máš v ~95% případů konstatní přístup k prvku stringu, kdežto v utf-8 lineární vždy/velmi často.Což nic nemění na tom, že je to podle mě bezvýznamné.
Mně se stejně opravdu nechce diskutovat na téma "standard X je špatný, protože programátor by ho mohl špatně pochopit."Standard X je horší než standard Y, pokud se už předem dá předpokládat, že povede na chybné a nebezpečné implementace, zatímco standard Y už z principu nabízí daleko rychlejší objevení chyb :). Prostě UTF-16 je pouhý hack který vznikl z šestnáctibitového Unicode, který už byl překonán.
UTF-8 je taky hack, takže bych se raději zabýval tím, jaké jsou výhody/nevýhody v praxi, která jasně ukazuje, že UTF-16 je poměrně dobrý kompromis mezi výkonem a spotřebou paměti.Nepřesvedčil jsi mě.
No tak si zkus napsat nějakou funkci na manipulaci se stringem, třeba funkci, která vrátí substring od pozice m do n nebo tak něco, a porovnej si implementaci pro utf-8 a utf-16. Chápu, že na tvém 6-jádrovém Core i7 nebude rozdíl moc vidět, na nějakém mobilním ARMu apod. už to ale je něco jinýho...Psal jsem kdysi... Běžně ale počítač používám k jiným účelům než testování rychlosti rutin pro počítání znaků v řetězcích.
Běžně ale počítač používám k jiným účelům než testování rychlosti rutin pro počítání znaků v řetězcích.Je mi to jasný
:p
Mi bohatě stačí, když mají rozum návrháři knihoven typu Qt;)
The current plans for Qt5 mean that, unlike Qt4's reinvent the world approach (which was needed, if painful), it will be evolutionary and far less disruptive. This is the good news.Nevypada to tak.
Já jsem kdysi taky měl k JavaScriptu averzi, ale pokud se jednou podíváte na jeho model a hlouběji pod pokličku, tak zjistíte, že je vlastně velice dobře navržený. Hádám, že vývojáři Qt se na něj podívali a zjistili, že se k jejich záměrům hodí.
Adaptivní optimalizace. JVMko dělá něco podobného: např. když se zjistí, že dané volání, byť je třeba na proměnné typu rozhraní, je ve skutečnosti vždycky na jedné konkrétní třídě, tak ho devirtualizuje a z vyhledání metody udělá přímé volání s jednoduchou kontrolou. Pokud se někdy později stane, že se tam dostane objekt jiné třídy, tak to volání deoptimalizuje.Na jednu stranu ano, ale na druhou stranu v JS se díky obrovské dynamičnosti strašně špatně dělá ta kategorizace (kdežto ve staticky typovaném jazyce je tato informace známá). I když si v JS udělám třídu, tak do ní můžu dynamicky narvat další členy, čímž tuto optimalizaci zruším (a nebo se dostanu do fáze, kdy VM bude stále dokola patchovat kód, ale toto je asi ošetřené podmínkou 1x a dost). Javascript se začíná používat na hodně interaktivní grafické hračky, kde bych optimalizace uvítal. Já osobně věřím, že je možné jít ještě dál, ale staticky typované jazyky prostě mají tu hranici jinde, to je to:)
Ono v zásadě JVMko je taky virtuální mašina pro dynamicky typované jazyky (invokeinterface nezná typ cílového objektu a musí příslušnou metodu vyhledat za běhu, což má dokonce na různých JVMkách různou složitost), akorát že při nahrávání kódu se provádí verifikaceNo já osobně bych byl opatrnější v takovém tvrzení. Ono JVM využívá toho, že ty metody a jejich prototypy je možné získat z kompilovaných tříd, takže je logické, že můžu zavolat metodu v objektu, jehož typ neznám v době kompilace (já jsem něco takového používal třeba pro RPC). Na druhou stranu (nevím jak nejnovější JVM) je toto zjišťování poměrně drahé, řekl bych, mnohem dražší než v případě V8, kde je ta dynamičnost built-in. Ale toto všechno jen potvrzuje to, co si myslím - občas je vhodné mít dynamické typy, občas je lepší mít typovou kontrolu na úrovni jazyka. Mít možnost kombinovat statické/dynamické typování (takže mít výhody obou) mi přijde jako ta správná cesta, která by se mohla prosadit i v korporátní sféře.
v JS se díky obrovské dynamičnosti strašně špatně dělá ta kategorizace (kdežto ve staticky typovaném jazyce je tato informace známá). I když si v JS udělám třídu, tak do ní můžu dynamicky narvat další členy, čímž tuto optimalizaci zrušímVyrobí se nová třída, zneplatní se pár callsite a jede se dál
Dobře, není to tak jednoduché, vlastně je to docela magie, ale není to žádná tragédie. IMHO javascriptové virtuální mašiny jsou s optimalizacemi teprve na začátku. C/C++ z toho nebude nikdy, ale už dneska na tom JavaScript není výkonnostně nijak špatně. Výpočetně náročná místa asi bolí (nemůžu pořádně říct), ale ta řekl bych nebudou nijak závratně dynamická. Naopak může bolet to, že JavaScript má jeden jediný (hloupý) číselný typ, takže co by stačilo udělat v celých číslech se zbytečně počítá v plovoucí řádové čárce. Takových věcí asi bude víc.
Naopak může bolet to, že JavaScript má jeden jediný (hloupý) číselný typ, takže co by stačilo udělat v celých číslech se zbytečně počítá v plovoucí řádové čárce. Takových věcí asi bude víc.Toto na x86 problém není, ale na takovém ARMu celkem i jo
), ale na věci okolo je IMHO dostatečně výkonný už dneska.
hlavně ať se co nejdřív podaří z běžných desktop aplikací vymlátit C/C++Wtf! Blábol týdne...
Je to takovy scriptovaci Cecko. Kdyz se odhodi ta prisehna obludarna, kterou je JS ovesenej v browserech, tak je to prekvapive fajn jazyk. Navic mu intitivne rozumi skoro kdokoliv.
Když odhodím to obludárium, tak dostanu jazyk, ve kterém nejde napsat ani knihovna:)No, zato v něm lze triviálně napsat systém, který knihovny implementuje. Existuje pro to poměrně široce přijímaná specifikace. To zamlčuješ proto, že o tom nevíš?
10.5.2011 17:25
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
10.5.2011 12:49
11.5.2011 12:15
Row {
PushButton { width: parent.width / 2 ...}
PushButton { width: parent.width / 2 ...}
}
s layoutmi sa to dalo poriešiť jednotucho ako
QVBoxLayout *layout = new QVBoxLayout(this); layout->addWidget(btn1); layout->addWidget(btn2);Riešenie s layoutmi sa mi zdá ďaleko elegantnejšie. Na rozdiel od QML mi layouty zaručia, že okno bude mať určitú minimálnu veľkosť odvodenú od veľkosti komponentov. Nehovorím, že sa podobné správanie nedá dosiahnuť pomocou QML, ale pripadá mi to ako riešenie pre psychopatov. Robili ste niekto niečo ako layouty pre QML? Neviete, či v Qt 5 bude niečo pre automatické umiestňovanie komponentov?
10.5.2011 19:54
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
10.5.2011 19:11