Společnost Google Cloud dnes oznámila, že její infrastruktura a služby byly oficiálně zařazeny do Katalogu cloud computingu vedeného Digitální a informační agenturou (DIA). Tato certifikace potvrzuje, že infrastruktura a služby Google Cloud splňují přísné bezpečnostní a regulační požadavky České republiky pro provoz cloudových služeb ve veřejném sektoru.
Vůbec poprvé v historii se stát při testování digitálních služeb obrací na širokou veřejnost. Digitální a informační agentura (DIA) a Ministerstvo vnitra zvou občany k zapojení do zátěžového testu eDokladů, které od loňského podzimu prošly optimalizací aplikace a posílením infrastruktury. Test proběhne 13. srpna ve 13:00 a pro jeho úspěch bude potřeba zapojení několika desítek tisíc občanů. Zapojení do testu je zcela dobrovolné a úkol
… více »FireDragon je webový prohlížeč, doposud založený na Floorpu, jednom z forků Firefoxu s větším důrazem na ochranu soukromí a přizpůsobení uživatelského rozhraní. Spravuje ho člen komunity distribuce Garuda Linux. Nové vydání verze 13 opouští Floorp a přechází přímo na Firefox s patchi z LibreWolfu a vlastními úpravami. Dostupný je také na Flathubu.
picogame (GitHub) je malý 2D herní engine pro mikrokontroléry jako RP2040, čip uvnitř kapesní konzole Picopad. Hru napíšeš v Pythonu a vyzkoušíš ji v prohlížeči nebo desktopovém simulátoru. Až bude hotová, zkopíruješ ji na podporovanou desku. Na začátku nepotřebuješ C, sestavení firmwaru ani hardware.
Multiplatformní prohlížeč elektronických knih KOReader byl vydán ve verzi 2026.07 "Sailing Walrus". U PDF souborů s SMask lze vyčistit pozadí. Přibyla podpora Kobo v5 nebo základní podpora OPDS 2.0.
Společnost Valve sponzoruje a společnost Collabora portuje RADV (open source Vulkan ovladač pro AMD GPU z projektu Mesa) na Windows.
Starling (GitHub) je desktopové prostředí vytvořeno umělou inteligencí (s dohledem jednoho vývojáře během šesti měsíců).
Dne 30. června 2026 byla završena fyzická realizace projektu Czech National Quantum Communication Infrastructure (CZQCI), tedy České národní kvantové komunikační infrastruktury. Projekt byl realizován od 1. března 2023 a financován z Národního plánu obnovy částkou 121,6 milionu Kč. Cílem podpořeného projektu bylo vybudovat základy národní kvantové komunikační infrastruktury a ověřit možnosti jejího praktického využití. Mezi
… více »Město Šumperk se stalo terčem kybernetického útoku, chod úřadu je omezen. Zjišťuje se, jestli unikla nějaká data. Cílem hackerů byla městská datová síť. První útoky zaznamenali odborníci na informační technologie již v pondělí večer, závady se ale plně projevily až dnes ráno. Město událost nahlásilo Národnímu úřadu pro kybernetickou a informační bezpečnost (NUKIB).
Samba, svobodná implementace síťového protokolu SMB/CIFS, byla vydána ve verzích 4.24.5, 4.23.10 a 4.22.11. Řešeno je 6 zranitelností.
Kdysi jsem si chtěl udělat vlastní webové stránky. Hezké, čisté jednoduché. Ve své třetí verzi jsou stále ve vývoji a technologii jsem věnoval tolik času, že se příliš nedostává na obsah. Vyzkoušel jsem všechny možné jazyky, technologie, CMS, frameworky a jiné buzzwordy, bez přílišného výsledku. Přestože si rád hraju s různými technologiemi, pořád je to pro mě hlavně o obsahu a pohodlná práce s ním je pro mě klíčová. Představuji si web, který se točí kolem dokumentu, jako původní ideály prastarého HTML, jen trochu pohodlnější. Ovšem kromě lidsky zpracovatelného obsahu (nápady, zamyšlení, pohádky...) tu máme i obsah, u kterého je výhodnější, aby za nás udělal práci stroj. U projektů chci automaticky generovat sekci stažení podle souborů v download adresáři, zobrazovat changelogy, etc. Myšlenka je jednoduchá — zkombinovat krásu jednoduchých značkovacích jazyků (Markdown, Textile, RST...) se silou programovacího jazyka (v tomto případě Pythonu) vloženého do dokumentu trochu jako PHP...
0. Přirozenost — co nejvíce se přiblížit lidskému myšlení, aby stálo minimální úsilí převést myšlenku do strojem zpracovatelné podoby. Minimalizovat pomyslnou bariéru mezi rozmanitostí lidské mysli a omezeností stroje.
1. Jednoduchost — abych nemusel mít na zdi přivěšenou referenční příručku
2. Neukecanost — (X)HTML je dost "ukecané" (i když oproti Javě úplný břídil) — moc píšete a málo dostanete. Rád bych se vyjádřil za pomoci minimálního množství zbytečných znaků.
3. Univerzálnost — narozdíl od jednoduchých značkovacích jazyků bych rád plně využil plnou množinu XHTML tagů — bez přímého vkládání XHTML kódu, které většinou není řešeno příliš šťastně (např. nejde používat jednoduché značky uvnitř XHTML bloku)
4. Rozšiřitelnost — možnost vytvářet si vlastní "tagy" či příkazy, které se mohou nějakým způsobem převést na XHTML. Ne všechno se dá řešit přes CSS a ne vždy je to žádoucí. V ideálním případě obecně rozšiřitelná syntaxe (prostřednictvím nějakých regexů či gramatik), aby se vlastní příkazy daly vkládat nejen použitím jakési obecné syntaxe, ale třeba i jejich vlastní. Základ by měl obsahovat v ideálním případě jen naprosto minimální obecnou syntaxi, zbytek doplní jednotlivé moduly. Dá-li Bůh.
5. Kontextovost — plně kontextová gramatika, která např. umožní zpracování všech řádkových značek uprostřed nově vytvořeného blokového tagu, který o nich nemusí mít ani ponětí. Prostě nastaví, že chce obsah zpracovat v řádkovém kontextu.
6. Programovatelnost — podpora rozumného vkládání Pythoního
kódu (případně s rozšířením na další programovací jazyky),
blokový exec příkaz, klasická eval syntaxe $proměnná
a ${výraz}. Jednoduché vkládání řídících konstrukcí
(if, for, ...), jejihž obsahem není kód, ale kus dokumentu.
Vhodné pro generovaná data jako tabulky apod.
7. Objektovost — každý "kus dokumentu" — tedy nějaký text, prvek, nebo jejich posloupnost, i celý dokument, by měl být schopen být reprezentován nějakým objektem — nad kterým půjde udělat nějaké zpracování, a hlavně jej půjde na nějaké místo nějakého dokumentu zase vložit — tímhle by se daly řešit layout šablony a podobné
8. Sémantičnost — výsledkem by měly být výhradně sémantické značky, i při použití vlastních. Vzhled se vyřeší odděleně. Minimalizovat "režijní" tagy nutné z technických důvodů (i když to ne vždy lze).
9. Lineárnost — zpracování lineárním, ideálně jednoprůchodovým parserem, bez nutnosti přednačtení celého vstupu do paměti. Možnost zpracování dat z pajpy.
10. Strukturovanost — jasná, logická, vnořovatelná struktura. Musí být jasné co k čemu patří. Nepoužívat pevné úrovně nadpisů (kdo se s tím má přepisovat, když zjistí, že chce celou sekci zabalit do jiné?)
Jednak je třeba zachovat jednoduchou syntaxi, na kterou jsou
všichni zvyklí (prázdný řádek oddělující odstavce,
*zvýraznění*, etc.), ale druhak také vytvořit syntaktická
pravidla obecná, pro vkládání libovolných příkazů, která ovšem
nesmí být příliš složitá nebo jít na obtíž. Ideálně by si měla
vystačit s minimálním počtem speciálních znaků, aby ostatní
zbyly na "volná" syntaktická pravidla.
Následuje spíše taková sbírka hrubých nápadů, rád budu za jakékoliv připomínky:
Základem syntaxe je příkaz. Každý příkaz musí mít dopředu definováno, v jakém kontextu/režimu se může vyskytovat. Celý parser funguje jako takový state machine, svým způsobem. Žádný příkaz nemůže být současně řádkový i blokový, protože by se nepoznalo, o který případ jde, pokud by se vyskytl na začátku bloku.
Každý příkaz má parametry, nejspíše poziční i pojmenované, jako jsme zvyklí z Pythonu, a případný textový obsah, který může případně obsahovat i další prvky. U blokových příkazů jsou možné dvě základní podoby syntaxe: odsazená (nám Pythonistům dobře známá) a s explicitním ukončením (ala Ruby či Pascal). Myslím, že obě mají něco do sebe (při psaní textu by odsazení mohlo být nepříjemné, ale v dokumentu, kde převládá struktura — např. layoutu stránek — by zvýšilo přehlednost), proč tedy neimplementovat obě? Třeba takto:
:section
text
:section
podsekce
:end
pokračuje sekce
:end
a :section: Tady máme nějaký text :code: and some(code) a tak dále...
Samozřejmě případně libovolně kombinovat. Dvojtečka jako začátek
příkazu je používána z čistě estetických důvodů — pokud by se
ukázalo, že je potřeba v textu příliš často, není problém zvolit
jiný znak. Jinak se samozřejmě dá escapovat příkazem ::.
Pokud mají inline příkazy textový obsah, asi by odsazení nebylo příliš vhodné, myslím, že docela hezky by mohl vypadat například následující zápis:
Toto je odstavec s :em{zvýrazněným} písmem a odkazem na
:link http://seznam.cz;
Středník je nutný aby se poznal konec příkazu, protože narozdíl
od blokového, který můžeme uzavřít koncem řádku, za ním ještě
může následovat další text. Ovšem po ukončovací } již není
třeba, jak jistě všichni céčkaři chápou;)
S takto překvapivě jednoduchou syntaxí, která si vyžádala
obětování defacto dvou znaků (v kontextu běžného textu se mohou
objevit jen : a }) už se toho dá udělat docela hodně.
A na první pohled to vypadá i čitelně:
:header První dokument
:section
:header Úvod
V dokumentu se mohou vyskytovat různé věci. Třeba takové
:img obrazky.png Obrázky;, :link http://seznam.cz{
Odkazy}.
:if 'MSIE' not in environ['HTTP_USER_AGENT']:
:link #{:img $logo; :)}
Ony tam jdou i obrázkové odkazy, ale Exploreristům
:strong{ani muk}.
:end /*konec sekce*/
Ale jistě by se to dalo udělat ještě čitelněji s trochou syntax sugaru...
První dokument
==============
Úvod
<<<< /*nadpis začánající sekci — jen ukázka, nevím, jestli
to k něčemu bude */
:defimg logoimg $logo
:defimg obr obrazky.png Obrázky
:deflink imglink #{[logoimg]{logo} :)}
:deflink ukazka http://seznam.cz{Odkazy}
V dokumentu se mohou vyskytovat různé věci. Třeba takové
[obr], [ukazka].
:if 'MSIE' not in environ['HTTP_USER_AGENT']
[imglink]
Ony tam jdou i obrázkové odkazy, ale Exploreristům
**ani muk**
:end MSIE /*end ignoruje vše za ním — můžeme si třeba popsat co končí*/
>>> /*konec sekce; nic lepšího mě zrovna nenapadlo*/
Základní trik se jmenuje vkládané objekty a ve většině podobných věcí je dnes běžný. Prostě si definuji objekt (odkaz, obrázek, …) a později se na něj odkazuji. Jen narozdíl od jednoduchých jazyků nebude v duchu průběhu programu shora dolů možné implementovat používání objektů nad jejich definicí, třeba všechny odkazy definovat na konci odstavce, etc.
Při samotném vložení objektu se někdy hodí změnit/doplnit určité parametry,
jako např. v ukázce výše textový obsah. Měnit můžeme i jiné parametry,
např. [mujimg alt=Nějaký popisek|title=Titulek] (možná by byla
přijatelnější qouted syntaxe [mujimg alt="Nějaký popisek" title=Titulek]
...
Ukázky zmíněné víše jsou jen takovým hrubým nástinem obecné idey a rád bych slyšel také názory a náměty jiných. Zatím to vypadá, že z toho vznikne ne-zcela-texu-nepodobné monstrum se složitým syntaktickým aparátem, ale doufám, že pro člověka trochu čitelnější a hlavně zaměřené na XHTML výstup a tedy i webové prezentace...
Tiskni
Sdílej:
Co Lisp? (to bude flame...)
(header První dokument)
(section
(header Úvod)
V dokumentu se mohou vyskytovat různé věci. Třeba takové
(img obrazky.png Obrázky)(link http://seznam.cz Odkazy)
(if 'MSIE'
(link (img $logo ))
Ony tam jdou i obrázkové odkazy, ale Exploreristům
(strong ani muk).
)
)
Tohle by se mi fakt líbilo. 
No ja tedy nevim, ale mysl, ktera by se lepe pracovalo s XML nez s vyse uvedenym zapisem, ma k te moji hodne daleko.
No vida, nemyslel jsem to predtim uplne vazne, ale tohle je fakt hezke. Jeste poresit escapovani zavorek (a dalsich znaku) a je vymalovano. Mozna by bylo lepe pouzit hranate - nedavno jsem premyslel nad Lispem s hranatymi zavorkami, maji tu velkou vyhodu, ze maji na klavesnici vlastni klavesy (resp. ja jsem premyslel nad Lispem, kde by bylo jedno, jakou ze tri zavorek clovek pouzije, pokud by se matchovaly, a tedy by se lepe vizualne pocitaly).
Na originalniho autora - mel byste si podle me predevsim vyjasnit, jestli chcete pravidelnou syntaxi (jako Lisp, HTML nebo obvykle programovaci jazyky), nebo nejakou "lidsky citelnou" (jako maji treba Wiki, YAML nebo ruzne publikacni systemy).
Pravidelna syntaxe ma jasna pravidla, snadno se parsuje pomoci bezkontextove nebo LL(1) gramatiky, jasne escapovani (vetsinou), a jasne definovano, co je syntakticky spravne a spatne. Naopak lidsky citelna syntaxe miva mnohem slozitejsi pravidla a parsery, nejasne ecapovani (pokud vubec) a byva daleko volnejsi, co se tyce zpracovani chyb. Toto rozhodnuti IMHO zasadne ovlivnuje zpusob, jakym bude parser napsany.
Mozna by bylo lepe pouzit 2 jazyky - jeden na markup a druhy na logiku. Kombinovat je do jednoho je nesmyslne.
Líbí se mi myšlenka odkazování na objekty, to by mohlo být hodně užitečné a lehce propojitelné s generovaným obsahem. Ale znamená to nutnost víceprůchodového zpracování.