Všem vše nejlepší do nového roku 2026.
Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.60. Vyzkoušet lze online demo.
Daniel Stenberg na svém blogu informuje, že po strncpy() byla ze zdrojových kódů curlu odstraněna také všechna volání funkce strcpy(). Funkci strcpy() nahradili vlastní funkcí curlx_strcopy().
Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Kdyby se NIC.CZ radeji vykaslal na televizni reklamy na CT1 a dal DNSSEC zadarmo, tak to bude lepsi.CZ.NIC dát DNSSEC zadarmo nemůže, protože je to věcí provozovatelů DNS serverů (tj. obvykle registrátorů). Resp. CZ.NIC na svých serverech DNSSEC má a je to již v ceně domén pro registrátory; zbývá tedy ten článek, co je u registrátorů.
Nevím o tom, že by se někdy někde za DNSSEC platilo, prostě ho registrátor buď podporuje a pak ho poskytuje jako součást služby, nebo ne.Nelze vyloučit, že někde se za to platí. Nebo spíš dříve platilo, dnes už to asi bude jen úplně výjimečné.
Zajímalo by mě, kolik zákazníků jim to zaplatí.Asi dost. Tak jako stále platí za české domény třeba 300 Kč ročně. Nebo jako platí za domain-validated certifikáty 2000 Kč za kus ročně a při reissue to zaplatí znovu. Často totiž vůbec nevědí, že to lze mít levněji (protože si to třeba pořídili před lety a pak každoročně vždycky jen zaplatí fakturu, která přijde).
Mimochodem, nezdražili u Active 24 .cz domény?Nevím, u Active24 jsem pořizoval domény jen v té jejich vypečené akci (15 Kč/ks), na které za pár hodin prodělali kalhoty
Za rok jsem je pak samozřejmě převedl jinam, protože není důvod platit o desítky procent víc.
Docela by mě překvapilo, kdyby jejich - obvykle méně významná - konkurence za to něco chtěla.Některé firmy fungují tak, že jejich obchodníci obvolávají firmy a okecávají to tak, že jim leckdo sedne na lep, pokud věci nerozumí (teď nemluvím o skutečných podvodnících, jen o firmách prodávajících "leštěný prd"). Proto za to mohou klidně peníze chtít a také je dostanou. Od někoho.
Horší je to s cizími doménami, ale tam podle všeho většinou hraje/hrála roli spíš absence potřebného API pro automatizované úpravy DS záznamů. Tam by mě poplatek za ruční úpravy zase tolik nepřekvapil.Po různorodých zkušenost každému radím, ať si pořízení nějaké cizí (nebo generické) domény stokrát rozmyslí. Takové ty situace, kdy se po 5 pokusech nepovede z neznámých důvodů změnit registrátora (a pokaždé to jen stojí peníze), bohužel nejsou vůbec řídké. Subregistrátor se vymlouvá na registrátora, ten zase na druhého registrátora, ten na subregistrátora ... nikdo za nic nemůže, peníze mizí a operace neprobíhá. Plus další problémy, například ty mé oblíbené s doménou .name. Tohle za to fakt nestojí. Pokud někdo chce cizí doménu jen proto, že příslušná česká je obsazená, ať si raději vybere nějakou jinou českou.
A je to velmi jednoduché, s nasazováním IPv6 se to naprosto nedá srovnat.Na straně provozovatele webu je podle mě IPv6 a DNSSEC úplně stejně jednoduché, případně se dá říct, že složitost závisí jen na tom, jak moc to provozovatel hostingu komplikuje. V roli webhostingu je IPv6 podle mě jednodušší, ale ani DNSSEC nevidím jako nějakou krizi. Obě dvě technologie trpí na klientské straně. Nejvýraznější rozdíl mezi nimi vidím v tom, že DNSSEC lze provozovat bez podpory ISP.
V roli webhostingu je IPv6 podle mě jednoduššíV roli webhostingu je jednodušší DNSSEC, protože ho webhoster vůbec řešit nemusí - pokud neprovozuje vlastní DNS servery a nechává vše na svém registrátorovi (což může být mnohem snazší a levnější - ve svém nástroji pro registraci domén prostě přidá pár funkcí k API registrátora navíc).
A je to velmi jednoduché, s nasazováním IPv6 se to naprosto nedá srovnat.
Tak s tím bych s dovolením polemizoval. Zatímco u IPv6 prostě dostaneš rozsah "a je to", tak u DNSSEC musíš pro každou zónu: podepsat, odeslat podpisový klíč správci vyšší domény a dále pravidelně znovu podepisovat všechny zónové soubory.
Ano, dneska už jsou lepší nástroje na údržbu podepsaných zónových souborů, ale ty zbývající úkony, zejména nutnost kontaktovat správce nadražené domény, je docela velká komplikace.
Celkem by mě zajímalo, jak kdo má tohle řešené, předpokládám, že velcí správci záznamů (jako například Active24) mají se správcem domény .cz domluvené nějaké nadstandardní API, ale co v případě malého správce s několika stovkami zónových souborů? Zkrátka nějaké best practice. 
Zatímco u IPv6 prostě dostaneš rozsah "a je to"Není to. Musí ho podporovat všechny serverové aplikace, což u těch běžných samozřejmě není problém, ale u těch exotičtějších se to někdy musí řešit přesměrováním portů nebo jinými technikami, protože tam nativní podpora IPv6 prostě není.
Celkem by mě zajímalo, jak kdo má tohle řešené, předpokládám, že velcí správci záznamů (jako například Active24) mají se správcem domény .cz domluvené nějaké nadstandardní API, ale co v případě malého správce s několika stovkami zónových souborů?Velcí správci bývají zároveň registrátoři a se správcem domény .cz komunikují přes API. Malý správce může využít místo svých DNS serverů využití servery svého registrátora a nemusí tedy tuto problematiku vůbec řešit.
Malý správce může využít místo svých DNS serverů využití servery svého registrátora a nemusí tedy tuto problematiku vůbec řešit.
Hmm, v tom případě muže i další služby využívat jinde čímž by tito malí poskytovatelé zanikli a zbyl by pouze jeden globální velký. Takže ano může, ale co když si chce vše spravovat sám?
v tom případě muže i další služby využívat jinde čímž by tito malí poskytovatelé zanikli a zbyl by pouze jeden globální velkýNení pravda. Je na zvážení pro každou konkrétní službu, zda je z různých aspektů výhodnější ji brát od někoho jiného nebo ji řešit interně. Není to rozhodně černobílé.
Takže ano může, ale co když si chce vše spravovat sám?Pak se ale musí stát i registrátorem (protože jinak ho na mezi sebou a správcem bude stejně mít) a tedy splnit všechny podmínky pro to, aby registrátorem mohl být (tj. včetně složení příslušné zálohy na úhradu poplatků). Je otázka, zda je výhodnější mít DNS servery zdarma (resp. již v ceně domén) u zvoleného registrátora a nemuset se téměř o nic starat nebo na vlastní náklady tyto servery provozovat a zajišťovat si všechno vlastními silami.
Malý správce může využít místo svých DNS serverů využití servery svého registrátora a nemusí tedy tuto problematiku vůbec řešit.A rozcilovat se pokazde s pitomym webovym rozhranim registratora kdyz chci zmenit libovolny DNS zaznam. Dekuji nechci.
O DNSSEC se to říct nedá.Tady je potřeba rozlišovat formální podporu DNSSEC na straně serveru a reálnou podporu na DNSSEC postavených technologiích.
Zatímco pro využití IPv6 je alespoň minimální podpora na straně aplikace nutnáTo není tak úplně pravda. Mnoho (serverových) aplikací lze používat tak, že si ani nevytvářejí vlastní komunikační kanál, ale dostanou ho již vytvořený. A nebo používají výstupy z getaddrinfo(), které sice vzniklo s IPv6, ale umí být zcela neutrální.
pro DNSSEC to potřeba neníIdeální samozřejmě je, aby aplikace DNSSEC používala jen prostřednictvím knihoven, což ve většině případů platí i pro IPv6.
nebo dostane odpověď, že doména neexistuje (pokud validace selže).To je pravda. Nepodporující aplikace dostane tuto nepravdivou/neúplnou informaci.
protože aplikace už tím pádem IP adresy logovat nemůžeI aplikace, ktera dostava jiz vytvorena spojeni, muze logovat jejich adresy. Viz funkce getpeername() a getsockname().
I přes mohutnou propagaci DNSSEC ze strany sdružení CZ.NICŘekl bych, že právě v tom bude ten problém...
Tiskni
Sdílej: