Na YouTube lze zhlédnout nový celovečerní dokumentární film The Story of VS Code | Official Documentary věnovaný Visual Studio Code.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová stabilní verze 8.2 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 152. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána nová stabilní verze 4.0 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). S rozhraním přepsaným do Qt. Přehled novinek také na YouTube. Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
NVIDIA kupuje Hugging Face za 12,93 miliardy dolarů.
Předobjednat si lze nový jednodeskový počítač Arduino VENTUNO Q s předinstalovaným Ubuntu. S 16 GB LPDDR5 a 64 GB eMMC. Pro lokální LLM, agentní AI, počítačové vidění, robotiku…
Hexpair není nejlepší HEX editor na světě a ani se o to nesnaží. Zato je k dispozici kdykoliv a kdekoliv – všude tam, kde máte svůj Vim. Vznikl jako hobby projekt před pár měsíci a dospěl do stavu, kdy by mohl být užitečný širší komunitě. Přepnout do HEX režimu se dá i uprostřed rozdělané práce: Soubor, který už máte otevřený běžným vim file.md, jedním příkazem přepnete do HEX editoru a dalším příkazem ho můžete vrátit zpět do textu. Kurzor přitom
CERN dlouhodobě používal vlastní sestavení RHEL, ze kterého přešel na CentOS Stream. Federico Vaga a Nikos Tsipinakis ale nyní v přednášce na MiniDebConf Winterthur 2026 popisují plán probíhajícího přechodu na Debian pro řízení akcelerátorů. Důvodem k opuštění CentOS Stream jsou zachování zpětné kompatibility se starším hardwarem, kterou Red Hat narušuje, když tlačí sestavení balíčků pro novější verze architektury (x86-64), a nedostatečné nástroje pro sestavování vlastních balíčků a repozitářů.
UZDoom (Wikipedie), tj. fork GZDoom, byl vydán ve verzi 5.0.0. Videopředstavení na YouTube. Podrobný přehled novinek v Changelogu.
<ShareKeys/> v kasp.xml (to je předpokládám jediný způsob). Po vygenerování prvních tří domén (A, B, C) všechno vypadalo OK, Keytag KSK byl u všech stejný, automatická rotace ZSK taky probíhala bez problémů a obecně všechno fungovalo jak má.
V průběhu roku jsem přidal další dvě zóny (D, E) k podepisování, opět bez problémů.
Nicméně o víkendu nastal čas rotace KSK, když jsem zjistil, že jsem buď udělal něco špatně, nebo sdílení klíčů funguje jinak než jsem čekal. Moje představa byla taková, že ten sdílený klič je globálně jeden, s jednou platností a při jeho rotaci jen umístím novou verzi k registrátorovi, jednou zavolám ds-seen a na rok bude zase klid.
Ve skutečnosti se ale ukázalo, že rotace byla požadovaná jen pro ty tři nejstarší domény a pro každou zvlášť jsem musel zavolat ds-seen. Původní KSK jsem v keysetu u registrátora nechal, jen jsem přidal nový klíč, takže překlad všech domén pořád funguje, ale nevím, jestli je to správný postup. Například netuším, co se stane, až dojde na rotaci u těch dalších dvou domén. Použije se ten právě vytvořený KSK nebo se vygeneruje další?
Takže můj dotaz je: udělal jsem někde chybu, nebo je tohle normální průběh? Díky.
Přikládám výpis existujících klíčů (KSK 29793 byl původně jako KSK i u domén A, B a C):
# ods-ksmutil key list --verbose Keys: Zone: Keytype: State: Date of next transition: Keytag: domenaA ZSK retire 2016-06-02 19:38:55 58674 domenaA ZSK active 2016-06-25 06:38:55 25407 domenaA KSK active 2017-05-29 20:55:13 29133 domenaB ZSK retire 2016-06-02 19:38:55 58674 domenaB ZSK active 2016-06-25 06:38:55 25407 domenaB KSK active 2017-05-29 20:55:01 29133 domenaC ZSK retire 2016-06-02 19:38:56 58674 domenaC ZSK active 2016-06-25 06:38:56 25407 domenaC KSK active 2017-05-29 20:52:36 29133 domenaD KSK active 2016-08-14 08:51:22 29793 domenaD ZSK retire 2016-06-02 19:38:56 58674 domenaD ZSK active 2016-06-25 06:38:56 25407 domenaE KSK active 2016-11-13 09:41:35 29793 domenaE ZSK active 2016-06-10 13:41:45 58674
Řešení dotazu:
Tiskni
Sdílej: