Google Chrome 126 byl prohlášen za stabilní. Nejnovější stabilní verze 126.0.6478.55 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán Mozilla Firefox 127.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 127 je již k dispozici také na Flathubu a Snapcraftu.
Byla vydána (𝕏) nová verze 9.5 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Společnost Raspberry Pi dnes vstoupila na Londýnskou burzu jako Raspberry Pi Holdings plc (investor).
Do 17. června do 19:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | červen 2024 doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.
Apple na své vývojářské konferenci WWDC24 (Worldwide Developers Conference, keynote) představil řadu novinek: svou umělou inteligenci pojmenovanou jednoduše Apple Intelligence, iOS 18, visionOS 2, macOS Sequoia, iPadOS 18, watchOS 11, …
Vyšla nová verze XMPP (Jabber) klienta Gajim, která přidává podporu reakcí pomocí emoji (XEP-0444: Message Reactions) a citace zpráv (XEP-0461: Message Replies). Přehled dalších vylepšení je k dispozici na oficiálních stránkách.
Po po téměř roce vývoje od vydání verze 5.38 byla vydána nová stabilní verze 5.40 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 75 vývojářů. Změněno bylo přibližně 160 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Laboratoře CZ.NIC vydaly testovací verzi 1.5.0-rc1 autoritativního DNS serveru Knot DNS. Mezi stěžejní novinky patří syntetizování dopředných a reverzních záznamů pro IPv4 a IPv6 adresy, asynchronní načítání zónových souborů a multi-master failover. Nová verze také přináší snížení paměťových nároků a vylepšení po výkonnostní stránce. Velkých změn se dočkal i uživatelský manuál. Odkazy pro stažení naleznete v oficiálním oznámení v mailové konferenci Knot DNS Users.
Tiskni
Sdílej:
Záleží na obsahu zón. Patrně jste koukal pouze na deployment pro Root server. U všech ostatních konfigurací v benchmarku spotřeba paměti mezi 1.4 a 1.5 klesla. Když se podíváte třeba na Hosting (100k zón), tak tam RSS spadla z 3280 MB na 1038 MB.
Podařilo se nám zredukovat některé interní struktury pro ukládání obsahu zóny. Ale také jsme chtěli zvýšit výkon odpovídání pro kořenové servery a TLD, kdy server velmi často vrací delegace. A u delegací je nutné v zóně ještě dohledat záznamy do Additional sekce odpovědi, což tvoří velkou část zpracování dotazu. Takže tyto záznamy dohledáváme už při načítání zóny. Cenou za to je paměť navíc pro zóny, které obsahují velké množství různých delegací, což je právě případ kořenové zóny. Ale to je dost specifický případ.
V každém případě Knot DNS používá hodně velkých hosterů (ne jako výhradní řešení). Napadá mě: .cz doména, .dk doména, Netriplex, RIPE NCC, Hosting90, Igloonet, O2, ...
Obecně doporučujeme postup 1. knotc flush, 2. upravit zónový soubor, 3. zvýšit serial a 4. knotc reload.Promiň mi blbý dotaz, to obecně doporučujeme znamená, že to má i nějaké prominentní místo v dokumentaci nebo se to šíří jen ústně?
Co se trochu zlepšilo je formát zónového souboru. Teď se postupně do souboru zapisují nejdříve "běžné" záznamy, pak RRSIG záznamy a nakonec NSEC/NSEC3 chain. Takže se běžné záznamy nemíchají s těmi automaticky vygenerovanými a ten soubor je výrazně přehlednější.To je skvělý nápad.
Ideální to ale není. Snažíme se najít nějaký lepší způsob a uvítáme nápady.Z diskuze vyplynulo že (1) řešení není zcela triviální a hlavním problémem jsou ta sériová čísla a (2) BIND to nějak řeší. Takže pokud byste měli čas trochu analyzovat jak to funguje v BINDu (já to asi sám nedám, jedině se pobavit s Petrem), docela by mě zajímal výstup a informace jestli je nebo není možné jejich postup aplikovat na Knot a proč.
Promiň mi blbý dotaz, to obecně doporučujeme znamená, že to má i nějaké prominentní místo v dokumentaci nebo se to šíří jen ústně?V dokumentaci to není, takže ústně. Ale mohu se vymluvit na to, že automatické podepisování stále považujeme za technical preview.
Z diskuze vyplynulo že (1) řešení není zcela triviální a hlavním problémem jsou ta sériová čísla a (2) BIND to nějak řeší. Takže pokud byste měli čas trochu analyzovat jak to funguje v BINDu (já to asi sám nedám, jedině se pobavit s Petrem), docela by mě zajímal výstup a informace jestli je nebo není možné jejich postup aplikovat na Knot a proč.Ano, problém jsou především sériová čísla. BIND 9.9 to řeší tak, že si udžuje zvlášt nepodepsanou a podepsanou zónu. A sériová čísla počítá pro nepodepsanou a podepsanou zónu zvlášť. Pokud sériové číslo u nepodepsané zóny je vyšší než u podepsané zóny, tak sériové číslo podepsáné zóny zvedne na stejnou hodnotu. Knot DNS má pouze jeden zónový soubor, jedno sériové číslo a snaží se ho nezvedat, pokud to není potřeba. Oba přístupy mají výhody a nevýhody.
Ale mohu se vymluvit na to, že automatické podepisování stále považujeme za technical preview.A toto už je součástí psané dokumentace, doufám.
BIND 9.9 to řeší tak, že si udžuje zvlášt nepodepsanou a podepsanou zónu. A sériová čísla počítá pro nepodepsanou a podepsanou zónu zvlášť.To mi dává docela smysl.
Oba přístupy mají výhody a nevýhody.Jak moc složité by bylo implementovat v Knotu obojí a volbu nechat na uživateli? Pochopím, když mě s tím pošleš do háje ;).
A toto už je součástí psané dokumentace, doufám.Ano.
Jak moc složité by bylo implementovat v Knotu obojí a volbu nechat na uživateli? Pochopím, když mě s tím pošleš do háje ;).Já osobně bych se přikláněl pro jedno lepší řešení, na kterém se usneseme. Ale nezáleží to jenom na mně. Oddělení nepodepsané a podepsané zóny stále diskutujeme. Líbí se nám to, ale zatím jsme se nerozhodli, jakým konkrétním způsobem to implementovat. Takže nevím, neumím na to odpovědět.
Ano, problém jsou především sériová čísla.A co tenhle pristup: 1) Mame uzivatelsky zonovy soubor (treba v /etc/..., nepodepsany) a interni zonovy soubor (treba ve /var/..., automaticky podepsany). Uzivatelsky zonovy soubor demon nemodifikuje (jen ho cte), na interni zonovy soubor by zas nemel sahat uzivatel. 2) Uzivatelsky zonovy soubor *neobsahuje* seriove cislo, management serioveho cisla je plne v rezii demona (a je ulozeno v internim zonovem souboru). 3) Pri startu ci pozadavku na reload zony demon pozna, zda doslo ke zmene uzivatelskeho zonoveho (napr. podle timestampu, hashe ci porovnani s prislusnou cast interniho zonoveho souboru), v takovem pripade si updatuje interni kopii, vygeneruje podpisy a zvysi seriove cislo.
2) Uzivatelsky zonovy soubor *neobsahuje* seriove cislo, management serioveho cisla je plne v rezii demona (a je ulozeno v internim zonovem souboru).To by se mi hodně líbilo. Spravovat sériové číslo v texťáku je věc, která mě na BINDu nejvíc nebaví.
Uzivatelsky zonovy soubor *neobsahuje* seriove cislo, management serioveho cisla je plne v rezii demonaTam může vzniknout problém, pokud se přechází z jiného serveru. Chtělo by to umět KnotDNS říct alespoň počáteční sériové číslo. Nebo pokud by někdo chtěl provozovat různé servery vedle sebe stále a chtěl je mít na sobě úplně nezávislé (tj. i data synchronizovat přes zdrojové zónové soubory). Každopádně pro běžný provoz by tenhle způsob byl podle mne nejjednodušší.
Chtělo by to umět KnotDNS říct alespoň počáteční sériové číslo.To lze osetrit tak, ze pokud by v uzivatelske zone seriove cislo bylo uvedene, tak by ho demon vzal jako dolni mez a pripadne realne seriove cislo navysil.
Nebo pokud by někdo chtěl provozovat různé servery vedle sebe stále a chtěl je mít na sobě úplně nezávislé (tj. i data synchronizovat přes zdrojové zónové soubory).V takovem pripade by je uzivatel nemel provozovat v rezimu, kdy si sami upravuji zonu (napr. podepisuji).
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
6.6.2014 11:18
6.6.2014 11:36
6.6.2014 15:54