Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »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
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: