AlmaLinux OS byl vydán ve verzích 9.8 s kódovým jménem Olive Jaguar a 10.2 s kódovým jménem Lavender Lion. Podrobnosti v poznámkách k vydání (9.8 a 10.2). Opraveny byly zranitelnosti Copy Fail (CVE-2026-31431), Dirty FRAG, Fragnesia (CVE-2026-46300), nginx Rift (CVE-2026-42945) a SSH Keysign Pwn (CVE-2026-46333).
Seznam.cz vykázal za rok 2025 tržby v celkové hodnotě 6,454 miliardy korun. Oproti roku 2024 nárůst o 3,68 %. Zisk před zdaněním oproti předcházejícímu roku poklesl, a to o 11,21 % na 1,330 miliardy korun. Vlastní velké jazykové modely SeLLMa najdou dnes uživatelé téměř na všech seznamáckých službách. Na všechny obsahové služby byla zavedena technologie text-to-speech, díky níž si mohou uživatelé přehrát články v audio verzi namluvené
… více »Vláda představila strategické digitalizační projekty. Roadmapa zahrnuje celkem 55 projektů napříč státní správou, z toho 22 prioritních projektů vycházejících přímo z programového prohlášení vlády a 33 projektů založených na platné legislativě. Portfolio pokrývá oblasti financí, zdravotnictví, digitální identity, dat, registrů, dopravy, krizového řízení, sociálních agend i kybernetické bezpečnosti.
Vyjádřeni Software Freedom Conservancy (SFC) k porušování licence AGPLv3 společností Bambu Lab v jejich softwaru Bambu Studio pro 3D tisk. Bambu Studio vychází z PrusaSliceru. Ten zase z Slic3ru. Spuštěn byl projekt baltobu, který kombinuje několik strategií pro řešení problému. SFC zastřeší vývoj svobodné náhrady proprietární knihovny libbambu_networking pomocí reverzního inženýrství a reimplementace, forku OrcaSliceru pro Bambu Lab tiskárny od Paweła Jarczaka a forku celého Bambu Studia pod názvem Viscose.
Správce souborů GNOME Commander (Wikipedie) byl přepsán do Rustu a vydán v nové verzi 2.0.0.
Sway (Wikipedie), dlaždicový (tiling) správce oken pro Wayland kompatibilní s i3, byl vydán ve verzi 1.12. Do vývoje se zapojilo 50 vývojářů. Přehled novinek na GitHubu. Sway 1.12 závisí na wlroots 0.20.0.
Papež Lev XIV. ve své první encyklice Magnifica Humanitas (Skvělé lidství), která se věnuje umělé inteligenci (AI), varoval před dezinformacemi, které AI manipulací s obsahem vytváří. Moc mají podle něj sociální sítě ovládané hrstkou soukromníků. Upozornil také roli digitálních platforem v obchodování s lidmi, které podle něj musí být uznáno jako současná forma otroctví. Papež se také poprvé omluvil za roli, kterou Vatikán sehrál při legitimizaci otroctví, a za to, že jej po staletí neodsoudil.
Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2025 (pdf), která shrnuje jeho hlavní aktivity v oblasti regulace elektronických komunikací, poštovních služeb, digitálních služeb a přípravy na dohled nad umělou inteligencí. Součástí zprávy jsou také data o vývoji trhu, včetně pokračujícího růstu spotřeby mobilních dat a rozšiřování sítí nové generace. Celkový objem přenesených mobilních dat dosáhl v roce 2025 přibližně
… více »Tým sdružení CZ.NIC vyvíjející routovacího daemona BIRD oznámil vydání nových verzí 3.3.0 a 2.19.0. Ty přinášejí podporu pro EVPN/VXLAN a automatizaci BGP na základě router advertisementů. Více informací je k dispozici v archivu uživatelského mailing-listu.
Open source software pro úpravu digitálních fotografií LightZone (Wikipedie) byl vydán v nové verzi 5.0.0. LightZone je dnes k dispozici pod licencí BSD. Původně se jednalo o proprietární software vyvíjený společností Light Crafts. Ta v prosinci 2012 souhlasila s uvolněním zdrojových kódů jako open source [Wayback Machine].
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